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

["Randall S. Becker" <rsbecker@nexbridge.com>]

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