[RFC] git clone add option to track all remote branches

[RFC] git clone add option to track all remote branches

[Yubin Ruan]

Hi,

I am writing to ask that whether or not you think will be appropriate to add
an option to "git clone" so that whenever a repo is cloned, branches are
created automatically to track corresponding remote branches. (or is there any
equivelant option?)

You can obviously do this by a bash command like this

    git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done

but it will be better if we can have an option in "git clone".

Regards,
Yubin

Re: [RFC] git clone add option to track all remote branches

[Junio C Hamano]

Yubin Ruan <ablacktshirt@gmail.com> writes:

> I am writing to ask that whether or not you think will be appropriate to add
> an option to "git clone" so that whenever a repo is cloned, branches are
> created automatically to track corresponding remote branches. (or is there any
> equivelant option?)
>
> You can obviously do this by a bash command like this
>
>     git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done
>
> but it will be better if we can have an option in "git clone".

I am not sure how it will be more useful than what you already have.
In short, you are getting "all of the remote branches" but with a
twist.  You get them "on demand".

With your hypothetical "clone" command that makes copies of each and
every remote branch to a local one, you can ask "git branch<Enter>"
to show all of them (i.e. "please list what is happening at the
central repository").  With the current system, you would instead
need to ask "git branch -r<Enter>", which may be a bit more to type.

Also when you want to look at or work on top of a remote branch, say
"frotz", you do not have to do "git checkout -b frotz origin/frotz"
to create one, as your hypothetical "clone" would have already
created it when you cloned.  But I think "git checkout frotz" in
such a situation would create a local "frotz" branch out of the
"origin/frotz" remote-tracking branch with the current system, so
I do not think your hypothetical "clone" is all that more useful.

And there certainly is a huge downside.

If you are really doing your own development, then you would have
some topic branches of your own, with forks of some (but most likely
not all, especiallyi when there are many branches at the upstream)
branches you got from the upstream, and "git branch --list" that
shows only your own and what you are interested in (i.e. those that
you actually bothered to "git checkout <branchname>") without
showing random other branches that exist at the remote but do not
interest you is a feature.  Your hypothetical "clone" that
indiscriminatedly forks all branches at remote locally will destroy
the usefulness of it.

Re: [RFC] git clone add option to track all remote branches

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> If you are really doing your own development, then you would have
> some topic branches of your own, with forks of some (but most likely
> not all, especiallyi when there are many branches at the upstream)
> branches you got from the upstream, and "git branch --list" that
> shows only your own and what you are interested in (i.e. those that
> you actually bothered to "git checkout <branchname>") without
> showing random other branches that exist at the remote but do not
> interest you is a feature.  Your hypothetical "clone" that
> indiscriminatedly forks all branches at remote locally will destroy
> the usefulness of it.

Related to this, a feature I have long thought we wished to have is
complete opposite of this.  After creating and working on a local
topic branch and then concluding the work on it, a user would "git
push" the branch out to a remote, and then check out a different
branch (e.g. the 'master' branch).  I wish we had a mode that would
automatically *delete* the local topic branch that has already been
pushed out (and more importantly, a branch that I have *done* with,
at least for now), to unclutter my local branch namespace.  When I
want to further work on it, I can ask "git checkout" to dwim to
recreate one on demand.

Of course, there are some wrinkles due to pesky impleemntation
details (e.g. the "autonuke-and-recreate" would lose reflog), but I
do not think it is fundamental hurdle.

RE: [RFC] git clone add option to track all remote branches

[Randall S. Becker]

On April 1, 2018 11:22 PM Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > If you are really doing your own development, then you would have some
> > topic branches of your own, with forks of some (but most likely not
> > all, especiallyi when there are many branches at the upstream)
> > branches you got from the upstream, and "git branch --list" that shows
> > only your own and what you are interested in (i.e. those that you
> > actually bothered to "git checkout <branchname>") without showing
> > random other branches that exist at the remote but do not interest you
> > is a feature.  Your hypothetical "clone" that indiscriminatedly forks
> > all branches at remote locally will destroy the usefulness of it.
> 
> Related to this, a feature I have long thought we wished to have is
complete
> opposite of this.  After creating and working on a local topic branch and
then
> concluding the work on it, a user would "git push" the branch out to a
> remote, and then check out a different branch (e.g. the 'master' branch).
I
> wish we had a mode that would automatically *delete* the local topic
branch
> that has already been pushed out (and more importantly, a branch that I
> have *done* with, at least for now), to unclutter my local branch
> namespace.  When I want to further work on it, I can ask "git checkout" to
> dwim to recreate one on demand.
> 
> Of course, there are some wrinkles due to pesky impleemntation details
> (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think
it is
> fundamental hurdle.

I'm a little skeptical and confused here. The original RFC does not appear
to stipulate that this is isolated to a single bare. If B,C,D all clone
A.git from one server, it might be ok. If B clones A.git, and C clones B,
and D mirrors C, where would the remote tracking occur. The main value, as a
repo admin of A.git would be to know everything, but that's unlikely.
Stating the obvious rub is, in a DVCS, where connections are not guaranteed,
one can easily move a clone or delete a clone, and your tracking branch
becomes worthless. You might never know about C/D mirrors or even be able to
establish a connection between A.git and those two, in practice - I have
examples of those.
OTOH I have been toying with suggesting a solution to this for a couple of
years, differentiating a transient clone from a (pick a term) authentic
clone, the latter which has some blockchainish so that git will whine
without a valid signature on the clone. Changing the clone without
communicating with the upstream to revalidate it (deferrals could be
implemented), temporarily or permanently invalidates the authentic clone so
it effective becomes pruneable, like a worktree. I see a very deep potential
rabbit hole here that detracts from DVCS principles unless we do have the
conceptual split of the two classes of clones. rm .git is just too easy and
too frequent an operation to just ignore the implication of the deliberate
loss of tracking that is highly unlikely to be trackable by the farthest
upstream, resulting in a whole lot of clutter with no way back.
Alternatively, if the downstreams periodically are forced to revalidate the
tracking branches, then you have sometime potentially workable but annoying
at best, and impractical in some security policies at worst.

Just my $0.02 from managing boat-loads of 4 and 5 level deep repositories.

Cheers,
Randall

Re: [RFC] git clone add option to track all remote branches

[Ævar Arnfjörð Bjarmason]

On Mon, Apr 02 2018, Yubin Ruan wrote:

> I am writing to ask that whether or not you think will be appropriate to add
> an option to "git clone" so that whenever a repo is cloned, branches are
> created automatically to track corresponding remote branches. (or is there any
> equivelant option?)
>
> You can obviously do this by a bash command like this
>
>     git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done

Aside from this specific suggestion, we should be careful when adding
more special snowflakes to git-clone that aren't available through
git-fetch or via after the fact config, such as git clone
--single-branch which has no fetch equivalent (i.e. in finding out what
the remote HEAD is).

Actually now that I mention that it occurs to me that what you want
could just be a special case of generalizing our existing
--single-branch feature. I.e. we would clone repos as:

    [remote "origin"]
    url = git@github.com:git/git.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    branch = $symref(HEAD):refs/remotes/origin/HEAD:TRACK

Or some other such syntax to create a refs/heads/master from the remote
HEAD symref if it doesn't exist (note the lack of a +), then for your
feature:

    branch = refs/heads/*:refs/remotes/origin/*:TRACK

But you could also do:

    branch = +refs/heads/origin/*:refs/remotes/origin/*:TRACK

Or whatever. I don't know what syntax would be sensible, but something
like this is a missing feature of our existing --single-branch feature,
and because of that you can only get its semantics by re-cloning.