[RFC/PATCH] git-what: explain what to do next

[RFC/PATCH] git-what: explain what to do next

[Santi Béjar]

In case you don't know the next step, if it is "git commit",
"git commit --amend", "git rebase --continue" or something else.

---

 Hi *,

 there are some todo, as:

# TODO: explain the context?
#         * which commit you are
#         * which commit you cherry-pick, revert
#         * how many commits left in the bisect
#         * ...
# TODO: Move some logic to "git commit"?
# TODO: Show the help from "git cherry-pick" -> -c $sha1 ...

 What do you think about the idea and the implementation?

 Santi

 .gitignore                    |    1 +
 Makefile                      |    1 +
 git-am.sh                     |   12 ++++++++++++
 git-bisect.sh                 |   37 ++++++++++++++++++++++++++++++++++++-
 git-merge.sh                  |   24 +++++++++++++++++++++---
 git-rebase--interactive.sh    |   25 ++++++++++++++++---------
 git-rebase.sh                 |   10 +++++++++-
 git-what.sh                   |   23 +++++++++++++++++++++++
 t/t3404-rebase-interactive.sh |   37 +++++++++++++++++++++++++++++++++++++
 t/t7800/expect_am             |    3 +++
 t/t7800/expect_bisect_bad     |    2 ++
 t/t7800/expect_bisect_both    |    5 +++++
 t/t7800/expect_bisect_good    |    2 ++
 t/t7800/expect_bisect_start   |    3 +++
 t/t7800/expect_cherry_pick    |    2 ++
 t/t7800/expect_merge          |    2 ++
 t/t7800/expect_merge_squash   |    2 ++
 t/t7800/expect_rebase         |    6 ++++++
 t/t7800/expect_revert         |    2 ++
 19 files changed, 185 insertions(+), 14 deletions(-)
 create mode 100644 git-what.sh
 create mode 100644 t/t7800/expect_am
 create mode 100644 t/t7800/expect_bisect_bad
 create mode 100644 t/t7800/expect_bisect_both
 create mode 100644 t/t7800/expect_bisect_good
 create mode 100644 t/t7800/expect_bisect_start
 create mode 100644 t/t7800/expect_cherry_pick
 create mode 100644 t/t7800/expect_merge
 create mode 100644 t/t7800/expect_merge_squash
 create mode 100644 t/t7800/expect_rebase
 create mode 100644 t/t7800/expect_revert

diff --git a/.gitignore b/.gitignore
index 4ff2fec..7d2b1a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -137,6 +137,7 @@ git-var
 git-verify-pack
 git-verify-tag
 git-web--browse
+git-what
 git-whatchanged
 git-write-tree
 git-core-*/?*
diff --git a/Makefile b/Makefile
index f08d5f7..1d23241 100644
--- a/Makefile
+++ b/Makefile
@@ -254,6 +254,7 @@ SCRIPT_SH += git-sh-setup.sh
 SCRIPT_SH += git-stash.sh
 SCRIPT_SH += git-submodule.sh
 SCRIPT_SH += git-web--browse.sh
+SCRIPT_SH += git-what.sh
 
 SCRIPT_PERL += git-add--interactive.perl
 SCRIPT_PERL += git-archimport.perl
diff --git a/git-am.sh b/git-am.sh
index b48096e..2cfb430 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,6 +22,7 @@ p=              pass it through git-apply
 resolvemsg=     override error message when patch failure occurs
 r,resolved      to be used after a patch failure
 skip            skip the current patch
+what            explain what to do if in the middle of an am
 rebasing        (internal use for git-rebase)"
 
 . git-sh-setup
@@ -33,6 +34,7 @@ cd_to_toplevel
 git var GIT_COMMITTER_IDENT >/dev/null || exit
 
 stop_here () {
+    [ "$what" = t ] && exit
     echo "$1" >"$dotest/next"
     exit 1
 }
@@ -122,6 +124,7 @@ dotest=".dotest"
 sign= utf8=t keep= skip= interactive= resolved= binary= rebasing=
 resolvemsg= resume=
 git_apply_opt=
+what=
 
 while test $# != 0
 do
@@ -155,6 +158,8 @@ do
 		git_apply_opt="$git_apply_opt $1=$2"; shift ;;
 	-C|-p)
 		git_apply_opt="$git_apply_opt $1$2"; shift ;;
