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

Re: builtin-fetch code with messy history

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jun 19, 2007, 19:47 UTC
Message-ID
<Pine.LNX.4.64.0706192043310.4059@racer.site>
In-Reply-To
<Pine.LNX.4.64.0706191239260.4740@iabervon.org>
Hi,
On Tue, 19 Jun 2007, Daniel Barkalow wrote:
Show 17 quoted lines
> On Tue, 19 Jun 2007, Johannes Schindelin wrote:
> 
> > 
> > On Tue, 19 Jun 2007, Daniel Barkalow wrote:
> > 
> > > In my branch at: git://iabervon.org/~barkalow/git builtin-fetch
> > > 
> > > I have a bunch of not-for-merging history leading up to a C version 
> > > of fetch which passes all of the tests except that:
> > > 
> > >  * it might be fetching too much with --depth.
> > 
> > That should be fixable. (If I get more time this week than I expect, 
> > I'll do it myself.)
> 
> I just haven't taken the time to look at what it's supposed to do 
> exactly, since I wasn't paying attention to the discussions there.

Come to think of it, I am not sure that it does the right thing in existing code either. There are still a bunch of emails regarding shallow clone in my inbox, awaiting calmer weather.

Show 7 quoted lines
> > >  * bundle isn't implemented.
> > 
> > That's an easy one.
> 
> Yeah, just a section in transport.c about it, but the functions I need 
> aren't available directly and I got distracted until I was looking at my 
> list of what tests I'd disabled.

What I meant is not that it is so easy that you should have done it. I meant that this is so easy you should not bother with it, since I'll gladly step in once builtin-fetch is otherwise feature complete.

Show 13 quoted lines
> > >  * when a branch config file section refers to a branches/* remote, the 
> > >    merge setting is used (if one is given), even though this isn't useful 
> > >    either way.
> > 
> > Maybe this is the right time to cut off branches/* and remotes/*?
> 
> It's not actually too difficult to support them, except for some weird 
> combination cases that nobody would do anyway. I just made the remote.c 
> config file parser generate the corresponding configurations from them, 
> and the rest of the code doesn't have to care. The only oddity is that I 
> had to support having a remote always auto-follow tags, even without 
> tracking branches, because that's what branches/* did. But this is 
> probably a reasonable thing to support as an option anyway.

As Junio said, I think in the interest of clean code we should deprecate that, and eventually get rid of it. We could do that even before builtin-fetch reaches 'next'...

Ciao, Dscho

Previous: Junio C Hamano
Message 11 of 11 in “builtin-fetch code with messy history”
  1. Daniel BarkalowJun 19, 2007
  2. Johannes SchindelinJun 19, 2007
  3. Alex RiesenJun 19, 2007
  4. Johannes SchindelinJun 19, 2007
  5. Alex RiesenJun 19, 2007
  6. Johannes SchindelinJun 19, 2007
  7. Alex RiesenJun 19, 2007
  8. Jakub NarebskiJun 19, 2007
  9. Daniel BarkalowJun 19, 2007
  10. Junio C HamanoJun 19, 2007
  11. Johannes SchindelinJun 19, 2007

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.