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

[Junio C Hamano <junkio@cox.net>]

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.