+	--what)
+		what=t ;;
 	--)
 		shift; break ;;
 	*)
@@ -163,6 +168,13 @@ do
 	shift
 done
 
+if test -n "$what" ; then
+   test ! -e "$dotest/next" && exit 1
+   echo "You are in the middle of a \"git am\":"
+   stop_here_user_resolve
+   exit
+fi
+
 # If the dotest directory exists, but we have finished applying all the
 # patches in them, clear it out.
 if test -d "$dotest" &&
diff --git a/git-bisect.sh b/git-bisect.sh
index 4bcbace..27d3946 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|what]'
 LONG_USAGE='git bisect help
         print this long help message.
 git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -23,6 +23,8 @@ git bisect log
         show bisect log.
 git bisect run <cmd>...
         use <cmd>... to automatically bisect.
+git bisect what...
+        explain what to do if in the midle of a bisect.
 
 Please use "git help bisect" to get the full man page.'
 
@@ -206,6 +208,14 @@ bisect_next_check() {
 	test -n "$(git for-each-ref "refs/bisect/good-*")" || missing_good=t
 
 	case "$missing_good,$missing_bad,$1" in
+	,,what)
+		# have both good and bad - ok
+		echo "Test the commit and mark it as"
+		echo "bad)  $ git bisect bad"
+		echo "good) $ git bisect good"
+		echo "skip) $ git bisect skip"
+		exit
+		;;
 	,,*)
 		: have both good and bad - ok
 		;;
@@ -213,6 +223,16 @@ bisect_next_check() {
 		# do not have both but not asked to fail - just report.
 		false
 		;;
+	,t,what)
+		# have good but not bad.
+		echo "No bad commit, mark one with \"git bisect bad <rev>"\"
+		exit
+		;;
+	t,,what)
+		# have bad but not good.
+		echo "No good commit, mark one with \"git bisect good <rev>\""
+		exit
+		;;
 	t,,good)
 		# have bad but not good.  we could bisect although
 		# this is less optimum.
@@ -224,6 +244,14 @@ bisect_next_check() {
 		fi
 		: bisect without good...
 		;;
+	t,t,what)
+		# TODO: Reuse the text in the next case
+		echo 'You need to give me at least one good' \
+			'and one bad revisions.'
+		echo '(You can use "git bisect bad" and' \
+			'"git bisect good" for that.)'
+		exit
+		;;
 	*)
 		THEN=''
 		test -f "$GIT_DIR/BISECT_NAMES" || {
@@ -497,6 +525,11 @@ bisect_run () {
     done
 }
 
+bisect_what () {
+	test -s "$GIT_DIR/BISECT_START" || return 1
+	echo "You are in the middle of a bisect:"
+	bisect_next_check what
+}
 
 case "$#" in
 0)
@@ -524,6 +557,8 @@ case "$#" in
 	cat "$GIT_DIR/BISECT_LOG" ;;
     run)
         bisect_run "$@" ;;
+    what)
+	bisect_what ;;
     *)
         usage ;;
     esac
diff --git a/git-merge.sh b/git-merge.sh
index 5fc5f52..a729621 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -17,6 +17,7 @@ commit               perform a commit if the merge sucesses (default)
 ff                   allow fast forward (default)
 s,strategy=          merge strategy to use
 m,message=           message to be used for the merge commit (if any)
+what                 explain what to do if in the middle of a merge
 "
 
 SUBDIRECTORY_OK=Yes
@@ -24,9 +25,6 @@ SUBDIRECTORY_OK=Yes
 require_work_tree
 cd_to_toplevel
 
-test -z "$(git ls-files -u)" ||
-	die "You are in the middle of a conflicted merge."
-
 LF='
 '
 
@@ -40,6 +38,7 @@ use_strategies=
 allow_fast_forward=t
 allow_trivial_merge=t
 squash= no_commit= log_arg=
+what=
 
 dropsave() {
 	rm -f -- "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/MERGE_MSG" \
@@ -186,6 +185,9 @@ parse_config () {
 			merge_msg="$1"
 			have_message=t
 			;;
+		--what)
+			shift
+			what=t ;;
 		--)
 			shift
 			break ;;
@@ -212,6 +214,22 @@ fi
 parse_config "$@"
 while test $args_left -lt $#; do shift; done
 
