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
