libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

git merging (was: [SCM] GNU Libtool branch, pr-msvc-support, updated.) v


From: Ralf Wildenhues
Subject: git merging (was: [SCM] GNU Libtool branch, pr-msvc-support, updated.) v2.2.6-93-g7b44e17
Date: Sat, 24 Jan 2009 15:25:15 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Ralf Wildenhues wrote on Sat, Jan 24, 2009 at 10:39:35AM CET:
> * Peter Rosin wrote on Fri, Jan 23, 2009 at 02:18:30PM CET:
> > The branch, pr-msvc-support has been updated

> >     Merge branch 'pr-changelog-libtool-ar' into pr-msvc-support

> >     Merge branch 'pr-changelog-embed-manifest-exeext' into pr-msvc-support
> [...]
> 
> Just as a minor note, it would not have been necessary to create a
> separate branch for each single ChangeLog entry.  You could have done
> them all on one pr-fix-changelog-entries branch.  :-)
> But it really doesn't matter much.

Ahh, I didn't look properly.  You used one branch only, renamed it a few
times, and merged it several times.  This is all fine and well, but it
highlights one data point you may not be aware of:

"git merge" merges not just the tip of some branch, it adds all changes
which are in the to-be-merged-branch into the current branch.  More
precisely, if you look at the directed graph of change history, then it
picks all changes from the branch for which there is no (directed) path
to the current branch tip yet.  This is why criss-cross merges work, and
this is one of the distinctive features you won't find in most other
version control systems.

Just thought I'd mention it.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]