[PATCH] bash completion: remove deprecated --prune from git-gc

[PATCH] bash completion: remove deprecated --prune from git-gc

[Markus Heidelberg]

Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
 contrib/completion/git-completion.bash |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..9e0c48b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -835,7 +835,7 @@ _git_gc ()
 	local cur="${COMP_WORDS[COMP_CWORD]}"
 	case "$cur" in
 	--*)
-		__gitcomp "--prune --aggressive"
+		__gitcomp "--aggressive"
 		return
 		;;
 	esac
-- 
1.6.1.rc1.54.gd1643

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Johannes Schindelin]

Hi,

On Sat, 13 Dec 2008, Markus Heidelberg wrote:

> -		__gitcomp "--prune --aggressive"
> +		__gitcomp "--aggressive"

git gc --prune is deprecated?  That's news to me.

How would you suggest, then, to remove the loose objects you always get 
with conflicts in a merge?

Ciao,
Dscho

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Jeff King]

On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:

> > -		__gitcomp "--prune --aggressive"
> > +		__gitcomp "--aggressive"
> git gc --prune is deprecated?  That's news to me.

Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
effect, 2008-05-09).

Which annoyingly has no discussion about _why_ it no longer has an
effect. But I suspect it has something to do with 25ee973 (gc: call
"prune --expire 2.weeks.ago" by default, 2008-03-12) by you.

-Peff

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Johannes Schindelin]

Hi,

On Sun, 14 Dec 2008, Jeff King wrote:

> On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
> 
> > > -		__gitcomp "--prune --aggressive"
> > > +		__gitcomp "--aggressive"
> > git gc --prune is deprecated?  That's news to me.
> 
> Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
> effect, 2008-05-09).
> 
> Which annoyingly has no discussion about _why_ it no longer has an
> effect. But I suspect it has something to do with 25ee973 (gc: call
> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.

Oops.

But I thought that git gc --prune does expire _all_ dangling loose 
objects _now_, not with --expire 2.weeks.ago.

Ciao,
Dscho

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Jeff King]

On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:

> > Which annoyingly has no discussion about _why_ it no longer has an
> > effect. But I suspect it has something to do with 25ee973 (gc: call
> > "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
> 
> Oops.
> 
> But I thought that git gc --prune does expire _all_ dangling loose 
> objects _now_, not with --expire 2.weeks.ago.

Nope, see 25ee973. You explicitly wrote:

      Note that this new behaviour makes "--prune" be a no-op.

That being said, I think that is perhaps a reasonable thing for --prune
to do (and I don't think there is any conflict with the name, because
that is what it _used_ to do before becoming a no-op). But nobody has
actually implemented it.

-Peff

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sat, 13 Dec 2008, Markus Heidelberg wrote:
> 
> > -		__gitcomp "--prune --aggressive"
> > +		__gitcomp "--aggressive"
> 
> git gc --prune is deprecated?  That's news to me.

More like "git gc --prune" is no-op now.
 
> How would you suggest, then, to remove the loose objects you always get 
> with conflicts in a merge?

"git gc" does pruning of loose objects, but protected by grace period
for loose objects with gc.pruneexpire

You always have (admittedly lowe level) git-prune.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Brandon Casey]

Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
> 
>>> -		__gitcomp "--prune --aggressive"
>>> +		__gitcomp "--aggressive"
>> git gc --prune is deprecated?  That's news to me.
> 
> Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
> effect, 2008-05-09).
> 
> Which annoyingly has no discussion about _why_ it no longer has an
> effect. But I suspect it has something to do with 25ee973 (gc: call
> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.

I think the nail in the coffin for --prune was a37cce3b, which preceded
9e7d501. I guess the commit message for 9e7d501 made sense with a37cce3b
as a reference. There was another commit around the same time which
claimed that --prune was deprecated even though it still provided some
functionality, hence the "...really has no effect" part.

I definitely remember that Johannes implemented the gc.pruneExpire
functionality, so his "That's news to me" made me laugh. Thanks for
the chuckle Johannes. :)

-brandon

Re: [PATCH] bash completion: remove deprecated --prune from git-gc

[Brandon Casey]

Jeff King wrote:
> On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
> 
>>> Which annoyingly has no discussion about _why_ it no longer has an
>>> effect. But I suspect it has something to do with 25ee973 (gc: call
>>> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
>> Oops.
>>
>> But I thought that git gc --prune does expire _all_ dangling loose 
>> objects _now_, not with --expire 2.weeks.ago.
> 
> Nope, see 25ee973. You explicitly wrote:
> 
>       Note that this new behaviour makes "--prune" be a no-op.
> 
> That being said, I think that is perhaps a reasonable thing for --prune
> to do (and I don't think there is any conflict with the name, because
> that is what it _used_ to do before becoming a no-op). But nobody has
> actually implemented it.

Maybe --mrproper would be a more appropriate name.

-brandon