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

Re: [PATCH] fetch-pack: demonstrate --all failure when remote is empty

From
Kirill Smelkov <kirr@nexedi.com>
Date
Jun 13, 2018, 18:21 UTC
Message-ID
<20180613182122.GA22854@deco.navytux.spb.ru>
In-Reply-To
<xmqqh8m67gpo.fsf@gitster-ct.c.googlers.com>
On Wed, Jun 13, 2018 at 10:13:07AM -0700, Junio C Hamano wrote:
Show 22 quoted lines
> Kirill Smelkov <kirr@nexedi.com> writes:
> 
> > ( Junio, please pick up the patch provided in the end )
> >
> > On Tue, Jun 12, 2018 at 06:54:17PM +0000, Kirill Smelkov wrote:
> >> On Tue, Jun 12, 2018 at 05:48:49AM -0400, Jeff King wrote:
> >> > On Mon, Jun 11, 2018 at 09:43:02AM +0000, Kirill Smelkov wrote:
> > [...]
> >
> >> > > I'm not sure, but I would say that `fetch-pack --all` from an empty
> >> > > repository should not fail and should just give empty output as fetch
> >> > > does.
> >> > 
> >> > Yeah, that seems reasonable to me. The die() that catches this dates
> >> > back to 2005-era, and we later taught the "fetch" porcelain to handle
> >> > this. I don't _think_ anybody would be upset that the plumbing learned
> >> > to treat this as a noop. It's probably a one-liner change in
> >> > fetch_pack() to return early instead of dying.
> 
> I actually have a slight preference to the current "attempting to
> fetch from a total emptiness is so rare that it is worth grabbing
> attention of whoever does so" behaviour, to be honest.
I see.
Show 7 quoted lines
> Oh, wait, is this specific to "fetch-pack" and the behaviour of
> end-user-facing "git fetch" is kept same as before?  If then, I'd be
> somewhat sympathetic to the cause---it would be more convenient for
> the calling Porcelain script if this turned into a silent noop (even
> though it would probably make it harder to diagnose when such a
> Porcelain is set up incorrectly e.g. pointing at an empty repository
> that is not the one the Porcelain writer intended to fetch from).

Yes, it is only for fetch-pack, and behaviour of porcelain fetch is kept as it was before.

Show 8 quoted lines
> > However with transport.c being there too, since I'm no longer using
> > `fetch-pack --all`, now it is best for me to not delve into this story
> > and just stop with attached patch.
> 
> If we do not plan to change the behaviour later ourselves, I do not
> think it makes sense, nor it is fair to those future developers who
> inherit this project, to declare that the established behaviour is
> wrong with an 'expect-failure' test like this, to be honest.
I see. Let's please cancel this patch then.
Show 7 quoted lines
> > +test_expect_failure 'test --all wrt empty.git' '
> > +	git init --bare empty.git &&
> > +	(
> > +		cd client &&
> > +		git fetch-pack --all ../empty.git
> > +	)
> > +'
Previous: Junio C HamanoNext: Jeff King
Message 19 of 21 in “fetch-pack: demonstrate --all breakage when remote have tags to non-commit objects”
  1. fetch-pack: demonstrate --all breakage when remote have tags to non-commit objectsKirill Smelkov, Jun 10, 2018
  2. Jeff KingJun 11, 2018
  3. fetch-pack: don't try to fetch peeled values with --allJeff King, Jun 11, 2018
  4. Eric SunshineJun 11, 2018
  5. fetch-pack: don't try to fetch peel values with --allJeff King, Jun 11, 2018
  6. Kirill SmelkovJun 11, 2018
  7. Jeff KingJun 12, 2018
  8. Kirill SmelkovJun 12, 2018
  9. fetch-pack: test explicitly that --all can fetch tag references pointing to non-commitsKirill Smelkov, Jun 13, 2018
  10. Junio C HamanoJun 13, 2018
  11. Kirill SmelkovJun 13, 2018
  12. Jeff KingJun 13, 2018
  13. Jeff KingJun 13, 2018
  14. Kirill SmelkovJun 14, 2018
  15. Junio C HamanoJun 14, 2018
  16. Kirill SmelkovJun 14, 2018
  17. fetch-pack: demonstrate --all failure when remote is emptyKirill Smelkov, Jun 13, 2018
  18. Junio C HamanoJun 13, 2018
  19. Kirill SmelkovJun 13, 2018
  20. Jeff KingJun 13, 2018
  21. Kirill SmelkovJun 14, 2018

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.