+if test -n "$what" ; then
+     if test -f "$GIT_DIR"/MERGE_HEAD ; then
+	 echo "You are in the middle of a merge:"
+	 echo "Fix conflicts and then commit the result."
+	 exit
+     elif test -f "$GIT_DIR"/SQUASH_MSG ; then
+	 echo "You are in the middle of a merge --squash:"
+	 echo "Fix conflicts and then commit the result."
+	 exit
+     fi
+     exit 1
+fi
+
+test -z "$(git ls-files -u)" ||
+	die "You are in the middle of a conflicted merge."
+
 if test -z "$show_diffstat"; then
     test "$(git config --bool merge.diffstat)" = false && show_diffstat=false
     test "$(git config --bool merge.stat)" = false && show_diffstat=false
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 8ee08ff..0ca35e2 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -35,6 +35,16 @@ mark the corrected paths with 'git add <paths>', and
 run 'git rebase --continue'"
 export GIT_CHERRY_PICK_HELP
 
+AMENDMSG="
+You can amend the commit now, with
+
+	git commit --amend
+
+Once you are satisfied with your changes, run
+
+	git rebase --continue"
+
+
 warn () {
 	echo "$*" >&2
 }
@@ -263,15 +273,7 @@ do_next () {
 			die_with_patch $sha1 "Could not apply $sha1... $rest"
 		make_patch $sha1
 		: > "$DOTEST"/amend
-		warn
-		warn "You can amend the commit now, with"
-		warn
-		warn "	git commit --amend"
-		warn
-		warn "Once you are satisfied with your changes, run"
-		warn
-		warn "	git rebase --continue"
-		warn
+		warn "$AMENDMSG"
 		exit 0
 		;;
 	squash|s)
@@ -437,6 +439,11 @@ do
 			shift ;;
 		esac
 		;;
+	--what)
+		test ! -f "$DOTEST"/interactive && exit 1
+		test -e "$DOTEST"/amend && echo "$AMENDMSG" && exit
+		echo "$GIT_CHERRY_PICK_HELP" && exit
+		;;
 	-m|--merge)
 		# we use merge anyway
 		;;
diff --git a/git-rebase.sh b/git-rebase.sh
index dd7dfe1..20afce5 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,7 +3,7 @@
 # Copyright (c) 2005 Junio C Hamano.
 #
 
-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'
+USAGE='[--what] [--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'
 LONG_USAGE='git-rebase replaces <branch> with a new branch of the
 same name.  When the --onto option is provided the new branch starts
 out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
@@ -46,6 +46,7 @@ dotest=$GIT_DIR/.dotest-merge
 prec=4
 verbose=
 git_am_opt=
+what=
 
 continue_merge () {
 	test -n "$prev_head" || die "prev_head must be defined"
@@ -249,6 +250,13 @@ do
 	-C*)
 		git_am_opt="$git_am_opt $1"
 		;;
+	--what)
+		test ! -f ".dotest/onto" && exit 1
+		test -f "$dotest"/interactive && exec git-rebase--interactive --what
+		echo "You are in the middle of a rebase:"
+		echo "$RESOLVEMSG"
+		exit
+		;;
 	-*)
 		usage
 		;;
diff --git a/git-what.sh b/git-what.sh
new file mode 100644
index 0000000..316f1e3
--- /dev/null
+++ b/git-what.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+commit_what () {
+    # TODO: Move this to "git commit"?
+    # TODO: Show the help from "git cherry-pick" -> -c $sha1 ...
+    GIT_DIR=$(git rev-parse --git-dir) || return 1
+    test -f "$GIT_DIR"/MERGE_MSG || return 1
+    echo "You are in the middle of a prepared commit:"
+    echo "Fix conflicts and then commit the result."
+    return
+}
+
+git bisect what ||
+git merge --what ||
+git rebase --what ||
+commit_what ||
+git am --what
+
+# TODO: explain the context?
+#         * which commit you are
+#         * which commit you cherry-pick, revert
+#         * how many commits left in the bisect
+#         * ...
\ No newline at end of file
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index b9e3dbd..54a6646 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -302,6 +302,12 @@ test_expect_success 'ignore patch if in upstream' '
 	test $HEAD = $(git rev-parse HEAD^)
 '
 
