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

Jon Loeliger [off-list ref] 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.

Dear diary, on Tue, Sep 27, 2005 at 12:03:47AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...

 - 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.

By the way, this is how Cogito did merging for some (rather short) time
period (actually, there's perhaps still some remnant of this, I think
Cogito still by default ignores ,,merge* which was the subdirectory
where the merge happenned). I removed it because IIRC the people weren't
eventually all that excited about it after all and Linus changed his
mind too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.