On 11/15/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Full ACK from a platform integrator's perspective. Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible. It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.
I don't have to manually log the _mechanical_origin_ of a given delta;
git does that for me, and mostly just DTRT when the same delta arrives
via several paths. When I use git pull from a remote branch (with or
without an entry in remotes/heads, which for this purpose is just
shorthand), I don't have to manually log what conflicts I have and
haven't resolved, either; I must have assimilated whatever I cared
about in the remote branch's history up to that point, because as long
as there are things in that remote branch that I haven't decided how
to handle, I stick to cherry-picking.
Obviously, fetch to local space is great (especially when you spend
some of your working hours behind a firewall that blocks outbound TCP
9418). Fetch from local space is also great, when the local space you
are fetching from reflects local work (such as a sync point and
reconciliation of several upstream sources, which then needs to be
ported forward or back to the chosen core version for each platform).
Fetch from a local space that is just a tracker for remote work is not
great, because it doesn't capture the editorial decision implied by a
remote pull: I looked at what the remote branch had to offer as of
this date, systematically decided which bits did and didn't belong in
the branch to which I was pulling, and pulled.
The record of that pull becomes a first-class object because it's
attached to an actual content delta in the target branch. So it
propagates into branches that pull from it. Pulling this delta into
another branch is different from cherry-picking a feature delta; it
implies acceptance of the reconciliation and editorial work associated
with the merge in the source branch.
Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion. But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.
Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html