Re: [PATCH] git remote update: New option --prune (-p)
- From
- demerphq <demerphq@gmail.com>
- Date
- Apr 2, 2009, 19:05 UTC
- Message-ID
- <9b18b3110904021205t6b00e486k2d0717e252b01d14@mail.gmail.com>
- In-Reply-To
- <20090402163213.GA28261@coredump.intra.peff.net>
2009/4/2 Jeff King <peff@peff.net>:
Show 15 quoted lines
> On Thu, Apr 02, 2009 at 06:07:33PM +0200, demerphq wrote: > >> Er, personally i find that documentation pretty cryptic. And when i >> check git config for group, i see this: >> >> remotes.<group> >> The list of remotes which are fetched by "git remote update >> <group>". See git-remote(1). > > Yeah, this should probably say "separated by space" or whatever (I > actually don't even know). I would assume it contains the remote name; I > can't imagine what other thing it would include. But it wouldn't hurt to > make that more explicit. > > I'm sure a documentation patch would be welcome.
If/when i feel that i understand the subject sufficiently Ill make an attempt. :-)
Show 15 quoted lines
>> remote.<name>.skipDefaultUpdate >> If true, this remote will be skipped by default when updating using >> the update subcommand of git-remote(1). >> >> Neither of which really explain groups, how to define them properly, >> (the list is separated by what? and includes the remote name?) or >> whether there are implicit groups. I mean, it seems logical that if >> you can have user defined groups that there are some built in ones >> too, like "all" and "none" or perhaps groups defined by transport >> "http" or "git" for instance. > > I think what is confusing is that there is exactly one implicit group, > and it is "the default group", which contains every remote that doesn't > have skipDefaultUpdate set. You refer to the "default group" by not > mentioning any group.
Yes well an implicit group "default" would be nice.
Show 7 quoted lines
> > So no, there aren't other implicit groups (AFAIK). > > You can propose implicit groups, but I think they would have to have a > compelling use case over simply creating them manually. To avoid > conflict with groups people have already defined, they would only be > used if no remotes.$whatever config existed.
Or perhpas simply use syntax not likely or expected to be used in the name of a group. Like colon. Or something like that.
Show 7 quoted lines
> > I think having "git remote update foo" fall back to a group containing > only the remote "foo" when "remotes.foo" does not exist makes sense. > I'm not sure that "none", "http", or "git" is all that useful in > practice (the only thing I can think of for the latter two is that you > might use "git" versus "http" depending on restrictive firewall > settings).
Well i was think of situations where somebody has coded something that just must have a group. Thus 'none' would be essentially a no-op in this case. I know you can argue "well dont do that", but people tend to do silly things whatever they are told, and explicit arguments make for less special cases in wrapper scripts and the like...
> > You could give the unnamed "default group" a name (like "all"), but then > you risk conflict with existing "remotes.all".
Id much prefer the default group to be called default. Not "all". Ideally "all" would really be "all". :-)
> And in this case, it is > hard to remain backwards compatible: "git remote update" will do > something different now in the case that the user has configured > remotes.all.
Well, id have a thought a better approach is to use a character that cannot or is extremely unlikely to be used in an existing group definition and cannot be used in a remote definition. Like maybe ":all" or something.
Or maybe: `git config remote.implicitgroups true` could be used to enable it?
cheers, Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"