threads / patch / 16715

patchbash completion: remove deprecated --prune from git-gc

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

## tl;dr

8 messages between Dec 13, 2008 and Dec 15, 2008. Diffs are folded; open one to read it.

replies: 7people: 5as markdown or json

Markus Heidelberg· Dec 13, 2008, 19:08 UTC · lore
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
 contrib/completion/git-completion.bash |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Show changes to contrib/completion/git-completion.bash +1 −1
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
Johannes Schindelin· Dec 14, 2008, 10:38 UTC · re: Markus Heidelberg · lore

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

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

Jeff King· Dec 14, 2008, 11:12 UTC · re: Johannes Schindelin · lore

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

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
Johannes Schindelin· Dec 14, 2008, 11:17 UTC · re: Jeff King · lore

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

Hi,
On Sun, 14 Dec 2008, Jeff King wrote:
Show 12 quoted lines
> 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

Jeff King· Dec 14, 2008, 11:19 UTC · re: Johannes Schindelin · lore

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

On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
Show 8 quoted lines
> > 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
Brandon Casey· Dec 15, 2008, 18:06 UTC · re: Jeff King · lore

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

Jeff King wrote:
Show 18 quoted lines
> 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
Brandon Casey· Dec 15, 2008, 16:51 UTC · re: Jeff King · lore

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

Jeff King wrote:
Show 12 quoted lines
> 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
Jakub Narebski· Dec 14, 2008, 11:23 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 6 quoted lines
> 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

← back to recent threads