threads / patch / 25413

patch, 2 partsbash: offer refs for 'git bisect start'

Subject: [PATCH 1/2] bash: offer refs for 'git bisect start'

## tl;dr

5 messages between Oct 10, 2010 and Oct 10, 2010. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

SZEDER Gábor· Oct 10, 2010, 21:39 UTC · lore

The completion script only offered path completion after 'git bisect start', although bad and good refs could also be specified before the doubledash.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.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 6756990..eb8ef47 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -912,7 +912,7 @@ _git_bisect ()
 	fi
 
 	case "$subcommand" in
-	bad|good|reset|skip)
+	bad|good|reset|skip|start)
 		__gitcomp "$(__git_refs)"
 		;;
 	*)

-- 
1.7.3.1.148.g2fffa

SZEDER Gábor· Oct 10, 2010, 21:39 UTC · re: SZEDER Gábor · lore

[PATCH 2/2] bash: not all 'git bisect' subcommands make sense when not bisecting

... but only 'start' and 'replay'. The other commands will either error out or offer to start bisecting for the user.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

Show changes to contrib/completion/git-completion.bash +5 −1

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index eb8ef47..1262f72 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -907,7 +907,11 @@ _git_bisect ()
 	local subcommands="start bad good skip reset visualize replay log run"
 	local subcommand="$(__git_find_on_cmdline "$subcommands")"
 	if [ -z "$subcommand" ]; then
-		__gitcomp "$subcommands"
+		if [ -f "$(__gitdir)"/BISECT_START ]; then
+			__gitcomp "$subcommands"
+		else
+			__gitcomp "replay start"
+		fi
 		return
 	fi

-- 
1.7.3.1.148.g2fffa

Sverre Rabbelier· Oct 10, 2010, 22:05 UTC · re: SZEDER Gábor · lore

Re: [PATCH 2/2] bash: not all 'git bisect' subcommands make sense when not bisecting

Heya,

On Sun, Oct 10, 2010 at 23:39, SZEDER Gábor <szeder@ira.uka.de> wrote:

> ... but only 'start' and 'replay'.  The other commands will either
> error out or offer to start bisecting for the user.

I'm not sure, following the same concept "git rebase" should not offer "--continue" if you're not rebasing. It might just be frustrating for the user since they might not realize they're not bisecting yet.

-- 
Cheers,

Sverre Rabbelier

SZEDER Gábor· Oct 10, 2010, 22:12 UTC · re: Sverre Rabbelier · lore

Re: [PATCH 2/2] bash: not all 'git bisect' subcommands make sense when not bisecting

Hi,

On Mon, Oct 11, 2010 at 12:05:52AM +0200, Sverre Rabbelier wrote:

Show 8 quoted lines

> Heya,
> 
> On Sun, Oct 10, 2010 at 23:39, SZEDER Gábor <szeder@ira.uka.de> wrote:
> > ... but only 'start' and 'replay'.  The other commands will either
> > error out or offer to start bisecting for the user.
> 
> I'm not sure, following the same concept "git rebase" should not offer
> "--continue" if you're not rebasing.

Actually, my patch follows the same concept of 'git rebase', because that's exactly what the completion function for 'git rebase' does: it doesn't offer '--continue' (nor '--abort' and '--skip') if you're not rebasing.

Best, Gábor

Sverre Rabbelier· Oct 10, 2010, 22:14 UTC · re: SZEDER Gábor · lore

Re: [PATCH 2/2] bash: not all 'git bisect' subcommands make sense when not bisecting

Heya,

2010/10/11 SZEDER Gábor <szeder@ira.uka.de>:

> Actually, my patch follows the same concept of 'git rebase', because
> that's exactly what the completion function for 'git rebase' does: it
> doesn't offer '--continue' (nor '--abort' and '--skip') if you're not
> rebasing.

Had you only mentioned that in the commit message... ;).

In that case, sounds good!

-- 
Cheers,

Sverre Rabbelier