2009/4/2 Jeff King <peff@xxxxxxxx>:
> On Thu, Apr 02, 2009 at 04:17:35PM +0200, demerphq wrote:
>
>> > But "git remote update" actually respects "remote groups", so it is not
>> > just "--all". I think what you want is "git remote prune <group>".
>>
>> Are there any implicit groups defined, like "all-remotes" or
>> something? It seems less than desirable to have to define such a group
>> for an operation that IMO is pretty reasonable to expect to happen
>> regularly.
>
> Yes. From "git help remote":
>
> update
> Fetch updates for a named set of remotes in the repository as
> defined by remotes.<group>. If a named group is not specified on
> the command line, the configuration parameter remotes.default will
> get used; if remotes.default is not defined, all remotes which do
> not have the configuration parameter
> remote.<name>.skipDefaultUpdate set to true will be updated. (See
> git-config(1)).
>
> So without defining any other config, "git remote update" will by
> default update everything
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).
and
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 personally haven't found any use for defining remote groups yet to
>> be honest. Its a granularity of operation that hasnt served much
>> purpose for me yet. Although i could see it being useful in the
>> future.
>
> I haven't either. I suspect it would be useful if you had a complex set
> of repo relationships, like an integration manager pulling from an
> upstream but also from other developers.
Now that you have called my attention to them in more detail i suspect
ill end up using them for a few things. Maybe ill try to write up a
doc patch once i have.
>> Generally tho I either want to update and prune one remote only, with
>>
>> git fetch $remote; git prune $remote,
>
> It might be useful if "remote update" treated an unconfigured group as a
> simple remote. So that "git remote update --prune $remote" would do what
> you wanted here.
It seems reasonable to me that names for groups and remotes should
stay distinct and that remotes are treated as being groups which
contain only the remote of the same name. These would be yet more
implicit groups.
>
> I could even see "remote.*.autoprune" config being useful so you could
> avoid --prune. It is living dangerously, I suppose, for some workflows;
> but I generally consider whatever is in my remote tracking branches to
> be throwaway, and automatically pruning is not really dangerous.
Me too.
>> or i want to update and prune all with something like:
>>
>> git remote update; for r in $(git remote); do git remote prune $r; done;
>>
>> This patch makes the latter better huffman encoded, but I'd kind of
>> expect both to be doable as single commands in terms of how often I
>> want to do them.
>>
>> Maybe git fetch --prune would be a nice complement to this patch.
>
> I think we have tried to keep pruning out of fetch, as fetch does not
> necessarily use or know about tracking branches. But the "git remote
> update $remote" proposal I gave above would do basically the same thing
> (except you would call it "remote update" instead of "fetch").
Ok, that makes sense. I see why fetch would be left out. Thanks for explaining.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
--
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
