git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 19, 2013, 19:34 UTC
Message-ID
<xmqq7gb0fxd0.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20131219014859.GA32240@gmail.com>
Tom Miller <jackerran@gmail.com> writes:
Show 7 quoted lines
>> 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.
Previous: Jeff KingNext: Junio C Hamano
Message 8 of 13 in “builtin/fetch.c: Add pretty_url() and print_url()”
  1. 1/3 builtin/fetch.c: Add pretty_url() and print_url()Tom Miller, Dec 18, 2013
  2. 2/3 fetch --prune: Always print header urlTom Miller, Dec 18, 2013
  3. 3/3 fetch --prune: Repair branchname DF conflictsTom Miller, Dec 18, 2013
  4. Junio C HamanoDec 18, 2013
  5. Tom MillerDec 19, 2013
  6. Junio C HamanoDec 19, 2013
  7. Jeff KingDec 19, 2013
  8. Junio C HamanoDec 19, 2013
  9. Junio C HamanoDec 18, 2013
  10. Tom MillerDec 19, 2013
  11. Thomas MillerDec 19, 2013
  12. 1/2 fetch --prune: Always print header urlTom Miller, Dec 19, 2013
  13. 2/2 fetch --prune: Run prune before fetchingTom Miller, Dec 19, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.