Re: [PATCH/RFC] remote: support --all for the prune-subcommand

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Oct 4, 2011, 08:22 UTC
Message-ID: <CABPQNSb7WACrr=7FsR8YVMC1-q3i0zRhQtXiV8VshfCJn3qgEA@mail.gmail.com>
In-Reply-To: <20111004075608.GC7308@sigill.intra.peff.net>

On Tue, Oct 4, 2011 at 9:56 AM, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> 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?

Show 7 quoted lines

> 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?

Show 6 quoted lines

> 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.

Show 8 quoted lines

>> 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.