threads / patch / 13703

patchCompletion: Hint whether amend is the right thing to do.

Subject: [PATCH] Completion: Hint whether amend is the right thing to do.

## tl;dr

6 messages between May 28, 2008 and May 28, 2008. Diffs are folded; open one to read it.

replies: 5people: 3as markdown or json

Robin Rosenberg· May 28, 2008, 14:08 UTC · lore

When you get a conflict during interactive rebase the next thing to do is not to amend, but to continue the rebase. With this change you get a reminder in the prompt.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
 contrib/completion/git-completion.bash |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

I got a couple of broken rebases. Hence this fix.

-- robin

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

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 1698463..a606328 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -82,7 +82,12 @@ __git_ps1 ()
 			b="$(git symbolic-ref HEAD 2>/dev/null)"
 		elif [ -f "$g/.dotest-merge/interactive" ]
 		then
-			r="|REBASE-i"
+			if [ -f "$g/.dotest-merge/amend" ]
+			then
+				r="|REBASE-i-amend"
+			else
+				r="|REBASE-i-continue"
+			fi
 			b="$(cat "$g/.dotest-merge/head-name")"
 		elif [ -d "$g/.dotest-merge" ]
 		then

-- 
1.5.5.1.178.g1f811

Junio C Hamano· May 28, 2008, 15:53 UTC · re: Robin Rosenberg · lore

Re: [PATCH] Completion: Hint whether amend is the right thing to do.

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

Show 33 quoted lines

> When you get a conflict during interactive rebase the next
> thing to do is not to amend, but to continue the rebase.
> With this change you get a reminder in the prompt.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>  contrib/completion/git-completion.bash |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> I got a couple of broken rebases. Hence this fix.
>
> -- robin
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 1698463..a606328 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -82,7 +82,12 @@ __git_ps1 ()
>  			b="$(git symbolic-ref HEAD 2>/dev/null)"
>  		elif [ -f "$g/.dotest-merge/interactive" ]
>  		then
> -			r="|REBASE-i"
> +			if [ -f "$g/.dotest-merge/amend" ]
> +			then
> +				r="|REBASE-i-amend"
> +			else
> +				r="|REBASE-i-continue"
> +			fi
>  			b="$(cat "$g/.dotest-merge/head-name")"
>  		elif [ -d "$g/.dotest-merge" ]
>  		then
> -- 
> 1.5.5.1.178.g1f811

Hmm. The "|REBASE-blah" prefix is already too long for my liking and this makes it even longer X-<

Does this mean that it would help reduce mistakes if "git commit --amend" noticed the presense of .dotest-merge but absense of .dotest-merge/amend and refused to operate, I have to wonder?

Shawn O. Pearce· May 28, 2008, 23:16 UTC · re: Junio C Hamano · lore

Re: [PATCH] Completion: Hint whether amend is the right thing to do.

Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> 
> > When you get a conflict during interactive rebase the next
> > thing to do is not to amend, but to continue the rebase.
> > With this change you get a reminder in the prompt.

...

> Does this mean that it would help reduce mistakes if "git commit --amend"
> noticed the presense of .dotest-merge but absense of .dotest-merge/amend
> and refused to operate, I have to wonder?

Yea, even though rebase and commit are two different tools we don't want the user to amend in the middle of a failed conflict from rebase. Adding the safety valve to commit --amend makes more sense to me than teaching bash to show you the state. Not all of our users use bash. Not all of our bash using users use the bash completion package, or the _git_ps1 function we ship. Etc.

I'd rather see the amend safety net than the bash prompt change.

-- 
Shawn.

Robin Rosenberg· May 28, 2008, 23:33 UTC · re: Junio C Hamano · lore

Re: [PATCH] Completion: Hint whether amend is the right thing to do.

onsdagen den 28 maj 2008 17.53.40 skrev Junio C Hamano:

> Does this mean that it would help reduce mistakes if "git commit --amend"
> noticed the presense of .dotest-merge but absense of .dotest-merge/amend
> and refused to operate, I have to wonder?

Well I found myself making these mistakes. That would probably be better. Shouldn't one block commit without amend too then? And then rebase needs another option to be able to commit. Fixing the prompt was easier at the time .)

-- robin

Junio C Hamano· May 28, 2008, 23:39 UTC · re: Robin Rosenberg · lore

Re: [PATCH] Completion: Hint whether amend is the right thing to do.

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

Show 7 quoted lines

> onsdagen den 28 maj 2008 17.53.40 skrev Junio C Hamano:
>> Does this mean that it would help reduce mistakes if "git commit --amend"
>> noticed the presense of .dotest-merge but absense of .dotest-merge/amend
>> and refused to operate, I have to wonder?
>
> Well I found myself making these mistakes. That would probably be better. 
> Shouldn't one block commit without amend too then?

If you mean to forbid "git commit" during rebase (perhaps interrupted by s/pick/edit/), I do not think that would fly -- it is the advertised way to split a commit into two, if I am not mistaken.

Shawn O. Pearce· May 28, 2008, 23:45 UTC · re: Junio C Hamano · lore

Re: [PATCH] Completion: Hint whether amend is the right thing to do.

Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> 
> > onsdagen den 28 maj 2008 17.53.40 skrev Junio C Hamano:
> >> Does this mean that it would help reduce mistakes if "git commit --amend"
> >> noticed the presense of .dotest-merge but absense of .dotest-merge/amend
> >> and refused to operate, I have to wonder?
> >
> > Well I found myself making these mistakes. That would probably be better. 
> > Shouldn't one block commit without amend too then?
> 
> If you mean to forbid "git commit" during rebase (perhaps interrupted by
> s/pick/edit/), I do not think that would fly -- it is the advertised way
> to split a commit into two, if I am not mistaken.

Right, you don't want to block commit if we stopped for an edit.

But if we stopped because merge-recursive failed due to merge conflicts we want the user to fix up the tree, stage the changes, and call `git rebase --continue` to let rebase continue further.

If further means finish the commit and then immediately stop (as we had failed while picking an edit) , rebase will stop and let the user edit.

We don't need a special flag for rebase to pass to commit, it can just delete the state flag that prevents commits just before it calls commit.

-- 
Shawn.