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

[demerphq <demerphq@gmail.com>]

2009/4/2 Jeff King <peff@peff.net>:
> On Thu, Apr 02, 2009 at 03:34:15PM +0200, demerphq wrote:
>
>> 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
>
> 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.

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.

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

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

>
>> Although to me having both be allowed and mean the same thing also
>> makes sense.
>
> I think that would make sense, too.

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

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"