2009/4/2 Jeff King <peff@xxxxxxxx>: > 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/" -- 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
