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:
>
> > 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@xxxxxxxxxxxxxx/T/#mcb3953542dc265516e3ab1bff006ff1b5b85126a
