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.
We've had a few discussions around the
office about this, but I'll comment here too.
This works as long as you are not trying to collaborate with other people. There are 5 of
us trying to use our analytics repository for development work. We are doing fake-scrum,
and every day we talk about what has been worked on. We are using git/gerrit to share
this work. Committing often to only local branches doesn't help us for collaboration.
Roan and Ryan have helped us work out a workflow that will work for us decently. We can
push directly to the main repository when we need to, and use gerrit for all other times.
Depending on the changes, we'll end up reviewing code when it is first pushed to a
remote branch, OR later when it is merged into master. That way we only have to review
code at a single point, rather than multiple. This requires that everyone our in our team
is communicating and responsibly pushing for review. Our team is small so that's no
problem for us. But this will be a bigger problem for MediaWiki fo sho.
Thanks Antoine!
- otto
http://ottomata.com
http://www.flickr.com/photos/OttomatonA
http://www.couchsurfing.org/people/otto
On Feb 23, 2012, at 1:43 PM, Antoine Musso wrote:
> 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.
>
>
> :-)
>
> --
> Antoine "hashar" Musso
> Migration to French is not scheduled yet
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l