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

From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Date: Dec 8, 2017, 00:15 UTC
Message-ID: <f9a94a62-9541-e019-8ab3-9fc9cfe2c43f@gmail.com>
In-Reply-To: <CAPc5daWupO6DMOMFGn=XjUCG-JMYc4eyo8+TmAsdWcAOHXzwWg@mail.gmail.com>

On 06/12/2017 19:34, Johannes Sixt wrote:

> 
> I am sorry for not responding in detail. I think we've reached a 
> mutual understanding of our workflows.

No problem, thanks for your time so far.

There might be one more thing I should address, possibly left unclear from my previous message, but I`ll leave that for a follow-up e-mail, not being that important at the moment for the topic itself.

On 06/12/2017 19:40, Junio C Hamano wrote:

Show 8 quoted lines

> 
> > Though, from the ideas you tossed around most recently, you seem to
> > want to make git-commit into a kitchen-sink for everything. I have
> > my doubts that this will be a welcome change. Just because new
> > commits are created does not mean that the feature must live in
> > git-commit.
> 
> Nicely put.

Yeah, I understand that might have felt cluttering, besides also being out of scope of the original topic idea. Thanks for the reality check (to both).

To get back on track, and regarding what`s already been said, would having something like this(1) feel useful?

(1) git commit --onto <commit>

So in previously mentioned situation:

(2) ...A    ...C            <- topics A, C
        \       \
      ---o---o---o---o I    <- integration <- HEAD
            /       /
        ...B    ...D        <- topics B, D

... it would allow committing changes F inside HEAD on top of B directly, no checkout / branch switching needed, getting to:

(3) ...A    ...C            <- topics A, C
        \       \
      ---o---o---o---o I    <- integration <- HEAD
            /       /
        ...B    ...D        <- topic D
            \
             F              <- topic B

So the most conservative approach, where changes F are removed from HEAD index and working tree, leaving it up to the user to decide if he will then merge them back in (or do something else).

I stress the major selling point here still being avoiding branch switching back and forth in order to commit a fixup on a different branch, which could otherwise trigger needless rebuilds, being significant in large projects.

And thanks to that `git-merge-one-file--cached`[1] script, we are also able to resolve some more of trivial conflicts when applying F onto B, using three-way file merge when needed, but still not touching working tree (contrary to original `git-merge-one-file`).

Regards, Buga

[1] https://public-inbox.org/git/CAPc5daWupO6DMOMFGn=XjUCG-JMYc4eyo8+TmAsdWcAOHXzwWg@mail.gmail.com/T/#mcb3953542dc265516e3ab1bff006ff1b5b85126a