ydirson@xxxxxxx writes: > Hi Sergey, Hi Yann, [...] > This reminds me of the approach used in git-reintegrate: to get merges > redone without loosing the fixup, it allows you to do exactly this, and > then is able to use rerere information to redo that often-incomplete part > of conflict resolution. Then it squashes the fixup commit in the merge, > and is able to do that as long as the fixup commit is reachable. > > One thing we could do given a merge commit, and provided that 1. we have > access to rerere cache, 2. a "standard merge" was done, and 3. the merge > algorithm did not change, we can pretty easily derive the two "separate > commits" (or arguably "separate parts of the merge"). Unfortunately, rerere is unreliable as you may rebase in a different repository in the first place. Fortunately, all the needed information is still there in the original merge commit though. I suggest you read the following. You will find that it exactly talks about 2 separate parts of the merge, but does not need rerere to do the job: https://public-inbox.org/git/87r2oxe3o1.fsf@xxxxxxxxx/ To give you even more background, here is a reference to "Git Rev News" that discusses the issue: https://git.github.io/rev_news/2018/04/18/edition-38/#general Unfortunately I've turned to other issues and lost track of what current situation is, but according to your question the cart remains there still. > > That alone could maybe form the basis of the "redo merge" you're suggesting, > and would already cover a good number of use-cases. > > For the case where the rerere cache is not available any more, I saw > we have a contrib/rerere-train.sh script, although I never tried it, > as I had written mine at the time, though I felt it had left it had > too many rough edges to share. I'm attaching it for reference, as it > also creates the separate fixup commit (originally for use by > git-reintegrate). > > In fact, I wonder how much replaying merges created by other > strategies would perform, if we simply try to apply this idea to them > too. I deeply believe that Git should not care. You already have a merge commit. What "strategies" or algorithm have been used to create that commit should not matter for Git when it rebases *that commit*, the same way it doesn't care how exactly you've created a non-merge commit. I think that only after the basic rebasing is done right, some additional niceties, such as guessing the strategy, could be implemented, on top of fundamentally correct rebasing. > > However, before I get too high on the idea, I have to say that in the >rebase that triggered this mail the rerere cache failed to get used in >a couple of situations: I did not care to check but I'd wager those >were the commits in conflict with precisely the fixup I was bringing >down below the merges. In this case (quite lots of conflicts to >re-resolve because of a one-line conflict, I felt so bad), the "apply >the one-line by hand and juste resolve *that* conflict" approach was >really effective - so maybe it makes sense to provide the two options, >which may be suitable for different situations. I'd not rely on rerere for rebasing merges if at all possible, and it *is* possible, see the aforementioned reference. Options are definitely good to have, but the default one must be the safest, that currently is not the case at all. If Git tried to actually rebase the merge, it could have happened there would be no conflict, or else, but the worst situation currently is when Git silently replaces original merge with something rather different that just happens to result in no textual conflicts. -- Sergey Organov
