Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

[Johannes Sixt <j6t@kdbg.org>]

Am 26.11.2017 um 23:35 schrieb Igor Djordjevic:
> Approach discussed here could have a few more useful applications,
> but one seems to be standing out the most - in case where multiple
> topic branches are temporarily merged for integration testing, it
> could be very useful to be able to post "hotfix" commits to merged
> branches directly, _without actually switching to them_ (and thus
> without touching working tree files), and still keeping everything
> merged, in one go.
> 
> Example starting point is "master" branch with 3 topic branches (A,
> B, C), to be (throwaway) merged for integration testing inside
> temporary "test" branch:
> 
> (1)        o---o---A (topicA)
>            /
>           /
>          /
>      ---o---o---M (master, test, HEAD)
>          \   \
>           \   o---B (topicB)
>            \
>             o---o---C (topicC)
> 
> 
> This is what we end up with once "master" and topic branches are
> merged in merge commit M1 inside temporary "test" branch for further
> integration testing:
> 
> (2)        o---o---A (topicA)
>            /         \
>           /           M1 (test, HEAD)
>          /           /||
>      ---o---o---M---/ || (master)
>          \   \       / |
>           \   o---B-/  | (topicB)
>            \           |
>             o---o---C--/ (topicC)
> 
> 
> Upon discovery of a fix needed inside "topicA", hotfix changes X
> should be committed to "topicA" branch and re-merged inside merge
> commit M2 on temporary integration "test" branch (previous temporary
> merge commit M1 is thrown away as uninteresting):
> 
> (3)        o---o---A---X (topicA)
>            /             \
>           /               M2 (test, HEAD)
>          /               /||
>      ---o---o---M-------/ || (master)
>          \   \           / |
>           \   o---B-----/  | (topicB)
>            \              /
>             o---o---C----/ (topicC)

I my opinion, putting the focus on integration merge commits and the 
desire to automate the re-merge step brings in a LOT of complexity in 
the implementation for a very specific use-case that does not 
necessarily help other cases.

For example, in my daily work, I have encountered situations where, 
while working on one topic, I made a hot-fix for a different topic. 
There is no demand for a merge step in this scenario.

In your scenario above, it would certainly not be too bad if you forgo 
the automatic merge and have the user issue a merge command manually. 
The resulting history could look like this:

(3)         o---o---A---X    (topicA)
            /         \   \
           /           M1--M2 (test, HEAD)
          /           /||
      ---o---o---M---' ||     (master)
          \   \       / |
           \   o-----B /      (topicB)
            \         /
             o---o---C        (topicC)

I.e., commit --onto-parent A produced commit X, but M2 was then a 
regular manual merge. (Of course, I am assuming that the merge commits 
are dispensible, and only the resulting tree is of interest.)

Moreover, you seem to assume that an integration branch is an octopus 
merge, that can be re-created easily. I would say that this a very, very 
exceptional situation.

----

At this point, I spent five minutes thinking of how I would use commit 
--onto-parent if I did not have git-post.

While on the integration branch, I typically make separate commits for 
each fix, mostly because the bugs are discovered and fixed not 
simultaneously, but over time. So, I have a small number of commits that 
I distribute later using my git-post script. But that does not have to 
be so. I think I could work with a git commit --onto-parent feature as 
long as it does not attempt to make a merge commit for me. (I would hate 
that.)

Sometimes, however I have two bug fixes in the worktree, ready to be 
committed. Then the ability to pass pathspec to git commit is useful. 
Does your implementation support this use case (partially staged 
worktree changes)?

Thanks,
-- Hannes