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

Tom Miller [off-list ref] writes:

quoted

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.