{"thread":{"id":"3245","subject":"[PATCH] git-commit: revamp the git-commit semantics.","startedAt":"2006-02-05T10:24:03Z","lastAt":"2006-02-08T05:41:37Z","messageCount":16,"participants":["Junio C Hamano","Marco Costalba","Michael Fischer","Nicolas Pitre","Jon Loeliger"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"15608","messageId":"7vpsm2hzng.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":null,"subject":"[PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-05T10:24:03Z","receivedAt":"2006-02-05T10:24:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I am addressing people who participated with their valuable\ninputs to the earlier \"git commit\" discussion.\n\nHere is my first cut.  I'd appreciate to hear from both\ngit-experienced people and git newcomers how comfortable this\nnew implementation is.  Improvement patches on top of this are\ncertainly appreciated.\n\nThe main focus of this patch is to reduce the confusion factor\nwhile not disrupting experienced git users with trained fingers,\nbut it unfortunately does introduce two incompatible changes:\n\n - When the command decides not to create a commit for whatever\n   reason, the updates made to the index file, either because of\n   --all option or \"-i paths...\" option, are forgotten.\n\n - Traditional \"git commit paths...\" _must_ be spelled as \"git\n   commit -i paths...\".  \"git commit paths...\" means a\n   completely different thing now.\n\nI think the first incompatibility would not break anybody's work\nhabit and I am hoping that everybody considers this to be purely\nan improvement.  It reduces major confusion factor in the\ncurrent implementation when you do:\n\n\t$ edit foo\n        $ git commit -a\n\nand cause the commit to abort by giving it an empty log\nmessage.  In the current implementation, \"git diff\" would not\nshow anything after that, but with this you would see the edit\nof foo.\n\nThe second one is not something I am too happy about, but many\npeople seem to have been confused that running \"git update-index\nfoo\" and then \"git commit bar\" commits both foo and bar.  To\nprevent this change from burning index-aware people too much,\nthis form refuses to run during a merge.  Also to reduce\nconfusion for people who forget differences between \"git diff\" and\n\"git diff HEAD\", it refuses to run when the paths involved do\nnot match between the index and HEAD.\n\n-- >8 --\n[PATCH] git-commit: revamp the git-commit semantics.\n\n - \"git commit\" without _any_ parameter keeps the traditional\n   behaviour.  It commits the current index.\n\n   We commit the whole index even when this form is run from a\n   subdirectory.\n\n - \"git commit --include paths...\" (or \"git commit -i paths...\")\n   is equivalent to:\n\n   \tgit update-index --remove paths...\n        git commit\n\n - \"git commit paths...\" acquires a new semantics.  This is an\n   incompatible change that needs user training, which I am\n   still a bit reluctant to swallow, but enough people seem to\n   have complained that it is confusing to them.  It\n\n   1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds\n      trained git users that the traditional semantics now needs\n      -i flag.\n\n   2. refuses to run if named paths... are different in HEAD and\n      the index (ditto about reminding).  Added paths are OK.\n\n   3. reads HEAD commit into a temporary index file.\n\n   4. updates named paths... from the working tree in this\n      temporary index.\n\n   5. does the same updates of the paths... from the working\n      tree to the real index.\n\n   6. makes a commit using the temporary index that has the\n      current HEAD as the parent, and updates the HEAD with this\n      new commit.\n\n - \"git commit --all\" can run from a subdirectory, but it updates\n   the index with all the modified files and does a whole tree\n   commit.\n\n - In all cases, when the command decides not to create a new\n   commit, the index is left as it was before the command is\n   run.  This means that the two \"git diff\" in the following\n   sequence:\n\n       $ git diff\n       $ git commit -a\n       $ git diff\n\n   would show the same diff if you abort the commit process by\n   making the commit log message empty.\n\nThis commit also introduces much requested --author option.\n\n\t$ git commit --author 'A U Thor <author@example.com>'\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Documentation/core-tutorial.txt |    6 -\n Documentation/git-commit.txt    |   61 ++++++\n git-commit.sh                   |  403 ++++++++++++++++++++++++++++-----------\n t/t1200-tutorial.sh             |    6 -\n 4 files changed, 354 insertions(+), 122 deletions(-)\n\n551045c2a2eefdc85307de5f4b72ba720d095106\ndiff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\nindex 4513ad6..4e6ec0e 100644\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -858,7 +858,7 @@ that branch, and do some work there.\n ------------------------------------------------\n $ git checkout mybranch\n $ echo \"Work, work, work\" >>hello\n-$ git commit -m 'Some work.' hello\n+$ git commit -m 'Some work.' -i hello\n ------------------------------------------------\n \n Here, we just added another line to `hello`, and we used a shorthand for\n@@ -881,7 +881,7 @@ hasn't happened in the `master` branch a\n ------------\n $ echo \"Play, play, play\" >>hello\n $ echo \"Lots of fun\" >>example\n-$ git commit -m 'Some fun.' hello example\n+$ git commit -m 'Some fun.' -i hello example\n ------------\n \n since the master branch is obviously in a much better mood.\n@@ -946,7 +946,7 @@ Work, work, work\n and once you're happy with your manual merge, just do a\n \n ------------\n-$ git commit hello\n+$ git commit -i hello\n ------------\n \n which will very loudly warn you that you're now committing a merge\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 72f96fc..53b64fa 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -8,8 +8,8 @@ git-commit - Record your changes\n SYNOPSIS\n --------\n [verse]\n-'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]\n-\t   [-e] [--] <file>...\n+'git-commit' [-a] [-i] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]\n+\t   [-e] [--author <author>] [--] <file>...\n \n DESCRIPTION\n -----------\n@@ -40,6 +40,10 @@ OPTIONS\n \tTake the commit message from the given file.  Use '-' to\n \tread the message from the standard input.\n \n+--author <author>::\n+\tOverride the author name used in the commit.  Use\n+\t`A U Thor <author@example.com>` format.\n+\n -m <msg>::\n \tUse the given <msg> as the commit message.\n \n@@ -63,17 +67,66 @@ OPTIONS\n \tcommit log message unmodified.  This option lets you\n \tfurther edit the message taken from these sources.\n \n+-i|--include::\n+\tInstead of committing only the files specified on the\n+\tcommand line, update them in the index file and then\n+\tcommit the whole index.  This is the traditional\n+\tbehaviour.\n+\n --::\n \tDo not interpret any more arguments as options.\n \n <file>...::\n-\tUpdate specified paths in the index file before committing.\n-\n+\tCommit only the files specified on the command line.\n+\tThis format cannot be used during a merge, nor when the\n+\tindex and the latest commit does not match on the\n+\tspecified paths to avoid confusion.\n \n If you make a commit and then found a mistake immediately after\n that, you can recover from it with gitlink:git-reset[1].\n \n \n+Discussion\n+----------\n+\n+`git commit` without _any_ parameter commits the tree structure\n+recorded by the current index file.  This is a whole-tree commit\n+even the command is invoked from a subdirectory.\n+\n+`git commit --include paths...` is equivalent to\n+\n+\tgit update-index --remove paths...\n+\tgit commit\n+\n+That is, update the specified paths to the index and then commit\n+the whole tree.\n+\n+`git commit paths...` largely bypasses the index file and\n+commits only the changes made to the specified paths.  It has\n+however several safety valves to prevent confusion.\n+\n+. It refuses to run during a merge (i.e. when\n+  `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users\n+  that the traditional semantics now needs -i flag.\n+\n+. It refuses to run if named `paths...` are different in HEAD\n+  and the index (ditto about reminding).  Added paths are OK.\n+  This is because an earlier `git diff` (not `git diff HEAD`)\n+  would have shown the differences since the last `git\n+  update-index paths...` to the user, and an inexperienced user\n+  may mistakenly think that the changes between the index and\n+  the HEAD (i.e. earlier changes made before the last `git\n+  update-index paths...` was done) are not being committed.\n+\n+. It reads HEAD commit into a temporary index file, updates the\n+  specified `paths...` and makes a commit.  At the same time,\n+  the real index file is also updated with the same `paths...`.\n+\n+`git commit --all` updates the index file with _all_ changes to\n+the working tree, and makes a whole-tree commit, regardless of\n+which subdirectory the command is invoked in.\n+\n+\n Author\n ------\n Written by Linus Torvalds <torvalds@osdl.org> and\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 10946ed..d3325bc 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -1,85 +1,170 @@\n #!/bin/sh\n #\n # Copyright (c) 2005 Linus Torvalds\n-#\n+# Copyright (c) 2006 Junio C Hamano\n+\n+USAGE='[-a] [-i] [-s] [-v | --no-verify]  [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [--author <author>] [<path>...]'\n \n-USAGE='[-a] [-s] [-v | --no-verify]  [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [<path>...]'\n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n \n-all= logfile= use_commit= no_edit= log_given= log_message= verify=t signoff=\n+git-rev-parse --verify HEAD >/dev/null 2>&1 ||\n+initial_commit=t\n+\n+refuse_partial () {\n+\techo >&2 \"$1\"\n+\techo >&2 \"Experienced git users:\"\n+\techo >&2 \"You might have meant to say 'git commit -i paths...', perhaps?\"\n+\texit 1\n+}\n+\n+all=\n+also=\n+logfile=\n+use_commit=\n+no_edit=\n+log_given=\n+log_message=\n+verify=t\n+signoff=\n+force_author=\n while case \"$#\" in 0) break;; esac\n do\n   case \"$1\" in\n+  -F|--F|-f|--f|--fi|--fil|--file)\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      no_edit=t\n+      log_given=t$log_given\n+      logfile=\"$1\"\n+      shift\n+      ;;\n+  -F*|-f*)\n+      no_edit=t\n+      log_given=t$log_given\n+      logfile=`expr \"$1\" : '-[Ff]\\(.*\\)'`\n+      shift\n+      ;;\n+  --F=*|--f=*|--fi=*|--fil=*|--file=*)\n+      no_edit=t\n+      log_given=t$log_given\n+      logfile=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n+      shift\n+      ;;\n   -a|--a|--al|--all)\n-    all=t\n-    shift ;;\n-  -F=*|--f=*|--fi=*|--fil=*|--file=*)\n-    log_given=t$log_given\n-    logfile=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n-    no_edit=t\n-    shift ;;\n-  -F|--f|--fi|--fil|--file)\n-    case \"$#\" in 1) usage ;; esac; shift\n-    log_given=t$log_given\n-    logfile=\"$1\"\n-    no_edit=t\n-    shift ;;\n-  -m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)\n-    log_given=t$log_given\n-    log_message=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n-    no_edit=t\n-    shift ;;\n+      all=t\n+      shift\n+      ;;\n+  --au=*|--aut=*|--auth=*|--autho=*|--author=*)\n+      force_author=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n+      shift\n+      ;;\n+  --au|--aut|--auth|--autho|--author)\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      force_author=\"$1\"\n+      shift\n+      ;;\n+  -e|--e|--ed|--edi|--edit)\n+      no_edit=\n+      shift\n+      ;;\n+  -i|--i|--in|--inc|--incl|--inclu|--includ|--include)\n+      also=t\n+      shift\n+      ;;\n   -m|--m|--me|--mes|--mess|--messa|--messag|--message)\n-    case \"$#\" in 1) usage ;; esac; shift\n-    log_given=t$log_given\n-    log_message=\"$1\"\n-    no_edit=t\n-    shift ;;\n-  -c=*|--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\\\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      log_given=t$log_given\n+      log_message=\"$1\"\n+      no_edit=t\n+      shift\n+      ;;\n+  -m*)\n+      log_given=t$log_given\n+      log_message=`expr \"$1\" : '-m\\(.*\\)'`\n+      no_edit=t\n+      shift\n+      ;;\n+  --m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)\n+      log_given=t$log_given\n+      log_message=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n+      no_edit=t\n+      shift\n+      ;;\n+  -n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)\n+      verify=\n+      shift\n+      ;;\n+  -c)\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      log_given=t$log_given\n+      use_commit=\"$1\"\n+      no_edit=\n+      shift\n+      ;;\n+  --ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\\\n   --reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\\\n   --reedit-messag=*|--reedit-message=*)\n-    log_given=t$log_given\n-    use_commit=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n-    shift ;;\n-  -c|--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\\\n+      log_given=t$log_given\n+      use_commit=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n+      no_edit=\n+      shift\n+      ;;\n+  --ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\\\n   --reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|--reedit-message)\n-    case \"$#\" in 1) usage ;; esac; shift\n-    log_given=t$log_given\n-    use_commit=\"$1\"\n-    shift ;;\n-  -C=*|--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\\\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      log_given=t$log_given\n+      use_commit=\"$1\"\n+      no_edit=\n+      shift\n+      ;;\n+  -C)\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      log_given=t$log_given\n+      use_commit=\"$1\"\n+      no_edit=t\n+      shift\n+      ;;\n+  --reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\\\n   --reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\\\n   --reuse-message=*)\n-    log_given=t$log_given\n-    use_commit=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n-    no_edit=t\n-    shift ;;\n-  -C|--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\\\n+      log_given=t$log_given\n+      use_commit=`expr \"$1\" : '-[^=]*=\\(.*\\)'`\n+      no_edit=t\n+      shift\n+      ;;\n+  --reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\\\n   --reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)\n-    case \"$#\" in 1) usage ;; esac; shift\n-    log_given=t$log_given\n-    use_commit=\"$1\"\n-    no_edit=t\n-    shift ;;\n-  -e|--e|--ed|--edi|--edit)\n-    no_edit=\n-    shift ;;\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      log_given=t$log_given\n+      use_commit=\"$1\"\n+      no_edit=t\n+      shift\n+      ;;\n   -s|--s|--si|--sig|--sign|--signo|--signof|--signoff)\n-    signoff=t\n-    shift ;;\n-  -n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)\n-    verify=\n-    shift ;;\n+      signoff=t\n+      shift\n+      ;;\n   -v|--v|--ve|--ver|--veri|--verif|--verify)\n-    verify=t\n-    shift ;;\n+      verify=t\n+      shift\n+      ;;\n   --)\n-    shift\n-    break ;;\n+      shift\n+      break\n+      ;;\n   -*)\n-     usage ;;\n+      usage\n+      ;;\n   *)\n-    break ;;\n+      break\n+      ;;\n   esac\n done\n \n@@ -88,30 +173,92 @@ tt*)\n   die \"Only one of -c/-C/-F/-m can be used.\" ;;\n esac\n \n-case \"$all,$#\" in\n-t,0)\n-\tgit-diff-files --name-only -z |\n-\tgit-update-index --remove -z --stdin\n-\t;;\n-t,*)\n-\tdie \"Cannot use -a and explicit files at the same time.\"\n-\t;;\n-,0)\n+TOP=`git-rev-parse --show-cdup`\n+\n+case \"$all,$also\" in\n+t,t)\n+\tdie \"Cannot use -a and -i at the same time.\" ;;\n+t,)\n+\tSAVE_INDEX=\"$GIT_DIR/save-index$$\" &&\n+\tcp \"$GIT_DIR/index\" \"$SAVE_INDEX\" &&\n+\t(\n+\t\tif test '' != \"$TOP\"\n+\t\tthen\n+\t\t\tcd \"$TOP\"\n+\t\tfi &&\n+\t\tgit-diff-files --name-only -z |\n+\t\tgit-update-index --remove -z --stdin\n+\t)\n \t;;\n-*)\n-\tgit-diff-files --name-only -z -- \"$@\" |\n+,t)\n+\tcase \"$#\" in\n+\t0) die \"No paths with -i does not make sense.\" ;;\n+\tesac\n+\tSAVE_INDEX=\"$GIT_DIR/save-index$$\" &&\n+\tcp \"$GIT_DIR/index\" \"$SAVE_INDEX\" &&\n+\tgit-diff-files --name-only -z -- \"$@\"  |\n \tgit-update-index --remove -z --stdin\n \t;;\n-esac || exit 1\n+,)\n+\tcase \"$#\" in\n+\t0)\n+\t    ;; # commit as-is\n+\t*)\n+\t    if test -f \"$GIT_DIR/MERGE_HEAD\"\n+\t    then\n+\t\trefuse_partial \"Cannot do a partial commit during a merge.\"\n+\t    fi\n+\t    TMP_INDEX=\"$GIT_DIR/tmp-index$$\"\n+\t    if test -z \"$initial_commit\"\n+\t    then\n+\t\t# make sure index is clean at the specified paths, or\n+\t\t# they are additions.\n+\t\tdirty_in_index=`git-diff-index --cached --name-status \\\n+\t\t\t--diff-filter=DMTXU HEAD -- \"$@\"`\n+\t\ttest -z \"$dirty_in_index\" ||\n+\t\trefuse_partial \"Cannot do a partial commit of paths dirty in index:\n+\n+$dirty_in_index\"\n+\t    fi\n+\t    commit_only=`git-ls-files -- \"$@\"` ;;\n+\tesac\n+\t;;\n+esac\n+\n git-update-index -q --refresh || exit 1\n \n-case \"$verify\" in\n-t)\n-\tif test -x \"$GIT_DIR\"/hooks/pre-commit\n+trap '\n+\ttest -f \"$TMP_INDEX\" && rm -f \"$TMP_INDEX\"\n+\ttest -f \"$SAVE_INDEX\" && mv -f \"$SAVE_INDEX\" \"$GIT_DIR/index\"\n+' 0\n+\n+if test \"$TMP_INDEX\"\n+then\n+\tif test -z \"$initial_commit\"\n \tthen\n-\t\t\"$GIT_DIR\"/hooks/pre-commit || exit\n-\tfi\n-esac\n+\t\tGIT_INDEX_FILE=\"$TMP_INDEX\" git-read-tree HEAD\n+\telse\n+\t\trm -f \"$TMP_INDEX\"\n+\tfi || exit\n+\techo \"$commit_only\" |\n+\tGIT_INDEX_FILE=\"$TMP_INDEX\" git-update-index --add --remove --stdin &&\n+\techo \"$commit_only\" |\n+\tgit-update-index --remove --stdin ||\n+\texit\n+else\n+\t#\n+\t:\n+fi\n+\n+if test t = \"$verify\" && test -x \"$GIT_DIR\"/hooks/pre-commit\n+then\n+\tif test \"$TMP_INDEX\"\n+\tthen\n+\t\tGIT_INDEX_FILE=\"$TMP_INDEX\" \"$GIT_DIR\"/hooks/pre-commit\n+\telse\n+\t\t\"$GIT_DIR\"/hooks/pre-commit\n+\tfi || exit\n+fi\n \n if test \"$log_message\" != ''\n then\n@@ -155,42 +302,52 @@ if [ -f \"$GIT_DIR/MERGE_HEAD\" ]; then\n \techo \"#\"\n fi >>\"$GIT_DIR\"/COMMIT_EDITMSG\n \n+# Author\n+if test '' != \"$use_commit\"\n+then\n+\tpick_author_script='\n+\t/^author /{\n+\t\ts/'\\''/'\\''\\\\'\\'\\''/g\n+\t\th\n+\t\ts/^author \\([^<]*\\) <[^>]*> .*$/\\1/\n+\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\ts/.*/GIT_AUTHOR_NAME='\\''&'\\''/p\n+\n+\t\tg\n+\t\ts/^author [^<]* <\\([^>]*\\)> .*$/\\1/\n+\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\ts/.*/GIT_AUTHOR_EMAIL='\\''&'\\''/p\n+\n+\t\tg\n+\t\ts/^author [^<]* <[^>]*> \\(.*\\)$/\\1/\n+\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\ts/.*/GIT_AUTHOR_DATE='\\''&'\\''/p\n+\n+\t\tq\n+\t}\n+\t'\n+\tset_author_env=`git-cat-file commit \"$use_commit\" |\n+\tLANG=C LC_ALL=C sed -ne \"$pick_author_script\"`\n+\teval \"$set_author_env\"\n+\texport GIT_AUTHOR_NAME\n+\texport GIT_AUTHOR_EMAIL\n+\texport GIT_AUTHOR_DATE\n+elif test '' != \"$force_author\"\n+then\n+\tGIT_AUTHOR_NAME=`expr \"$force_author\" : '\\(.*[^ ]\\) *<.*'` &&\n+\tGIT_AUTHOR_EMAIL=`expr \"$force_author\" : '.*\\(<.*\\)'` &&\n+\ttest '' != \"$GIT_AUTHOR_NAME\" &&\n+\ttest '' != \"$GIT_AUTHOR_EMAIL\" ||\n+\tdie \"malformatted --author parameter\"\n+\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL\n+fi\n+\n PARENTS=\"-p HEAD\"\n-if GIT_DIR=\"$GIT_DIR\" git-rev-parse --verify HEAD >/dev/null 2>&1\n+if test -z \"$initial_commit\"\n then\n \tif [ -f \"$GIT_DIR/MERGE_HEAD\" ]; then\n \t\tPARENTS=\"-p HEAD \"`sed -e 's/^/-p /' \"$GIT_DIR/MERGE_HEAD\"`\n \tfi\n-\tif test \"$use_commit\" != \"\"\n-\tthen\n-\t\tpick_author_script='\n-\t\t/^author /{\n-\t\t\ts/'\\''/'\\''\\\\'\\'\\''/g\n-\t\t\th\n-\t\t\ts/^author \\([^<]*\\) <[^>]*> .*$/\\1/\n-\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/GIT_AUTHOR_NAME='\\''&'\\''/p\n-\n-\t\t\tg\n-\t\t\ts/^author [^<]* <\\([^>]*\\)> .*$/\\1/\n-\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/GIT_AUTHOR_EMAIL='\\''&'\\''/p\n-\n-\t\t\tg\n-\t\t\ts/^author [^<]* <[^>]*> \\(.*\\)$/\\1/\n-\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n-\t\t\ts/.*/GIT_AUTHOR_DATE='\\''&'\\''/p\n-\n-\t\t\tq\n-\t\t}\n-\t\t'\n-\t\tset_author_env=`git-cat-file commit \"$use_commit\" |\n-\t\tLANG=C LC_ALL=C sed -ne \"$pick_author_script\"`\n-\t\teval \"$set_author_env\"\n-\t\texport GIT_AUTHOR_NAME\n-\t\texport GIT_AUTHOR_EMAIL\n-\t\texport GIT_AUTHOR_DATE\n-\tfi\n else\n \tif [ -z \"$(git-ls-files)\" ]; then\n \t\techo Nothing to commit 1>&2\n@@ -198,10 +355,21 @@ else\n \tfi\n \tPARENTS=\"\"\n fi\n-git-status >>\"$GIT_DIR\"/COMMIT_EDITMSG\n+\n+(\n+\tif test '' != \"$TOP\"\n+\tthen\n+\t\tcd \"$TOP\"\n+\tfi &&\n+\tgit-status >>\"$GIT_DIR\"/COMMIT_EDITMSG\n+)\n if [ \"$?\" != \"0\" -a ! -f \"$GIT_DIR/MERGE_HEAD\" ]\n then\n \trm -f \"$GIT_DIR/COMMIT_EDITMSG\"\n+\tif test '' != \"$TOP\"\n+\tthen\n+\t\tcd \"$TOP\"\n+\tfi &&\n \tgit-status\n \texit 1\n fi\n@@ -213,7 +381,8 @@ case \"$no_edit\" in\n \t\techo >&2 \"Please supply the commit log message using either\"\n \t\techo >&2 \"-m or -F option.  A boilerplate log message has\"\n \t\techo >&2 \"been prepared in $GIT_DIR/COMMIT_EDITMSG\"\n-\t\texit 1 ;;\n+\t\texit 1\n+\t\t;;\n \tesac\n \t${VISUAL:-${EDITOR:-vi}} \"$GIT_DIR/COMMIT_EDITMSG\"\n \t;;\n@@ -235,7 +404,13 @@ if cnt=`grep -v -i '^Signed-off-by' \"$GI\n \twc -l` &&\n    test 0 -lt $cnt\n then\n-\ttree=$(git-write-tree) &&\n+\tif test -z \"$TMP_INDEX\"\n+\tthen\n+\t\ttree=$(git-write-tree)\n+\telse\n+\t\ttree=$(GIT_INDEX_FILE=\"$TMP_INDEX\" git-write-tree) &&\n+\t\trm -f \"$TMP_INDEX\"\n+\tfi &&\n \tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&\n \tgit-update-ref HEAD $commit $current &&\n \trm -f -- \"$GIT_DIR/MERGE_HEAD\"\n@@ -250,4 +425,8 @@ if test -x \"$GIT_DIR\"/hooks/post-commit \n then\n \t\"$GIT_DIR\"/hooks/post-commit\n fi\n+if test 0 -eq \"$ret\"\n+then\n+\trm -f \"$SAVE_INDEX\"\n+fi\n exit \"$ret\"\ndiff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh\nindex 8ff5dd9..c8a85f9 100755\n--- a/t/t1200-tutorial.sh\n+++ b/t/t1200-tutorial.sh\n@@ -95,13 +95,13 @@ test_expect_success 'git branch' 'cmp br\n \n git checkout mybranch\n echo \"Work, work, work\" >>hello\n-git commit -m 'Some work.' hello\n+git commit -m 'Some work.' -i hello\n \n git checkout master\n \n echo \"Play, play, play\" >>hello\n echo \"Lots of fun\" >>example\n-git commit -m 'Some fun.' hello example\n+git commit -m 'Some fun.' -i hello example\n \n test_expect_failure 'git resolve now fails' 'git resolve HEAD mybranch \"Merge work in mybranch\"'\n \n@@ -112,7 +112,7 @@ Play, play, play\n Work, work, work\n EOF\n \n-git commit -m 'Merged \"mybranch\" changes.' hello\n+git commit -m 'Merged \"mybranch\" changes.' -i hello\n \n cat > show-branch.expect << EOF\n * [master] Merged \"mybranch\" changes.\n-- \n1.1.6.g9e4e\n"},{"id":"15610","messageId":"e5bfff550602050536j73f1091dq9afae232f574d0b4@mail.gmail.com","threadId":"3245","inReplyTo":"7vpsm2hzng.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-02-05T13:36:51Z","receivedAt":"2006-02-05T13:36:51Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/5/06, Junio C Hamano <junkio@cox.net> wrote:\n> I am addressing people who participated with their valuable\n> inputs to the earlier \"git commit\" discussion.\n>\n> Here is my first cut.  I'd appreciate to hear from both\n> git-experienced people and git newcomers how comfortable this\n> new implementation is.  Improvement patches on top of this are\n> certainly appreciated.\n>\n\nI think the new semantics is clear and better then old one, especially\nfor people coming from different scm systems.\n\nUnfortunately it breaks qgit commit functionality. So I would like to\nask _how_  do you plan to update main line.\n\nI would like to update qgit also today, but it is impossible because\n\"git-commit -i\"  _currently_ raises an error. So I am just wondering\nif adding a temporary -i \"no op\" option to _current_ git-commit, until\nsemantics change is released could be done.\n\nAdding a -i \"place holder\" option to _current_ git-commit has the\nfollowing advantages:\n\n1) No functionality change and 100%  compatibility with current git-commit use.\n2) Give people time to update tools/script in the mean time\n3) When the real patch will be released all the (modified) tools will\nbe automatically compatible.\n\nWhat do you think?\n\nMarco\n"},{"id":"15615","messageId":"7v64ntindq.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"e5bfff550602050536j73f1091dq9afae232f574d0b4@mail.gmail.com","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-05T20:03:45Z","receivedAt":"2006-02-05T20:03:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was planning to think about the migration strategy _after_ I\nget the feeling that everybody who got confused by the current\none thinks this is a good change, and I am glad you did that\nwork for me ;-).\n\nI think it is sane to add a no-op '--include' to the current\nversion.\n\nI am not sure if it is worth to take two-phased introduction of\nthis new \"temporary index\" thing.  We could:\n\n * add '--only' that asks for the new \"temporary index\" thing.\n\n * initially make '--include' the default, not '--only'.\n\n * later switch the default to '--only'.\n"},{"id":"15618","messageId":"43E67745.2080302@gmail.com","threadId":"3245","inReplyTo":"7v64ntindq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-02-05T22:08:05Z","receivedAt":"2006-02-05T22:08:05Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Junio C Hamano ha scritto:\n> I was planning to think about the migration strategy _after_ I\n> get the feeling that everybody who got confused by the current\n> one thinks this is a good change, and I am glad you did that\n> work for me ;-).\n> \n> I think it is sane to add a no-op '--include' to the current\n> version.\n> \n> I am not sure if it is worth to take two-phased introduction of\n> this new \"temporary index\" thing.  We could:\n> \n>  * add '--only' that asks for the new \"temporary index\" thing.\n> \n>  * initially make '--include' the default, not '--only'.\n> \n>  * later switch the default to '--only'.\n> \n> \n\nI think both are viable choices, with the second one better in\ncase the planned transition phase is going to be long, while the\nfirst one is better if it is going to be short.\n\nBecause when, at last, you will switch the default to '--only', this option could be\nremoved. So it's a temporary option with, peraphs, a temporary documentation, and\na temporary user training to use it: IMHO has a meaning if the transition period is\nlong enough.\n\nIf we are talking about just one or two weeks, more then enough to update scripts, I think\nthe first approach is simpler.\n\nIn any case to let things more clear could be useful to tag a fresh new git version\nfor this commit semantics change.\n\n\nMarco\n"},{"id":"15622","messageId":"7voe1le71b.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"43E67745.2080302@gmail.com","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-05T23:10:24Z","receivedAt":"2006-02-05T23:10:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marco Costalba <mcostalba@gmail.com> writes:\n\n> Because when, at last, you will switch the default to\n> '--only', this option could be removed. So it's a temporary\n> option with, peraphs, a temporary documentation, and a\n> temporary user training to use it: IMHO has a meaning if the\n> transition period is long enough.\n\nHmph, actually I was planning to leave --only in forever if we\ngo that route.  Peoples' scripts would need to explicitly ask\nfor --only during the transition if they want that semantics,\nand removing that support afterwards would mean they would then\nneed to remove --only from their scripts again.\n\nI was hoping that, once people get used to --include and --only,\nthey start to \"revel in the index\" (as Linus puts it), and\nrealize that defaulting to --only is not such a good idea after\nall.  When that happens, I could leave --include as the\ndefault without getting complaints from them ;-).\n\nThe net effect, if we end up doing so, would be that we gained\nan extra flag --only that the user can use to explicitly ask for\na partial commit when they want one, without disrupting the\nestablished workflow of old timers.\n\nThe --only semantics is a useful thing in many situations, while\nthe --include semantics is also a useful thing in many other\ncases.  The latter might be a better match to the way the git\ninternal works, but both are equally useful options that support\ndifferent workflows.  I do not see an inherent reason to declare\none over the other to be \"the default\".  So we could instead\nhave no defaults at all (i.e. you have to explicitly say which\nkind you want if you use paths...).\n"},{"id":"15623","messageId":"7vwtg9cq0k.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"20060205225116.GC24561@blinkenlights.visv.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-06T00:03:23Z","receivedAt":"2006-02-06T00:03:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Fischer <michael@visv.net> writes:\n\n[Michael, forgive me to respond in public -- which I know is\nagainst an established netiquette, but I think this comment is\nuseful to people on the list in general.]\n\n> $ git-applymbox ../patch \n> 1 patch(es) to process.\n>\n> Applying 'git-commit: revamp the git-commit semantics.'\n>\n> error: Documentation/core-tutorial.txt: does not exist in index\n> error: patch failed: git-commit.sh:213\n> error: git-commit.sh: patch does not apply\n>\n> So, kind of hard to give an opinion on it.\n>\n> I've got 1.1.6 from a couple of days ago, downloaded source.\n\nAh, sorry, the development happens on the \"master\" branch.  The\nmaintenance release 1.1.6 has only fixes since 1.1.0 was done,\nand lacks all the new developments on the master branch.\n\nEspecially this update involves backward incompatible changes,\nit will _not_ appear in any of the future 1.1.X releases.\n\nTo keep yourself up to date:\n\n\t$ git clone git://git.kernel.org/pub/scm/git master.git\n        $ cd master.git\n\nThis would give you the latest from the master branch that the\npatch would apply cleanly to.\n\nIt is in the the pu (proposed updates) branch, so once you make\nclone like this, you do not have to apply the patch yourself.\nInstead, you could find the commit that merges jc/commit topic\nbranch on it:\n\n        $ git show-branch --topo-order master pu\n\nwhich probably would show something like this:\n\n\t...\n         - [pu^] Merge branch 'jc/commit'\n         + [pu^^2] git-commit: revamp the git-commit semantics.\n        ...\n\nThe easiest way to try it out is:\n\n\t$ git checkout -b test pu^\n\nNote: this would also get other topic branches merged on top of\nmaster, but I consider them to be safe.  The rule of thumb is\nthat the closer to the tip of the \"pu\", the less ready the\nchange is to be of general use.\n\nThen build it as usual.\n\n\t$ make && make install\n\nThanks.\n"},{"id":"15627","messageId":"7vzml5b7az.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"7vwtg9cq0k.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-06T01:32:52Z","receivedAt":"2006-02-06T01:32:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> To keep yourself up to date:\n>\n> \t$ git clone git://git.kernel.org/pub/scm/git master.git\n\nSilly me.  This URL is wrong.\n\n\t$ git clone git://git.kernel.org/pub/scm/git/git master.git\n"},{"id":"15628","messageId":"20060206022553.GB25603@blinkenlights.visv.net","threadId":"3245","inReplyTo":"7vzml5b7az.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Michael Fischer","fromEmail":"michael@visv.net","sentAt":"2006-02-06T02:25:54Z","receivedAt":"2006-02-06T02:25:54Z","isPatch":true,"sender":{"key":"michael@visv.net","avatar":null},"body":"On Sun, Feb 05, Junio C Hamano wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n> \n> > To keep yourself up to date:\n> >\n> > \t$ git clone git://git.kernel.org/pub/scm/git master.git\n> \n> Silly me.  This URL is wrong.\n> \n> \t$ git clone git://git.kernel.org/pub/scm/git/git master.git\n\nThanks. Instructions followed, patch tried:\n\n>From within a subdirectory:\n\n$ git commit -m\"fix the bounce file\" bounce.html \nassuming --include paths...\n$\n\nBoth my nits are solved. Happy. Thanks.\n\n\n\nMichael\n-- \nMichael Fischer                         Happiness is a config option.\nmichael@visv.net                        Recompile and be happy. \n"},{"id":"15630","messageId":"7virrtaqpn.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"20060206022553.GB25603@blinkenlights.visv.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-06T07:31:16Z","receivedAt":"2006-02-06T07:31:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Fischer <michael@visv.net> writes:\n\n> On Sun, Feb 05, Junio C Hamano wrote:\n>> Junio C Hamano <junkio@cox.net> writes:\n>> \n>> > To keep yourself up to date:\n>> >\n>> > \t$ git clone git://git.kernel.org/pub/scm/git master.git\n>> \n>> Silly me.  This URL is wrong.\n>> \n>> \t$ git clone git://git.kernel.org/pub/scm/git/git master.git\n>\n> Thanks. Instructions followed, patch tried:\n>\n> From within a subdirectory:\n>\n> $ git commit -m\"fix the bounce file\" bounce.html \n> assuming --include paths...\n> $\n>\n> Both my nits are solved. Happy. Thanks.\n\nThanks for the feedback.\n"},{"id":"15677","messageId":"Pine.LNX.4.64.0602071135110.5397@localhost.localdomain","threadId":"3245","inReplyTo":"7voe1le71b.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-07T16:59:26Z","receivedAt":"2006-02-07T16:59:26Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 5 Feb 2006, Junio C Hamano wrote:\n\n> I was hoping that, once people get used to --include and --only,\n> they start to \"revel in the index\" (as Linus puts it), and\n> realize that defaulting to --only is not such a good idea after\n> all.  When that happens, I could leave --include as the\n> default without getting complaints from them ;-).\n\nI know this is like fighting old habits, but at some point one as to \nrealize that there was a mistake in the interface and the best way to \nsolve that mistake is to go with the objectively most intuitive \nsolution.\n\nPeople can get used to the index concept like you did yourself of \ncourse, but that is still dismissing the very reason for doing that \nchange in the first place, which is that to a git beginner it is counter \nintuitive to have side effects when explicit paths are specified \n_alone_.\n\n> The net effect, if we end up doing so, would be that we gained\n> an extra flag --only that the user can use to explicitly ask for\n> a partial commit when they want one, without disrupting the\n> established workflow of old timers.\n\nIt is a bit deconcerting to see that git has already reached the \nsoftware stone age and that so called \"old timers\" already have more \nweight than clean interfaces... even after less than a year.\n\nPlease don't make it another CVS and fix those inconsistencies clean and \nquick while the user base is not yet inapt to change.\n\n> The --only semantics is a useful thing in many situations, while\n> the --include semantics is also a useful thing in many other\n> cases.  The latter might be a better match to the way the git\n> internal works, but both are equally useful options that support\n> different workflows.  I do not see an inherent reason to declare\n> one over the other to be \"the default\".\n\nWhat has happened to the \"least surprise\" principle?  That clearly \nfavorize the former IMHO.\n\n> So we could instead\n> have no defaults at all (i.e. you have to explicitly say which\n> kind you want if you use paths...).\n\nAnd that would be just a nice usability annoyance.\n\nMaybe being too intimate with git doesn't make it obvious to you, but if \nyou do a survey of the number of tools that allows accepting a list of \npaths for their only arguments it should be pretty obvious that the vast \nmajority operate only on those explicit paths without any hidden side \neffect.\n\nIf \"git commit\" is meant to be a user helper script to hide the low \nlevel git plumbing then it better do it with the least surprise \nprinciple in mind, otherwise it misses its very purpose.  And the faster \nthis is corrected the better, especially since this is not such a \ndisturbing change after all.\n\n\nNicolas\n"},{"id":"15679","messageId":"7vfymvvz1r.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"Pine.LNX.4.64.0602071135110.5397@localhost.localdomain","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T17:50:08Z","receivedAt":"2006-02-07T17:50:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@cam.org> writes:\n\n> What has happened to the \"least surprise\" principle?  That clearly \n> favorize the former IMHO.\n\nPlease see below.\n\n> Maybe being too intimate with git doesn't make it obvious to you,...\n\nI think you are looking at this with a bit shortsighted view.\nWe are aiming for the same end results.\n\nLet's say you have a git-commit that does --only semantics by\ndefault \"some day\", and everybody knows that is going to happen\non that \"some day\" for a long time (say, a month), because we\nare discussing about it right now in this thread.\n\nAnd a newcomer comes.  He's never used git before.  When he\ntypes \"git commit paths...\", the new --only semantics happens.\nBy that time (a month is a long time in git timescale) everybody\nknows \"git commit paths...\" mean --only, so if the newcomer has\ntrouble with \"git commit paths...\", people can help him with\nshared knowledge on what that command means.  And what the\ncommand does is less surprising than the current behaviour.\n\nIt is a Good Change.  I am agreeing with you that if --only were\nthe default from before I inherited git, things might have been\nbetter.\n\nBut let's say you make that \"some day\" today, or in the 1.2.0\nthat is hopefully imminent.  That newcomer is not using git yet.\nMany people and their scripts are already using git, expecting\n\"git commit paths...\"  to mean --include semantics.  What kind\nof surprise are you giving them?\n\nThat is this '--only/--include are available but currently the\ntraditional --include is the default' is all about.  It is about\nnot breaking current users during transition.  And People's\nScripts.  If a tool wants traditional semantics, it can hardcode\n\"--include\" (or --only if not), and does not have to worry about\nthe default getting switched \"some day\".\n\nOnce things are prepared that way, we can switch the default any\nday, as long as we give users enough advance notice.\n\nIt is possible that you are well aware of all of the above, and\nare arguing that \"enough advance notice\" period should be zero\ndays.  But I don't think that is nice.  When was this temporary\nthing formerly proposed in this round of discussion to make\neverybody realize that is what is happening?  4 days ago?  And\nthe actual code that claims to do --only hit the \"master\" branch\nonly 8 hours or so ago.\n\nI was hoping that before 1.2.0 I can take a final \"just in case\"\nquick poll to see everybody agrees making --only the default is\nthe way to go, then state it clearly that 1.3.0 will have the\ndefault switched to --only in the release announcement.\n"},{"id":"15680","messageId":"7vpslzuj6e.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"7vfymvvz1r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T18:18:17Z","receivedAt":"2006-02-07T18:18:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> I was hoping that before 1.2.0 I can take a final \"just in case\"\n> quick poll to see everybody agrees making --only the default is\n> the way to go, then state it clearly that 1.3.0 will have the\n> default switched to --only in the release announcement.\n\nClarification.  Here is what I want to do.\n\nI've said enough times that we _may_ switch the default from\ntraditional --include semantics to new --only semantics.  Nico\nalready even objected to the \"may\" part, and I am hoping it is\nshared by everybody on the list that \"may\" should be \"will\nsoon\".  Unless somebody comes up with a convincing argument\notherwise, I'll write \"this will switch to --only by the time\n1.3.0 release is made, so start converting your scripts to\nexplicitly say --include or --only if you want a specific\nbehaviour, and start training your fingers in the meantime as\nwell\" in the 1.2.0 announcement, probably done sometime late\nthis week.\n\nThat means 1.2.0 (and its maintenance series 1.2.X) will ship\nwith --include semantics for \"git commit paths...\", and will\nallow explicit --only/--include.  After 1.2.0, at some point,\nthe \"master\" branch will start shipping with --only semantics as\ndefault.  No script should break when 1.3.0 happens.\n\nPeople who want to use --include semantics will acquire a habit\nof explicitly askign for --include during 1.3.0 development\nperiod.  They do not need to unlearn anything when 1.3.0 happens.\n\nPeople who learned to type --only can unlearn it to reduce\ntyping when 1.3.0 happens, but unlearning is not a requirement.\nBeing explicit should always work.\n\nNew people that come after 1.3.0 will get the --only semantics\nby default, the intuitiveness of which has been argued to death,\nwithout using any flags.\n"},{"id":"15684","messageId":"Pine.LNX.4.64.0602071304160.5397@localhost.localdomain","threadId":"3245","inReplyTo":"7vfymvvz1r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-07T18:39:19Z","receivedAt":"2006-02-07T18:39:19Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 7 Feb 2006, Junio C Hamano wrote:\n\n> That is this '--only/--include are available but currently the\n> traditional --include is the default' is all about.  It is about\n> not breaking current users during transition.  And People's\n> Scripts.  If a tool wants traditional semantics, it can hardcode\n> \"--include\" (or --only if not), and does not have to worry about\n> the default getting switched \"some day\".\n\nI'm completely with you here.  However is there so many tools that \nrelies on the current behavior of \"git commit\"?\n\n> Once things are prepared that way, we can switch the default any\n> day, as long as we give users enough advance notice.\n\nGood.  It just seemed to me that you weren't convinced that any default \nswitching was needed.  Sorry if I misread you.\n\nWhat prompted my initial reply to you was this:\n\n|The --only semantics is a useful thing in many situations, while\n|the --include semantics is also a useful thing in many other\n|cases.  The latter might be a better match to the way the git\n|internal works, but both are equally useful options that support\n|different workflows.  I do not see an inherent reason to declare\n|one over the other to be \"the default\".  So we could instead\n|have no defaults at all (i.e. you have to explicitly say which\n|kind you want if you use paths...).\n\nto which I disagreed.\n\n> It is possible that you are well aware of all of the above, and\n> are arguing that \"enough advance notice\" period should be zero\n> days.  But I don't think that is nice.\n\nCertainly not zero days.  I'm just trying to counter-balance the \n\"without disrupting the established workflow of old timers\" argument \nwhich is the worst enemy of healthy software evolution.  If such an \nargument was to prevail in the Linux world then we would have had those \nevil \"stable driver ABI\" for a long time already.  If that argument was \nto prevail for git then that would be the beginning of its stagnation.\n\nAs for the advance notice, it might be a good idea to simply switch the \ndefault in 1.3.0 giving any script author relying on the --include \nbehavior (if any) proper insentive to fix them. The 1.3.x branch being \nthe so called \"unstable\" branch makes it the appropriate place to do \nit at the earliest, providing script authors enough time to test their \nmodifications on the real thing before it becomes official 1.4.0.\n\nBut you should consider all above rambling as part of the feedback you \nasked for.  I don't pretend to always be right.\n\n\nNicolas\n"},{"id":"15686","messageId":"Pine.LNX.4.64.0602071412390.5397@localhost.localdomain","threadId":"3245","inReplyTo":"Pine.LNX.4.64.0602071304160.5397@localhost.localdomain","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-02-07T19:18:39Z","receivedAt":"2006-02-07T19:18:39Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 7 Feb 2006, Nicolas Pitre wrote:\n\n> The 1.3.x branch being the so called \"unstable\" branch makes it the \n> appropriate place to do it at the earliest...\n\nAs someone refreshed my memory in private, there is no \"unstable\" branch \nlike Linux used to have.  But hopefully you all understood what I meant \ni.e. in the main branch after the stable 1.2.0 branch is forked.\n\n\nNicolas\n"},{"id":"15687","messageId":"1139340302.13067.42.camel@cashmere.sps.mot.com","threadId":"3245","inReplyTo":"7vpslzuj6e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-02-07T19:25:02Z","receivedAt":"2006-02-07T19:25:02Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Tue, 2006-02-07 at 12:18, Junio C Hamano wrote:\n\n> That means 1.2.0 (and its maintenance series 1.2.X) will ship\n> with --include semantics for \"git commit paths...\", and will\n> allow explicit --only/--include.  After 1.2.0, at some point,\n> the \"master\" branch will start shipping with --only semantics as\n> default.  No script should break when 1.3.0 happens.\n> \n> People who want to use --include semantics will acquire a habit\n> of explicitly askign for --include during 1.3.0 development\n> period.  They do not need to unlearn anything when 1.3.0 happens.\n> \n> People who learned to type --only can unlearn it to reduce\n> typing when 1.3.0 happens, but unlearning is not a requirement.\n> Being explicit should always work.\n> \n> New people that come after 1.3.0 will get the --only semantics\n> by default, the intuitiveness of which has been argued to death,\n> without using any flags.\n\nHmmm...  So maybe just to add fire to the discussion,\nmaybe the problem lies in the \"tool name\".  What if there\nwere two tools named \"git-commit-index\" and \"git-commit-path\"?\nI understand that this is, in some way, identical to the\n\"--include\" and \"--only\" sorts of notions.  But I think it\nmight make the intent clearer, and easier to describe/document.\nI think part of my concern with the options is trying to\nrecall/describe just exactly _what_ is \"included\" with\nthe \"--include\", or what is excluded with the \"--only\".\nIt is the index's data/state, of course.  So perhaps\na \"git commit-index\" might be consistent tool naming?\nAnd for contrast \"git commit-file\" or \"git commit-path\"?\n\nJust a thought.\n\njdl\n"},{"id":"15710","messageId":"7vbqxiquem.fsf@assigned-by-dhcp.cox.net","threadId":"3245","inReplyTo":"Pine.LNX.4.64.0602071412390.5397@localhost.localdomain","subject":"Re: [PATCH] git-commit: revamp the git-commit semantics.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-08T05:41:37Z","receivedAt":"2006-02-08T05:41:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@cam.org> writes:\n\n> As someone refreshed my memory in private, there is no \"unstable\" branch \n> like Linux used to have.  But hopefully you all understood what I meant \n> i.e. in the main branch after the stable 1.2.0 branch is forked.\n\nYes I understood what you meant.  Eventually we ship with --only\nas the default and the best timing is between 1.2.0 and 1.3.0.\n\nI am just worried if it might turn out to be like shipping a\nbicycle with training wheels welded onto it (so it cannot be\neasily removed).  That is where my reluctance comes from.\n\nBut I do not have to be convinced 100% myself in order to set it\nto the default, as long as the more important users are happy.\n"}]}