Re: builtin-fetch code with messy history

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 19 Jun 2007, Daniel Barkalow wrote:

> 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.

> > >  * 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.

> > >  * 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