Re: [RFC/PATCH] Fast forward strategies only, common, fork and path
- From
Sverre Hvammen Johansen <hvammen@gmail.com>
- Date
- Feb 5, 2008, 07:32 UTC
- Message-ID
- <402c10cd0802042332i4e49cdaxf1fa1a7fc09c15b9@mail.gmail.com>
- In-Reply-To
- <7v8x21ku6b.fsf@gitster.siamese.dyndns.org>
On Feb 4, 2008 12:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 5 quoted lines
> > 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.
This + only are all the interesting cases for fast forward. Some work flows between more than two repositories in the general case would require additional features for rebase: Rebase on any patch, the fork point, or common ancestor of the remote branches. This is something I would like to discuss at some later time.
> > --ff=never will turn this off together with fast forward. Maybe we > > should have --ff=traditional that is the old behavior. > > Sure, and I mildly suspect that it should be the default.
I would argue that it should not be the default, simply because we already use the real parents when only two branches are involved, This is most convenient for most users. Exactly the same argument holds when there are more than two branches involved. The history may be simplified in a similar way. Most projects would however not care simply because they never merge more than two branches. It is quite common to have one topic branch that is based on the tip of another topic branch and if those are merged back to the main branch you would like it to be reduced down to two real heads (or even a fast forward), exactly as one branch would result in a fast forward if it happened to be based on the tip of master.
-- Sverre Hvammen Johansen