Junio C Hamano <gits...@pobox.com> writes:
> Junio C Hamano <gits...@pobox.com> writes:
>> So I think the reasoning (i.e. "is a descendant" is not quite right)
>> is correct, but the updated text is not quite right. Changing it
>> further to "only the committer timestamps and identities would
>> change" is probably not an improvement, either. "Force the rebase
>> that would otherwise be a no-op" may be a better phrasing that does
>> not risk going stale even if we update what are preserved and what
>> are modified in the future.
>> Also I notice the sentence "Normally non-interactive...in such a
>> situation" is not helping the reader in this description very much.
>> I wonder if we should keep it if we are rewriting this paragraph.
> How about doing it this way, perhaps?
> - Force the rebase even if the current branch is a descendant
> - of the commit you are rebasing onto. Normally non-interactive rebase
> - exit with the message "Current branch is up to date" in such a
> - situation.
> - Incompatible with the --interactive option.
> + Force a rebase even if the current branch is up-to-date and
> + the command without `--force` would return without doing anything.
> You may find this (or --no-ff with an interactive rebase) helpful after
> reverting a topic branch merge, as this option recreates the topic branch
It's OK with me, as in fact I think that there is no good explanation
for current git behavior, and thus it's git behavior that should have
been changed, not the documentation. I.e., git must not rebase anything
when "Current branch is a descendant of the commit you are rebasing
onto", unless -f is given. Simple, reasonable, straightforward.
The version you propose at least does not lie, so it's definiteley an
"Force the rebase when the command exits with "Current branch is up to
reads even more simple and clear for me.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html