Junio C Hamano [off-list ref] writes:
quoted
"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?
Ben
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Monday, September 19, 2016 1:04 PM
To: Ben Peart <redacted>
Cc: pclouds@gmail.com; Ben Peart <redacted>; git@vger.kernel.org
Subject: Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout
Junio C Hamano [off-list ref] writes:
quoted
"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.
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" <redacted>
From: Junio C Hamano [mailto:gitster@pobox.com]
quoted
Junio C Hamano <gitster@pobox.comwrites:
quoted
"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.