On Tue, Dec 15, 2020 at 02:41:38AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > > Another reason I'm not a fan of it is because it's another piece of
> > > magic "clone" does that you can't emulate in "init/fetch".
> >
> > That ship has sailed longlonglong time ago when dfeff66e (revamp
> > git-clone., 2006-03-20) started pointing our HEAD to match theirs.
>
> Let me rephrase: I think it's unfortunate when we add new things things
> to porcelain commands that aren't easy or possible to emulate in
> plumbing.
>
> I.e. this feature seems like a candidate to be exposed by something like
> by a ls-remote flag if you'd like to do an init/config/fetch. AFAIK the
> only way to do it is to mock a "clone" with GIT_TRACE_PACKET or get the
> information out-of-bounds.
I think the situation is better than that. We are surfacing the remote
HEAD here, and there is already a command for copying that to our local
tracking symref: "git remote set-head origin -a", which will set up
refs/remotes/origin/HEAD.
I think there are two ways we could improve that further:
- making it more natural to pick up or update the remote HEAD via
fetch; Felipe's patches to git-fetch look good to me
- 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
Or maybe not. It's not something people probably need to do a lot.
And if the point is to have plumbing commands that can do the same,
then maybe those commands are sufficient.
-Peff
