"Sverre Hvammen Johansen" <hvammen@xxxxxxxxx> writes:
> @@ -133,6 +133,47 @@ merge (which is typically a fraction of the whole
> tree), you can
> have local modifications in your working tree as long as they do
> not overlap with what the merge updates.
>
> +If more than one commit are specified for the merge, git will try to
> +reduce the number of commits (real parents) by eliminating commits
> +than can be reached from other commits...
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?
> +... The commit message will
> +reflect the actual commits specified but the merge strategy will be
> +selected based on the real parents, but always including `HEAD`....
Now your terminology gets the other way around and reduced ones are called
"real" and the earlier "real parents" are now called "actual".
I think "real" vs "actual" is an invitation for "which is which"
confusion. How about calling them "given" vs "reduced"?
Anyway, "the commit log message talks about the commits specified by the
end user, but the command outsmarts the user and does something different".
> +... 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.
> +The following shows master and three topic branches. topicB is based
> +on topicA, topicA is previously branched off from master, and topicC
> +is based on the current `HEAD` of master:
We do not say "HEAD of branch". HEAD spelled in all capital always means
"that pointer thing directly under $GIT_DIR that typically talks about
which branch we are on but sometimes can be detached to name a commit
directly." Call it the "tip of the master branch".
> +------------
> + o---o---o topicB
> + /
> + o---o---o topicA
> + /
> + o---o---o---o---o---o master
> + \
> + o---o topicC
> +------------
> +
> +A merger of master with topicA, topicB, and topicC will select the
"Merging topicA, B and C to the master branch will select" may be easier
to understand.
> +merge strategy based on the three branches master, topicB, and topicC
> +(topicA is eliminated since it can be reached from topicB). topicB
> +and topicC are the only real parents and are therefore the only
> +parents recorded in the merge commit object:
> +------------
> + % git checkout master
> + % git merge topicA topicB topicC
Please do not use C-shell in our examples.
> +
> + o---o---o topicB
> + / \
> + o---o---o topicA \
> + / \
> + o---o---o---o---o---o o master
> + \ /
> + o---o topicC
> +------------
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.
> diff --git a/git-merge.sh b/git-merge.sh
> index 2acd2cc..5398606 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -209,24 +209,41 @@ parse_config () {
> ...
> + # This will preserve the order the user gave.
> + ff_head=${real_parents%%$LF*}
"%%$LF*"? Heh, that's clever.
--
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
