Re: GIT 0.99.7d, and end of week status.

From: Junio C Hamano <junkio@cox.net>
Date: Sep 26, 2005, 22:03 UTC
Message-ID: <7vr7bba3lo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1127765852.5735.36.camel@cashmere.sps.mot.com>

Jon Loeliger <jdl@freescale.com> writes:

There is a small problem in that proposal. "Merging" in git does not work that way. Specifically,

>     # When merging, merge origin, maint and pu into master
>     Merge: master origin maint pu
>     # Merge into master the just the origin bits
>     Merge: master origin

the problem with these is that you may be in your "test" branch and say "git pull". 'git pull' does not let you say 'pull into this branch which is not my current branch', and "into master" part would not work -- merge in git always merges things into the current branch, so writing

>     # When merging, merge origin, maint and pu into the current
>     Merge: origin maint pu
>     # Merge just the origin bits into the current
>     Merge: origin

may make sense.

Having said that I doubt Octopus is what people do regularly, so being able to write "Merge: origin maint pu" (or "Merge: ncq chs-support") as a short-hand makes much sense.

There is not much inherent reason to require that the merge happens only to the current branch, if we stop using the files in the working tree for resolving conflicts (either manually or automatically). We could rewrite 'git pull' like this:

 - have it take 'merge into this branch' parameter, defaulting
   to the current branch, or your "Merge: <into> <remote>..."
   proposal.

 - if the merge is not to happen in the current branch, then
   use a temporary index file and a temporary working directory
   to do the merge -- when manual conflict resolution is needed,
   ask the user to go to that temporary working directory and
   resolve conflicts there and make commits there.  The
   temporary working directory is actually cheap because we do
   not have to checkout all the paths -- only the paths involved
   in the merge.

I remember the merge Linus originally envisioned would have worked along the above lines, until he changed his mind around 2a68a8659f7dc55fd285d235ae2d19e7a8116c30 commit, beginning of June, for 1.0 (ewww, we were already aiming for 1.0 back then).

	http://marc.theaimsgroup.com/?l=git&m=111806925225305&w=2

declared the merge in separate directory is post 1.0 item, and I tend to agree with that. Most of the time you will be merging into the current branch, and otherwise you could make it so by switching to that branch before pulling.