git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Thomas Rast <trast@inf.ethz.ch>
Date
Jun 16, 2013, 11:08 UTC
Message-ID
<87ip1e2tzx.fsf@hexa.v.cablecom.net>
In-Reply-To
<7vk3lvlmat.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 42 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 7 of 23 in “rebase --autosquash does not handle fixup! of fixup!”
  1. Andrew PimlottJun 11, 2013
  2. Thomas RastJun 11, 2013
  3. rebase -i: fixup fixup! fixup!Andrew Pimlott, Jun 14, 2013
  4. Andrew PimlottJun 15, 2013
  5. Junio C HamanoJun 15, 2013
  6. Junio C HamanoJun 16, 2013
  7. Thomas RastJun 16, 2013
  8. Junio C HamanoJun 17, 2013
  9. Thomas RastJun 17, 2013
  10. Junio C HamanoJun 17, 2013
  11. Andrew PimlottJun 25, 2013
  12. Junio C HamanoJun 25, 2013
  13. Andrew PimlottJun 25, 2013
  14. Junio C HamanoJun 25, 2013
  15. Junio C HamanoJun 25, 2013
  16. Junio C HamanoJun 25, 2013
  17. Andrew PimlottJun 25, 2013
  18. Andrew PimlottJun 26, 2013
  19. Junio C HamanoJun 26, 2013
  20. Andrew PimlottJun 27, 2013
  21. Andrew PimlottJun 27, 2013
  22. Junio C HamanoJun 27, 2013
  23. Andrew PimlottJun 28, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.