On April 1, 2018 11:22 PM Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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
