{"thread":{"id":"13681","subject":"[RFC/PATCH] git-what: explain what to do next","startedAt":"2008-05-27T08:34:59Z","lastAt":"2008-05-29T14:56:05Z","messageCount":14,"participants":["Santi Béjar","Johannes Schindelin","Stephen R. van den Berg","Steven Walter","Junio C Hamano","Christian Couder","Jon Loeliger"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"77832","messageId":"1211877299-27255-1-git-send-email-sbejar@gmail.com","threadId":"13681","inReplyTo":null,"subject":"[RFC/PATCH] git-what: explain what to do next","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-05-27T08:34:59Z","receivedAt":"2008-05-27T08:34:59Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"In case you don't know the next step, if it is \"git commit\",\n\"git commit --amend\", \"git rebase --continue\" or something else.\n\n---\n\n Hi *,\n\n there are some todo, as:\n\n# TODO: explain the context?\n#         * which commit you are\n#         * which commit you cherry-pick, revert\n#         * how many commits left in the bisect\n#         * ...\n# TODO: Move some logic to \"git commit\"?\n# TODO: Show the help from \"git cherry-pick\" -> -c $sha1 ...\n\n What do you think about the idea and the implementation?\n\n Santi\n\n .gitignore                    |    1 +\n Makefile                      |    1 +\n git-am.sh                     |   12 ++++++++++++\n git-bisect.sh                 |   37 ++++++++++++++++++++++++++++++++++++-\n git-merge.sh                  |   24 +++++++++++++++++++++---\n git-rebase--interactive.sh    |   25 ++++++++++++++++---------\n git-rebase.sh                 |   10 +++++++++-\n git-what.sh                   |   23 +++++++++++++++++++++++\n t/t3404-rebase-interactive.sh |   37 +++++++++++++++++++++++++++++++++++++\n t/t7800/expect_am             |    3 +++\n t/t7800/expect_bisect_bad     |    2 ++\n t/t7800/expect_bisect_both    |    5 +++++\n t/t7800/expect_bisect_good    |    2 ++\n t/t7800/expect_bisect_start   |    3 +++\n t/t7800/expect_cherry_pick    |    2 ++\n t/t7800/expect_merge          |    2 ++\n t/t7800/expect_merge_squash   |    2 ++\n t/t7800/expect_rebase         |    6 ++++++\n t/t7800/expect_revert         |    2 ++\n 19 files changed, 185 insertions(+), 14 deletions(-)\n create mode 100644 git-what.sh\n create mode 100644 t/t7800/expect_am\n create mode 100644 t/t7800/expect_bisect_bad\n create mode 100644 t/t7800/expect_bisect_both\n create mode 100644 t/t7800/expect_bisect_good\n create mode 100644 t/t7800/expect_bisect_start\n create mode 100644 t/t7800/expect_cherry_pick\n create mode 100644 t/t7800/expect_merge\n create mode 100644 t/t7800/expect_merge_squash\n create mode 100644 t/t7800/expect_rebase\n create mode 100644 t/t7800/expect_revert\n\ndiff --git a/.gitignore b/.gitignore\nindex 4ff2fec..7d2b1a6 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -137,6 +137,7 @@ git-var\n git-verify-pack\n git-verify-tag\n git-web--browse\n+git-what\n git-whatchanged\n git-write-tree\n git-core-*/?*\ndiff --git a/Makefile b/Makefile\nindex f08d5f7..1d23241 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -254,6 +254,7 @@ SCRIPT_SH += git-sh-setup.sh\n SCRIPT_SH += git-stash.sh\n SCRIPT_SH += git-submodule.sh\n SCRIPT_SH += git-web--browse.sh\n+SCRIPT_SH += git-what.sh\n \n SCRIPT_PERL += git-add--interactive.perl\n SCRIPT_PERL += git-archimport.perl\ndiff --git a/git-am.sh b/git-am.sh\nindex b48096e..2cfb430 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -22,6 +22,7 @@ p=              pass it through git-apply\n resolvemsg=     override error message when patch failure occurs\n r,resolved      to be used after a patch failure\n skip            skip the current patch\n+what            explain what to do if in the middle of an am\n rebasing        (internal use for git-rebase)\"\n \n . git-sh-setup\n@@ -33,6 +34,7 @@ cd_to_toplevel\n git var GIT_COMMITTER_IDENT >/dev/null || exit\n \n stop_here () {\n+    [ \"$what\" = t ] && exit\n     echo \"$1\" >\"$dotest/next\"\n     exit 1\n }\n@@ -122,6 +124,7 @@ dotest=\".dotest\"\n sign= utf8=t keep= skip= interactive= resolved= binary= rebasing=\n resolvemsg= resume=\n git_apply_opt=\n+what=\n \n while test $# != 0\n do\n@@ -155,6 +158,8 @@ do\n \t\tgit_apply_opt=\"$git_apply_opt $1=$2\"; shift ;;\n \t-C|-p)\n \t\tgit_apply_opt=\"$git_apply_opt $1$2\"; shift ;;\n+\t--what)\n+\t\twhat=t ;;\n \t--)\n \t\tshift; break ;;\n \t*)\n@@ -163,6 +168,13 @@ do\n \tshift\n done\n \n+if test -n \"$what\" ; then\n+   test ! -e \"$dotest/next\" && exit 1\n+   echo \"You are in the middle of a \\\"git am\\\":\"\n+   stop_here_user_resolve\n+   exit\n+fi\n+\n # If the dotest directory exists, but we have finished applying all the\n # patches in them, clear it out.\n if test -d \"$dotest\" &&\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 4bcbace..27d3946 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -1,6 +1,6 @@\n #!/bin/sh\n \n-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'\n+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|what]'\n LONG_USAGE='git bisect help\n         print this long help message.\n git bisect start [<bad> [<good>...]] [--] [<pathspec>...]\n@@ -23,6 +23,8 @@ git bisect log\n         show bisect log.\n git bisect run <cmd>...\n         use <cmd>... to automatically bisect.\n+git bisect what...\n+        explain what to do if in the midle of a bisect.\n \n Please use \"git help bisect\" to get the full man page.'\n \n@@ -206,6 +208,14 @@ bisect_next_check() {\n \ttest -n \"$(git for-each-ref \"refs/bisect/good-*\")\" || missing_good=t\n \n \tcase \"$missing_good,$missing_bad,$1\" in\n+\t,,what)\n+\t\t# have both good and bad - ok\n+\t\techo \"Test the commit and mark it as\"\n+\t\techo \"bad)  $ git bisect bad\"\n+\t\techo \"good) $ git bisect good\"\n+\t\techo \"skip) $ git bisect skip\"\n+\t\texit\n+\t\t;;\n \t,,*)\n \t\t: have both good and bad - ok\n \t\t;;\n@@ -213,6 +223,16 @@ bisect_next_check() {\n \t\t# do not have both but not asked to fail - just report.\n \t\tfalse\n \t\t;;\n+\t,t,what)\n+\t\t# have good but not bad.\n+\t\techo \"No bad commit, mark one with \\\"git bisect bad <rev>\"\\\"\n+\t\texit\n+\t\t;;\n+\tt,,what)\n+\t\t# have bad but not good.\n+\t\techo \"No good commit, mark one with \\\"git bisect good <rev>\\\"\"\n+\t\texit\n+\t\t;;\n \tt,,good)\n \t\t# have bad but not good.  we could bisect although\n \t\t# this is less optimum.\n@@ -224,6 +244,14 @@ bisect_next_check() {\n \t\tfi\n \t\t: bisect without good...\n \t\t;;\n+\tt,t,what)\n+\t\t# TODO: Reuse the text in the next case\n+\t\techo 'You need to give me at least one good' \\\n+\t\t\t'and one bad revisions.'\n+\t\techo '(You can use \"git bisect bad\" and' \\\n+\t\t\t'\"git bisect good\" for that.)'\n+\t\texit\n+\t\t;;\n \t*)\n \t\tTHEN=''\n \t\ttest -f \"$GIT_DIR/BISECT_NAMES\" || {\n@@ -497,6 +525,11 @@ bisect_run () {\n     done\n }\n \n+bisect_what () {\n+\ttest -s \"$GIT_DIR/BISECT_START\" || return 1\n+\techo \"You are in the middle of a bisect:\"\n+\tbisect_next_check what\n+}\n \n case \"$#\" in\n 0)\n@@ -524,6 +557,8 @@ case \"$#\" in\n \tcat \"$GIT_DIR/BISECT_LOG\" ;;\n     run)\n         bisect_run \"$@\" ;;\n+    what)\n+\tbisect_what ;;\n     *)\n         usage ;;\n     esac\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 5fc5f52..a729621 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -17,6 +17,7 @@ commit               perform a commit if the merge sucesses (default)\n ff                   allow fast forward (default)\n s,strategy=          merge strategy to use\n m,message=           message to be used for the merge commit (if any)\n+what                 explain what to do if in the middle of a merge\n \"\n \n SUBDIRECTORY_OK=Yes\n@@ -24,9 +25,6 @@ SUBDIRECTORY_OK=Yes\n require_work_tree\n cd_to_toplevel\n \n-test -z \"$(git ls-files -u)\" ||\n-\tdie \"You are in the middle of a conflicted merge.\"\n-\n LF='\n '\n \n@@ -40,6 +38,7 @@ use_strategies=\n allow_fast_forward=t\n allow_trivial_merge=t\n squash= no_commit= log_arg=\n+what=\n \n dropsave() {\n \trm -f -- \"$GIT_DIR/MERGE_HEAD\" \"$GIT_DIR/MERGE_MSG\" \\\n@@ -186,6 +185,9 @@ parse_config () {\n \t\t\tmerge_msg=\"$1\"\n \t\t\thave_message=t\n \t\t\t;;\n+\t\t--what)\n+\t\t\tshift\n+\t\t\twhat=t ;;\n \t\t--)\n \t\t\tshift\n \t\t\tbreak ;;\n@@ -212,6 +214,22 @@ fi\n parse_config \"$@\"\n while test $args_left -lt $#; do shift; done\n \n+if test -n \"$what\" ; then\n+     if test -f \"$GIT_DIR\"/MERGE_HEAD ; then\n+\t echo \"You are in the middle of a merge:\"\n+\t echo \"Fix conflicts and then commit the result.\"\n+\t exit\n+     elif test -f \"$GIT_DIR\"/SQUASH_MSG ; then\n+\t echo \"You are in the middle of a merge --squash:\"\n+\t echo \"Fix conflicts and then commit the result.\"\n+\t exit\n+     fi\n+     exit 1\n+fi\n+\n+test -z \"$(git ls-files -u)\" ||\n+\tdie \"You are in the middle of a conflicted merge.\"\n+\n if test -z \"$show_diffstat\"; then\n     test \"$(git config --bool merge.diffstat)\" = false && show_diffstat=false\n     test \"$(git config --bool merge.stat)\" = false && show_diffstat=false\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 8ee08ff..0ca35e2 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -35,6 +35,16 @@ mark the corrected paths with 'git add <paths>', and\n run 'git rebase --continue'\"\n export GIT_CHERRY_PICK_HELP\n \n+AMENDMSG=\"\n+You can amend the commit now, with\n+\n+\tgit commit --amend\n+\n+Once you are satisfied with your changes, run\n+\n+\tgit rebase --continue\"\n+\n+\n warn () {\n \techo \"$*\" >&2\n }\n@@ -263,15 +273,7 @@ do_next () {\n \t\t\tdie_with_patch $sha1 \"Could not apply $sha1... $rest\"\n \t\tmake_patch $sha1\n \t\t: > \"$DOTEST\"/amend\n-\t\twarn\n-\t\twarn \"You can amend the commit now, with\"\n-\t\twarn\n-\t\twarn \"\tgit commit --amend\"\n-\t\twarn\n-\t\twarn \"Once you are satisfied with your changes, run\"\n-\t\twarn\n-\t\twarn \"\tgit rebase --continue\"\n-\t\twarn\n+\t\twarn \"$AMENDMSG\"\n \t\texit 0\n \t\t;;\n \tsquash|s)\n@@ -437,6 +439,11 @@ do\n \t\t\tshift ;;\n \t\tesac\n \t\t;;\n+\t--what)\n+\t\ttest ! -f \"$DOTEST\"/interactive && exit 1\n+\t\ttest -e \"$DOTEST\"/amend && echo \"$AMENDMSG\" && exit\n+\t\techo \"$GIT_CHERRY_PICK_HELP\" && exit\n+\t\t;;\n \t-m|--merge)\n \t\t# we use merge anyway\n \t\t;;\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex dd7dfe1..20afce5 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[--what] [--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n@@ -46,6 +46,7 @@ dotest=$GIT_DIR/.dotest-merge\n prec=4\n verbose=\n git_am_opt=\n+what=\n \n continue_merge () {\n \ttest -n \"$prev_head\" || die \"prev_head must be defined\"\n@@ -249,6 +250,13 @@ do\n \t-C*)\n \t\tgit_am_opt=\"$git_am_opt $1\"\n \t\t;;\n+\t--what)\n+\t\ttest ! -f \".dotest/onto\" && exit 1\n+\t\ttest -f \"$dotest\"/interactive && exec git-rebase--interactive --what\n+\t\techo \"You are in the middle of a rebase:\"\n+\t\techo \"$RESOLVEMSG\"\n+\t\texit\n+\t\t;;\n \t-*)\n \t\tusage\n \t\t;;\ndiff --git a/git-what.sh b/git-what.sh\nnew file mode 100644\nindex 0000000..316f1e3\n--- /dev/null\n+++ b/git-what.sh\n@@ -0,0 +1,23 @@\n+#!/bin/sh\n+\n+commit_what () {\n+    # TODO: Move this to \"git commit\"?\n+    # TODO: Show the help from \"git cherry-pick\" -> -c $sha1 ...\n+    GIT_DIR=$(git rev-parse --git-dir) || return 1\n+    test -f \"$GIT_DIR\"/MERGE_MSG || return 1\n+    echo \"You are in the middle of a prepared commit:\"\n+    echo \"Fix conflicts and then commit the result.\"\n+    return\n+}\n+\n+git bisect what ||\n+git merge --what ||\n+git rebase --what ||\n+commit_what ||\n+git am --what\n+\n+# TODO: explain the context?\n+#         * which commit you are\n+#         * which commit you cherry-pick, revert\n+#         * how many commits left in the bisect\n+#         * ...\n\\ No newline at end of file\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex b9e3dbd..54a6646 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -302,6 +302,12 @@ test_expect_success 'ignore patch if in upstream' '\n \ttest $HEAD = $(git rev-parse HEAD^)\n '\n \n+cat > expect <<EOF\n+When you have resolved this problem run \\\"git rebase --continue\\\".\n+If you would prefer to skip this patch, instead run \\\"git rebase --skip\\\".\n+To restore the original branch and stop rebasing run \\\"git rebase --abort\\\".\n+EOF\n+\n test_expect_success '--continue tries to commit, even for \"edit\"' '\n \tparent=$(git rev-parse HEAD^) &&\n \ttest_tick &&\n@@ -360,4 +366,35 @@ test_expect_success 'rebase with a file named HEAD in worktree' '\n \n '\n \n+cat > expect <<EOF\n+  After resolving the conflicts,\n+mark the corrected paths with 'git add <paths>', and\n+run 'git rebase --continue'\n+EOF\n+\n+test_expect_success 'rebase, git what' '\n+\tgit reset --hard master~1 &&\n+\t! git rebase -i original-branch1 &&\n+\tgit what > output &&\n+\ttest_cmp expect output\n+'\n+\n+cat > expect <<EOF\n+\n+You can amend the commit now, with\n+\n+\tgit commit --amend\n+\n+Once you are satisfied with your changes, run\n+\n+\tgit rebase --continue\n+EOF\n+\n+test_expect_success 'rebase (amend), git what' '\n+\tgit rebase --abort &&\n+\tFAKE_LINES=\"edit 1\" git rebase -i HEAD^ &&\n+\tgit what > output &&\n+\ttest_cmp expect output\n+'\n+\n test_done\ndiff --git a/t/t7800/expect_am b/t/t7800/expect_am\nnew file mode 100644\nindex 0000000..9278d5d\n--- /dev/null\n+++ b/t/t7800/expect_am\n@@ -0,0 +1,3 @@\n+You are in the middle of a \"git am\":\n+When you have resolved this problem run \"git-am --resolved\".\n+If you would prefer to skip this patch, instead run \"git-am --skip\".\ndiff --git a/t/t7800/expect_bisect_bad b/t/t7800/expect_bisect_bad\nnew file mode 100644\nindex 0000000..602751f\n--- /dev/null\n+++ b/t/t7800/expect_bisect_bad\n@@ -0,0 +1,2 @@\n+You are in the middle of a bisect:\n+No good commit, mark one with \"git bisect good <rev>\"\ndiff --git a/t/t7800/expect_bisect_both b/t/t7800/expect_bisect_both\nnew file mode 100644\nindex 0000000..8b0f950\n--- /dev/null\n+++ b/t/t7800/expect_bisect_both\n@@ -0,0 +1,5 @@\n+You are in the middle of a bisect:\n+Test the commit and mark it as\n+bad)  $ git bisect bad\n+good) $ git bisect good\n+skip) $ git bisect skip\ndiff --git a/t/t7800/expect_bisect_good b/t/t7800/expect_bisect_good\nnew file mode 100644\nindex 0000000..c136a27\n--- /dev/null\n+++ b/t/t7800/expect_bisect_good\n@@ -0,0 +1,2 @@\n+You are in the middle of a bisect:\n+No bad commit, mark one with \"git bisect bad <rev>\"\ndiff --git a/t/t7800/expect_bisect_start b/t/t7800/expect_bisect_start\nnew file mode 100644\nindex 0000000..923396b\n--- /dev/null\n+++ b/t/t7800/expect_bisect_start\n@@ -0,0 +1,3 @@\n+You are in the middle of a bisect:\n+You need to give me at least one good and one bad revisions.\n+(You can use \"git bisect bad\" and \"git bisect good\" for that.)\ndiff --git a/t/t7800/expect_cherry_pick b/t/t7800/expect_cherry_pick\nnew file mode 100644\nindex 0000000..60e733e\n--- /dev/null\n+++ b/t/t7800/expect_cherry_pick\n@@ -0,0 +1,2 @@\n+You are in the middle of a prepared commit:\n+Fix conflicts and then commit the result.\ndiff --git a/t/t7800/expect_merge b/t/t7800/expect_merge\nnew file mode 100644\nindex 0000000..2c9b821\n--- /dev/null\n+++ b/t/t7800/expect_merge\n@@ -0,0 +1,2 @@\n+You are in the middle of a merge:\n+Fix conflicts and then commit the result.\ndiff --git a/t/t7800/expect_merge_squash b/t/t7800/expect_merge_squash\nnew file mode 100644\nindex 0000000..3cdd4fa\n--- /dev/null\n+++ b/t/t7800/expect_merge_squash\n@@ -0,0 +1,2 @@\n+You are in the middle of a merge --squash:\n+Fix conflicts and then commit the result.\ndiff --git a/t/t7800/expect_rebase b/t/t7800/expect_rebase\nnew file mode 100644\nindex 0000000..3975cc0\n--- /dev/null\n+++ b/t/t7800/expect_rebase\n@@ -0,0 +1,6 @@\n+You are in the middle of a rebase:\n+\n+When you have resolved this problem run \"git rebase --continue\".\n+If you would prefer to skip this patch, instead run \"git rebase --skip\".\n+To restore the original branch and stop rebasing run \"git rebase --abort\".\n+\ndiff --git a/t/t7800/expect_revert b/t/t7800/expect_revert\nnew file mode 100644\nindex 0000000..60e733e\n--- /dev/null\n+++ b/t/t7800/expect_revert\n@@ -0,0 +1,2 @@\n+You are in the middle of a prepared commit:\n+Fix conflicts and then commit the result.\n-- \n1.5.6.rc0.14.g4e34b.dirty\n"},{"id":"77844","messageId":"alpine.DEB.1.00.0805271151430.30431@racer","threadId":"13681","inReplyTo":"1211877299-27255-1-git-send-email-sbejar@gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-27T10:53:43Z","receivedAt":"2008-05-27T10:53:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 May 2008, Santi Béjar wrote:\n\n> In case you don't know the next step, if it is \"git commit\",\n> \"git commit --amend\", \"git rebase --continue\" or something else.\n\nWe had a patch similar to this already, but I think that the right \napproach is _not_ to teach the single commands to explain their state, but \nto make a new script guessing the current state.  AFAIR we have something \nlike that in the completions already, as an (optional) prompt.\n\nHowever, I think it would make sense to push for that \n.dotest,.git/.dotest-merge -> .git/rebase change _before_ having anything \nlike git-whazzup.sh.\n\nCiao,\nDscho"},{"id":"77851","messageId":"8aa486160805270558v40e7faabh7d4426731693f917@mail.gmail.com","threadId":"13681","inReplyTo":"alpine.DEB.1.00.0805271151430.30431@racer","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-05-27T12:58:23Z","receivedAt":"2008-05-27T12:58:23Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Tue, 27 May 2008, Santi Béjar wrote:\n>\n>> In case you don't know the next step, if it is \"git commit\",\n>> \"git commit --amend\", \"git rebase --continue\" or something else.\n>\n> We had a patch similar to this already, but I think that the right\n> approach is _not_ to teach the single commands to explain their state, but\n> to make a new script guessing the current state.\n\nI think it belongs to each command to know the state, but I have no\nproblem with the single command approach.\n\n>  AFAIR we have something\n> like that in the completions already, as an (optional) prompt.\n\nThanks. And they do it a bit different, I'll use it if it is better than mine.\n\n>\n> However, I think it would make sense to push for that\n> .dotest,.git/.dotest-merge -> .git/rebase change _before_ having anything\n> like git-whazzup.sh.\n\nThat's a problem of the single command approach.\n\nSanti\n"},{"id":"77852","messageId":"alpine.DEB.1.00.0805271411520.30431@racer","threadId":"13681","inReplyTo":"8aa486160805270558v40e7faabh7d4426731693f917@mail.gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-27T13:12:44Z","receivedAt":"2008-05-27T13:12:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 May 2008, Santi Béjar wrote:\n\n> On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n>\n> > On Tue, 27 May 2008, Santi Béjar wrote:\n> >\n> >> In case you don't know the next step, if it is \"git commit\", \"git \n> >> commit --amend\", \"git rebase --continue\" or something else.\n> >\n> > We had a patch similar to this already, but I think that the right \n> > approach is _not_ to teach the single commands to explain their state, \n> > but to make a new script guessing the current state.\n> \n> I think it belongs to each command to know the state, but I have no \n> problem with the single command approach.\n> \n> >  AFAIR we have something like that in the completions already, as an \n> > (optional) prompt.\n> \n> Thanks. And they do it a bit different, I'll use it if it is better than \n> mine.\n> \n> >\n> > However, I think it would make sense to push for that \n> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having \n> > anything like git-whazzup.sh.\n> \n> That's a problem of the single command approach.\n\nSure it is.  But cluttering up the commands for something that is not \nreally proven to be wanted by many is IMO inferior.\n\nCiao,\nDscho\n"},{"id":"77856","messageId":"8aa486160805270637m3fc640bfr9fa51eb917460e5c@mail.gmail.com","threadId":"13681","inReplyTo":"alpine.DEB.1.00.0805271411520.30431@racer","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-05-27T13:37:49Z","receivedAt":"2008-05-27T13:37:49Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Tue, 27 May 2008, Santi Béjar wrote:\n>\n>> On Tue, May 27, 2008 at 12:53 PM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>>\n>> > On Tue, 27 May 2008, Santi Béjar wrote:\n>> >\n>> >> In case you don't know the next step, if it is \"git commit\", \"git\n>> >> commit --amend\", \"git rebase --continue\" or something else.\n>> >\n>> > We had a patch similar to this already, but I think that the right\n>> > approach is _not_ to teach the single commands to explain their state,\n>> > but to make a new script guessing the current state.\n>>\n>> I think it belongs to each command to know the state, but I have no\n>> problem with the single command approach.\n>>\n>> >  AFAIR we have something like that in the completions already, as an\n>> > (optional) prompt.\n>>\n>> Thanks. And they do it a bit different, I'll use it if it is better than\n>> mine.\n>>\n>> >\n>> > However, I think it would make sense to push for that\n>> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having\n>> > anything like git-whazzup.sh.\n>>\n>> That's a problem of the single command approach.\n>\n> Sure it is.  But cluttering up the commands for something that is not\n> really proven to be wanted by many is IMO inferior.\n\nThis is an argument against git-whatzzup.sh in general. Point taken.\n\nMaybe you are right, but I remember that this is something some people\nhas asked in this list a number of times.\n\nMoreover, this could be integrated in \"git status\".\n\nSanti\n"},{"id":"77858","messageId":"20080527135259.GA12551@cuci.nl","threadId":"13681","inReplyTo":"8aa486160805270637m3fc640bfr9fa51eb917460e5c@mail.gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-05-27T13:52:59Z","receivedAt":"2008-05-27T13:52:59Z","isPatch":true,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Santi B?jar wrote:\n>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin\n><Johannes.Schindelin@gmx.de> wrote:\n>> Sure it is.  But cluttering up the commands for something that is not\n>> really proven to be wanted by many is IMO inferior.\n\n>This is an argument against git-whatzzup.sh in general. Point taken.\n\nNot really.  It's an argument against cluttering up the existing core\nwith this stuff.\n\n>Moreover, this could be integrated in \"git status\".\n\nI personally have no need for such a thing, but in effect it is the git\ncommandline equivalent of MS-Office \"Clippy\", which provides a hands-on\ntutorial in git while you are trying to use it (with the subtle yet\nimportant difference that it only provides advice when called).\n\nSo if you'd keep it confined to a shell script externally from the core\ncommands, I could imagine a lot of new (or occasional) users of git being\nrather happy with an \"interactive manual/hands-on tutorial\" like this.\n-- \nSincerely,                                                          srb@cuci.nl\n           Stephen R. van den Berg.\n\nSkiing beyond this point may result in death and/or loss of skiing privileges.\n"},{"id":"77861","messageId":"8aa486160805270721q64dff3f0gfbb9eb5384db027d@mail.gmail.com","threadId":"13681","inReplyTo":"20080527135259.GA12551@cuci.nl","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-05-27T14:21:04Z","receivedAt":"2008-05-27T14:21:04Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, May 27, 2008 at 3:52 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:\n> Santi B?jar wrote:\n>>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin\n>><Johannes.Schindelin@gmx.de> wrote:\n>>> Sure it is.  But cluttering up the commands for something that is not\n>>> really proven to be wanted by many is IMO inferior.\n>\n>>This is an argument against git-whatzzup.sh in general. Point taken.\n>\n> Not really.  It's an argument against cluttering up the existing core\n> with this stuff.\n\nOk. I misunderstood it, sorry.\n\n>\n>>Moreover, this could be integrated in \"git status\".\n>\n> I personally have no need for such a thing, but in effect it is the git\n> commandline equivalent of MS-Office \"Clippy\", which provides a hands-on\n> tutorial in git while you are trying to use it (with the subtle yet\n> important difference that it only provides advice when called).\n\nI don't have experience with Clippy, but my git-what.sh was just\nshowing the help as shown before (well, actually not for bisect but is\neasy to fix).\n\nIt is not a hands-on tutorial, it is more of \"in which state (merging,\nbisecting,...) is my working tree, if it is in the middle of a complex\nprocess (bisect, merge, rebase,...) tell me what was the help\nmessage\". It is not that different from the output of \"git status\",\nbut for states.\n\nSanti\n"},{"id":"77877","messageId":"e06498070805271108t66a45abfy9abb5ed065e59e35@mail.gmail.com","threadId":"13681","inReplyTo":"8aa486160805270721q64dff3f0gfbb9eb5384db027d@mail.gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-05-27T18:08:35Z","receivedAt":"2008-05-27T18:08:35Z","isPatch":true,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, May 27, 2008 at 10:21 AM, Santi Béjar <sbejar@gmail.com> wrote:\n> On Tue, May 27, 2008 at 3:52 PM, Stephen R. van den Berg <srb@cuci.nl> wrote:\n>> Santi B?jar wrote:\n>>>On Tue, May 27, 2008 at 3:12 PM, Johannes Schindelin\n>>><Johannes.Schindelin@gmx.de> wrote:\n>>>> Sure it is.  But cluttering up the commands for something that is not\n>>>> really proven to be wanted by many is IMO inferior.\n\nWANT.\n\n>>>This is an argument against git-whatzzup.sh in general. Point taken.\n>>\n>> Not really.  It's an argument against cluttering up the existing core\n>> with this stuff.\n\nThe only changes I saw were to porcelain, not plumbing (or is this not\nwhat you mean by \"core?\")  I see no problem with making the plumbing\nmore user-friendly.  That is really the only point of the porcelain.\nIf you don't want user-friendly, use the plumbing directly.\n\n> It is not a hands-on tutorial, it is more of \"in which state (merging,\n> bisecting,...) is my working tree, if it is in the middle of a complex\n> process (bisect, merge, rebase,...) tell me what was the help\n> message\". It is not that different from the output of \"git status\",\n> but for states.\n\nSurely it has happened to everyone that you start a rebase, walk away\nand then continue hacking and committing with the rebase still in\nprogress.  It isn't too bad for an experienced user to recover from\nthis state, but prevention is much better than cure.  A simple \"git\nwhat\" command that could remind you of what you were doing would be a\nwelcome addition, in my mind.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"77884","messageId":"7v3ao31omy.fsf@gitster.siamese.dyndns.org","threadId":"13681","inReplyTo":"e06498070805271108t66a45abfy9abb5ed065e59e35@mail.gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-27T20:24:37Z","receivedAt":"2008-05-27T20:24:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Steven Walter\" <stevenrwalter@gmail.com> writes:\n\n> Surely it has happened to everyone that you start a rebase, walk away\n> and then continue hacking and committing with the rebase still in\n> progress.  It isn't too bad for an experienced user to recover from\n> this state, but prevention is much better than cure.  A simple \"git\n> what\" command that could remind you of what you were doing would be a\n> welcome addition, in my mind.\n\nI haven't looked at the patch in question, but I'd agree with the above,\nand that is why I use the $PS1 support in bash completion (especially the\nresent one can tell between \"am\" and \"rebase\", which made it even nicer).\n"},{"id":"77891","messageId":"7vwslfzd0i.fsf@gitster.siamese.dyndns.org","threadId":"13681","inReplyTo":"alpine.DEB.1.00.0805271411520.30431@racer","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-27T20:51:41Z","receivedAt":"2008-05-27T20:51:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> > However, I think it would make sense to push for that \n>> > .dotest,.git/.dotest-merge -> .git/rebase change _before_ having \n>> > anything like git-whazzup.sh.\n>> \n>> That's a problem of the single command approach.\n>\n> Sure it is.  But cluttering up the commands for something that is not \n> really proven to be wanted by many is IMO inferior.\n\nI do not necessarily see them as cluttering, although I'd agree that\nchanges to some scripts may look a bit too intrusive.\n\nYou _could_ argue that the handling of --what option is part of the\nprotocol for commands that want to implement a workflow with sequencing\nelements, just like we have a protocol for commands that want to work from\na subdirectory is to call setup_git_directory() to have it cd up to the\ntop of the work tree and prepend the prefix to all user supplied paths.\n\nHowever, that new protocol this patch introduces need to be documented\nclearly.  It's the new contract \"git-what\" wants to impose on commands\nwith sequencing elements.\n\nBut a problem I see with the patch as an implementation of \"git-what\" is\nthat some commands use other commands as their internal implementation\ndetails.  For example, when you are in the middle of a \"git rebase\"\nsession, which might be using \"git am\" as its internal implementation\ndetail, if you ask the \"are you in the middle of doing something, and if\nso how can I continue?\" question (which is what the \"git-cmd --what\" is\nall about) to \"git am\", before you ask the same question to \"git rebase\",\n\"am\" could say \"Yeah, I have applied a few patches successfully but gave\ncontrol back to the user to resolve conflicts while applying this patch\",\nwhich may be a truthful statement from \"git am\"'s point of view, but is\nnot a useful information from the end user's point of view, as all s/he\ntyped was \"git rebase\".  In addition, if Porcelain X uses Porcelain Y as\nits internal implementation, the series of commands that need to be\nfollowed to continue from a particular sequence point might be different\nbetween the case where the toplevel request was Y and the case where it\nwas X.  Not just X needs to know that it uses Y, Y also needs to know that\nthe toplevel command the end user gave could be X which called it and\nbehave differently.  So a nice \"each command knows what its doing\"\nseparation cannot really solve everything in practice.\n\nIn other words, \"git-X --what\" could give a guidance to the \"I've done X,\nnow what can I do?\" situation, but it by itself cannot be used as a basis\nof \"git-what\" to answer \"I'm totally lost and I do not know what I was\ndoing.  Where was I and what should I do next?\"  question.\n"},{"id":"77923","messageId":"8aa486160805280212u742a311gef61676870af147@mail.gmail.com","threadId":"13681","inReplyTo":"7vwslfzd0i.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-05-28T09:12:30Z","receivedAt":"2008-05-28T09:12:30Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, May 27, 2008 at 10:51 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> But a problem I see with the patch as an implementation of \"git-what\" is\n> that some commands use other commands as their internal implementation\n> details.  For example, when you are in the middle of a \"git rebase\"\n> session, which might be using \"git am\" as its internal implementation\n> detail, if you ask the \"are you in the middle of doing something, and if\n> so how can I continue?\" question (which is what the \"git-cmd --what\" is\n> all about) to \"git am\", before you ask the same question to \"git rebase\",\n> \"am\" could say \"Yeah, I have applied a few patches successfully but gave\n> control back to the user to resolve conflicts while applying this patch\",\n> which may be a truthful statement from \"git am\"'s point of view, but is\n> not a useful information from the end user's point of view, as all s/he\n> typed was \"git rebase\".  In addition, if Porcelain X uses Porcelain Y as\n> its internal implementation, the series of commands that need to be\n> followed to continue from a particular sequence point might be different\n> between the case where the toplevel request was Y and the case where it\n> was X.  Not just X needs to know that it uses Y, Y also needs to know that\n> the toplevel command the end user gave could be X which called it and\n> behave differently.  So a nice \"each command knows what its doing\"\n> separation cannot really solve everything in practice.\n\nThis is the job of the git-what, so it first call \"git rebase --what\"\nand then \"git am --what\", and the individual \"git cmd --what\" can be\ndeclared internal.\n\n>\n> In other words, \"git-X --what\" could give a guidance to the \"I've done X,\n> now what can I do?\" situation, but it by itself cannot be used as a basis\n> of \"git-what\" to answer \"I'm totally lost and I do not know what I was\n> doing.  Where was I and what should I do next?\"  question.\n\nI think it does, it is exactly what my patch does, IMHO.\n\nSanti\n"},{"id":"78015","messageId":"200805290639.38134.chriscool@tuxfamily.org","threadId":"13681","inReplyTo":"1211877299-27255-1-git-send-email-sbejar@gmail.com","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-05-29T04:39:38Z","receivedAt":"2008-05-29T04:39:38Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le mardi 27 mai 2008, Santi Béjar a écrit :\n> In case you don't know the next step, if it is \"git commit\",\n> \"git commit --amend\", \"git rebase --continue\" or something else.\n\n[...]\n\n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index 4bcbace..27d3946 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -1,6 +1,6 @@\n>  #!/bin/sh\n>\n> -USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'\n> +USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|wha\n>t]' LONG_USAGE='git bisect help\n>          print this long help message.\n>  git bisect start [<bad> [<good>...]] [--] [<pathspec>...]\n> @@ -23,6 +23,8 @@ git bisect log\n>          show bisect log.\n>  git bisect run <cmd>...\n>          use <cmd>... to automatically bisect.\n> +git bisect what...\n> +        explain what to do if in the midle of a bisect.\n\nPerhaps it's better to add something like this first:\n\ngit bisect status\n\tshow the current bisect state\n\nIt could tell if we are currently bisecting and show the \"good\", \"bad\" \nand \"skip\"ped revs and the content of the BISECT_START and BISECT_NAMES \n(and perhaps BISECT_RUN) files. \n\n>  Please use \"git help bisect\" to get the full man page.'\n>\n> @@ -206,6 +208,14 @@ bisect_next_check() {\n>  \ttest -n \"$(git for-each-ref \"refs/bisect/good-*\")\" || missing_good=t\n>\n>  \tcase \"$missing_good,$missing_bad,$1\" in\n> +\t,,what)\n> +\t\t# have both good and bad - ok\n> +\t\techo \"Test the commit and mark it as\"\n> +\t\techo \"bad)  $ git bisect bad\"\n> +\t\techo \"good) $ git bisect good\"\n> +\t\techo \"skip) $ git bisect skip\"\n> +\t\texit\n> +\t\t;;\n>  \t,,*)\n>\n>  \t\t: have both good and bad - ok\n>\n>  \t\t;;\n> @@ -213,6 +223,16 @@ bisect_next_check() {\n>  \t\t# do not have both but not asked to fail - just report.\n>  \t\tfalse\n>  \t\t;;\n> +\t,t,what)\n> +\t\t# have good but not bad.\n> +\t\techo \"No bad commit, mark one with \\\"git bisect bad <rev>\"\\\"\n> +\t\texit\n> +\t\t;;\n> +\tt,,what)\n> +\t\t# have bad but not good.\n> +\t\techo \"No good commit, mark one with \\\"git bisect good <rev>\\\"\"\n> +\t\texit\n> +\t\t;;\n>  \tt,,good)\n>  \t\t# have bad but not good.  we could bisect although\n>  \t\t# this is less optimum.\n> @@ -224,6 +244,14 @@ bisect_next_check() {\n>  \t\tfi\n>\n>  \t\t: bisect without good...\n>\n>  \t\t;;\n> +\tt,t,what)\n> +\t\t# TODO: Reuse the text in the next case\n> +\t\techo 'You need to give me at least one good' \\\n> +\t\t\t'and one bad revisions.'\n> +\t\techo '(You can use \"git bisect bad\" and' \\\n> +\t\t\t'\"git bisect good\" for that.)'\n> +\t\texit\n> +\t\t;;\n>  \t*)\n>  \t\tTHEN=''\n>  \t\ttest -f \"$GIT_DIR/BISECT_NAMES\" || {\n> @@ -497,6 +525,11 @@ bisect_run () {\n>      done\n>  }\n>\n> +bisect_what () {\n> +\ttest -s \"$GIT_DIR/BISECT_START\" || return 1\n\nIt seems not very friendly to just \"return 1\" when not bisecting.\nAnd before my last patch to use BISECT_START to check if we are bisecting, \nit would perhaps have been better to use 'test -f \"$GIT_DIR/BISECT_NAMES\"'.\n\nThanks,\nChristian.\n"},{"id":"78017","messageId":"7vlk1tpug5.fsf@gitster.siamese.dyndns.org","threadId":"13681","inReplyTo":"200805290639.38134.chriscool@tuxfamily.org","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-29T05:09:46Z","receivedAt":"2008-05-29T05:09:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <chriscool@tuxfamily.org> writes:\n\n> It seems not very friendly to just \"return 1\" when not bisecting.\n> And before my last patch to use BISECT_START to check if we are bisecting, \n> it would perhaps have been better to use 'test -f \"$GIT_DIR/BISECT_NAMES\"'.\n\nThe reason for this silence is because Santi wants to call potential\nculprits in turn and stop when one responds \"Yeah, I am the guilty one who\nthrew a monkey wrench into the user's workflow\".  For that to work, \"No,\nthe user is not in the middle of any interaction with me\" response needs\nto be silent.\n"},{"id":"78049","messageId":"483EC405.6090400@freescale.com","threadId":"13681","inReplyTo":"7vlk1tpug5.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH] git-what: explain what to do next","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-05-29T14:56:05Z","receivedAt":"2008-05-29T14:56:05Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Christian Couder <chriscool@tuxfamily.org> writes:\n> \n>> It seems not very friendly to just \"return 1\" when not bisecting.\n>> And before my last patch to use BISECT_START to check if we are bisecting, \n>> it would perhaps have been better to use 'test -f \"$GIT_DIR/BISECT_NAMES\"'.\n> \n> The reason for this silence is because Santi wants to call potential\n> culprits in turn and stop when one responds \"Yeah, I am the guilty one who\n> threw a monkey wrench into the user's workflow\".  For that to work, \"No,\n> the user is not in the middle of any interaction with me\" response needs\n> to be silent.\n\nHrm.  Do both?  Have the normal interactive user command\nbe more verbose, but let the pseudo-scripted version supply\nan additional --status-only flag as it sequences through\nthe status checks?\n\njdl\n"}]}