Re: [PATCH] git remote update: New option --prune (-p)

From: Jeff King <peff@peff.net>
Date: Apr 2, 2009, 14:31 UTC
Message-ID: <20090402143112.GA26974@coredump.intra.peff.net>
In-Reply-To: <9b18b3110904020717h3a0d4b34h7f4b2b83527e6743@mail.gmail.com>

On Thu, Apr 02, 2009 at 04:17:35PM +0200, demerphq wrote:

Show 7 quoted lines

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

Show 9 quoted lines

> 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