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

Re: rebase -p loses amended changes

From
Jon Seymour <jon.seymour@gmail.com>
Date
Apr 3, 2012, 21:43 UTC
Message-ID
<CAH3Anrq_Z0V=DpU1iH-A3F8RFWTG0_C1hEe3iDZYe=AYDTRT3g@mail.gmail.com>
In-Reply-To
<CADb3U=4Y0njLiYC1qrYbdm+h0h8vLh78yfz_u3B6veEqCX0xCQ@mail.gmail.com>
On Wed, Apr 4, 2012 at 4:55 AM, J Robert Ray <jrobertray@gmail.com> wrote:
> On Sat, Mar 31, 2012 at 2:39 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> On Sat, Mar 31, 2012 at 8:35 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>>> Jon Seymour <jon.seymour@gmail.com> writes:
orrectness point of view.
Show 8 quoted lines
>
> I thought there would be more concern about the silent data loss.
> Instead of throwing away the amended changes I would prefer the rebase
> to at least fail, if not have the problem require manual conflict
> resolution.
>
> A warning at the time of the amend could confuse or scare users. But a
> mention of this problem in the rebase docs would help.

It'd be quite expensive to attempt to detect cases where this might be a problem, but let's articulate, as a thought experiment, what such a solution might look like - I am not suggesting that it is a good idea, but the thought experiment might be illustrative.

Suppose you have a merge of a A and B that produces M, which is then amended as M'.

During rebase, you redo the merge A and B. If there are no conflicts, then compare M with M' to produce D. You now have enough information to reproduce the amended commit M' during a rebase (merge Ar and,Br then apply D).

What isn't clear to me, in this thought experiment, is how you might attempt to solve the case where there were syntactic (as opposed to semantic) conflicts between the merge of A and B originally. You have no idea, at that point, how the user originally resolved the conflicts to produce M, thus no idea how to calculate D or even if there was a non-trivial D.

In this circumstance, you stop and warn the user about the merge conflict, but you have no good way (??) to warn them about the potential loss of the amendment, D, since at this point you have no clue whether there was such an amendment and you don't want to worry them about conditions that usually do not occur (amended merges, I would have thought, are quite rare).

??: does git rerere help at all, in this case, I wonder?

Certainly, there is no harm, I think, adding a note to the documentation of --preserve-merges that states something like:

--preserve-merges does not attempt to preserve the resolution of merge conflicts or the amendment of merge commits ???; any histories containing such changes cannot be reliably recreated by git rebase.

??? - except to the extent allowed by git rerere?
jon.
Previous: J Robert RayNext: Junio C Hamano
Message 5 of 18 in “Re: rebase -p loses amended changes”
  1. Jon SeymourMar 31, 2012
  2. Thomas RastMar 31, 2012
  3. Jon SeymourMar 31, 2012
  4. J Robert RayApr 3, 2012
  5. Jon SeymourApr 3, 2012
  6. Junio C HamanoApr 3, 2012
  7. Phil HordApr 3, 2012
  8. Johannes SixtApr 4, 2012
  9. Junio C HamanoApr 4, 2012
  10. Junio C HamanoApr 4, 2012
  11. Jon SeymourApr 4, 2012
  12. Junio C HamanoApr 4, 2012
  13. Jon SeymourApr 4, 2012
  14. Junio C HamanoApr 4, 2012
  15. Martin von ZweigbergkApr 5, 2012
  16. Jon SeymourApr 5, 2012
  17. Martin von ZweigbergkApr 5, 2012
  18. Johannes SixtApr 10, 2012

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.