www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [1/2] git commit: f92a685 -
Date Mon, 11 Jun 2012 06:53:48 GMT
merge vs rebase mostly comes down to basically one question: did someone rely on your intermediate
results? Did you share this work with others?

If so, a rebase is mostly out of question as it will trash all those 'downstream' repos of
the folks you collaborated with. If those are only a few well known colleagues then they might
git reset --hard to the last common ancestor and grab the history tree from you again. But
in general this is not working friction free if you have pushed your work to a public repo
already.


LieGrue,
strub

>________________________________
> From: Filip Maj <fil@adobe.com>
>To: "infrastructure-dev@apache.org" <infrastructure-dev@apache.org> 
>Sent: Monday, June 11, 2012 7:13 AM
>Subject: Re: [1/2] git commit: f92a685 -
> 
>+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