Hi Igor On 09/12/17 03:03, Igor Djordjevic wrote: > > Hi Alexei, > > On 09/12/2017 03:18, Alexei Lozovsky wrote: >> >>> Chris reported in this very topic[1] that sometimes, due to >>> conflicts with later commits, "checkout > commit > [checkout >] >>> rebase --onto" is "much easier to do", where "commit --fixup > >>> rebase -i" "breaks" (does not apply cleanly). >> >> It was more of a rant about conflict resolution by rebase rather than >> a concern about modification time of files. While I'd prefer git to >> not touch the source tree unnecessarily, it's not really a big deal >> for me if it does and some parts of the project need to be rebuilt. > > Nevertheless, I found it valuable in supporting the case where > "commit --fixup > rebase -i" seems to require even more work than > otherwise necessary :) > > But thanks for clarifying, anyway, it does feel like `git rebase -i > --autosquash` could be smarter in this regards, if `git rebase > --onto` does it better...? Creating the fixup directly on A rather than on top of B avoids the conflicting merge B f!A A. Creating the fixup on top of B and then using git commit --onto A would suffer from the same conflicts as rebase does. I don't think there is any way for 'git rebase --autosquash' to avoid the conflicts unless it used a special fixup merge strategy that somehow took advantage of the DAG to resolve the conflicts by realizing they come from a later commit. However I don't think that could be implemented reliably as sometimes one wants those conflicting lines from the later commit to be moved to the earlier commit with the fixup. Best Wishes Phillip > > Even though your explanation seems clear, having a real, easily > reproducible case would help as well, I guess. > >> I kinda hoped that you may know this magic and incorporate it into >> "commit --onto" which will allow to immediately get to the result of >> the rebase: >> >> ---A---f!A---B' >> >> without spelling it all manually. > > If you mind enough to be bothered testing it out, might be even > existing/initial state of originally proposed `git commit > --onto-parent` script would work for you, as it does incorporate some > trivial three-way merge resolution. > > In your starting situation: > > ---A---B > > .... you would just do something like: > > git commit --onto-parent A > > .... hopefully ending up in the desired state (hopefully = conflicts > automatically resolved): > > ---A---C---B' > > You could even do this instead: > > git commit --onto-parent A --amend > > .... ending up with: > > ---A'---B' > > .... as that is basically what you wanted in the first place ;) > >> (And yeah, I'm actually Alexei, not Chris. That was my MUA being >> dumb and using an old pseudonym than Google insists I'm called by.) > > Ah, sorry for the confusion :) > > Regards, Buga >
