From: Junio C Hamano <junkio@cox.net>
Date: Fri, 27 May 2005 20:13:58 GMT
Subject: Re: More gitweb queries..
Message-ID: <7vu0kowho9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050527195552.GA6541@cip.informatik.uni-erlangen.de>

>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:

>> You merge by hand and resolve if they have conflicts, just like
>> what you already do in two head merge case.

TG> I see. Does that mean that 'git-ls-files --unmerged' will report upto 9
TG> stages per file?

No, I think my description was unclear.  You still merge two at
a time because that is what git-read-tree -m gives you (3-way
merge is between $(merge-base $A $B) and $A and $B so you are
merging two heads).

To confess, my workflow to merge with Linus is currently
primarily patch based, so I do not even use git-read-tree -m
3-way merge when I make an Octopus (for that matter, I do not
myself do Octopus at all these days).  When I have bunch of
independent changes, I would first prepare and test these:

           -- JC#1
          / - JC#2
         /  - JC#3
  Linus#1-  - JC#4  
         \    ...
          \-- JC#7

By the time I am done and happy with them, tip of Linus tree may
have already advanced and he is at Linus#2.  I would then apply
diffs between Linus#1 and JC#n (1 <= n <= 7) on top of Linus #2,
and commit the result with parents set to Linus #2 and JC#1,
JC#2, ..., JC#7.

           ------- Linus#2
          /               \
         / -- JC#1 --------\
        / /-- JC#2 ---------\ 
       / /--- JC#3 ----------\
  Linus#1---- JC#4 ---------- Octopus 
         \    ...            /
          \-- JC#7 ----------