"Sverre Hvammen Johansen" <hvammen@xxxxxxxxx> writes:
> On Feb 4, 2008 12:22 AM, Junio C Hamano <gitster@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
