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, 23:54 UTC
Message-ID: <a3510c14-23e9-d1d9-0847-b60451f8e15d@gmail.com>
In-Reply-To: <xmqqo9n99ohc.fsf@gitster.mtv.corp.google.com>

On 08/12/2017 17:24, Junio C Hamano wrote:

Show 9 quoted lines

> 
> > 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>
> 
> Are you asking me if _I_ find it useful?  It is not a very useful
> question to ask, as I've taken things that I do not find useful
> myself.

It was also (kind of shy and subtle) "would you take it?", indeed, but I do value your personal opinion here, too, being a recognized developer, and one really knowing the Git (mailing list) community on top of it, so I appreciate you addressed both sides of the question.

And it was partly addressed to Hannes, but more for a confirmation, I guess, him being the one to favor such a flow in the first place, over what I initially suggested.

Show 5 quoted lines

> Having said that, I do not see me personally using it. You keep
> claiming that committing without ever materializing the exact state
> that is committed in the working tree is a good thing.
> 
> I do not subscribe to that view.

No - and I find it an important difference to note - just that it might be acceptable / more preferable _in certain situations_, where the only alternative seems to be wasting (significant) amount of time on needless rebuilds of many files (just because of branch switching, otherwise untouched by the changes we`re interested in).

If this is perceived a too uncommon/exotic case to worth addressing is a different matter, though.

Show 5 quoted lines

> I'd rather do a quick fix-up on top (which ensures that at least the
> fix-up works in the context of the tip), and then "rebase -i" to
> move it a more appropriate place in the history (during which I have
> a chance to ensure that the fix-up works in the context it is
> intended to apply to).

Chris reported in this very topic[1] that sometimes, due to conflicts with later commits, "checkout > commit > [checkout >] rebase --onto" is "much easier to do", where "commit --fixup > rebase -i" "breaks" (does not apply cleanly).

Show 5 quoted lines

> I know that every time I say this, people who prefer to commit
> things that never existed in the working tree will say "but we'll
> test it later after we make these commit without having their state
> in the working tree".  But I also know better that "later" often do
> not come, ever, at least for people like me ;-).

No comment here ;)

Show 10 quoted lines

> The amount of work _required_ to record the fix-up at its final
> resting place deeper in the history would be larger with "rebase -i"
> approach, simply because approaches like "commit --onto" and "git
> post" that throw a new commit deep in the history would not require
> ever materializing it in the working tree.  But because I care about
> what I am actually committing, and because I am just lazy as any
> other human (if not more), I'd prefer an apporach that _forces_ me
> to have a checkout of the exact state that I'd be committing.  That
> would prod me to actually looking at and testing the state after the
> change in the context it is meant to go.

All that I agree with, too.

But that said, I do find `git add --patch` invaluable (for example), where one can still opt to commit right away (and test later ;)), or do a proper `git stash push --keep-index` first in order to actually check/test the exact state/context before committing.

One of the biggest advantages I see in using Git is that it provides so many possibilities, where there is not necessarily a single "correct" way to do something - depending on the (sub)context, the decision on "_the_ correct" way can be deferred to the user himself.

Git (usually) does not judge, except in cases where something is considered "plain wrong" - still different than "might not be the best approach", but not necessarily a wrong one, either.

But I do realize it also means more chances for beginner users to shoot themselves in the foot, blaming it on Git, so even if just a matter of personal taste, a more restrictive preference from the Git maintainer is understandable :)

Regards, Buga

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