Subject: Re: [PATCH 3/3] fetch --prune: Repair branchname DF conflicts

From: Junio C Hamano <[email-masked]>
Date: Thu, 19 Dec 2013 11:34:51 -0800

Tom Miller <[email-masked]> writes:

>> But what should happen when we do not give --prune to "git fetch" in
>> such a situation?  Should it fail, because we still have frotz/nitfol
>> and we cannot create frotz without losing it?
>
> You talk about this to some extent in an email from 2009. I have linked
> it below for your review.
> http://article.gmane.org/gmane.comp.version-control.git/132276

I do not think the old discussion talks about the case.  It was
about "we have remotes/origin/{frotz,nitfol} from the origin from an
earlier fetch, the origin now has updated its frotz and deleted its
nitfol.  'git remote prune' removes our remotes/origin/nitfol
without updating our copy of remotes/origin/frotz, but I do not
think it is sensible.  'git fetch --prune origin' would update both
and make our remote-tracking branches for 'origin' in line with the
reality".  It was not about what 'git fetch' without '--prune'
should do.

Your "'git fetch' without '--prune' should be less destrictive" is a
good guiding principle.  If we have a copy of the 'frotz/nitfol'
branch from the 'origin', removing it so that we can have a new copy
of the 'frotz' branch the 'origin' now has (after it removed
'frotz/nitfol' to make room) is indeed an operation that loses
information.  And it probably is the right thing to do to fail such
a fetch. 'git fetch --prune' on the other hand really means "I do
not care about the branches' histories my 'origin' discarded; bring
me up to date and give me the same view as my 'origin' has in my
remote-tracking branches", so losing 'frotz/nitfol', which the
'origin' already decided to discard, is what the user wants.

The atomicity issue Peff brings up is an interesting and important
one, but I think that is an orthogonal issue.

With the background information from the previous thread between you
and trast, the patch [3/3] looks good to me.

Thanks.