+cat > expect <<EOF
+When you have resolved this problem run \"git rebase --continue\".
+If you would prefer to skip this patch, instead run \"git rebase --skip\".
+To restore the original branch and stop rebasing run \"git rebase --abort\".
+EOF
+
 test_expect_success '--continue tries to commit, even for "edit"' '
 	parent=$(git rev-parse HEAD^) &&
 	test_tick &&
@@ -360,4 +366,35 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
 
 '
 
+cat > expect <<EOF
+  After resolving the conflicts,
+mark the corrected paths with 'git add <paths>', and
+run 'git rebase --continue'
+EOF
+
+test_expect_success 'rebase, git what' '
+	git reset --hard master~1 &&
+	! git rebase -i original-branch1 &&
+	git what > output &&
+	test_cmp expect output
+'
+
+cat > expect <<EOF
+
+You can amend the commit now, with
+
+	git commit --amend
+
+Once you are satisfied with your changes, run
+
+	git rebase --continue
+EOF
+
+test_expect_success 'rebase (amend), git what' '
+	git rebase --abort &&
+	FAKE_LINES="edit 1" git rebase -i HEAD^ &&
+	git what > output &&
+	test_cmp expect output
+'
+
 test_done
diff --git a/t/t7800/expect_am b/t/t7800/expect_am
new file mode 100644
index 0000000..9278d5d
--- /dev/null
+++ b/t/t7800/expect_am
@@ -0,0 +1,3 @@
+You are in the middle of a "git am":
+When you have resolved this problem run "git-am --resolved".
+If you would prefer to skip this patch, instead run "git-am --skip".
diff --git a/t/t7800/expect_bisect_bad b/t/t7800/expect_bisect_bad
new file mode 100644
index 0000000..602751f
--- /dev/null
+++ b/t/t7800/expect_bisect_bad
@@ -0,0 +1,2 @@
+You are in the middle of a bisect:
+No good commit, mark one with "git bisect good <rev>"
diff --git a/t/t7800/expect_bisect_both b/t/t7800/expect_bisect_both
new file mode 100644
index 0000000..8b0f950
--- /dev/null
+++ b/t/t7800/expect_bisect_both
@@ -0,0 +1,5 @@
+You are in the middle of a bisect:
+Test the commit and mark it as
+bad)  $ git bisect bad
+good) $ git bisect good
+skip) $ git bisect skip
diff --git a/t/t7800/expect_bisect_good b/t/t7800/expect_bisect_good
new file mode 100644
index 0000000..c136a27
--- /dev/null
+++ b/t/t7800/expect_bisect_good
@@ -0,0 +1,2 @@
+You are in the middle of a bisect:
+No bad commit, mark one with "git bisect bad <rev>"
diff --git a/t/t7800/expect_bisect_start b/t/t7800/expect_bisect_start
new file mode 100644
index 0000000..923396b
--- /dev/null
+++ b/t/t7800/expect_bisect_start
@@ -0,0 +1,3 @@
+You are in the middle of a bisect:
+You need to give me at least one good and one bad revisions.
+(You can use "git bisect bad" and "git bisect good" for that.)
diff --git a/t/t7800/expect_cherry_pick b/t/t7800/expect_cherry_pick
new file mode 100644
index 0000000..60e733e
--- /dev/null
+++ b/t/t7800/expect_cherry_pick
@@ -0,0 +1,2 @@
+You are in the middle of a prepared commit:
+Fix conflicts and then commit the result.
diff --git a/t/t7800/expect_merge b/t/t7800/expect_merge
new file mode 100644
index 0000000..2c9b821
--- /dev/null
+++ b/t/t7800/expect_merge
@@ -0,0 +1,2 @@
+You are in the middle of a merge:
+Fix conflicts and then commit the result.
diff --git a/t/t7800/expect_merge_squash b/t/t7800/expect_merge_squash
new file mode 100644
index 0000000..3cdd4fa
--- /dev/null
+++ b/t/t7800/expect_merge_squash
@@ -0,0 +1,2 @@
+You are in the middle of a merge --squash:
+Fix conflicts and then commit the result.
diff --git a/t/t7800/expect_rebase b/t/t7800/expect_rebase
new file mode 100644
index 0000000..3975cc0
--- /dev/null
+++ b/t/t7800/expect_rebase
@@ -0,0 +1,6 @@
+You are in the middle of a rebase:
+
+When you have resolved this problem run "git rebase --continue".
+If you would prefer to skip this patch, instead run "git rebase --skip".
+To restore the original branch and stop rebasing run "git rebase --abort".
+
diff --git a/t/t7800/expect_revert b/t/t7800/expect_revert
new file mode 100644
index 0000000..60e733e
--- /dev/null
+++ b/t/t7800/expect_revert
@@ -0,0 +1,2 @@
+You are in the middle of a prepared commit:
+Fix conflicts and then commit the result.
-- 
1.5.6.rc0.14.g4e34b.dirty

