From: Junio C Hamano <gitster@pobox.com>
To: "Philip Oakley" <philipoakley@iee.org>
Cc: "Ben Peart" <Ben.Peart@microsoft.com>, <pclouds@gmail.com>,
<git@vger.kernel.org>
Subject: Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout
Date: Sat, 24 Sep 2016 11:26:54 -0700 [thread overview]
Message-ID: <xmqqd1jtyx01.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <99A866BEF8944598A50C6E061A703297@PhilipOakley> (Philip Oakley's message of "Sat, 24 Sep 2016 15:28:11 +0100")
"Philip Oakley" <philipoakley@iee.org> writes:
>> > >"git checkout -b foo" (without -f -m or <start_point>) is defined in
>> > >the manual as being a shortcut for/equivalent to:
>> > >
>> > > (1a) "git branch foo"
>> > > (1b) "git checkout foo"
>> > >
>> > >However, it has been our experience in our observed use cases and all
>> > >the existing git tests, that it can be treated as equivalent to:
>> > >
>> > > (2a) "git branch foo"
>> > > (2b) "git symbolic-ref HEAD refs/heads/foo"
>> > >...
>> > >
>> > I am still not sure if I like the change of what "checkout -b" is this
>> > late in the game, though.
>>
>> ...
>> That said, you're much more on the frontline of receiving negative
>> feedback about doing that than I am. :) How would you like to
>> proceed?
>
> I didn't see an initial confirmation as to what the issue really
> was. You indicated the symptom ('a long checkout time'), but then we
> missed out on hard facts and example repos, so that the issue was
> replicable.
I took it as a given, trivial and obvious optimization opportunity,
that it is wasteful having to traverse two trees to consolidate and
reflect their differences into the working tree when we know upfront
that these two trees are identical, no matter what the overhead for
doing so is.
> At the moment there is the simple workaround of an alias that executes
> that two step command dance to achieve what you needed, and Junio has
> outlined the issues he needed to be covered from his maintainer
> perspective (e.g. the detection of sparse checkouts). Confirming the
> root causes would help in setting a baseline.
>
> I hope that is of help - I'd seen that the discussion had gone quiet.
Some of the problems I have are:
(1) "git checkout -b NEW", "git checkout", "git checkout HEAD^0"
and "git checkout HEAD" (no other parameters to any of them)
ought to give identical index and working tree. It is too
confusing to leave subtly different results that will lead to
hard to diagnose bugs for only one of them.
(2) The proposed log message talks only about "performance
optimization", while the purpose of the change is more about
changing the definition of what "git checkout -b NEW" is from
"git branch NEW && git checkout NEW" to "git branch NEW && git
symbolic-ref HEAD refs/heads/NEW". The explanation in a Ben's
later message <007401d21278$445eba80$cd1c2f80$@gmail.com> does
a much better job contrasting the two.
(3) I identified only one difference as an example sufficient to
point out why the patch provided is not a pure optimization but
behaviour change. Fixing that example alone to avoid change in
the behaviour is trivial (see if the "info/sparse-checkout"
file is present and refrain from skipping the proper checkout),
but a much larger problem is that I do not know (and Ben does
not, I suspect) know what other behaviour changes the patch is
introducing, and worse, the checks are sufficiently dense too
detailed and intimate to the implementation of unpack_trees()
that it is impossible for anybody to make sure the exceptions
defined in this patch and updates to other parts of the system
will be kept in sync.
So my inclination at this point, unless we see somebody invents a
clever way to solve (3), is that any change that violates (1),
i.e. as long as the patch does "Are we doing '-b NEW'? Then we do
something subtly different", is not acceptable, and solving (3) in a
maintainable way smells like quite a hard thing to do. But it would
be ideal if (3) is solved cleanly, as we will then not have to worry
about changing behaviour at all and can apply the optimization for
all of the four cases equally. As a side effect, that approach
would solve problem (2) above.
If we were to punt on keeping the sanity (1) and introduce a subtly
different "create a new branch and point the HEAD at it", an easier
way out may be be one of
1. a totally new command, e.g. "git branch-switch NEW" that takes
only a single argument and no other "checkout" options, or
2. a new option to "git checkout" that takes _ONLY_ a single
argument and incompatible with any other option or command line
argument, or
3. an alias that does "git branch" followed by "git symbolic-ref".
Neither of the first two sounds palatable, though.
next prev parent reply other threads:[~2016-09-24 18:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 14:26 [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout Ben Peart
2016-09-13 22:34 ` Junio C Hamano
2016-09-14 6:30 ` Oleg Taranenko
2016-09-14 15:48 ` Junio C Hamano
[not found] ` <BL2PR03MB3232D3128A72D4EC9ADC2C6F4F10@BL2PR03MB323.namprd03.prod.outlook.com>
[not found] ` <BL2PR03MB323E1B2F810C63CB01AA234F4F30@BL2PR03MB323.namprd03.prod.outlook.com>
2016-09-19 13:18 ` Ben Peart
2016-09-19 16:30 ` Junio C Hamano
2016-09-19 17:03 ` Junio C Hamano
2016-09-21 18:32 ` Ben Peart
2016-09-24 14:28 ` Philip Oakley
2016-09-24 18:26 ` Junio C Hamano [this message]
2016-09-24 19:31 ` Philip Oakley
-- strict thread matches above, loose matches on Subject: below --
2016-09-28 17:02 Ben Peart
2016-09-28 17:52 ` Junio C Hamano
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
--in-reply-to=xmqqd1jtyx01.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Ben.Peart@microsoft.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://80x24.org/mirrors/git.git
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).