Re: builtin-fetch code with messy history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 19 Jun 2007, Johannes Schindelin wrote:

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

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

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

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux