patchgit remote update: New option --prune (-p)

With the --prune (or -p) option, git remote update will also prune all the remotes that it fetches. Previously, you had to do a manual git remote prune <remote> for each of the remotes you wanted to prune, and this could be tedious with many remotes.

A single command will now update all remotes, and remove all stale branches: git remote update -p

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/git-remote.txt |    4 ++-
 builtin-remote.c             |   73 ++++++++++++++++++++++++++----------------
 2 files changed, 48 insertions(+), 29 deletions(-)

2009/4/2 Finn Arne Gangstad <finnag@pvv.org>:

Yay!

But one question. It seem to me odd to put this as an option to git remote update, and not git remote prune.

I mean, it seems weird that one must say:

   git remote update --prune

and one cannot say:

   git remote prune --all

especially when there is a `git remote prune` already. It seems a bit counterintuitive to find pruning actions under "update", but not all that strange to find an all "--all" option for the "prune" action.

Although to me having both be allowed and mean the same thing also makes sense.

Anyway, thanks for this regardless, I am looking forward to this functionality. :-)

Cheers, yves

On Thu, Apr 02, 2009 at 03:34:15PM +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>".

I think it makes sense under update as pruning is really just a different (and perhaps slightly more dangerous) form of update. Generally I would only want to run prune after having run update, so combining them makes sense from a workflow perspective.

I think that would make sense, too.

-Peff

2009/4/2 Jeff King <peff@peff.net>:

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.

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.

Generally tho I either want to update and prune one remote only, with

   git fetch $remote; git prune $remote,

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.

Yeah, conceptually they approach the same point from different angles.

And the solution that presents the least surprise to the most users.

Yves

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

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

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.

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

2009/4/2 Jeff King <peff@peff.net>:

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.

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.

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.

Me too.

Ok, that makes sense.  I see why fetch would be left out. Thanks for explaining.

cheers, Yves

On Thu, Apr 02, 2009 at 06:07:33PM +0200, demerphq wrote:

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.

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.

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.

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

You could give the unnamed "default group" a name (like "all"), but then you risk conflict with existing "remotes.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.

-Peff

2009/4/2 Jeff King <peff@peff.net>:

If/when i feel that i understand the subject sufficiently Ill make an attempt. :-)

Yes well an implicit group "default" would be nice.

Or perhpas simply use syntax not likely or expected to be used in the name of a group. Like colon. Or something like that.

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

Id much prefer the default group to be called default. Not "all". Ideally "all" would really be "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

Jeff King <peff@peff.net> writes:

I agree with you that "oh by the way please prune as well" makes perfect sense, but I actually would even go stronger than that---if we _were_ adding this command today, I would probably make "update" prune by default, perhaps with an option to skip the pruning step.

I gave the patch an only cursory look, so I wouldn't comment on the implementation; two things I would look at in the code would be if it makes two connections to the remote to learn the same information (which would be bad) and if it skips the pruning stage if the update stage failed (which would probably be a sane precaution).

On Thu, Apr 02, 2009 at 11:06:56AM -0700, Junio C Hamano wrote:

How bad? git remote update execs "git fetch <remote>" to do the fetching part, and after that the information is lost of course. It might be possible to do a --prune option to fetch instead, and just use that directly.

Yes, this should be fixed.

- Finn Arne

Finn Arne Gangstad <finnag@pvv.org> writes:

I'd say only "could be improved later" bad.

On Thu, Apr 02, 2009 at 01:52:48PM -0700, Junio C Hamano wrote:

Ok. I split the patch into two to make it easier to review. 1/2 just splits out prune_remote() as a separate function, and does not change any behavior. 2/2 adds the new option to remote update.

Finn Arne Gangstad (2):
  builtin-remote.c: Split out prune_remote as a separate function.
  git remote update: New option --prune

 Documentation/git-remote.txt |    4 ++-
 builtin-remote.c             |   76 ++++++++++++++++++++++++++----------------
 2 files changed, 50 insertions(+), 30 deletions(-)

- Finn Arne

prune_remote will be used in update(), so this function was split out to avoid code duplication.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 builtin-remote.c |   56 +++++++++++++++++++++++++++++------------------------
 1 files changed, 31 insertions(+), 25 deletions(-)

With the --prune (or -p) option, git remote update will also prune all the remotes that it fetches. Previously, you had to do a manual git remote prune <remote> for each of the remotes you wanted to prune, and this could be tedious with many remotes.

A single command will now update a set of remotes, and remove all stale branches: git remote update -p [group]

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
 Documentation/git-remote.txt |    4 +++-
 builtin-remote.c             |   20 ++++++++++++++++----
 2 files changed, 19 insertions(+), 5 deletions(-)

Thanks, queued (with a minor C90 fixup).