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

Hi to all,

Here`s my humble attempt on (once more) scratching a use case which seems to be desired occasionally through the years, obviously not enough to be actually implemented yet, but might be worth some more attention... :)

For the reference, some past mentions of (more or less) similar ideas are listed at the end of this e-mail[*1*], where I`m also Cc-ing people previously involved, might be still sharing interest - as this is my first "new thread" list message, I`m sorry if this is not an encouraged practice, please let me know.

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)

Now, usually advised approach to get from (2) to (3), where one is expected to switch to desired topic branch, commit the change, and then re-merge everything again into integration testing branch, is arguably a bit tiresome, but where it actually fails short is the fact that branch switching back and forth (for each hotfix commit) could possibly keep changing a lot of files otherwise untouched by the hotfix changes we`re committing (but different between branches), causing build systems to needlessly waste what could be significant time compiling them again and again.

Example script proposes using something like this instead:

(4) git commit --onto-parent topicA
     
... in above-mentioned case (2) to commit X onto "topicA" branch 
directly, re-merging all previously merged integration testing topic 
branches at the same time, reaching state (3) without any 
intermediate branch switching (and without touching working tree, 
thus without needless recompilation).

Once integration tests pass, integration test branch will be thrown away and new commits on each topic branch should still be properly tested - we`re just deferring it not to do it in the middle of integration testing, saving some (or a lot) needless rebuild cycles at the same time (or in the first place, even).

Scripts in series:
  [1/3]: setup.sh
  [2/3]: git-merge-one-file--cached
  [3/3]: git-commit--onto-parent.sh

Regards, Buga

[*1*] Some previous list mentions of similar functionality, in order 
 of appearance, latest on top (I kind of remember seeing more, but 
 can`t find them now, please feel free to add here, or notify more 
 people interested in the past):

 - [PATCH/RFC] git-post: the opposite of git-cherry-pick (2017-10-05)
   https://public-inbox.org/git/c6b52120-98bf-d685-6dc0-3c83e9e80d30@kdbg.org/

 - "groups of files" in Git? (2017-07-11)
   https://public-inbox.org/git/CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com/

 - Making a (quick) commit to another branch (2013-04-27)
   https://public-inbox.org/git/517BDB6D.8040809@cedarsoft.com/

 - Commit to other branch (2010-05-31)
   https://public-inbox.org/git/4C03D9C1.1060404@cedarsoft.com/

 - [RFC] git commit --branch (2006-05-29)
   https://public-inbox.org/git/20060529202851.GE14325@admingilde.org/

 - n-heads and patch dependency chains (2006-04-03)
   https://public-inbox.org/git/4430D352.4010707@vilain.net/

 - Multi-headed branches (hydra? :)) for basic patch calculus (2006-04-02)
   https://public-inbox.org/git/1143950852.21233.23.camel@localhost.localdomain/