Re: [RFC/PATCH] git-what: explain what to do next

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 623 bytes --]

Hi,

On Tue, 27 May 2008, Santi Béjar wrote:

> In case you don't know the next step, if it is "git commit",
> "git commit --amend", "git rebase --continue" or something else.

We had a patch similar to this already, but I think that the right 
approach is _not_ to teach the single commands to explain their state, but 
to make a new script guessing the current state.  AFAIR we have something 
like that in the completions already, as an (optional) prompt.

However, I think it would make sense to push for that 
.dotest,.git/.dotest-merge -> .git/rebase change _before_ having anything 
like git-whazzup.sh.

Ciao,
Dscho

Re: [RFC/PATCH] git-what: explain what to do next

[Santi Béjar]

On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 May 2008, Santi Béjar wrote:
>
>> In case you don't know the next step, if it is "git commit",
>> "git commit --amend", "git rebase --continue" or something else.
>
> We had a patch similar to this already, but I think that the right
> approach is _not_ to teach the single commands to explain their state, but
> to make a new script guessing the current state.

I think it belongs to each command to know the state, but I have no
problem with the single command approach.

>  AFAIR we have something
> like that in the completions already, as an (optional) prompt.

Thanks. And they do it a bit different, I'll use it if it is better than mine.

>
> However, I think it would make sense to push for that
> .dotest,.git/.dotest-merge -> .git/rebase change _before_ having anything
> like git-whazzup.sh.

That's a problem of the single command approach.

Santi

Re: [RFC/PATCH] git-what: explain what to do next

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1202 bytes --]

Hi,

On Tue, 27 May 2008, Santi Béjar wrote:

> On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Tue, 27 May 2008, Santi Béjar wrote:
> >
> >> In case you don't know the next step, if it is "git commit", "git 
> >> commit --amend", "git rebase --continue" or something else.
> >
> > We had a patch similar to this already, but I think that the right 
> > approach is _not_ to teach the single commands to explain their state, 
> > but to make a new script guessing the current state.
> 
> I think it belongs to each command to know the state, but I have no 
> problem with the single command approach.
> 
> >  AFAIR we have something like that in the completions already, as an 
> > (optional) prompt.
> 
> Thanks. And they do it a bit different, I'll use it if it is better than 
> mine.
> 
> >
> > However, I think it would make sense to push for that 
> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having 
> > anything like git-whazzup.sh.
> 
> That's a problem of the single command approach.

Sure it is.  But cluttering up the commands for something that is not 
really proven to be wanted by many is IMO inferior.

Ciao,
Dscho

Re: [RFC/PATCH] git-what: explain what to do next

[Santi Béjar]

On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 27 May 2008, Santi Béjar wrote:
>
>> On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Tue, 27 May 2008, Santi Béjar wrote:
>> >
>> >> In case you don't know the next step, if it is "git commit", "git
>> >> commit --amend", "git rebase --continue" or something else.
>> >
>> > We had a patch similar to this already, but I think that the right
>> > approach is _not_ to teach the single commands to explain their state,
>> > but to make a new script guessing the current state.
>>
>> I think it belongs to each command to know the state, but I have no
>> problem with the single command approach.
>>
>> >  AFAIR we have something like that in the completions already, as an
>> > (optional) prompt.
>>
>> Thanks. And they do it a bit different, I'll use it if it is better than
>> mine.
>>
>> >
>> > However, I think it would make sense to push for that
>> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having
>> > anything like git-whazzup.sh.
>>
>> That's a problem of the single command approach.
>
> Sure it is.  But cluttering up the commands for something that is not
> really proven to be wanted by many is IMO inferior.

