On Tue, Oct 4, 2011 at 9:56 AM, Jeff King <peff@xxxxxxxx> 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 <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.
--
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