On Dec 9, 2017, at 01:54, Igor Djordjevic wrote:
> On 08/12/2017 17:24, Junio C Hamano wrote:
>> I'd rather do a quick fix-up on top (which ensures that at least the
>> fix-up works in the context of the tip), and then "rebase -i" to
>> move it a more appropriate place in the history (during which I have
>> a chance to ensure that the fix-up works in the context it is
>> intended to apply to).
>
> 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.
The situations which tend to cause conflicts for me usually look
like this.
---A---B
Say, a file has this line added somewhere in commit A:
+int some_function();
Then commit B adds another line:
int some_function();
+int another_function();
Then I realize that I would like to have commit A to introduce some
other_function() as well, so I add a fixup:
---A---B---f!A
with the following diff:
int some_function();
+int other_function();
int another_function();
And then I often find that "rebase -i --autosquash" fails to apply
the commit B because it expects slightly different context around
the changed lines.
However, sometimes I see that if I do this:
---A---B
\
f!A
then "rebase --onto f!A A B" succeeds, nicely resolving the conflict
without bothering me. No idea why. 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.
(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.)
