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
> 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.
> 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.
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.
> 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").
-Peff
--
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
