On Tue, Oct 04, 2011 at 10:22:35AM +0200, Erik Faye-Lund wrote: > > 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. Right. And that's why we don't prune by default. In practice, it tends to be safe if you pick a reasonable time to prune, and the upstream is reasonable about their branches. But turning it on all the time takes away the "pick a reasonable time". > 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? They can do that, but on the local side, you will just see a jump in history. But because we didn't _delete_ the ref on the local side, you will retain your reflog. IOW, the reflog can save us from anything the upstream will do. And that's what makes deletion so special: we delete the local reflog. > > 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. This is on my long-term todo list, but if somebody gets around to it before me, I won't be upset. :) > 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 <remote>'s branches" than "the union of all the > branches that were ever pulled from <remote>, 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. Agreed. Really, everything argument points towards auto-prune except the reflog-safety thing. I think once that is fixed, turning on pruning by default becomes a no-brainer. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html