Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout

["Philip Oakley" <philipoakley@iee.org>]

Ben,
Using a 'bottom / in-line' posting flow is much preferred, which may require 
some manual editing[1], hopefully I have it about right...
Philip
--
[1] this is massaged and mangled Outlook Express, sometimes one has to work 
with the tools at hand...

From: "Ben Peart" <Ben.Peart@microsoft.com>
> From: Junio C Hamano [mailto:gitster@pobox.com]
> > Junio C Hamano <gitster@pobox.comwrites:
> >
> > >"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.
> >
> > Having said all that.
> >
> > I do see the merit of having a shorthand way to invoke your 2 above.
> > It is just that I am not convinced that it is the best way to achieve 
> > that goal to redefine what "git checkout -b <new-name>" (no other 
> > parameters) does.
> >
> ---
>
> I understand the reluctance to change the existing behavior of the "git 
> checkout -b <new-name>" command.
>
> I see this as a tradeoff between taking advantage of the muscle memory for 
> the existing command and coming up with a new shortcut command and 
> training people to use it instead.
>
> The fact that all the use cases we've observed and all the git test cases 
> actually produce the same results but significantly faster with that 
> change in behavior made me hope we could redefine the command to take 
> advantage of the muscle memory.
>
> 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?

The discussion can often feel harsh [2], especially if there is accidental 
'talking past each other', which is usually because of differing 
perspectives on the issues.

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.

Is there an example public repo that you can show the issue on? (or 
anonymise a private one - there is a script for that [3])

Can you give local timings (and indication of the hardware and software 
versions used for the test, and if appropriate, network setup)?

I know at my work that sometime our home drives are multiply mapped to H:, a 
C:/homedrive directory and a $netshare/me network directory via the 
Microsofy roaming profiles, and if there is hard synchronization (or 
whatever term is appropriate) there can be sudden slowdowns as local C: 
writes drop from 'instant' to 'forever'...

Is there anything special about the repos that have the delays? Is it a 
local process issue that causes the repos to develop those symptoms (see 
above about not being sure why you have these issues), in which case it 
could be local self inflicted issues, or it could be that you have a 
regulatory issue for that domain that requires such symptoms, which would 
shift the problem from a 'don't do that' response to a 'hmm, how to cover 
this'.


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.

--
Philip


[2] Been there, feel your pain. It's not in any way malicious, just a 
reflection that email can be a poor medium for such discussions.
[3] https://public-inbox.org/git/20140827170127.GA6138@peff.net/ suggest 
that the `git fast-export --anonymize --all` maybe the approach.