Thread (1 message) 1 message, 1 author, 2016-06-15

Re: rebase flattens history when it shouldn't?

From: Sergey Organov <hidden>
Date: 2016-06-15 23:02:08
Subsystem: documentation, the rest · Maintainers: Jonathan Corbet, Linus Torvalds

Possibly related (same subject, not in this thread)

Jonathan Nieder [off-list ref] writes:
Hi Sergei,

Sergei Organov wrote:
quoted
     --C--
    /     \
   /   ----M topic,HEAD
  /   /
 A---B master

shouldn't

$ git rebase master

be a no-op here?
[...]
quoted
I'd expect --force-rebase to be required for this to happen:

-f, --force-rebase
    Force the rebase even if the current branch is a descendant of the
    commit you are rebasing onto. Normally non-interactive rebase will
    exit with the message "Current branch is up to date" in such a
    situation.
[...]
quoted
Do you think it's worth fixing?
Thanks for a clear report.

After a successful 'git rebase master', the current branch is always a
linear string of patches on top of 'master'.
Is this documented? Except implicitly by the: 

-p, --preserve-merges
           Instead of ignoring merges, try to recreate them.

??

Anyway, why such a requirement, and is it actually enforced by tests?
The "already up to date" behavior when -f is not passed is in a
certain sense an optimization --- it is about git noticing that 'git
rebase' wouldn't have anything to do (except for touching timestamps)
and therefore doing nothing.
Maybe, but I'd argue it's rather sane behavior to do no rebase when new
rebase point is the same as original in general. I.e., when "current
branch is a descendant of the commit you are rebasing onto", as
documentation says.
So I don't think requiring -f for this case would be an improvement.
I still do, as it will match documentation, that in turn looks
reasonable.
I do agree that the documentation is misleading.
If the problem is in documentation, it's not only misleading, it's
formally wrong.
Any ideas for wording that could make it clearer?
Well, if it's indeed documentation, how about this:
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2a93c64..62dac31 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -316,10 +316,9 @@ which makes little sense.
 
 -f::
 --force-rebase::
-	Force the rebase even if the current branch is a descendant
-	of the commit you are rebasing onto.  Normally non-interactive rebase will
-	exit with the message "Current branch is up to date" in such a
-	situation.
+	Force the rebase even if the result will only change commit
+	timestamps. Normally non-interactive rebase will exit with the
+	message "Current branch is up to date" in such a situation.
 	Incompatible with the --interactive option.
 +
 You may find this (or --no-ff with an interactive rebase) helpful after
BTW, why "Incompatible with the --interactive option."? Isn't "force"
assumed by --interactive, functionally?

-- 
Sergey.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help