Jakub Narebski wrote: > Brandon Casey <casey@xxxxxxxxxxxxxxx> writes: > >> Is 'git-gc --prune' still useful to end users when those in-the-know can use >> git-prune when they really want all loose unreferenced objects to be removed? > > It is one command less to remember (just like with "git tag --verify" > and "git verify-tag"), so I'm all for "git gc --prune" to remain. I think the issue here is that the prune behavior of git-gc is more complex when both 'git-gc' does prune and 'git-gc --prune' does prune, but only one of them is controlled by gc.pruneExpire. From a high level perspective, this is non-obvious and so has to be explicitly outlined in the help text _and_ users have to remember it. The git-gc command and the documentation and suggested work flows can all be simplified by just always doing a safe prune. 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. -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
