www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: [1/2] git commit: f92a685 -
Date Mon, 11 Jun 2012 05:13:25 GMT
+1 agree with push over commit notifications for the mailer. Also making
the *branch* the commits are against top-level information is important :)

As for using rebase vs. merge for your work on a branch, I think it comes
down to the question of "who will handle the (potential) merge hell?"
There is a good discussion on stackoverflow regarding when to use merge
vs. rebase [1]. There are times for both. For large feature branches that
evolve over longer spans of time, it may sometimes be easier to focus
changes within a single isolated branch that gets merged in at some point
in the future. This puts the onus of resolving the merge in the hands of
the reviewer/committer who will merge the changes in. Rebasing during a
feature branch's evolution puts the merging onus on the contributor
working on the feature, as merges get resolved then.

In the end, accepting a patch that is up-to-date with the master's HEAD is
trivial for a committer. Merging a divergent branch trickier. As such my
rule of thumb is branch, commit, and rebase often (especially right before
putting the branch up for review).

[1] 
http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-
questions

On 6/6/12 5:12 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Tue, Jun 5, 2012 at 8:51 PM, Joe Schaefer <joe_schaefer@yahoo.com>
>wrote:
>> Merge commits do peculiar things- part of what happened
>> is that I committed my change locally first, then pulled
>> to sync up with the central repo, then pushed back.  Somehow
>> history gets reordered and that is supposed to be reflected
>> in these merge commit notices.
>
>Diffs of merge commits are tricky as you'll either need to specify
>against which one of the two or more parent commits you're doing the
>diff, or use a three- or many-way diff notation to express all the
>changes included in the merge.
>
>A better approach IMHO is to send *push* instead of *commit*
>notifications. The notification message includes a log of all the
>commits being pushed, and a diff between the old and the new state of
>the pushed branch. This is closer to the way svn commit notifications
>work.
>
>I wrote a script for doing that for our Git repositories at work, and
>I can adjust it to work also for Apache if there's interest.
>
>BR,
>
>Jukka Zitting


Mime
View raw message