"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. This is a good material. The information here should reach the end users who will be exposed to these new features in the documentation patch before the final submission. > 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 Just to avoid confusion by making sure I understand. Earlier you said two plus an observer above but the example is about one observer and three other repositories, and the "merge" operation happens inside the observer's one. This reminds me of an ancient message I sent to darcs list, before or soon after I took git.git over, with a topic (iirc) "mutually supervised developer workflow". Each developer may make excellent and crap changes, but they communicate with each other. The "consensus" can be made by picking the changes that appear in all repositories (or majority of repositories). That is unfortunately hard to arrange in git workflow if you do not use topic branches and/or if you rebase often (but would be more natural match to darcs's world view). Even if you have a set of changes in the same spirit (i.e. "the same patch text"), the committer and the author information would make the actual commit objects different, so you would need to identify different commits that introduce the same change for this to be really useful. And it may not work well in practice, even if we somehow solved that "changes in the same spirit are often made into different commits" issue. If the place they agree last is a dud, and some have fix-ups that others lack, the observer will end up getting that common dud commit. > 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 If --ff=common fast-forwards to the commit all of X, Y, and Z have in common, that means commits on X, Y or Z that are beyond that point are the ones these three do not agree with. How's that different from --ff=fork? > 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. "Any given path up to one of the true parents?" Path from where? How is "true parent" (as opposed to untrue ones?) defined? > 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. Sorry, I referred --ff=traditional by "it". Are we talking about the same thing? - 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
