From: Erik Faye-Lund Date: Tue, 04 Oct 2011 08:22:35 GMT Subject: Re: [PATCH/RFC] remote: support --all for the prune-subcommand Message-ID: In-Reply-To: <20111004075608.GC7308@sigill.intra.peff.net> On Tue, Oct 4, 2011 at 9:56 AM, Jeff King wrote: > On Tue, Oct 04, 2011 at 09:40:22AM +0200, Erik Faye-Lund wrote: >> In fact, I'm not sure I understand why we simply do not always prune >> by default. > > I think the original rationale was that we didn't want fetch to be > "lossy". That is, if I were using upstream's "foo" branch as part of my > work (to diff against, or whatever), then doing a "git fetch" to update > should not suddenly make it hard to do my work. And not just hard as in > "I notice that it's gone and I adapt my workflow". But that you no > longer have _any_ record of where upstream's "foo" branch used to point, > so even doing something like: > >  git rebase --onto new-foo foo my-topic > > is impossible. > Following that logic, a user cannot _ever_ safely prune a remote if he wants to work on some of the branches. Doing something like "git remote foo -n" to check if the branch would get pruned before doing a proper prune is prone to a race-condition; the branch could be deleted on the remote between the dry-run and the actual pruning. Besides, the owner of the repo can just as easily have deleted the branch and created a new one with the same name, causing the contents of the branch to be lost. This happens all the time with "for-upstream"-kind of branches, no? > These days we have reflogs, so you would hope to do something like: > >  git rebase --onto new-foo foo@{1} my-topic > > But ref deletion also deletes the reflog completely, so that doesn't > work. > ...and this just makes the problem I pointed out above a lot worse. So surely, the only sane thing is to make a local branch of what you're interested in to be safe? > The right solution, IMHO, is that ref deletion should actually keep the > reflog around in a graveyard of some sort. Entries would expire > naturally over time, as they do in regular reflogs. And then it becomes > a lot safer to prune on every fetch, because you still have 90 days look > at the reflog. > Fixing the reflog to expire for ref deletion rather than completely deleting it sounds like a good move, indeed. >> If a user wants to keep another user's branch, surely the most sane >> thing would be to make a local branch of it? > > Unfortunately there are some management problems there. How do I keep my > local branch up to date with what I fetch? I have to keep checking out > and merging on every fetch (or use some plumbing), which is a pain. But > if I don't, then when the upstream branch goes away, I still have no > clue where its tip was right before it got pruned. Hmm, good point. I tend to just do the dirty work every now and then myself. But I only tend to track upstream and stale development-branches that I intend to pick up, so I'm probably not the best user-example. While we're on the subject, an additional argument to change "git fetch" to always prune is that it's much much easier for user to grok "last known state of 's branches" than "the union of all the branches that were ever pulled from , unless --prune was specified". But that's not a technical one, and surely there's issues to resolve with the proposal before going in that direction.