On 08/12/2017 17:24, Junio C Hamano wrote: > > > 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. > 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. > 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). > 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 ;) > 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@xxxxxxxxxxxxxx/T/#m989306ab9327e15f14027cfd74ae8c5bf487affb
