Re: [RFC/PATCH] Fast forward strategies only, common, fork and path

"Sverre Hvammen Johansen" [off-list ref] writes:

On Feb 4, 2008 12:22 AM, Junio C Hamano [off-list ref] wrote:

quoted

The documentation updates talked about what the options do, but
it was unclear why they could be useful in what situations and
workflows.  At least it was not apparent to me on my cursory
read.

Common, fork, and path only make sense where there are at least three
repositories or two plus an observer involved.

Lets explain the observer cases.

The observer is interested in changes that X, Y and Z agree upon.  He
can merge as follows:

  git merge --ff=common X Y Z

The observer is interested in changes up to the point where someone is
known to disagree.  He can merge as follows:

   git merge --ff=fork X Y Z

 The observer is interested in any give path up to one of the true
parents.  He can merge as follows:

  git merge --ff=path X Y Z

This will give priority to X then Y.

Could you please provide ascii-art diagrams for above explanations
(above cases), such as the following diagrams for fast-forward, and
for forced merge (no fast-forward)? This would make your explanations
much easier to follow, I think.


1. Fast-forward ("traditional", 2 heads)

   before merge

   a---b---c---d               <-- main
                \
                 \-E---F---G  <-- side


   after merge

   a---b---c---d---E---F---G  <-- main
                           ^
                            \----- side

2. Forced merge commits ("never", 2 heads)

   before merge

   a---b---c---d               <-- main
                \
                 \-E---F---G  <-- side


   after merge

   a---b---c---d-------------*  <-- main
                \           /
                 \-E---F---G    <-- side


-- 
Jakub Narebski
Poland
ShadeHawk on #git