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

[Jakub Narebski <jnareb@gmail.com>]

"Sverre Hvammen Johansen" <hvammen@gmail.com> writes:

> On Feb 4, 2008 12:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > 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