On Mon, Dec 14, 2020 at 06:55:33PM -0800, Junio C Hamano wrote:
> > - it might be nice to be able to have some equivalent to the dwim "git
> > checkout foo" that creates a new "foo" based off of origin/foo.
> > Doing "git checkout origin/HEAD" will detach the HEAD. I think right
> > now you'd have to do something like:
> >
> > tracking=$(git symbolic-ref refs/remotes/origin/HEAD)
> > branch=${tracking#refs/remotes/origin/}
> > git checkout -b $branch $tracking
>
> Meaning "git checkout origin" would look at origin/HEAD and find the
> remote-tracking branch it points at, and uses that name? I think
> that does make quite a lot of sense. You are correct to point out
> that not just "git checkout origin/HEAD", but "git checkout origin",
> currently detaches the HEAD at that commit, if you have origin/HEAD
> pointing at one of the remote-tracking branches.
I'm not sure if it's a good idea to change "git checkout origin" here or
not. It already does something useful. I was mostly suggesting that the
other thing might _also_ be useful, but I'm not sure if it is wise to
change the current behavior.
I was thinking more like an explicit way to trigger the dwim-behavior,
like:
# same as "git checkout foo" magic that creates "foo", but we
# have said explicitly both that we expect to make the new branch, and
# also that we expect it to come from origin.
git checkout --make-local origin/foo
# similar, but because we are being explicit, we know it is reasonable
# to dereference HEAD to find the actual branch name
git checkout --make-local origin/HEAD
I dunno. I hate the name "--make-local", and in the non-dereferencing
form, it is not much different than just "git checkout -b foo
origin/foo". I'm mostly just thinking aloud here. :)
> But if we were to make such a change, "git fetch" shouldn't
> automatically update remotes/origin/HEAD, I would think. It does
> not matter too much if we are talking about a publishing repository
> where the HEAD rarely changes (and when it does, it is a significant
> event that everybody in the downstream should take notice), but if
> you clone from a live repository with active development, you do not
> want to lose a stable reference to what you consider as the primary
> branch at your origin repository.
That seems orthogonal. Whether there is checkout magic or not, changing
what origin/HEAD points to would be disruptive to selecting it as a
tracking source, or doing diffs, or whatever. But that is why the
proposal in that series was to make the behavior configurable, and
default to "fill it in if missing" as the default, not "always update on
fetch".
-Peff