This is an argument against git-whatzzup.sh in general. Point taken.

Maybe you are right, but I remember that this is something some people
has asked in this list a number of times.

Moreover, this could be integrated in "git status".

Santi

Re: [RFC/PATCH] git-what: explain what to do next

[Stephen R. van den Berg]

Santi B?jar wrote:
>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin
><Johannes.Schindelin@gmx.de> wrote:
>> Sure it is.  But cluttering up the commands for something that is not
>> really proven to be wanted by many is IMO inferior.

>This is an argument against git-whatzzup.sh in general. Point taken.

Not really.  It's an argument against cluttering up the existing core
with this stuff.

>Moreover, this could be integrated in "git status".

I personally have no need for such a thing, but in effect it is the git
commandline equivalent of MS-Office "Clippy", which provides a hands-on
tutorial in git while you are trying to use it (with the subtle yet
important difference that it only provides advice when called).

So if you'd keep it confined to a shell script externally from the core
commands, I could imagine a lot of new (or occasional) users of git being
rather happy with an "interactive manual/hands-on tutorial" like this.
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg.

Skiing beyond this point may result in death and/or loss of skiing privileges.

Re: [RFC/PATCH] git-what: explain what to do next

[Santi Béjar]

On Tue, May 27, 2008 at 3:52 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
> Santi B?jar wrote:
>>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin
>><Johannes.Schindelin@gmx.de> wrote:
>>> Sure it is.  But cluttering up the commands for something that is not
>>> really proven to be wanted by many is IMO inferior.
>
>>This is an argument against git-whatzzup.sh in general. Point taken.
>
> Not really.  It's an argument against cluttering up the existing core
> with this stuff.

Ok. I misunderstood it, sorry.

>
>>Moreover, this could be integrated in "git status".
>
> I personally have no need for such a thing, but in effect it is the git
> commandline equivalent of MS-Office "Clippy", which provides a hands-on
> tutorial in git while you are trying to use it (with the subtle yet
> important difference that it only provides advice when called).

I don't have experience with Clippy, but my git-what.sh was just
showing the help as shown before (well, actually not for bisect but is
easy to fix).

It is not a hands-on tutorial, it is more of "in which state (merging,
bisecting,...) is my working tree, if it is in the middle of a complex
process (bisect, merge, rebase,...) tell me what was the help
message". It is not that different from the output of "git status",
but for states.

Santi

Re: [RFC/PATCH] git-what: explain what to do next

[Steven Walter]

On Tue, May 27, 2008 at 10:21 AM, Santi Béjar <sbejar@gmail.com> wrote:
> On Tue, May 27, 2008 at 3:52 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:
>> Santi B?jar wrote:
>>>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin
>>><Johannes.Schindelin@gmx.de> wrote:
>>>> Sure it is.  But cluttering up the commands for something that is not
>>>> really proven to be wanted by many is IMO inferior.

WANT.

>>>This is an argument against git-whatzzup.sh in general. Point taken.
>>
>> Not really.  It's an argument against cluttering up the existing core
>> with this stuff.

The only changes I saw were to porcelain, not plumbing (or is this not
what you mean by "core?")  I see no problem with making the plumbing
more user-friendly.  That is really the only point of the porcelain.
If you don't want user-friendly, use the plumbing directly.

> It is not a hands-on tutorial, it is more of "in which state (merging,
> bisecting,...) is my working tree, if it is in the middle of a complex
> process (bisect, merge, rebase,...) tell me what was the help
> message". It is not that different from the output of "git status",
> but for states.

Surely it has happened to everyone that you start a rebase, walk away
and then continue hacking and committing with the rebase still in
progress.  It isn't too bad for an experienced user to recover from
this state, but prevention is much better than cure.  A simple "git
what" command that could remind you of what you were doing would be a
welcome addition, in my mind.
-- 
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
 -Robert Heinlein

Re: [RFC/PATCH] git-what: explain what to do next

[Junio C Hamano]

"Steven Walter" <stevenrwalter@gmail.com> writes:

> Surely it has happened to everyone that you start a rebase, walk away
> and then continue hacking and committing with the rebase still in
> progress.  It isn't too bad for an experienced user to recover from
> this state, but prevention is much better than cure.  A simple "git
> what" command that could remind you of what you were doing would be a
> welcome addition, in my mind.

