On Feb 5, 2008 1:40 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. There need to be at least 2 + 1. There is no difference between --ff=common and --ff=path when there are 2+1. I used 3+1 in the examples. > 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 I have no intention of doing that. This patch will keep it simple. I imagine that these features will not be used by most users and we should probably not document them in the tutorials. > > 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? Lets say X is on the path before the fork point before Y and Z. X is then the common ancestor, otherwise there will not be any difference. > > 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? The path from HEAD. Consider a number of distinct parents, then we can define it as follows. An untrue parent is a parent that can be fast forwarded to at least one other parent. A true (or real) parent is a parent that can not be fast forwarded to any other parent. > > 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? What I mean is that the commit should only record the true parents. That may already be the case by use of git show-branch --independent. I am not sure what that option does. However, the merge strategy itself is picked based on the parents specified. That part need to change. It could be that the patch could use the above option to find the true parents. Someone need to explain to me exactly what that option does. I am not exactly sure how a work flow between commiters would be. With one coordinator it would be as follows. The coordinator would merge using any of the --ff options. He would use --ff=same, --ff=only, or --ff=common if everyone needs to agree. He would use --ff=fork when less care needs to be taken and --ff=path when he essentially don't care. Everyone else needs to rebase on his work or something else based on his work. --ff=same is not included in the patch. It requires everyone except for HEAD to point to the same commit. I am really busy for about three weeks and will not be able to do much before beginning of March. -- Sverre Hvammen Johansen - 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
