From: Chris Nerwert <a.lozovsky@gmail.com>
Date: Thu, 30 Nov 2017 22:40:21 GMT
Subject: Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)
Message-ID: <0F30BEF8-A9F7-43B9-BC89-4B9CD7AF3E16@gmail.com>
In-Reply-To: <8998e832-f49f-4de4-eb8d-a7934fba97b5@gmail.com>

On Nov 27, 2017, at 00:35, Igor Djordjevic <igor.d.djordjevic@gmail.com> wrote:
> 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.
I'm actually doing the described workflow quite often with git rebase when working on a topic. Given the following structure:

  ---o               (master)
      \
       o---A---B---C (topic)

When I want to make changes to commit A one option is to make them directly on topic, then do "git commit --fixup A", and then eventual interactive rebase onto master will clean them up:

  ---o                     (master)
      \
       o---A---B---C---f!A (topic)

However, sometimes this breaks when changes in B or C conflict somehow with A (which may happen quite a lot during development of a topic), so the rebase will not apply cleanly. So sometimes I make a temporary branch from A, commit the fixup there:

  ---o               (master)
      \
       o---A---B---C (topic)
            \
             f!A     (temp)

and then use "git rebase --onto temp A topic" to move the topic back on track:

  ---o                     (master)
      \
       o---A---f!A         (temp)
                  \
                   B'---C' (topic)

after which the final cleanup rebase is much easier to do.

Obviously, all the branch switching and rebasing does take its tall on file modifications.