Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

Re: [PATCH] rebase -i: fixup fixup! fixup!

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:55

Possibly related (same subject, not in this thread)

Andrew Pimlott [off-list ref] writes:
I agree that it is better to preserve information as long as feasible.
If we are going to strip it, it may as well be later.  That is Thomas's
rearrange_squash patch, which I will send again.
Thanks.
The next question is, do we go all the way and respect the nested
fixup!s in rearrange_squash?  I understand the case for it, though it's
hardly compelling to me in practice. :-)  That would be more complicated
than Thomas's patch.  But I'm happy to try it if someone gives me a
nudge.  If not, at least the information is preserved in case someone
wants to do this later.
I think it is fine not to be too smart, as long as we do not lose
information that would help the user to compensate.

After all, autosquash will give the user an opportunity to eyeball
the result of automatic rearrangement.  If the user did this:

	git commit -m original
        git commit --fixup original ;# obviously fixing the first one
        git commit --fixup '!fixup original' ;# explicitly fixing the second
	git commit --fixup original ;# may want to fix the first one

and then "git rebase --autosquash" gave him this:

	pick d78c915 original
        fixup 0c6388e original
        fixup d15b556 !fixup original
        fixup 1e39bcd original

it may not be what the user originally intended, but I think it is
OK.

As long as "!fixup original" message is kept in the buffer, the user
can notice and rearrange, e.g.

	pick d78c915 original
        fixup 0c6388e original
        fixup 1e39bcd original
        fixup d15b556 !fixup original

if the user really wants to.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help