On 2018-05-09 03:46 PM, Ilya Kantor wrote:
I tried to compare --force-rebase VS --no-ff for the following repository:
http://jmp.sh/E7TRjcL
There's no difference in the resulf of:
git rebase --force-rebase 54a4
git rebase --no-ff 54a4
(rebases all 3 commits of feature)
Also, there's no difference in interactive mode:
git rebase --force-rebase -i 54a4
git rebase --no-ff -i 54a4
(picks all 3 commits of feature)
Is there a case where --no-ff differs from --force-rebase?
So now that "rebase -i" respects --force-rebase, the question is what to
do about it:
1. Teach "rebase -i" to stop respecting --force-rebase (restoring the
original intent when --no-ff was introduced)?
2. Deprecate --no-ff?
3. Deprecate --force-rebase?
As a heavy rebase user, I find --no-ff more intuitive than
--force-rebase. I'd be in favour of option 3, and keeping just --no-ff
(with -f as a synonym).
M.
---
Best Regards,
Ilya Kantor
On Wed, May 9, 2018 at 10:27 PM, Marc Branchaud <marcnarc@xxxxxxxxxxx> wrote:
On 2018-05-09 02:21 PM, Stefan Beller wrote:
+cc Marc and Johannes who know more about rebase.
On Wed, May 9, 2018 at 9:01 AM, Ilya Kantor <iliakan@xxxxxxxxx> wrote:
Right now in "git help rebase" for --no-ff:
"Without --interactive, this is a synonym for --force-rebase."
But *with* --interactive, is there any difference?
I found
https://code.googlesource.com/git/+/b499549401cb2b1f6c30d09681380fd519938eb0
from 2010-03-24
In the original discussion around this option [1], at one point I proposed
teaching rebase--interactive to respect --force-rebase instead of adding a
new option [2]. Ultimately --no-ff was chosen as the better user interface
design [3], because an interactive rebase can't be "forced" to run.
At the time, I think rebase--interactive only recognized --no-ff. That
might have been muddled a bit in the migration to rebase--helper.c.
Looking at it now, I don't have a strong opinion about keeping both options
or deprecating one of them.
M.
[1] https://public-inbox.org/git/4B9FD9C1.9060200@xxxxxxxxxxx/t/
[2]
https://public-inbox.org/git/1269361187-31291-1-git-send-email-marcnarc@xxxxxxxxxxx/
[3] https://public-inbox.org/git/7vzl1yd5j4.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/
Teach rebase the --no-ff option.
For git-rebase.sh, --no-ff is a synonym for --force-rebase.
For git-rebase--interactive.sh, --no-ff cherry-picks all the commits
in
the rebased branch, instead of fast-forwarding over any unchanged
commits.
--no-ff offers an alternative way to deal with reverted merges.
Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the
branch
with entirely new commits (they're new because at the very least the
committer time is different). This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly. Added
an
addendum to revert-a-faulty-merge.txt describing the situation and
how to
use --no-ff to handle it.
which sounds as if there is?
Stefan
