Petr Baudis <pasky@xxxxxxx> writes:
> * The branch was created long ago, but has merged latest changes of the
> top of HEAD in, and now the branch is merged back, that's a "bad
> fastforward" since that flips the perspective of main-vs-topic branch.
>
> I feel that it's important to point out this caveat.
Ah, I thought you were contrasting between ff and non-ff, but instead you
were giving caveat about trusting "fast-parent", which I didn't realize.
Yeah, but in general, unless it is the final merge to consolidate the work
on the topic to mainline that was delegated by the mainline maintainer to
the topic person, merging _from_ mainline _to_ topic should rarely happen.
And when it happens, relying on the first-parent ancestry obviously breaks
down.
> I really dislike the "first-parent ancestry" wording, I think it muds
> down the whole issue.
I am not particularly fond of the wording, either, but any other word you
would use, you would need to explain the background information, i.e. how
and why the concept embodied by that other word you choose to use relates
to the "--first-parent" option.
You can for example say "the changes introduced to the mainline by each
commit" (and by "commit" we mean both single parent ones directly made
while the mainline was the current branch, and merges made into that
branch); you need to define what you mean by "the mainline", and what your
assumptions are about the workflow employed (e.g. "rarely if ever merge
goes the wrong direction").
>> > + else if (opt->first_parent_only) {
>> > + /* Generate merge log entry only for the first
>> > + * parent, showing summary diff of the others
>> > + * we merged _in_. */
>>
>> Style?
>
> What's wrong?
/*
* We prefer to write multi-line comments
* like this.
*/
--
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