Kurt Roeckx wrote:
> On Fri, Feb 12, 2010 at 05:26:40PM -0600, Jonathan Nieder wrote:
>> Suppose (where time flows left to right), I have this history:
>>
>> E -- F -- G [topic]
>> /
>> A -- B -- C -- D [master]
>>
>> If I am on branch master and use 'git merge topic', then all the
>> changes from A to G get applied to master to form the merge commit.
>>
>> So it is not clear to me what it means to merge only the last patch on
>> a branch.
>
> I'm not sure how this is done in git, but as far as I know, I've
> seen this done. It's basicly about backporting fixes from a
> master branch to one of the release/stable branches.
Oh! Thanks for clarifying.
In some projects, it makes sense to develop each fix on its own branch
based on a stable branch and then merge it into each integration
branch when it is ready. See gitworkflows(7).
Suppose, however, that yor project does not work that way, or you
have a fix that was never intended for a stable branch and you need to
backport it. For example, you might have a history like this
E -- F -- G --- H --- I --- ... [devel]
/
A -- B -- C -- D [stable]
and only the patch H is suitable for the stable branch; the rest of
the changes are not quite cooked yet.
Then while on the stable branch you use 'git cherry-pick H'. This
produces a history like so:
E -- F -- G --- H --- I --- ... [devel]
/
A -- B -- C -- D --- H' [stable]
where H' introduces the same change as H did.
In this case, git does not record for itself that this H' is based on
H. I think Subversion would have recorded this information and used
it for later merges, but in git the merge algorithm is not so far from
a simple three-way merge, and in particular it has no way to use
details like this one. If stable is merged to devel, that diff hunk
will be noticed to be the same for both branches, so unless something
else interesting happened nearby it will not produce a conflict.
Commands such as 'git rebase' that consider commits one by one, on the
other hand, will often notice that H and H' represent the same change,
even though that fact is not recorded. This magic is implemented
by the 'git patch-id' command.
A human might have very good reasons to be interested in the fact that
H' is based on H. The 'git cherry-pick -x' option is meant to record
this in the commit message and gitweb will treat the result as a link.
The 'git cherry' front-end to patch-id can also be helpful when
cherry-pick was used without -x.
Sorry for the information dump. With all that out of the way, I
wonder:
- Where do you think this kind of overview documentation could go
to make it easier to find?
- How should gitk help? For example, if gitk converted commit object
IDs to hyperlinks like gitweb does, would that help?
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
