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@xxxxxxxx/
- "groups of files" in Git? (2017-07-11)
https://public-inbox.org/git/CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@xxxxxxxxxxxxxx/
- Making a (quick) commit to another branch (2013-04-27)
https://public-inbox.org/git/517BDB6D.8040809@xxxxxxxxxxxxx/
- Commit to other branch (2010-05-31)
https://public-inbox.org/git/4C03D9C1.1060404@xxxxxxxxxxxxx/
- [RFC] git commit --branch (2006-05-29)
https://public-inbox.org/git/20060529202851.GE14325@xxxxxxxxxxxxxx/
- n-heads and patch dependency chains (2006-04-03)
https://public-inbox.org/git/4430D352.4010707@xxxxxxxxxx/
- Multi-headed branches (hydra? :)) for basic patch calculus (2006-04-02)
https://public-inbox.org/git/1143950852.21233.23.camel@localhost.localdomain/
