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...?
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
