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

Re: [RFC/PATCH 1/2] rebuash - squash/rebase in a single step

From
Johannes Sixt <j6t@kdbg.org>
Date
Jul 2, 2019, 19:30 UTC
Message-ID
<e8a39f00-7f88-7c32-ac18-12f17faf2c72@kdbg.org>
In-Reply-To
<xmqqr2784alt.fsf@gitster-ct.c.googlers.com>
Am 02.07.19 um 19:20 schrieb Junio C Hamano:
Show 30 quoted lines
> Derrick Stolee <stolee@gmail.com> writes:
> 
>> On 7/1/2019 2:35 PM, Junio C Hamano wrote:
>>> Jeff King <peff@peff.net> writes:
>>>
>>>>> First, we create a (temporary) merge commit of both branches (M3)
>>>>>
>>>>> ------------
>>>>> 	R1---R2---R3---R4---R5---R6---R7---M3
>>>>> 	 \         \              \       /
>>>>> 	  F1---F2---M1---F3---F4---M2---F5
>>>>> ------------
>>>>>
>> ...
>>> If M3 merge is always easier to manage than incremental stepwise
>>> rebase of the topic, then doing the "git merge --reverse-squash"
>>> would be a saner interface and also conceptually simpler.
>>
>> I agree that this would be a better way to expose this behavior,
>> and likely the implementation could be very clean.
> 
> What I was sort-of hoping to get comments on was actually something
> else.
> 
> Would there be cases where the merge M3 gets unmanageably complex
> even if rebasing the feature commits one by one is relatively simple
> (and how often would that happen)?  "merge --squash" would not work
> well (and extending the command to merge in a different direction
> would not help) in such a situation, but "rebase -i" would work
> much better (and "imerge" would, too).

I've come across the situation occasionally. Once I have resolved a bunch of conflicts in M1 and M2, I think twice whether I should rebase individual commits; it is typically much more tedious.

A common situation is that a line is "A" in F1, "B" in F2, and "C" in R3; then I have to resolve ONE conflict in M1 ("<B=C>"), but with individual commits rebased on top of R3, I have two conflicts, "<C=A>" and "<AC=B>", neither of which is helped by rerere.

After merges M1 and M2, it is all a done deal, and M3 is typically a much simpler merge than the sum of conflicts incurred by the individual commits. I would generally not recommend a rebase in this situation.

But I wouldn't turn M3 into a squashed merged commit, either, as long as F1...F5 aren't messy.

-- Hannes
Previous: Junio C Hamano
Message 13 of 13 in “rebuash - squash/rebase in a single step”
  1. 1/2 rebuash - squash/rebase in a single stepEdmundo Carmona Antoranz, Jun 30, 2019
  2. 2/2 rebuash - support for statusEdmundo Carmona Antoranz, Jun 30, 2019
  3. Edmundo Carmona AntoranzJun 30, 2019
  4. Jeff KingJun 30, 2019
  5. Edmundo Carmona AntoranzJun 30, 2019
  6. Jeff KingJun 30, 2019
  7. Edmundo Carmona AntoranzJul 1, 2019
  8. Junio C HamanoJul 1, 2019
  9. Edmundo Carmona AntoranzJul 1, 2019
  10. Junio C HamanoJul 1, 2019
  11. Derrick StoleeJul 2, 2019
  12. Junio C HamanoJul 2, 2019
  13. Johannes SixtJul 2, 2019

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.