On Tue, Oct 04, 2011 at 09:40:22AM +0200, Erik Faye-Lund wrote:
> > Hmm, you might want to do that on, say, a mobile network to save
> > bandwidth; i.e throw away the stale branches, but not yet update the
> > non-stale ones because downloading the objects might take a long time
> > (and/or be expensive).
> >
> > So with that in mind, I actually think my patch makes sense in some
> > cases, but it certainly is less useful that I originally though ;)
>
> Strike that part; I hadn't had my morning coffee yet. It might make
> sense to have similar _functionality_, but having this as a flag to
> "git fetch" instead of "git remote prune" strikes me as the only sane
> approach.
I agree that "git fetch --prune-only" (or something similar) would be a
natural way to do it.
> 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.
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.
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.
There is still one sticky point, which is that your branch config may
refer to an upstream branch that gets pruned. That will break some
operations (as well it should, as the branch is gone, and the user needs
to adapt their config appropriately). It might be nice if we noticed
when accessing a ref that it doesn't exist but has a deleted reflog, so
we can give the user better advice.
> 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.
-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