Johannes Schindelin wrote: > Hi, > > On Wed, 12 Mar 2008, Brandon Casey wrote: > >> I think git-prune is seldomly used by normal users for the reasons Dscho >> described, and I think once the behavior implemented by his patch >> becomes standard it will never be used by normal users (except the ones >> who always use --prune for the reasons Geert Bosch described, and >> they'll probably want the new behavior). So I think git-prune will sink >> a little lower into plumbing and common users won't need to know >> anything about pruning, and only sophisticated users will need to know >> git-prune. > > But because we are nice people, we will deprecate --prune before we remove > it, should we go that route at all. I am not suggesting that git-gc stop parsing --prune and instead start erroring out on it. If it is ok to change the behavior of git-gc, it seems like it is ok to change the behavior of 'git-gc --prune' in the same way, especially if the change makes it less destructive. I would suggest not having the somewhat ambiguous state of 'git-gc' prunes one way and 'git-gc --prune' prunes in another more dangerous way. And only one is controlled by a config option named gc.pruneExpire (_and_ it's not the obvious usage of git-gc which actually has the word 'prune' on the command line). So I hope making --prune a noop fits your definition of nice deprecation. -brandon -- 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
