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

[Thomas Rast <trast@inf.ethz.ch>]

Junio C Hamano <gitster@pobox.com> writes:

> Andrew Pimlott <andrew@pimlott.net> writes:
>
>> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
>>> It happened to work and I added a test.  But then it occurred to me that
>>> it might have been better to fix commit --fixup/--squash to strip the
>>> fixup! or squash! from the referenced commit in the first place.
>>> Anyhow, below is my patch for --autosquash, but unles someone has an
>>> objection to doing it in commit, I'll work on that.
>
> Is it always true that you would squash and fixup in the same order
> as these follow-up commits happened?
>
> That is, if you did this (time flows from top to bottom):
>
> 	1 A
>         2 B
>         3 fixup A
>         4 squash B
>         5 fixup fixup A
>         6 fixup A
>
> I am wondering if applying 6 on top of 5 is always what you want, or
> you would want to apply it to 3 instead.  Otherwise you would have
> written
>
> 	6 fixup fixup fixup A
>
> instead.
>
> The two reordering possibilities are:
>
>         1 A                        1 A             
>         3 fixup A                  3 fixup A       
>         5 fixup fixup A            6 fixup A       
>         6 fixup A                  5 fixup fixup A
>         2 B                        2 B             
>         4 squash B                 4 squash B      
>
> If you strip out the prefix when you make commits, you may lose the
> information if you want to use in order to express these different
> orders.  I am not sure if it matters in practice, but I am not yet
> convinced it is a good idea.

Isn't it a bit of an academic question?

All 'fixup* A' are clearly intended to be squashed into A eventually.
You could reorder them, but unless you arranged your fixups as nonlinear
history (does anyone do that?) they have been built sequentially.  So at
best the extra reordering does not buy you anything, because you're
going to fix up A anyways.  You may even get extra conflicts during the
reordering, which make the process less automatic and more error-prone.

  [If you did actually arrange things nonlinearly, so that you have

    * A
    |\
    | * fixup A
    | |
    * | fixup A
    |/
    * M  (you need M so that you can rebase both fixups simultaneously)

  then you might actually use the number of 'fixup' prefixes to determine
  their order.  However, if you actually generate such history, you have
  to go out of your way to look at the other branches too, and make sure
  that the number of prefixes is sufficiently unique to disambiguate the
  order as far as you want it to do that, etc.  It sounds like too much of
  a headache to be worth using like that.]

And once you have that, it seems a nicer and cleaner idea to generate
'fixup! A' each time, instead of a successive sequence of

  fixup! A
  fixup! fixup! A
  fixup! fixup! fixup! A
  ...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch