Jakub Narebski wrote:
quoted text
> Brandon Casey <casey@nrlssc.navy.mil> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html