{"thread":{"id":"43062","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","startedAt":"2006-11-27T21:31:47Z","lastAt":"2006-11-30T17:13:44Z","messageCount":25,"participants":["Carl Worth","Junio C Hamano","Jakub Narebski","Nicolas Pitre","Seth Falcon","Josef Weidendorfer","Salikh Zakirov","Nguyen Thai Ngoc Duy","Andy Whitcroft","Han-Wen Nienhuys","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"296081","messageId":"Pine.LNX.4.64.0611271622260.9647@xanadu.home","threadId":"43062","inReplyTo":null,"subject":"[PATCH/RFC] \"init-db\" can really be just \"init\"","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-27T21:31:47Z","receivedAt":"2006-11-27T21:31:47Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"This should make first GIT impression a little less intimidating.\n\nSigned-off-by: Nicolas Pitre <nico@cam.org>\n---\n\nMaybe that could be a good rule of thumb to have all porcelainish \ncommands not have any hyphen in their name, like \"diff\", \"commit\", \n\"add\", etc. ?\n\ndiff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\nindex 9677671..ee9ddee 100644\n--- a/Documentation/everyday.txt\n+++ b/Documentation/everyday.txt\n@@ -25,7 +25,7 @@ Basic Repository[[Basic Repository]]\n \n Everybody uses these commands to maintain git repositories.\n \n-  * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a\n+  * gitlink:git-init[1] or gitlink:git-clone[1] to create a\n     new repository.\n \n   * gitlink:git-fsck-objects[1] to check the repository for errors.\n@@ -106,7 +106,7 @@ Use a tarball as a starting point for a new repository:\n ------------\n $ tar zxf frotz.tar.gz\n $ cd frotz\n-$ git-init-db\n+$ git-init\n $ git add . <1>\n $ git commit -m 'import of frotz source tree.'\n $ git tag v2.43 <2>\ndiff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt\nindex ca7d09d..bc3ba14 100644\n--- a/Documentation/git-init-db.txt\n+++ b/Documentation/git-init-db.txt\n@@ -74,6 +74,7 @@ Running `git-init-db` in an existing repository is safe. It will not overwrite\n things that are already there. The primary reason for rerunning `git-init-db`\n is to pick up newly added templates.\n \n+Note that `git-init` is the same as `git-init-db`.\n \n \n EXAMPLES\ndiff --git a/Documentation/git-init.txt b/Documentation/git-init.txt\nnew file mode 100644\nindex 0000000..36838c7\n--- /dev/null\n+++ b/Documentation/git-init.txt\n@@ -0,0 +1 @@\n+include::git-init-db.txt[]\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 619d656..5501ae0 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -347,6 +347,7 @@ gitlink:git-hash-object[1]::\n gitlink:git-index-pack[1]::\n \tBuild pack idx file for an existing packed archive.\n \n+gitlink:git-init[1]::\n gitlink:git-init-db[1]::\n \tCreates an empty git object database, or reinitialize an\n \texisting one.\ndiff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt\nindex 6389de5..13a1878 100644\n--- a/Documentation/tutorial-2.txt\n+++ b/Documentation/tutorial-2.txt\n@@ -17,7 +17,7 @@ Let's start a new project and create a small amount of history:\n ------------------------------------------------\n $ mkdir test-project\n $ cd test-project\n-$ git init-db\n+$ git init\n defaulting to local storage area\n $ echo 'hello world' > file.txt\n $ git add .\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex 35af81a..978d4bd 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -20,7 +20,7 @@ can place it under git revision control as follows.\n ------------------------------------------------\n $ tar xzf project.tar.gz\n $ cd project\n-$ git init-db\n+$ git init\n ------------------------------------------------\n \n Git will reply\ndiff --git a/Makefile b/Makefile\nindex e547e2a..c307324 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -203,7 +203,7 @@ EXTRA_PROGRAMS =\n \n BUILT_INS = \\\n \tgit-format-patch$X git-show$X git-whatchanged$X git-cherry$X \\\n-\tgit-get-tar-commit-id$X \\\n+\tgit-get-tar-commit-id$X git-init$X \\\n \t$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))\n \n # what 'all' will build and 'install' will install, in gitexecdir\ndiff --git a/builtin-init-db.c b/builtin-init-db.c\nindex 235a0ee..408b51a 100644\n--- a/builtin-init-db.c\n+++ b/builtin-init-db.c\n@@ -242,7 +242,7 @@ static void create_default_files(const char *git_dir, const char *template_path)\n }\n \n static const char init_db_usage[] =\n-\"git-init-db [--template=<template-directory>] [--shared]\";\n+\"git-init [--template=<template-directory>] [--shared]\";\n \n /*\n  * If you want to, you can share the DB area with any number of branches.\ndiff --git a/git.c b/git.c\nindex f97de60..5ae5afc 100644\n--- a/git.c\n+++ b/git.c\n@@ -241,6 +241,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n \t\t{ \"get-tar-commit-id\", cmd_get_tar_commit_id },\n \t\t{ \"grep\", cmd_grep, RUN_SETUP },\n \t\t{ \"help\", cmd_help },\n+\t\t{ \"init\", cmd_init_db },\n \t\t{ \"init-db\", cmd_init_db },\n \t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n"},{"id":"298185","messageId":"7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"Pine.LNX.4.64.0611271622260.9647@xanadu.home","subject":"Re: [PATCH/RFC] \"init-db\" can really be just \"init\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-27T22:05:27Z","receivedAt":"2006-11-27T22:05:27Z","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> This should make first GIT impression a little less intimidating.\n>\n> Signed-off-by: Nicolas Pitre <nico@cam.org>\n\nI was not sure about this for quite some time, thinking that it\nmight make sense to default the behaviour of init-db for bare\nrepositories and give init as a user-level wrapper to drive\ninit-db to add customization suitable for repositories with\nworking trees.  List?\n\n> Maybe that could be a good rule of thumb to have all porcelainish \n> commands not have any hyphen in their name, like \"diff\", \"commit\", \n> \"add\", etc. ?\n\nI was also hoping that would become the case except verify-tag,\ncherry-pick, and format-patch.  Also I was wondering if it would\nmake sense to give two dashes to the back-end ones that never\nget invoked by the end users directly (e.g. merge--recursive,\nupload--pack) but thought it was too ugly.\n"},{"id":"294160","messageId":"87bqmswm1e.wl%cworth@cworth.org","threadId":"43062","inReplyTo":"7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net","subject":"Hyphens and hiding core commands (was: \"init-db\" can really be just \"init\")","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-27T22:40:45Z","receivedAt":"2006-11-27T22:40:45Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 27 Nov 2006 14:05:27 -0800, Junio C Hamano wrote:\n> > Maybe that could be a good rule of thumb to have all porcelainish\n> > commands not have any hyphen in their name, like \"diff\", \"commit\",\n> > \"add\", etc. ?\n\nI like the proposed rule-of-thumb very much. (Particularly if\n\"update-index\" could be included on the list of things to eliminate,\nin favor of a new \"git resolve\" for resolving merges.)\n\nThere's another rule-of-thumb I would like to propose that's a bit\nharder to state, but I think is just as important (if not more):\n\n\tFor introductory documentation it should never make sense to\n\tintroduce a command with specific command-line options before\n\tthe same command without options.\n\nAs examples, both \"commit -a\" and \"cat-file -p\" fail that test and\nboth appear in the git tutorial here:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n\nMy proposals to fix those two are:\n\ncommit -a\n\n   Change \"commit\" to commit the working tree. The current \"commit\n   index\" option would be made available with a new \"-i\" or \"--index\"\n   option, which could easily be made the default in a config file for\n   any users that always want it. For merging, commit would also use\n   the working tree, but would balk at any unmerged paths in the\n   index, (which would have to be fixed with \"git resolve\" first).\n\ncat-file -p\n\n   Add new \"cat\" command with the functionality of \"cat-file -p\",\n   (also succeeds in removing a hyphenated command from the\n   tutorial).\n\n> I was also hoping that would become the case except verify-tag,\n> cherry-pick, and format-patch.\n\nHere are some none-too-considered options for even cleaning up those:\n\nverify-tag\n\n   A new \"git verify\" which would accept any object specifier and do a\n   restricted fsck on it, or a tag verification. Of course, the output\n   should clearly indicate whether a signed-tag had been verified or\n   just a tree object. [Perhaps the semantic mixing of signature\n   verification and object integrity verification makes this a bad\n   idea. I don't know.]\n\ncherry-pick\n\n   The name \"cherry\" is promising, but problematic in that it's\n   already used for another command, (which is definitely at a\n   lower-level in functionality, so would violate the rule-of-thumb\n   being considered here).\n\nformat-patch\n\n   I mentioned before that I'd like to see \"export\" and \"import\" as\n   commands to replace the functionality of \"format-patch\" and\n   \"am\". [These new names suggest something slightly different than\n   formatting a patch for mailing and applying an email message, and\n   perhaps even that difference should be taken advantage of.]\n\n>                       Also I was wondering if it would\n> make sense to give two dashes to the back-end ones that never\n> get invoked by the end users directly (e.g. merge--recursive,\n> upload--pack) but thought it was too ugly.\n\nIf you're willing to consider breaking backwards compatibility for\nthese, why not hide them even further? An idea I just had that would\nhide them quite well would be to tuck them away as sub-commands of a\nnew \"core\" command. That is:\n\n\tgit core merge-recursive\n\tgit core http-fetch\n\tetc.\n\nThat would bury these away from tab-completion of \"git-\" and even\n\"git \" with the completion scripts. It would still leave them\navailable with \"git core \" with the completion scripts of course.\n\nIt would also make things much more clear if these commands ever\nslipped into an introductory tutorial, etc.\n\n-Carl\n"},{"id":"298249","messageId":"Pine.LNX.4.63.0611280034010.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43062","inReplyTo":"7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"init-db\" can really be just \"init\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-27T23:36:15Z","receivedAt":"2006-11-27T23:36:15Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre <nico@cam.org> writes:\n> \n> > Maybe that could be a good rule of thumb to have all porcelainish \n> > commands not have any hyphen in their name, like \"diff\", \"commit\", \n> > \"add\", etc. ?\n> \n> I was also hoping that would become the case except verify-tag,\n> cherry-pick, and format-patch.\n\nI agree it might make a good rule-of-thumb, but let's not be overzealous. \nI have yet to see any better names for those three either, let alone \nbetter names without a hyphen.\n\n> Also I was wondering if it would make sense to give two dashes to the \n> back-end ones that never get invoked by the end users directly (e.g. \n> merge--recursive, upload--pack) but thought it was too ugly.\n\nI think it would appeal mostly to our friends, the monotone users...\n\nCiao,\nDscho\n"},{"id":"298769","messageId":"7vodqse90q.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"87bqmswm1e.wl%cworth@cworth.org","subject":"Re: Hyphens and hiding core commands","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-27T23:59:17Z","receivedAt":"2006-11-27T23:59:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> There's another rule-of-thumb I would like to propose that's a bit\n> harder to state, but I think is just as important (if not more):\n>\n> \tFor introductory documentation it should never make sense to\n> \tintroduce a command with specific command-line options before\n> \tthe same command without options.\n\nI tend to disagree.  \"This is the easiest way to use, even for\nbeginners\" and \"this way should be the default for all levels of\nusers\" are quite different.\n\n> As examples, both \"commit -a\" and \"cat-file -p\" fail that test and\n> both appear in the git tutorial here:\n>\n> \thttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n>\n> My proposals to fix those two are:\n\nCreating a \"git cat\" and promote that in the Tutorial makes a\nlot of sense, but then that can easily be done with aliases ;-).\ncat-file is plumbing.  We did not even have '-p' and you needed\nto _know_ the type of stuff you are feeding and we had '-t' to\nhelp you do so.  '-p' was done as a quick hack because showing\nthe representation of any object in semi human readable way was\nnot all that important but occasionally people found it useful,\nand it just was an easy thing to do inside cat-file.  Nobody\nbothered to do a real Porcelain called \"git cat\" for that\npurpose, so far, but that is probably what should have been.  On\nthe other hand, if \"cat-file -p\" needs to be used often, I think\nthere is something ELSE that is wrong.\n\nI do not think defaulting to \"commit -a\" is a fix; rather, it\nfeels exactly what Linus was talking about when he said about\n\"second system syndrome\".\n\nI would not mind if you created \"commit-easy\" (just like curl\nlibrary has curl_x_easy), but the current way the command works\nis more useful once you grok the index.  Being able to work in a\nslightly dirty tree and commit only the necessary things, and\nbeing able to do so even for a merge commit, is damn convenient.\n\nBecause there is a learning curve involved, an easier way to use\ngit without worrying about the index was added in the form of\n'-a' for beginners.  People who use index regularly should not\nbe forced to spend extra keystrokes for the rest of their lives\nonly because you want to lose '-a' from the tutorial document.\nThe tool should be designed for regular users, not for the first\nfew pages of the tutorial.\n"},{"id":"294179","messageId":"87ac2cwha4.wl%cworth@cworth.org","threadId":"43062","inReplyTo":"7vodqse90q.fsf@assigned-by-dhcp.cox.net","subject":"Re: Hyphens and hiding core commands","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-28T00:23:31Z","receivedAt":"2006-11-28T00:23:31Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 27 Nov 2006 15:59:17 -0800, Junio C Hamano wrote:\n>\n> I tend to disagree.  \"This is the easiest way to use, even for\n> beginners\" and \"this way should be the default for all levels of\n> users\" are quite different.\n\nI'll gladly agree that different defaults make sense for different\nusers. Fortunately, we have a config file syntax that allows advanced\nusers to select the defaults they prefer. But, what should be obvious\nis that the config file is not an option available for reducing the\nlearning curve of git.\n\n> Creating a \"git cat\" and promote that in the Tutorial makes a\n> lot of sense, but then that can easily be done with aliases ;-).\n...\n> On the other hand, if \"cat-file -p\" needs to be used often, I think\n> there is something ELSE that is wrong.\n\nSure. I don't think \"cat-file -p\" is any big problem. I only mention\nit because it _is_ mentioned in the git tutorial. So, let's add \"git\ncat\" or else find some other way to address what the tutorial is\ntrying to demonstrate there.\n\n> I would not mind if you created \"commit-easy\" (just like curl\n> library has curl_x_easy),\n\nAre you really serious about that? I think that's an awful idea.\n\nInterfaces that give longer names to the simpler functionality are\nreally broken. There are plenty of examples of this kind of thing,\n(XCreateWindow and XCreateSimpleWindow), but their existence in no way\njustifies this as a good thing.\n\nThe git commit syntax already suffers from this, (\"commit -a\" being a\nlonger name than its conceptually more complex cousin, \"commit\"), so\n\"commit-easy\" would only make that problem worse.\n\n>                           but the current way the command works\n> is more useful once you grok the index.  Being able to work in a\n> slightly dirty tree and commit only the necessary things, and\n> being able to do so even for a merge commit, is damn convenient.\n\nSure. You don't need to convert me to that idea. I use that mode\nregularly, (though probably not more often than when committing an\nindex that happens to match my working tree). But my proposal doesn't\nremove this functionality at all.\n\n> Because there is a learning curve involved, an easier way to use\n> git without worrying about the index was added in the form of\n> '-a' for beginners.\n\nYes, there is a learning curve. There's the \"once you grok the index\"\nstuff you just mentioned. And it's really backwards to have to teach\npeople that the \"basic\" way to do something is with a command line\nthat looks more complex, (\"commit -a\"), and that \"once you learn more\nyou'll understand what that -a is all about and you'll know when not\nto use it\".\n\nI've taught lots of people how to use git like that, and it's really\nawkward. It would be much easier if learning new concepts and learning\nnew command-line options were correlated. That would allow whole\nconcepts to be dropped from the most basic introductions to git.\n\n>                      People who use index regularly should not\n> be forced to spend extra keystrokes for the rest of their lives\n> only because you want to lose '-a' from the tutorial document.\n\nYou said yourself in the \"cat-file -p\" case, that can be done with\naliases. No extra keystrokes are needed.\n\nAnd many potential users who are evaluating git compared to other\nsystems _do_ currently see something that will cost them extra\nkeystrokes for the rest of their lives. And that is being used as part\nof the argument against git in some cases.\n\nNow, maybe that's not the real reason people are rejecting git, but it\nsure would be a nice excuse to remove from the potential list of\nobjections.\n\n> The tool should be designed for regular users, not for the first\n> few pages of the tutorial.\n\nI'm not proposing eliminating the index or anything here. I really\ndon't see how the default of this one command has any impact at all on\nthe design of git. It's all still there.\n\n-Carl\n"},{"id":"293933","messageId":"7vy7pwcsgp.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"87ac2cwha4.wl%cworth@cworth.org","subject":"Re: Hyphens and hiding core commands","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-28T00:42:14Z","receivedAt":"2006-11-28T00:42:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> Yes, there is a learning curve. There's the \"once you grok the index\"\n> stuff you just mentioned. And it's really backwards to have to teach\n> people that the \"basic\" way to do something is with a command line\n> that looks more complex, (\"commit -a\"), and that \"once you learn more\n> you'll understand what that -a is all about and you'll know when not\n> to use it\".\n\nI think you are teaching backwards.  Couldn't you start like this?\n\n\t\"git commit\" takes the list of paths you want to commit.\n\tEditing hello.c and saying \"git commit hello.c\" would\n\tcommit your changes to hello.c.  It is cumbersome to\n\tlist everything when your edit is all over the place,\n\tand in such a case you can say \"git commit -a\" to mean\n\t\"everything I changed\".\n\nLater you can enhance that experience by teaching them index,\nsaying:\n\n\tYou might want to tell git that your change to this file\n\tis more or less complete, even when you are not ready to\n\tcommit the whole thing.  You could use update-index to\n\tmark them and then later say \"git commit\" will make a\n\tcommit from the state you used update-index on, without\n\thaving you list them on the command line.  When you do\n\tthis, the commit template would list three classes of\n\tfiles and here are what they mean...\n\n\n"},{"id":"295965","messageId":"878xhwwdyj.wl%cworth@cworth.org","threadId":"43062","inReplyTo":"7vy7pwcsgp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Hyphens and hiding core commands","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-28T01:35:16Z","receivedAt":"2006-11-28T01:35:16Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 27 Nov 2006 16:42:14 -0800, Junio C Hamano wrote:\n> I think you are teaching backwards.  Couldn't you start like this?\n>\n> \t\"git commit\" takes the list of paths you want to commit.\n\nI've always started teaching with:\n\n\tgit init-db\n\tgit add file\n\tgit commit -m \"Initial commit\"\n\t# edit file\n\tgit commit -a -m \"edit file\"\n\nAnd at that point I've either apologized about \"-a\" or been asked a\nquestion about it. Every time.\n\nBut it's the tutorial we were talking about:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n\nThat has 6 examples of commit being used, and all of them are with\n\"commit -a\". What \"git commit\" does without -a must certainly be a\nquestion in the mind of any reader, (the tutorial doesn't mention\nanything).\n\nAnd unlike when I'm teaching in person, when the reader reads the\ntutorial, there's no person to explain the situation. The reader might\njust remain confused, or they might consult the documentation for\ngit-commit and find a first sentence that says:\n\n       Updates the index file for given paths, or all modified files\n       if -a is specified, and makes a commit object.\n\nAnd then we're back to the question of \"what the heck is an index, and\nwhy do I care?\".\n\nIf the \"commit the index\" operation were moved to a non-default\ncommand-line option of git-commit, then the commit command could be\nexplained without having to introduce the notion of the index at\nall. This would be a good thing. I don't think we have any\nintroductory documentation that introduces the index until the \"core\ntutorial\" and my goal here is to allow an introduction to using git\nthat doesn't require that level of detail.\n\nOne of the arguments I got here on the git mailing list when I first\nbrought up these kinds of \"hide the index\" proposals, (back in\nFebruary or so), was that the index is essential to understand for\nmerging anyway, and that I should just teach it early on.\n\nI've tried the \"teach it early\" approach in the months since and found\nit to be largely a failure. Most new users react by deciding that git\nis more complicated than other systems, or that it's more specialized\nor not targeted at someone with their needs.\n\nAs for merging, I'd rather introduce the new \"git resolve\" syntax so\nthat merging could be explained in terms of the working tree without\nhaving to fully understand the index either.\n\nIf we could fix \"git commit\" and add \"git resolve\" I think we would\nmost of the confusion/complaints that I've encountered in 8 months of\nteaching git. There would still be some aspects of \"git diff\" that are\npotentially confusing without understanding the index, but that's\nbeen much less of a problem than \"commit -a\" in my experience.\n\n-Carl\n"},{"id":"297603","messageId":"7vk61gcnzl.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"878xhwwdyj.wl%cworth@cworth.org","subject":"Re: Hyphens and hiding core commands","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-28T02:18:54Z","receivedAt":"2006-11-28T02:18:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> On Mon, 27 Nov 2006 16:42:14 -0800, Junio C Hamano wrote:\n>> I think you are teaching backwards.  Couldn't you start like this?\n>>\n>> \t\"git commit\" takes the list of paths you want to commit.\n> ...\n\n> If the \"commit the index\" operation were moved to a non-default\n> command-line option of git-commit, then the commit command could be\n> explained without having to introduce the notion of the index at\n> all.\n\nRead what I wrote again.  You can explain it without talking\nabout index at all.  I really do not think you need to break\n\"git commit\" nor rename \"update-index\" to \"resolve\" to explain\nthings to new people.\n\nThe tutorial might be better reworked not to start talking about\n-a but start building small project from a newly created\nhello.c, git add it, and \"git commit\" (the first commit), then\nedit hello.c and \"git commit hello.c\" (the second commit).\n\nPerhaps.\n\nEnough about \"git commit -a\" for tonight.\n"},{"id":"294457","messageId":"7vd5786opj.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"7vk61gcnzl.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-28T06:59:52Z","receivedAt":"2006-11-28T06:59: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> Enough about \"git commit -a\" for tonight.\n\nI've been playing with a \"private edition\" git to see how it\nfeels like to use \"git commit\" that defaults to the \"-a\"\nbehaviour, using myself as a guinea pig, for the rest of the\nevening.\n\nConfession time.  I've had a \"purist me\" deep inside, who always\nthought that people who play contributor role (that is to say\n\"99.9% of people\") should make no commits other than the \"-a\"\nkind [*1*].  So this is not only trying out the issues in the\ndiscussion I had with you, but what that \"other me\" wanted to do\nfor quite some time.\n\nA pair of patches will follow this message and I encourage you\nto try it out, work with it for a dozen or so commits, handful\nof merges, a patch application or two to get part of changes\nfrom different commits (not a \"git format-patch | git am\" to get\nanother commit wholesale, but \"git apply\" followed by your own\nedits that eventually result in \"git commit\"), a few rebases and\nresets.  If you have a few new people you can sacrifice their\n\"git virginity\" for experimenting this on, I am reasonably sure\nthey will like it, but I do not know how their learning curve\nlater will be affected by this change -- it would be interesting\nto know.  I do not think it would flatten the learning curve of\nindex much. I am somewhat fearful that it might make it harder,\nbut I lost my git virginity long time ago, so it is just an\nunsubstantiated feeling.\n\nJudging from my experience so far, although I really wanted to\nlike this, I am still hesitant to recommend this for inclusion.\nIt does not make any difference while I am doing the simplest\noperation (it is just not having to say \"-a\"), so I do not\nforesee problems either way for new people following a saner\nversion of tutorial, which does not exist yet, that does not\ntalk much about \"git commit -a\".\n\nThe problem I have with the new behaviour is that it goes\nagainst the mental model when I start doing anything nontrivial\n(I would not use words as strong as \"totally breaks the mental\nmodel\", but it comes close).  I am not sure how well I can\nexpress this, but the short of it is that \"grokking index\" is\nnot about understanding how the index works, but about trusting\nthat git does the right thing to the index and you do not have\nto worry about it all the time.\n\nFor example, \"git apply --index\" will update the index for paths\nthat the patch I feed it talks about (and reminds me if I have\nlocal changes to them by refusing to lose my changes) so after\nit finishes successfully, I do not have to think about the index\nat all [*2*].  After working on a few files, I can ask \"git\ndiff\" to see if the changes so far are reasonable, and mark them\nwith \"git update-index\" so that I do not have to worry about\nthem anymore and keep going to make matching changes to other\nfiles.  Once I tell something to git via index, I do not have to\nworry about it, and this is a big relief.\n\nThe same thing can be said about \"git merge\" (or \"git pull .\").\nThe index is updated for cleanly merged paths so I do not have\nto worry about the details -- the only thing I have to know is\nthat index keeps track of the state and cleanly merged paths are\ntaken care of for me automatically, so I do not have to worry\nabout them.  \"git diff\" and \"git ls-files -u\" will give me\nconflicting paths and I can only concentrate on them.\n\nOnce I am done, I can ask \"git diff\" and expect it to show my\nlocal changes I have no intention of committing for now\n(e.g. GIT-VERSION-GEN in the working tree has v1.4.5-rc1.GIT\nlong before I plan to start the rc1 cycle to constantly remind\nme what the next version will be, which is a trick I picked up\nfrom Linus), and \"git diff --cached\" would show exactly what I\nwill commit.\n\nAnd at that point, I trust \"git commit\" to do the right thing --\nthe damn thing I just checked with \"git diff --cached\" _is_ what\nwill be committed.  In that sense, I do not have to think about\nthe index at all, because I know git is doing appropriate things\nbehind the scene for me.\n\nComing from this perspective, having to say \"git commit -i\" at\nthe time of making the commit just makes me feel uneasy, if not\ncounterintuitive.  Making \"git commit\" default to \"-a\" rubs this\nmental model quite the wrong way.\n\nProbably new people who are not used to the index do not have\nthis problem, but I suspect I am not alone among old time\ngitters.\n\nI lost about half an hour after saying \"git commit --amend\",\nwithout thinking, because I wanted to amend only the commit\nmessage, and much later I noticed that it swallowed unrelated\nchanges I had in the working tree because it now implied the\n\"-a\" behaviour, and I should have said \"git commit -i --amend\".\n\nI needed to redo bunch of commits, which involved having to\nre-test a handful revisions (this is not git.git project but my\nday job one -- I do not work on it after work, but I was doing\nthe guinea pig).  But this is something re-training can fix and\nmuch a smaller problem than the mental model issue.\n\n\n[Footnote]\n\n*1* The reason to favor \"-a\" commit is not about hiding the\nindex but about discipline.  For the \"integrator\" people to be\nable to coast over the changes, they need to be able to trust\nthe work by contributors to some degree without worrying about\nsmall details; the changes fed to the integrators must be well\ntested when they leave the hand of a contributor, and making a\ncommit that never existed as a whole in the working tree goes\nagainst this discipline.\n\n*2* It might be a good idea to make \"--index\" the default for\n\"git apply\" when we know we are in a git repository (\"git apply\"\nmust be usable outside a git repository so this needs to be\nhandled with care if somebody wants to do it).  There is no\n\"--no-index\" option to countermand it right now, which also\nneeds to be added.\n\n\n"},{"id":"296014","messageId":"7v64d06op0.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"7vk61gcnzl.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 1/2] git-commit: prepare to make '-a' behaviour the default.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-28T07:00:11Z","receivedAt":"2006-11-28T07:00:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This makes \"git commit\" accept \"-i\" without any parameter (we\nused to barf on such a command line) to mean \"commit what is in\nthe index as-is\".  There is nothing surprising about this new\nbehaviour.  \"git commit -i paths...\"  means \"in addition to the\nchanges I accumulated in the index, also run update-index on\nthese paths and then make a commit\" and this new behaviour is a\nnatural extension to that to the case where \"paths...\" is empty.\n\n\"git commit\" without -i, -a, nor -o still behave the same way as\nit has done for a long time, but it now warns that this will be\nchanged to default to the \"-a\" behaviour.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n git-commit.sh |   30 ++++++++++++++++++------------\n 1 files changed, 18 insertions(+), 12 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 81c3a0c..6c95817 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -11,10 +11,10 @@ git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t\n branch=$(GIT_DIR=\"$GIT_DIR\" git-symbolic-ref HEAD)\n \n case \"$0\" in\n-*status)\n+*status|*status.sh)\n \tstatus_only=t\n \tunmerged_ok_if_status=--unmerged ;;\n-*commit)\n+*commit|*commit.sh)\n \tstatus_only=\n \tunmerged_ok_if_status= ;;\n esac\n@@ -287,11 +287,15 @@ esac\n case \"$#,$also,$only,$amend\" in\n *,t,t,*)\n \tdie \"Only one of --include/--only can be used.\" ;;\n-0,t,,* | 0,,t,)\n-\tdie \"No paths with --include/--only does not make sense.\" ;;\n+0,t,,*)\n+\t;;\n+0,,t,)\n+\tdie \"No paths with --only does not make sense.\" ;;\n 0,,t,t)\n \tonly_include_assumed=\"# Clever... amending the last one with dirty index.\" ;;\n 0,,,*)\n+\t: all=t\n+\tonly_include_assumed=\"# We will start assuming -a without -i; you have been warned.\"\n \t;;\n *,,,*)\n \tonly_include_assumed=\"# Explicit paths specified without -i nor -o; assuming --only paths...\"\n@@ -304,8 +308,6 @@ t,t,*)\n \tdie \"Cannot use -a and -i at the same time.\" ;;\n t,,[1-9]*)\n \tdie \"Paths with -a does not make sense.\" ;;\n-,t,0)\n-\tdie \"No paths with -i does not make sense.\" ;;\n esac\n \n ################################################################\n@@ -317,8 +319,8 @@ then\n \tTOP=./\n fi\n \n-case \"$all,$also\" in\n-t,)\n+case \"$all,$also,$#\" in\n+t,,*)\n \tsave_index &&\n \t(\n \t\tcd \"$TOP\"\n@@ -328,7 +330,7 @@ t,)\n \t\tgit-update-index --remove -z --stdin\n \t)\n \t;;\n-,t)\n+,t,[1-9]*)\n \tsave_index &&\n \tgit-ls-files --error-unmatch -- \"$@\" >/dev/null || exit\n \n@@ -340,7 +342,7 @@ t,)\n \t\tgit-update-index --remove -z --stdin\n \t)\n \t;;\n-,)\n+,,* | ,t,0)\n \tcase \"$#\" in\n \t0)\n \t\t;; # commit as-is\n@@ -407,7 +409,7 @@ GIT_INDEX_FILE=\"$USE_INDEX\" \\\n # If the request is status, just show it and exit.\n \n case \"$0\" in\n-*status)\n+*status|*status.sh)\n \trun_status\n \texit $?\n esac\n@@ -539,7 +541,11 @@ then\n \t\techo \"\"\n \t\techo \"# Please enter the commit message for your changes.\"\n \t\techo \"# (Comment lines starting with '#' will not be included)\"\n-\t\ttest -z \"$only_include_assumed\" || echo \"$only_include_assumed\"\n+\t\ttest -z \"$only_include_assumed\" || {\n+\t\t\techo \"#\"\n+\t\t\techo \"$only_include_assumed\"\n+\t\t\techo \"#\"\n+\t\t}\n \t\trun_status\n \t} >>\"$GIT_DIR\"/COMMIT_EDITMSG\n else\n-- \n1.4.4.1.gcee8-dirty\n\n"},{"id":"298066","messageId":"7vy7pw5a4d.fsf@assigned-by-dhcp.cox.net","threadId":"43062","inReplyTo":"7vk61gcnzl.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 2/2] git-commit: make '-a' the default.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-28T07:00:18Z","receivedAt":"2006-11-28T07:00:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"At the same time, stop talking about \"--only\" option being the\ndefault when given paths.  It has been that way for quite some\ntime.\n\nThis change breaks t1400 which assumed the long tradition of not\nmodifying index when not told to touch it with an explicit -a\nnor paths, so this commit includes adjustment for it as well.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n git-commit.sh         |   13 ++++++-------\n t/t1400-update-ref.sh |    4 ++--\n 2 files changed, 8 insertions(+), 9 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 6c95817..655340c 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -292,13 +292,12 @@ case \"$#,$also,$only,$amend\" in\n 0,,t,)\n \tdie \"No paths with --only does not make sense.\" ;;\n 0,,t,t)\n-\tonly_include_assumed=\"# Clever... amending the last one with dirty index.\" ;;\n+\tonly_include_assumed=\"Clever... amending the last one with dirty index.\" ;;\n 0,,,*)\n-\t: all=t\n-\tonly_include_assumed=\"# We will start assuming -a without -i; you have been warned.\"\n+\tall=t\n+\tonly_include_assumed=\"No -o nor -i is given; committing --all\"\n \t;;\n *,,,*)\n-\tonly_include_assumed=\"# Explicit paths specified without -i nor -o; assuming --only paths...\"\n \talso=\n \t;;\n esac\n@@ -542,9 +541,9 @@ then\n \t\techo \"# Please enter the commit message for your changes.\"\n \t\techo \"# (Comment lines starting with '#' will not be included)\"\n \t\ttest -z \"$only_include_assumed\" || {\n-\t\t\techo \"#\"\n-\t\t\techo \"$only_include_assumed\"\n-\t\t\techo \"#\"\n+\t\t\techo \"################################################\"\n+\t\t\techo \"# $only_include_assumed\"\n+\t\t\techo \"################################################\"\n \t\t}\n \t\trun_status\n \t} >>\"$GIT_DIR\"/COMMIT_EDITMSG\ndiff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh\nindex 6a917f2..1580224 100755\n--- a/t/t1400-update-ref.sh\n+++ b/t/t1400-update-ref.sh\n@@ -200,13 +200,13 @@ test_expect_success \\\n \t h_OTHER=$(git-rev-parse --verify HEAD) &&\n \t echo FIXED >F &&\n \t GIT_AUTHOR_DATE=\"2005-05-26 23:44\" \\\n-\t GIT_COMMITTER_DATE=\"2005-05-26 23:44\" git-commit --amend &&\n+\t GIT_COMMITTER_DATE=\"2005-05-26 23:44\" git-commit --amend -i &&\n \t h_FIXED=$(git-rev-parse --verify HEAD) &&\n \t echo TEST+FIXED >F &&\n \t echo Merged initial commit and a later commit. >M &&\n \t echo $h_TEST >.git/MERGE_HEAD &&\n \t GIT_AUTHOR_DATE=\"2005-05-26 23:45\" \\\n-\t GIT_COMMITTER_DATE=\"2005-05-26 23:45\" git-commit -F M &&\n+\t GIT_COMMITTER_DATE=\"2005-05-26 23:45\" git-commit -F M -i &&\n \t h_MERGED=$(git-rev-parse --verify HEAD)\n \t rm -f M'\n \n-- \n1.4.4.1.gcee8-dirty\n\n"},{"id":"295966","messageId":"ekgu98$83e$1@sea.gmane.org","threadId":"43062","inReplyTo":"7vy7pw5a4d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] git-commit: make '-a' the default.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T09:09:39Z","receivedAt":"2006-11-28T09:09:39Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> At the same time, stop talking about \"--only\" option being the\n> default when given paths.  It has been that way for quite some\n> time.\n> \n> This change breaks t1400 which assumed the long tradition of not\n> modifying index when not told to touch it with an explicit -a\n> nor paths, so this commit includes adjustment for it as well.\n\nPerhaps we should make it configuration option instead? I usually use\n\"git commit -a -s\"; I add -s anyway, so adding -a is not that much more.\n\nBy the way, if I understand correctly git-resolve is meant as restricted\ngit-update-index, which can _only_ mark file as resolved (and probably\ncheck for merge markers, unless --force'd).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296877","messageId":"456C0EE9.9050004@shadowen.org","threadId":"43062","inReplyTo":"7vd5786opj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-28T10:26:49Z","receivedAt":"2006-11-28T10:26:49Z","isPatch":true,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n> \n>> Enough about \"git commit -a\" for tonight.\n> \n> I've been playing with a \"private edition\" git to see how it\n> feels like to use \"git commit\" that defaults to the \"-a\"\n> behaviour, using myself as a guinea pig, for the rest of the\n> evening.\n\nI for one would find this change confusing.  Yes like most virgins I\nfound the -a being needed all the time left me with a bit of \"huh, why\nnot turn it on by default\" feeling.  But as time goes by and you use git\nmore and start to rebase and merge and start to get those conflicts then\nthe index comes into focus, you can see why that 'stupid layer' is there\nand its power.  I am now finding myself using the index more and more as\nyou described as a staging ground for the 'commit in progres'.\n\nI think the new wording in the tutorial really is a much better way\nround to teach it, and would have saved me some mental movement.  But\nthe index really is there and useful when you get beyond the trivial.  I\nam using git almost exclusivly in a contributer role and find it so.\n\nmy $0.02.\n\n"},{"id":"297770","messageId":"456C1338.2020303@xs4all.nl","threadId":"43062","inReplyTo":"7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH/RFC] \"init-db\" can really be just \"init\"","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-28T10:45:12Z","receivedAt":"2006-11-28T10:45:12Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Junio C Hamano escreveu:\n> I was not sure about this for quite some time, thinking that it\n> might make sense to default the behaviour of init-db for bare\n> repositories and give init as a user-level wrapper to drive\n> init-db to add customization suitable for repositories with\n> working trees.  List?\n\nwouldn't using --bare be more consistent for bare repos?\n\n>> Maybe that could be a good rule of thumb to have all porcelainish \n>> commands not have any hyphen in their name, like \"diff\", \"commit\", \n>> \"add\", etc. ?\n> \n> I was also hoping that would become the case except verify-tag,\n> cherry-pick, and format-patch.  \n\nwhy not shorten them to \"pick\" and \"verify\"?\n\n-- \n"},{"id":"296386","messageId":"200611281400.37191.Josef.Weidendorfer@gmx.de","threadId":"43062","inReplyTo":"7vd5786opj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-28T13:00:36Z","receivedAt":"2006-11-28T13:00:36Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 28 November 2006 07:59, Junio C Hamano wrote:\n> Once I am done, I can ask \"git diff\" and expect it to show my\n> local changes I have no intention of committing for now\n> ...\n> \n> And at that point, I trust \"git commit\" to do the right thing --\n> the damn thing I just checked with \"git diff --cached\" _is_ what\n> will be committed.\n\nI think the difference behavior between \"git commit\" and \"git diff\" is\na little bit confusing.\n\nCurrently, we have\n* \"git diff\" shows what \"git commit -a\" would commit\n* \"git diff --cached\" shows what \"git commit\" would commit\n\nIMHO, \"git diff\" should show what's in the staging area,\nand we should introduce \"git diff -a\" as a way to see the full\nchanges.\n\n"},{"id":"296064","messageId":"ekhd5q$qb1$1@sea.gmane.org","threadId":"43062","inReplyTo":"200611281400.37191.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-28T13:23:51Z","receivedAt":"2006-11-28T13:23:51Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Josef Weidendorfer wrote:\n\n> On Tuesday 28 November 2006 07:59, Junio C Hamano wrote:\n>> Once I am done, I can ask \"git diff\" and expect it to show my\n>> local changes I have no intention of committing for now\n>> ...\n>> \n>> And at that point, I trust \"git commit\" to do the right thing --\n>> the damn thing I just checked with \"git diff --cached\" _is_ what\n>> will be committed.\n> \n> I think the difference behavior between \"git commit\" and \"git diff\" is\n> a little bit confusing.\n> \n> Currently, we have\n> * \"git diff\" shows what \"git commit -a\" would commit\n> * \"git diff --cached\" shows what \"git commit\" would commit\n> \n> IMHO, \"git diff\" should show what's in the staging area,\n> and we should introduce \"git diff -a\" as a way to see the full\n> changes.\n\nI see it in other way. \"git diff\" tells us if a tree has changed wrt. what\nwould be committed. It is not a preview of commit.\n\nAlso, as of now the version without additional option is a fastest one, both\nfor diff and for commit.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"293798","messageId":"871wnnwi3k.wl%cworth@cworth.org","threadId":"43062","inReplyTo":"7vd5786opj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-28T18:18:07Z","receivedAt":"2006-11-28T18:18:07Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 27 Nov 2006 22:59:52 -0800, Junio C Hamano wrote:\n> I've been playing with a \"private edition\" git to see how it\n> feels like to use \"git commit\" that defaults to the \"-a\"\n> behaviour, using myself as a guinea pig, for the rest of the\n> evening.\n\nThanks already for the documentation improvements and the patches. I\nwill immediately start using these and use myself as a guinea pig as\nwell.\n\n> Confession time.  I've had a \"purist me\" deep inside, who always\n> thought that people who play contributor role (that is to say\n> \"99.9% of people\") should make no commits other than the \"-a\"\n> kind [*1*].\n...\n> *1* The reason to favor \"-a\" commit is not about hiding the\n> index but about discipline.\n\nI agree with your comments on discipline, (and honestly, I don't\nreally see why they wouldn't apply to anybody). It just plain makes\nsense to commit code as it existed and as it has been tested.\n\nAnd I think this is really the same motivation for the users whose\ncomplaints I've been representing in this thread. I know people who\nhave read all of the \"hide the index\" debates on the git list and\nstill find the \"staged commit\" features of the index useless, (because\nthey already have the discipline of never committing a state that\ndidn't actually exist in their working tree).\n\n> Judging from my experience so far, although I really wanted to\n> like this, I am still hesitant to recommend this for inclusion.\n\nI'm glad you were willing to try yourself out as a guinea pig on\nthis. That's definitely worthwhile. But I don't think your negative\nexperience here is good evidence against changing the default.\n\nMy proposal was not that old-time, index-loving git users should adapt\nto a new default. I think that it should be made very straight-forward\nfor experienced users to drop in an alias or a configuration option\nsuch that all the old defaults are preserved. With that, all of the\ncomplaints you ran into, (which are all of the form \"things act\ndifferently than I'm used to\"), go away.\n\n> The problem I have with the new behaviour is that it goes\n> against the mental model when I start doing anything nontrivial\n> (I would not use words as strong as \"totally breaks the mental\n> model\", but it comes close).  I am not sure how well I can\n> express this, but the short of it is that \"grokking index\" is\n> not about understanding how the index works, but about trusting\n> that git does the right thing to the index and you do not have\n> to worry about it all the time.\n\nFrankly, I do not currently trust git to always do the right thing\nwith the index. Part of that is that some commands are inconsistent\nwith respect to updating the index or not. For example, the following\ntwo operations:\n\n\tgit cherry-pick -n <something>\n\tgit am < something\n\nare conceptually very similar, (apply some change without creating a\nnew commit), but the first updates the index and the second does\nnot. (This is something you already pointed out in your message and\nsaid that perhaps \"apply --index\" should be the default. I'll come to\na different conclusion below.)\n\nSo things like \"git diff\" and others work very differently in the\nabove two situations, and the user has to stay well-aware of what's\nhappening in the index or not. So I do find myself having to \"worry\nabout it all the time\".\n\nAnother example is how to \"undo\" a modification of a file such that it\nis restored to its state as in the last commit. I'd like to be able to\nteach users a single, reliable command for operations like this. It\nwould be tempting to just say:\n\n\tgit checkout some/file\n\nwhich will often work, but not in the case of an updated index,\n(whether manual or due to something like \"cherry-pick -n\" or an\nin-progress merge). In those cases various suggestions might be\noffered such as:\n\n\tgit reset\n\tgit checkout some/file\n\nor:\n\n\tgit cat-file -p HEAD:some/file > some/file\n\nat which point we can send users screaming again. (I think there's yet\nanother option that was discussed on the list recently, but if I\nrecall correctly, it involved an even more obscure option to some git\ncommand than any of the above).\n\nSo a simple operation like this \"undo\" requires the user to understand\nthe index and adapt the workflow based on its state. But there's no\nadvantage being offered to the user at all in a case like this. (And\nwhether the change being undone came through something like\n\"cherry-pick -n\" or \"git-am\" is totally irrelevant to the work the\nuser is attempting to get (un)done).\n\nAll of the above is just to point out that there are times when the\nnotion of the index does get in the way. The user has to mentally\ntrack what's happening in the index even when there's no advantage. My\ngoal is to reduce the set of operations where the user is forced to do\nthat.\n\nIf users want to take advantage of the index, then by all means, it's\nthere and can be taken advantage of. And when the index does its job\nof taking care of things so the user doesn't have to think about it,\nthat's definitely a good thing.\n\n> The same thing can be said about \"git merge\" (or \"git pull .\").\n> The index is updated for cleanly merged paths so I do not have\n> to worry about the details -- the only thing I have to know is\n> that index keeps track of the state and cleanly merged paths are\n> taken care of for me automatically, so I do not have to worry\n> about them.  \"git diff\" and \"git ls-files -u\" will give me\n> conflicting paths and I can only concentrate on them.\n\nSure. The behavior of \"git diff\" during a conflicted merge is actually\nquite intuitive. And that's even intuitive to someone who has no idea\nwhat the index is. So the index is doing a fine job here of taking\ncare of things so the user doesn't have to think about them. We should\nhave more of that.\n\nThe \"git diff\" behavior would really only be surprising to someone who\ndoesn't totally grok the index if the index got updated other than\nduring a commit or merge. So I think it would be great if that only\nhappened when the user passed the word \"index\" on the command line as\nin \"update-index\" or \"apply --index\".\n\nIn fact that rule of them would argue for leaving \"git apply\" alone\nand instead solving the inconsistency I pointed out above by making\n\"cherry-pick -n\" not update the index, (unless passed a new \"--index\"\noption).\n\n> Once I am done, I can ask \"git diff\" and expect it to show my\n> local changes I have no intention of committing for now\n> (e.g. GIT-VERSION-GEN in the working tree has v1.4.5-rc1.GIT\n> long before I plan to start the rc1 cycle to constantly remind\n> me what the next version will be, which is a trick I picked up\n> from Linus), and \"git diff --cached\" would show exactly what I\n> will commit.\n\nI understand the trick, and I'm not proposing anything that would\npreclude it. But I really don't find it a compelling argument for the\ndefault behavior of git-commit. I don't see why the correct next value\nfor the version is easier to compute at one time vs. another. Linus\nargued that it helped him not forget to update the version, but I\nwould think this kind of thing would train users to leave uncommitted\nstuff around which could lead to mistakes, (and the user _still_ has\nto remember \"Oh, this is that special commit where I _don't_ leave\nthat uncommitted stuff around anymore, but I actually commit it.\"). So\nI don't personally see any gain to the trick.\n\n> Probably new people who are not used to the index do not have\n> this problem, but I suspect I am not alone among old time\n> gitters.\n\nSure, so put an alias or config option in place so you don't have to\nchange your ways at all.\n\n> I lost about half an hour after saying \"git commit --amend\",\n> without thinking, because I wanted to amend only the commit\n> message, and much later I noticed that it swallowed unrelated\n> changes I had in the working tree because it now implied the\n> \"-a\" behaviour, and I should have said \"git commit -i --amend\".\n\nI definitely commiserate on that one. I myself often use \"commit\n--amend\" to change just a commit message.\n\nBut at the same time, I also very often use \"commit --amend\" to fix up\nthe tree itself in the most recent commit. And I've also last the same\nhalf hour by forgetting to do \"commit -a\" or \"update-index\" when doing\nthat more than once in the past.\n\nI think the real fix for this particular issue is to add a little more\n\"stack\" functionality to git itself rather than just the one-step-back\nfunctionality of \"--amend\". For example, one simple thing that might\nhelp would be a command to edit the commit message of any commit. That\nwould at least be easy to implement as it wouldn't introduce any\nuser-interface concerns about dealing with conflicts while replaying\nhistory.\n\n-Carl\n"},{"id":"296465","messageId":"ekmkoe$a52$1@sea.gmane.org","threadId":"43062","inReplyTo":"7vd5786opj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Salikh Zakirov","fromEmail":"salikh.zakirov@intel.com","sentAt":"2006-11-30T12:23:13Z","receivedAt":"2006-11-30T12:23:13Z","isPatch":true,"sender":{"key":"salikh.zakirov@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> I've been playing with a \"private edition\" git to see how it\n> feels like to use \"git commit\" that defaults to the \"-a\"\n> behaviour, using myself as a guinea pig, for the rest of the\n> evening.\n\nThanks a lot for the patches, Junio!\n\nI am using them for two days, and my experience is great!\nMany times it saved me annoyances of forgetting to put '-a' to 'git commit'.\n\nIt should be noted, that I mostly used 'git-commit files...'\nor 'git-commit -a' forms before.\n\nSomeone said, that default '-a' does not go well with 'git-commit --amend',\nand I second that. It was somewhat suprising to see that 'git commit --amend'\nis going to include all of the dirty state into the commit,\nand since there is no easy way to abort a --amend commit (because the comment\nbuffer wasn't empty, and :q! does not work as it would on the regular commit),\nI had to untwine the changes manually.\n\n"},{"id":"295534","messageId":"ekmlf4$ask$3@sea.gmane.org","threadId":"43062","inReplyTo":"ekmkoe$a52$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T13:16:04Z","receivedAt":"2006-11-30T13:16:04Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Salikh Zakirov wrote:\n\n> Someone said, that default '-a' does not go well with 'git-commit --amend',\n> and I second that. It was somewhat suprising to see that 'git commit --amend'\n> is going to include all of the dirty state into the commit,\n> and since there is no easy way to abort a --amend commit (because the comment\n> buffer wasn't empty, and :q! does not work as it would on the regular commit),\n> I had to untwine the changes manually.\n\nBy the way, I think that git-commit should also watch the return code\nfrom the editor, so you can ^C it to abort git-commit --amend.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297276","messageId":"m2odqpm0d6.fsf@ziti.fhcrc.org","threadId":"43062","inReplyTo":"ekmlf4$ask$3@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2006-11-30T15:15:49Z","receivedAt":"2006-11-30T15:15:49Z","isPatch":true,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Salikh Zakirov wrote:\n>\n>> Someone said, that default '-a' does not go well with 'git-commit --amend',\n>> and I second that. It was somewhat suprising to see that 'git commit --amend'\n>> is going to include all of the dirty state into the commit,\n>> and since there is no easy way to abort a --amend commit (because the comment\n>> buffer wasn't empty, and :q! does not work as it would on the regular commit),\n>> I had to untwine the changes manually.\n>\n> By the way, I think that git-commit should also watch the return code\n> from the editor, so you can ^C it to abort git-commit --amend.\n\nFor those using emacsclient, I don't think ^C will work.  Is there\nanother way to undu an ammend commit?  If not, is there any sense in\n"},{"id":"296870","messageId":"fcaeb9bf0611300750t4adb4c97ibd65bc5b254e7efa@mail.gmail.com","threadId":"43062","inReplyTo":"m2odqpm0d6.fsf@ziti.fhcrc.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-30T15:50:23Z","receivedAt":"2006-11-30T15:50:23Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 11/30/06, Seth Falcon <sethfalcon@gmail.com> wrote:\n>\n> For those using emacsclient, I don't think ^C will work.  Is there\n> another way to undu an ammend commit?  If not, is there any sense in\n> detecting a magic comment to abort the ammend commit?\n\nUncomment to abort commit would be more intuitive.\n\n-- \n"},{"id":"296147","messageId":"m23b80ncpj.fsf@ziti.fhcrc.org","threadId":"43062","inReplyTo":"fcaeb9bf0611300750t4adb4c97ibd65bc5b254e7efa@mail.gmail.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2006-11-30T16:03:52Z","receivedAt":"2006-11-30T16:03:52Z","isPatch":true,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"\"Nguyen Thai Ngoc Duy\" <pclouds@gmail.com> writes:\n\n> On 11/30/06, Seth Falcon <sethfalcon@gmail.com> wrote:\n>>\n>> For those using emacsclient, I don't think ^C will work.  Is there\n>> another way to undu an ammend commit?  If not, is there any sense in\n>> detecting a magic comment to abort the ammend commit?\n>\n> Uncomment to abort commit would be more intuitive.\n\n"},{"id":"297203","messageId":"ekmvc6$inf$1@sea.gmane.org","threadId":"43062","inReplyTo":"m2odqpm0d6.fsf@ziti.fhcrc.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T16:05:11Z","receivedAt":"2006-11-30T16:05:11Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Seth Falcon wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n\n>> By the way, I think that git-commit should also watch the return code\n>> from the editor, so you can ^C it to abort git-commit --amend.\n> \n> For those using emacsclient, I don't think ^C will work.  Is there\n> another way to undo an amended commit?  If not, is there any sense in\n> detecting a magic comment to abort the ammend commit?\n\nYou can ^C the git-commit invocation.\n\nAnd I guess ORIG_HEAD would help, and reflog certainly would help\nreverting (undoing) amend of a commit.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298514","messageId":"456F1148.2020907@shadowen.org","threadId":"43062","inReplyTo":"ekmkoe$a52$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-30T17:13:44Z","receivedAt":"2006-11-30T17:13:44Z","isPatch":true,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Salikh Zakirov wrote:\n> Junio C Hamano wrote:\n>> I've been playing with a \"private edition\" git to see how it\n>> feels like to use \"git commit\" that defaults to the \"-a\"\n>> behaviour, using myself as a guinea pig, for the rest of the\n>> evening.\n> \n> Thanks a lot for the patches, Junio!\n> \n> I am using them for two days, and my experience is great!\n> Many times it saved me annoyances of forgetting to put '-a' to 'git commit'.\n> \n> It should be noted, that I mostly used 'git-commit files...'\n> or 'git-commit -a' forms before.\n> \n> Someone said, that default '-a' does not go well with 'git-commit --amend',\n> and I second that. It was somewhat suprising to see that 'git commit --amend'\n> is going to include all of the dirty state into the commit,\n> and since there is no easy way to abort a --amend commit (because the comment\n> buffer wasn't empty, and :q! does not work as it would on the regular commit),\n> I had to untwine the changes manually.\n\nIf you have no commit message the commit will be aborted.  So just write\nback a completly empty commit message.  \"dG:wq\" in vi land.\n\napw@larry:~/git/linux-2.6$ git commit --amend\n* no commit message?  aborting commit.\napw@larry:~/git/linux-2.6$\n\n"}]}