I haven't looked at the patch in question, but I'd agree with the above,
and that is why I use the $PS1 support in bash completion (especially the
resent one can tell between "am" and "rebase", which made it even nicer).

Re: [RFC/PATCH] git-what: explain what to do next

[Junio C Hamano]

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

>> > However, I think it would make sense to push for that 
>> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having 
>> > anything like git-whazzup.sh.
>> 
>> That's a problem of the single command approach.
>
> Sure it is.  But cluttering up the commands for something that is not 
> really proven to be wanted by many is IMO inferior.

I do not necessarily see them as cluttering, although I'd agree that
changes to some scripts may look a bit too intrusive.

You _could_ argue that the handling of --what option is part of the
protocol for commands that want to implement a workflow with sequencing
elements, just like we have a protocol for commands that want to work from
a subdirectory is to call setup_git_directory() to have it cd up to the
top of the work tree and prepend the prefix to all user supplied paths.

However, that new protocol this patch introduces need to be documented
clearly.  It's the new contract "git-what" wants to impose on commands
with sequencing elements.

But a problem I see with the patch as an implementation of "git-what" is
that some commands use other commands as their internal implementation
details.  For example, when you are in the middle of a "git rebase"
session, which might be using "git am" as its internal implementation
detail, if you ask the "are you in the middle of doing something, and if
so how can I continue?" question (which is what the "git-cmd --what" is
all about) to "git am", before you ask the same question to "git rebase",
"am" could say "Yeah, I have applied a few patches successfully but gave
control back to the user to resolve conflicts while applying this patch",
which may be a truthful statement from "git am"'s point of view, but is
not a useful information from the end user's point of view, as all s/he
typed was "git rebase".  In addition, if Porcelain X uses Porcelain Y as
its internal implementation, the series of commands that need to be
followed to continue from a particular sequence point might be different
between the case where the toplevel request was Y and the case where it
was X.  Not just X needs to know that it uses Y, Y also needs to know that
the toplevel command the end user gave could be X which called it and
behave differently.  So a nice "each command knows what its doing"
separation cannot really solve everything in practice.

In other words, "git-X --what" could give a guidance to the "I've done X,
now what can I do?" situation, but it by itself cannot be used as a basis
of "git-what" to answer "I'm totally lost and I do not know what I was
doing.  Where was I and what should I do next?"  question.

Re: [RFC/PATCH] git-what: explain what to do next

[Santi Béjar]

On Tue, May 27, 2008 at 10:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> But a problem I see with the patch as an implementation of "git-what" is
> that some commands use other commands as their internal implementation
> details.  For example, when you are in the middle of a "git rebase"
> session, which might be using "git am" as its internal implementation
> detail, if you ask the "are you in the middle of doing something, and if
> so how can I continue?" question (which is what the "git-cmd --what" is
> all about) to "git am", before you ask the same question to "git rebase",
> "am" could say "Yeah, I have applied a few patches successfully but gave
> control back to the user to resolve conflicts while applying this patch",
> which may be a truthful statement from "git am"'s point of view, but is
> not a useful information from the end user's point of view, as all s/he
> typed was "git rebase".  In addition, if Porcelain X uses Porcelain Y as
> its internal implementation, the series of commands that need to be
> followed to continue from a particular sequence point might be different
> between the case where the toplevel request was Y and the case where it
> was X.  Not just X needs to know that it uses Y, Y also needs to know that
> the toplevel command the end user gave could be X which called it and
> behave differently.  So a nice "each command knows what its doing"
> separation cannot really solve everything in practice.

This is the job of the git-what, so it first call "git rebase --what"
and then "git am --what", and the individual "git cmd --what" can be
declared internal.

>
> In other words, "git-X --what" could give a guidance to the "I've done X,
> now what can I do?" situation, but it by itself cannot be used as a basis
> of "git-what" to answer "I'm totally lost and I do not know what I was
> doing.  Where was I and what should I do next?"  question.

I think it does, it is exactly what my patch does, IMHO.

Santi

Re: [RFC/PATCH] git-what: explain what to do next

[Christian Couder]

Le mardi 27 mai 2008, Santi Béjar a écrit :
> In case you don't know the next step, if it is "git commit",
> "git commit --amend", "git rebase --continue" or something else.

