Le 21/02/12 18:44, Andrew Otto a écrit :
[~/Projects/wm/analytics/reportcard] (master)[29c6b47]$ git-review You have more than one commit that you are about to submit. The outstanding commits are:
29c6b47 (HEAD, master) observation.py - comments 14a771a test commit for git branch push 73dd606 Buncha mini changes + hackiness to parse a few things. This really needs more work 2d37c13 pipeline/user_agent.py - adding comment that this file should not be used 5892eb8 Adding loader.py - first hacky loader, just so we can get some data into mysql to work with. e3fb30b Renaming the concept of variables to 'traits'. Allowing trait_sets to be specified so that we don't record HUGE amounts of data. d0de74b base.py - adding schema in comments. Got lots of work to do to make this prettier 328e55d Trying my darndest to clean things up here! I've cloned a new repo, and am checking in my non-committed (an non-approved?) changes into this new branch. Hopefully gerrit will be happier with me.
This smells of me doing something really wrong.
It seems to be a git-review safe guard to prevents someone from sending several commits. Each of them would make Gerrit generates several changes. To those wondering why one would have multiple commits, three use cases come to mind.
I will give you the solution at the end of this post.
1) high frequency tradin^H^H^H^H^H^H committing
Some people, me for example, do local commits very often, then squashes them before submitting the final patch. Git squashing means regrouping multiples commits in just one. Imagine I have made 4 commits locally, possibly using my mother tongue (french), in such case, using git-review will have me submitting a commit list like:
abcde1 oh mygod d30909 variable fun f39004 je ne sais plus ce que c'est 439090 before lunch
f39004 is some French meaning "I don't remember what was that" which does not describe the commit change (hint: using French will be perfectly valid once we start migrating from English).
Anyway, git-review would generates 4 changes out of the 4 commits above. Not that helpful is it?
Instead I would have wanted to regroup them and write a nice commit description. For example:
30490 (bug 1234) fix issue in feature foobar
2) newbie spamming gerrit
This happen when you first play with Gerrit.
In subversion world, whenever you submit a new patch (svn commit) it is going to be written down in the central repository. You will not be able to change it, hence any subsequent submission based on it are guaranteed it is not going to change.
In git world, as I understand it, each commit as a parent commit. The reference is a sha1 based on the content of the commit. Whenever you change a commit, every children, grand-children .. will have their sha1 recomputed.
Enter in Gerrit world, when we send a commit in a queue, there is no guarantee that commit will end up in the reference repo. It might be amended or simply rejected. So your list of commit will be recomputed and all child / grand children will need to be resubmitted.
Guess that? That will update of all those Gerrit changes, making mass email spam / jenkins rebuild etc.
3) mixing features
You could well be mixing two different changes. Maybe you have made a commit to fix bug 1234 and two days later a fix for bug 6789. Those should really be two different changes.
In conclusion, it is best to use a local branch for any bug / feature you might be working on actually. Branches are cheap in git, they are just a pointer. Once you are happy with your small branch, squash the commits and submit the end result. Less changes, less spam.
If you really want to *spam* force git-review to do it with a yes card:
$ git-review --yes
But you probably want to use branch / squash instead.
:-)