From: Igor Djordjevic <email@example.com>
To: Junio C Hamano <firstname.lastname@example.org>, Johannes Sixt <email@example.com>
Cc: Git Mailing List <firstname.lastname@example.org>,
Nikolay Shustov <email@example.com>,
Johannes Schneider <firstname.lastname@example.org>,
Patrik Gornicz <email@example.com>,
Martin Waitz <firstname.lastname@example.org>,
Shawn Pearce <email@example.com>, Sam Vilain <firstname.lastname@example.org>,
Jakub Narebski <email@example.com>
Subject: Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)
Date: Sat, 9 Dec 2017 00:54:06 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
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 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 :)
next prev parent reply other threads:[~2017-12-08 23:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-26 22:35 [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 1/3] setup.sh Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 2/3] git-merge-one-file--cached Igor Djordjevic
2017-11-26 22:45 ` [SCRIPT/RFC 3/3] git-commit--onto-parent.sh Igor Djordjevic
2017-11-27 21:54 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Johannes Sixt
2017-11-28 1:15 ` Igor Djordjevic
2017-11-29 19:11 ` Johannes Sixt
2017-11-29 23:10 ` Igor Djordjevic
2017-12-01 17:23 ` Johannes Sixt
2017-12-04 2:33 ` Igor Djordjevic
2017-12-06 18:34 ` Johannes Sixt
2017-12-06 18:40 ` Junio C Hamano
2017-12-08 0:15 ` Igor Djordjevic
2017-12-08 16:24 ` Junio C Hamano
2017-12-08 23:54 ` Igor Djordjevic [this message]
2017-12-09 2:18 ` Alexei Lozovsky
2017-12-09 3:03 ` Igor Djordjevic
2017-12-09 19:00 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-09 19:01 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, noworking " Phillip Wood
2017-12-10 1:20 ` Igor Djordjevic
2017-12-10 12:22 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-10 23:17 ` Igor Djordjevic
2017-12-11 1:13 ` Alexei Lozovsky
2017-12-11 1:00 ` Alexei Lozovsky
2017-11-30 22:40 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working " Chris Nerwert
2017-12-03 23:01 ` Igor Djordjevic
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).