[...]

> diff --git a/git-bisect.sh b/git-bisect.sh
> index 4bcbace..27d3946 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>
> -USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
> +USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|wha
>t]' LONG_USAGE='git bisect help
>          print this long help message.
>  git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
> @@ -23,6 +23,8 @@ git bisect log
>          show bisect log.
>  git bisect run <cmd>...
>          use <cmd>... to automatically bisect.
> +git bisect what...
> +        explain what to do if in the midle of a bisect.

Perhaps it's better to add something like this first:

git bisect status
	show the current bisect state

It could tell if we are currently bisecting and show the "good", "bad" 
and "skip"ped revs and the content of the BISECT_START and BISECT_NAMES 
(and perhaps BISECT_RUN) files. 

>  Please use "git help bisect" to get the full man page.'
>
> @@ -206,6 +208,14 @@ bisect_next_check() {
>  	test -n "$(git for-each-ref "refs/bisect/good-*")" || missing_good=t
>
>  	case "$missing_good,$missing_bad,$1" in
> +	,,what)
> +		# have both good and bad - ok
> +		echo "Test the commit and mark it as"
> +		echo "bad)  $ git bisect bad"
> +		echo "good) $ git bisect good"
> +		echo "skip) $ git bisect skip"
> +		exit
> +		;;
>  	,,*)
>
>  		: have both good and bad - ok
>
>  		;;
> @@ -213,6 +223,16 @@ bisect_next_check() {
>  		# do not have both but not asked to fail - just report.
>  		false
>  		;;
> +	,t,what)
> +		# have good but not bad.
> +		echo "No bad commit, mark one with \"git bisect bad <rev>"\"
> +		exit
> +		;;
> +	t,,what)
> +		# have bad but not good.
> +		echo "No good commit, mark one with \"git bisect good <rev>\""
> +		exit
> +		;;
>  	t,,good)
>  		# have bad but not good.  we could bisect although
>  		# this is less optimum.
> @@ -224,6 +244,14 @@ bisect_next_check() {
>  		fi
>
>  		: bisect without good...
>
>  		;;
> +	t,t,what)
> +		# TODO: Reuse the text in the next case
> +		echo 'You need to give me at least one good' \
> +			'and one bad revisions.'
> +		echo '(You can use "git bisect bad" and' \
> +			'"git bisect good" for that.)'
> +		exit
> +		;;
>  	*)
>  		THEN=''
>  		test -f "$GIT_DIR/BISECT_NAMES" || {
> @@ -497,6 +525,11 @@ bisect_run () {
>      done
>  }
>
> +bisect_what () {
> +	test -s "$GIT_DIR/BISECT_START" || return 1

It seems not very friendly to just "return 1" when not bisecting.
And before my last patch to use BISECT_START to check if we are bisecting, 
it would perhaps have been better to use 'test -f "$GIT_DIR/BISECT_NAMES"'.

Thanks,
Christian.

Re: [RFC/PATCH] git-what: explain what to do next

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> It seems not very friendly to just "return 1" when not bisecting.
> And before my last patch to use BISECT_START to check if we are bisecting, 
> it would perhaps have been better to use 'test -f "$GIT_DIR/BISECT_NAMES"'.

The reason for this silence is because Santi wants to call potential
culprits in turn and stop when one responds "Yeah, I am the guilty one who
threw a monkey wrench into the user's workflow".  For that to work, "No,
the user is not in the middle of any interaction with me" response needs
to be silent.

Re: [RFC/PATCH] git-what: explain what to do next

[Jon Loeliger]

Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> 
>> It seems not very friendly to just "return 1" when not bisecting.
>> And before my last patch to use BISECT_START to check if we are bisecting, 
>> it would perhaps have been better to use 'test -f "$GIT_DIR/BISECT_NAMES"'.
> 
> The reason for this silence is because Santi wants to call potential
> culprits in turn and stop when one responds "Yeah, I am the guilty one who
> threw a monkey wrench into the user's workflow".  For that to work, "No,
> the user is not in the middle of any interaction with me" response needs
> to be silent.

Hrm.  Do both?  Have the normal interactive user command
be more verbose, but let the pseudo-scripted version supply
an additional --status-only flag as it sequences through
the status checks?

jdl