On Wed, Mar 26, 2008 at 9:17 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > In 3/4 you defined "real parents" as "the commits specified to be merged > from the command line", and you are picking only the independent ones out > of "real parents" to change the set of parents used for the merge > operation. What is the reduced set called? I was not happy about the split. 2/4 does not make much sense until you read 3/4, and when you read 3/4 you are confused by 2/4. Is it OK that I squash these together again? > I think "real" vs "actual" is an invitation for "which is which" > confusion. How about calling them "given" vs "reduced"? Agree. But reduced may not be reduced if --ff=never is specified. > Anyway, "the commit log message talks about the commits specified by the > end user, but the command outsmarts the user and does something different". This is also the current behavior of git and I don't think anyone have complained about it until now that we realize how git is actually doing this. We want the history to be as simple as possible when presented in gitk, but the commit message should record what the user asked for. The commit message is used for later refferense. The commit message will usually only contain branch names which may or may not make sense when we later look back the history. That two branches happen to point to the same commit or one is a fast forward of the other is just a coincident. I believe this is how most users want it and I don't intend to change the log message. > > +... The > > > +real parents (only including `HEAD` if it is real) are the parents > > +recorded in the merge commit object. > > Specifically, "does something different" above is "does not record some of > the commits given by the end user as parent commit of the resulting > merge". Hence the name of the operation: "head reduction". > > While I suspect that it would make sense to simplify parents, I do not > see why the seemingly deliberate discrepancy between what is recorded as > the parents (i.e. "reduced parents" on "parent " lines of the resulting > merge) and what the log message talks about (i.e. "given parents" you feed > to fmt-merge-msg) is a good idea. Isn't it more consistent and easier to > explain to the users if they match? Also it might be arguable that this > head reduction should be an optional feature. If you use --ff=never it is turned off. > I suspect this would be a _very_ unexpected behaviour to untrained eyes > and would be a source of confusion. You were on 'master' and merged many > things into it, but the resulting commit does not have 'master' as its > first parent. So far, ORIG_HEAD would always have matched HEAD^1 unless > you fast-forwarded. This alone may be a reason enough that this behaviour > can never be the default. I am not sure we need to explain this in the manual. What do you think? This behavior is also the current behavior of git. I don't think we should care. When we fast-forward, HEAD^1 may not match ORIG_HEAD anyway. -- 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
