{"thread":{"id":"23565","subject":"Re: Please default to 'commit -a' when no changes were added","startedAt":"2010-04-22T15:58:07Z","lastAt":"2010-04-25T08:01:06Z","messageCount":76,"participants":["Jonathan Nieder","Goswin von Brederlow","Nicolas Pitre","Sverre Rabbelier","Junio C Hamano","Matthieu Moy","Adam Brewster","Michael Witten","Jon Seymour","Tomas Carnecky","Miles Bader","Tor Arntsen","Björn Steinbrink","Sergei Organov","Wincent Colaiuta","Matthias Andree","Daniel Grace","Eric Raymond","Jakub Narebski","Andreas Schwab","Joey Hess","Mike Hommey","Petr Baudis","Jacob Helwig"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140140","messageId":"20100422155806.GC4801@progeny.tock","threadId":"23565","inReplyTo":"20100422151037.2310.2429.reportbug@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T15:58:07Z","receivedAt":"2010-04-22T15:58:07Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"[topic: making ‘git commit’ more helpful when there are no changes\nregistered in the index]\n\nHi Goswin,\n\nGoswin von Brederlow wrote:\n\n> in most (all but git?) RCS a plain 'commit' without any arguments\n> commits all changes (to registered files).\n\nYes, but they are wrong. :)\n\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n[...]\n> Imho in most cases where no changes\n> were added people do want to commit all modified files. And if not\n> then exiting the editor to abort is easy enough.\n\nI absent-mindedly type ‘git commit’ having forgotten to update the\nindex with my changes fairly often. Then I add the appropriate\nchanges, which is almost never all of them. I don’t think this is so\nunusual.\n\nStarting out, I can see how it would be comforting to people if\n‘git commit’ would default to -a behavior if they ignore the index.\nThat is logically a different operation, though, so it would also send\na wrong message and make it harder in the long run to get used to the\ninterface.\n\nInstead, I think it would be better to focus on making the error\nmessage more helpful. Right now there is a screen full of status\nbefore the advice, which might make it easy to get scared before\nreading it.\n\nHere’s a very rough patch to suppress that screenful. What do you\nthink?\n\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex c5ab683..9cb5489 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -396,7 +396,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int\n }\n \n static int run_status(FILE *fp, const char *index_file, const char *prefix, int nowarn,\n-\t\t struct wt_status *s)\n+\t\t struct wt_status *s, int simple)\n {\n \tunsigned char sha1[20];\n \n@@ -415,6 +415,13 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int\n \n \twt_status_collect(s);\n \n+\tif (simple) {\n+\t\tif (s->commitable)\n+\t\t\tdie(\"internal error: are there changes or not?\");\n+\t\twt_status_print_nochanges(s);\n+\t\treturn 0;\n+\t}\n+\n \tswitch (status_format) {\n \tcase STATUS_FORMAT_SHORT:\n \t\twt_shortstatus_print(s, null_termination);\n@@ -670,7 +677,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n \n \t\tsaved_color_setting = s->use_color;\n \t\ts->use_color = 0;\n-\t\tcommitable = run_status(fp, index_file, prefix, 1, s);\n+\t\tcommitable = run_status(fp, index_file, prefix, 1, s, 0);\n \t\ts->use_color = saved_color_setting;\n \t} else {\n \t\tunsigned char sha1[20];\n@@ -692,7 +699,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,\n \n \tif (!commitable && !in_merge && !allow_empty &&\n \t !(amend && is_a_merge(head_sha1))) {\n-\t\trun_status(stdout, index_file, prefix, 0, s);\n+\t\trun_status(stdout, index_file, prefix, 0, s, 1);\n \t\treturn 0;\n \t}\n \n@@ -946,7 +953,7 @@ static int dry_run_commit(int argc, const char **argv, const char *prefix,\n \tconst char *index_file;\n \n \tindex_file = prepare_index(argc, argv, prefix, 1);\n-\tcommitable = run_status(stdout, index_file, prefix, 0, s);\n+\tcommitable = run_status(stdout, index_file, prefix, 0, s, 0);\n \trollback_index_files();\n \n \treturn commitable ? 0 : 1;\ndiff --git a/wt-status.c b/wt-status.c\nindex 8ca59a2..b50bf71 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -589,6 +589,24 @@ static void wt_status_print_tracking(struct wt_status *s)\n \tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), \"#\");\n }\n \n+void wt_status_print_nochanges(struct wt_status *s)\n+{\n+\tif (s->amend)\n+\t\tfprintf(s->fp, \"# No changes\\n\");\n+\telse if (s->nowarn)\n+\t\t; /* nothing */\n+\telse if (s->workdir_dirty)\n+\t\tprintf(\"no changes added to commit (use \\\"git add\\\" and/or \\\"git commit -a\\\")\\n\");\n+\telse if (s->untracked.nr)\n+\t\tprintf(\"nothing added to commit but untracked files present (use \\\"git add\\\" to track)\\n\");\n+\telse if (s->is_initial)\n+\t\tprintf(\"nothing to commit (create/copy files and use \\\"git add\\\" to track)\\n\");\n+\telse if (!s->show_untracked_files)\n+\t\tprintf(\"nothing to commit (use -u to show untracked files)\\n\");\n+\telse\n+\t\tprintf(\"nothing to commit (working directory clean)\\n\");\n+}\n+\n void wt_status_print(struct wt_status *s)\n {\n \tconst char *branch_color = color(WT_STATUS_HEADER, s);\n@@ -629,22 +647,8 @@ void wt_status_print(struct wt_status *s)\n \n \tif (s->verbose)\n \t\twt_status_print_verbose(s);\n-\tif (!s->commitable) {\n-\t\tif (s->amend)\n-\t\t\tfprintf(s->fp, \"# No changes\\n\");\n-\t\telse if (s->nowarn)\n-\t\t\t; /* nothing */\n-\t\telse if (s->workdir_dirty)\n-\t\t\tprintf(\"no changes added to commit (use \\\"git add\\\" and/or \\\"git commit -a\\\")\\n\");\n-\t\telse if (s->untracked.nr)\n-\t\t\tprintf(\"nothing added to commit but untracked files present (use \\\"git add\\\" to track)\\n\");\n-\t\telse if (s->is_initial)\n-\t\t\tprintf(\"nothing to commit (create/copy files and use \\\"git add\\\" to track)\\n\");\n-\t\telse if (!s->show_untracked_files)\n-\t\t\tprintf(\"nothing to commit (use -u to show untracked files)\\n\");\n-\t\telse\n-\t\t\tprintf(\"nothing to commit (working directory clean)\\n\");\n-\t}\n+\tif (!s->commitable)\n+\t\twt_status_print_nochanges(s);\n }\n \n static void wt_shortstatus_unmerged(int null_termination, struct string_list_item *it,\ndiff --git a/wt-status.h b/wt-status.h\nindex 9120673..f249955 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -59,6 +59,8 @@ void wt_status_prepare(struct wt_status *s);\n void wt_status_print(struct wt_status *s);\n void wt_status_collect(struct wt_status *s);\n \n+void wt_status_print_nochanges(struct wt_status *s);\n+\n void wt_shortstatus_print(struct wt_status *s, int null_termination);\n void wt_porcelain_print(struct wt_status *s, int null_termination);\n \n"},{"id":"140144","messageId":"87wrvzs590.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"20100422155806.GC4801@progeny.tock","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-22T18:37:31Z","receivedAt":"2010-04-22T18:37:31Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Jonathan Nieder writes:\n\n> [topic: making ‘git commit’ more helpful when there are no changes\n> registered in the index]\n>\n> Hi Goswin,\n>\n> Goswin von Brederlow wrote:\n>\n>> in most (all but git?) RCS a plain 'commit' without any arguments\n>> commits all changes (to registered files).\n>\n> Yes, but they are wrong. :)\n>\n>> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> [...]\n>> Imho in most cases where no changes\n>> were added people do want to commit all modified files. And if not\n>> then exiting the editor to abort is easy enough.\n>\n> I absent-mindedly type ‘git commit’ having forgotten to update the\n> index with my changes fairly often. Then I add the appropriate\n> changes, which is almost never all of them. I don’t think this is so\n> unusual.\n\nThen you would type C-X C-c or :q or whatever exits your editor. No harm\ndone. Also, as you say below, git can output quite a long list of things\nin the message. With my proposed change you would get the list inside\nyour editor and could scroll through it and check if it can all go as a\nsingle commit or not. Imho doing nothing as it does now is the least\nusefull thing to do.\n\n> Starting out, I can see how it would be comforting to people if\n> ‘git commit’ would default to -a behavior if they ignore the index.\n> That is logically a different operation, though, so it would also send\n> a wrong message and make it harder in the long run to get used to the\n> interface.\n>\n> Instead, I think it would be better to focus on making the error\n> message more helpful. Right now there is a screen full of status\n> before the advice, which might make it easy to get scared before\n> reading it.\n>\n> Here’s a very rough patch to suppress that screenful. What do you\n> think?\n\nI have never ever needed anything but\n\ngit commit -a\ngit commit ...\n\nI do commit often and commit early and I start and finish one thing\nbefore I start another. Also I keep my files small so they do one thing\nand do it well. Overall that means I don't end up with multiple changes\nin a single file so I never need to cherry pick changes for a commit.\n\nSo I don't think people should be forced to utilize the index. Imho that\nis a matter of the workflow people use. Some people work better with the\nindex and some people (or projects) don't need it.\n\n\n\nAlternatively an option to take all changes but only if the index is\nempty would be helpfull. Then people could define an alias for that or\nset the option in the config. Other than setting -a that would allow\nusing an index when needed and commit everything in the normal case\nwithout having to change the command used to commit.\n\nMfG\n Goswin\n"},{"id":"140147","messageId":"alpine.LFD.2.00.1004221445310.7232@xanadu.home","threadId":"23565","inReplyTo":"87wrvzs590.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-22T19:03:07Z","receivedAt":"2010-04-22T19:03:07Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n\n> I have never ever needed anything but\n> \n> git commit -a\n> git commit ...\n\nWhen I was using CVS/SVN that's what I thought too.\n\n> I do commit often and commit early and I start and finish one thing\n> before I start another. Also I keep my files small so they do one thing\n> and do it well. Overall that means I don't end up with multiple changes\n> in a single file so I never need to cherry pick changes for a commit.\n\nGood for you. I'm not that disciplined. Hence I often end up working on \nmore than one thing in parallel. The index is just so incredibly useful \nin that case. I'm also a big fan of 'git add -e'.\n\n> So I don't think people should be forced to utilize the index. Imho that\n> is a matter of the workflow people use. Some people work better with the\n> index and some people (or projects) don't need it.\n\nExact. It is therefore not progress to impose some inconvenience to one \nwork flow in order to make another one easier. And in this case we're \ntalking about the difference between having to type an additional -a vs \nthe risk of creating a commit with unexpected content.\n\n> Alternatively an option to take all changes but only if the index is\n> empty would be helpfull. Then people could define an alias for that or\n> set the option in the config. Other than setting -a that would allow\n> using an index when needed and commit everything in the normal case\n> without having to change the command used to commit.\n\nBut you're proposing to change the semantics for that command. And I \nalso suspect that you're trying to make the index more hidden while what \nwe're actually trying to do is to promote it.\n\nWhat _you_ can do though, is this:\n\n\tgit config --global alias.ci \"commit -a\"\n\n\nNicolas\n"},{"id":"140148","messageId":"u2ifabb9a1e1004221208je2520cefo952367f02f51ec0e@mail.gmail.com","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004221445310.7232@xanadu.home","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-22T19:08:10Z","receivedAt":"2010-04-22T19:08:10Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Apr 22, 2010 at 21:03, Nicolas Pitre wrote:\n> Good for you.  I'm not that disciplined. Hence I often end up working on\n> more than one thing in parallel.  The index is just so incredibly useful\n> in that case.  I'm also a big fan of 'git add -e'.\n\nSpeaking of which... how about having just 'git commit' drop you in\ninteractive commit mode?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"140157","messageId":"87sk6n4426.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004221445310.7232@xanadu.home","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-22T20:37:05Z","receivedAt":"2010-04-22T20:37:05Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Nicolas Pitre writes:\n\n> On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n>\n>> I have never ever needed anything but\n>> \n>> git commit -a\n>> git commit ...\n>\n> When I was using CVS/SVN that's what I thought too.\n>\n>> I do commit often and commit early and I start and finish one thing\n>> before I start another. Also I keep my files small so they do one thing\n>> and do it well. Overall that means I don't end up with multiple changes\n>> in a single file so I never need to cherry pick changes for a commit.\n>\n> Good for you. I'm not that disciplined. Hence I often end up working on \n> more than one thing in parallel. The index is just so incredibly useful \n> in that case. I'm also a big fan of 'git add -e'.\n\nAs soon as you do 'git add -e' then you have an index. In that case a\n'git commit' would use the index. There would be no change in worflow or\nbehaviour for you.\n\n>> So I don't think people should be forced to utilize the index. Imho that\n>> is a matter of the workflow people use. Some people work better with the\n>> index and some people (or projects) don't need it.\n>\n> Exact. It is therefore not progress to impose some inconvenience to one \n> work flow in order to make another one easier. And in this case we're \n> talking about the difference between having to type an additional -a vs \n> the risk of creating a commit with unexpected content.\n\nIs there a risk? You do get an editor with all the files affected listed\ngiving you a big fat warning what you are about to commit. Yes I\nsometimes do start to commit wrongly too (no matter what RCS used) but\nthen I just close the editor to abort and commit the things seperately.\n\n>> Alternatively an option to take all changes but only if the index is\n>> empty would be helpfull. Then people could define an alias for that or\n>> set the option in the config. Other than setting -a that would allow\n>> using an index when needed and commit everything in the normal case\n>> without having to change the command used to commit.\n>\n> But you're proposing to change the semantics for that command. And I \n> also suspect that you're trying to make the index more hidden while what \n> we're actually trying to do is to promote it.\n\nYes, it would hide the index. But you are not just promoting it. You are\nforcing people to always use it, even if only through the -a option.\n\n> What _you_ can do though, is this:\n>\n> \tgit config --global alias.ci \"commit -a\"\n\nBut then when I accidentally use 'git ci' while having an index the\nindex gets ignored and all changed files get commited in one big mess.\nGiven how seldom I need an index (so far never) the risk of using 'git\nci' accidentally is way to high. Same with typing -a. I do it so often\nthat when I actualy don't want it I will probably type it anyway out of\nhabbit.\n\nMy way would be safe in that it will never ignore an index if there is\none. And if it is a new option then it would not alter the existing\nsemantic, just add to it. Call the option --smart-a or --a-if-empty.\n\nMfG\n Goswin\n"},{"id":"140164","messageId":"alpine.LFD.2.00.1004221651590.7232@xanadu.home","threadId":"23565","inReplyTo":"87sk6n4426.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-22T21:25:07Z","receivedAt":"2010-04-22T21:25:07Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n> >\n> >> I do commit often and commit early and I start and finish one thing\n> >> before I start another. Also I keep my files small so they do one thing\n> >> and do it well. Overall that means I don't end up with multiple changes\n> >> in a single file so I never need to cherry pick changes for a commit.\n> >\n> > Good for you. I'm not that disciplined. Hence I often end up working on \n> > more than one thing in parallel. The index is just so incredibly useful \n> > in that case. I'm also a big fan of 'git add -e'.\n> \n> As soon as you do 'git add -e' then you have an index. In that case a\n> 'git commit' would use the index. There would be no change in worflow or\n> behaviour for you.\n\nBut the point is if I did not use 'git add'.\n\n> >> So I don't think people should be forced to utilize the index. Imho that\n> >> is a matter of the workflow people use. Some people work better with the\n> >> index and some people (or projects) don't need it.\n> >\n> > Exact. It is therefore not progress to impose some inconvenience to one \n> > work flow in order to make another one easier. And in this case we're \n> > talking about the difference between having to type an additional -a vs \n> > the risk of creating a commit with unexpected content.\n> \n> Is there a risk? You do get an editor with all the files affected listed\n> giving you a big fat warning what you are about to commit. Yes I\n> sometimes do start to commit wrongly too (no matter what RCS used) but\n> then I just close the editor to abort and commit the things seperately.\n\nYes, but this is a much greater burden to 1) not forget to empty the \neditor, and 2) actually save the empty file. Simply exiting the editor \nwill cause unwanted commit.\n\nCompare that with simply adding -a to your commit command when told so.\n\n> >> Alternatively an option to take all changes but only if the index is\n> >> empty would be helpfull. Then people could define an alias for that or\n> >> set the option in the config. Other than setting -a that would allow\n> >> using an index when needed and commit everything in the normal case\n> >> without having to change the command used to commit.\n> >\n> > But you're proposing to change the semantics for that command. And I \n> > also suspect that you're trying to make the index more hidden while what \n> > we're actually trying to do is to promote it.\n> \n> Yes, it would hide the index. But you are not just promoting it. You are\n> forcing people to always use it, even if only through the -a option.\n\nWell, sure.\n\nAnd you might be glad that the -a option is there at all. When this was \ndebated, the concensus was that the index is what makes Git so \ndifferent, and actually *better* than the alternatives.\n\nConcerns were raised about natural human resistance to change and the \nfact that some people would have problem adapting to a different model. \nSo the -a argument was added as a compromize, although the concensus was \nmuch less strong in that case.\n\nAnd experience so far has shown that the vast majority of new Git users \nstarted to really appreciate the index once they've past the initial \nhurdle of getting used to a different concept.\n\nSo we can say that Git's index is one of its major feature. You should \nlearn to use it or stick to -a, but please don't try to make Git into \nwhat it was meant to be different from.\n\n> > What _you_ can do though, is this:\n> >\n> > \tgit config --global alias.ci \"commit -a\"\n> \n> But then when I accidentally use 'git ci' while having an index the\n> index gets ignored and all changed files get commited in one big mess.\n\nNot at all. You will end up in the same text editor with the same \nopportunity to abort the messed up commit as you are claiming above. \nExcept now this is your own burden instead of mine. See? One's gain is \nanother one's loss.\n\nHowever in this case this would happen because you mixed up an \nindex-using workflow with a non-index-using workflow. While with your \nsuggested change the messed up commit could occur without mixing up \nworkflows.\n\nSo either you use the index or you don't. And of course I'd strongly \nsuggest you truly consider using it.\n\n> Given how seldom I need an index (so far never) the risk of using 'git\n> ci' accidentally is way to high. Same with typing -a. I do it so often\n> that when I actualy don't want it I will probably type it anyway out of\n> habbit.\n\nThis is a strawman. If you do not use the index and never used it so \nfar, why are you so afraid of this ci alias? Please get over it.\n\n\nNicolas\n"},{"id":"140165","messageId":"7vsk6n2n48.fsf@alter.siamese.dyndns.org","threadId":"23565","inReplyTo":"87sk6n4426.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-22T21:28:23Z","receivedAt":"2010-04-22T21:28:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Goswin von Brederlow writes:\n\n>> Exact. It is therefore not progress to impose some inconvenience to one \n>> work flow in order to make another one easier. And in this case we're \n>> talking about the difference between having to type an additional -a vs \n>> the risk of creating a commit with unexpected content.\n>\n> Is there a risk?\n\nAbsolutely.\n\nThink of this sequence:\n\n ... edit edit edit to enhance the program a lot\n ... oops, noticed that there is a small typo in hello.c\n ... fix and do \"git add hello.c\" (at least I thought I did)\n ... edit edit edit to enhance the program a lot more.\n ... it is a good time to get rid of the trivial fix first.\n $ git commit -m 'hello.c: typofix the message'\n ... oops, I mistyped the earlier one as \"git ad hello.c\" and\n ... didn't notice it.\n\nwhich is just an example.\n\nAnd the problem is a lot bigger at the _conceptual_ level.\n\nWe promise to the user that \"git commit\" without paths (nor -a which is\nmerely a short hand to specify all the paths that have changed) to commit\nonly what has been added to the index. If you earlier did \"git add foo\"\nand \"git add bar\", changes made to these two files are the only changes\nthat are committed. If you did only \"git add foo\", then changes made to\nthis one file are the only changes that are committed. If you haven't\nadded anything yet, there is no change to be committed.\n\nSpecial casing the last case (and only the last case) breaks consistency a\nbig way. It is one more pitfall that users need to worry about.\n"},{"id":"140166","messageId":"vpq7hnzcgjq.fsf@bauges.imag.fr","threadId":"23565","inReplyTo":"7vsk6n2n48.fsf@alter.siamese.dyndns.org","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-22T21:40:09Z","receivedAt":"2010-04-22T21:40:09Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Think of this sequence:\n\nThere's another case where it would be hard to decide what's \"The\nRight Thing\":\n\nvi existing-file.c # do some changes\nvi new-file.c # create the file\ngit add new-file.c\ngit commit\n\nIf you take the SVN semantics, the last \"git commit\" should commit the\nchanges to existing-file.c. But keeping the current Git semantics, it\ndoesn't. There are valid reasons why a user can type the above\nsequence with today's Git, and changing it would be backward\nincompatible, and would make the senario a lot more painfull.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"140167","messageId":"x2qc376da901004221448i373a342p1d7b763383e80472@mail.gmail.com","threadId":"23565","inReplyTo":"87sk6n4426.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Adam Brewster","fromEmail":"adambrewster@gmail.com","sentAt":"2010-04-22T21:48:34Z","receivedAt":"2010-04-22T21:48:34Z","isPatch":false,"sender":{"key":"adambrewster@gmail.com","avatar":"https://avatars.githubusercontent.com/u/223816?v=4"},"body":">> What _you_ can do though, is this:\n>>\n>>       git config --global alias.ci \"commit -a\"\n>\n> But then when I accidentally use 'git ci' while having an index the\n> index gets ignored and all changed files get commited in one big mess.\n> Given how seldom I need an index (so far never) the risk of using 'git\n> ci' accidentally is way to high. Same with typing -a. I do it so often\n> that when I actualy don't want it I will probably type it anyway out of\n> habbit.\n>\n> My way would be safe in that it will never ignore an index if there is\n> one. And if it is a new option then it would not alter the existing\n> semantic, just add to it. Call the option --smart-a or --a-if-empty.\n>\n\nConsider\n\n$ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n-a; else git commit; fi' > `git --exec-path`/git-ci\n$ chmod 555 `git --exec-path`/git-ci\n\nAdam\n"},{"id":"140169","messageId":"x2rb4087cc51004221457v1460ffctf29bc0fd90d75aee@mail.gmail.com","threadId":"23565","inReplyTo":"vpq7hnzcgjq.fsf@bauges.imag.fr","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-22T21:57:56Z","receivedAt":"2010-04-22T21:57:56Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 22, 2010 at 16:40, Matthieu Moy\n wrote:\n> There's another case where it would be hard to decide what's \"The\n> Right Thing\":\n>\n> vi existing-file.c # do some changes\n> vi new-file.c      # create the file\n> git add new-file.c\n> git commit\n>\n> If you take the SVN semantics\n\nThe original feature request is pretty specific and still backwards\ncompatible with this case; indeed, the feature request is almost\n99.9999% backwards compatible from what I've skimmed.\n"},{"id":"140173","messageId":"20100422222723.GB12000@progeny.tock","threadId":"23565","inReplyTo":"x2qc376da901004221448i373a342p1d7b763383e80472@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-22T22:27:23Z","receivedAt":"2010-04-22T22:27:23Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Adam Brewster wrote:\n\n> Consider\n> \n> $ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n> -a; else git commit; fi' > `git --exec-path`/git-ci\n> $ chmod 555 `git --exec-path`/git-ci\n\nOr just put it in your $PATH. :)\n\nBy the way, all this talk of “if there is an index” sounds funny to\nmy brainwashed ears. Every version control system I have tried uses\nan index to ensure consistency during a commit; it’s just that most\nof them hide it from the user.\n\nThis may sound pedantic, I realize.\n\nHave fun,\nJonathan\n"},{"id":"140174","messageId":"x2l2cfc40321004221538qade3dd4dkc149f2748b94ef81@mail.gmail.com","threadId":"23565","inReplyTo":"x2qc376da901004221448i373a342p1d7b763383e80472@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2010-04-22T22:38:21Z","receivedAt":"2010-04-22T22:38:21Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, Apr 23, 2010 at 7:48 AM, Adam Brewster wrote:\n\n> Consider\n>\n> $ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n> -a; else git commit; fi' > `git --exec-path`/git-ci\n> $ chmod 555 `git --exec-path`/git-ci\n>\n> Adam\n\nPerhaps I am missing something, but I would have thought git\ndiff-files --quiet would be more useful in this context...\n\njon.\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"140180","messageId":"l2vc376da901004221704l55f06952z4380c398783e5f9f@mail.gmail.com","threadId":"23565","inReplyTo":"x2l2cfc40321004221538qade3dd4dkc149f2748b94ef81@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Adam Brewster","fromEmail":"adambrewster@gmail.com","sentAt":"2010-04-23T00:04:20Z","receivedAt":"2010-04-23T00:04:20Z","isPatch":false,"sender":{"key":"adambrewster@gmail.com","avatar":"https://avatars.githubusercontent.com/u/223816?v=4"},"body":">\n> Perhaps I am missing something, but I would have thought git\n> diff-files --quiet would be more useful in this context...\n>\n> jon.\n>\n\nMaybe so. I really just meant to suggest that if you need something\nmore complicated than a simple git-command, you can put whatever you\nwant in a shell script and use it like an alias.\n\nThen I learned that git aliases can be pretty fancy if they start with \"!sh -c\".\n\nAfter looking at the man pages a bit more, I think \"git diff --cached\n--quiet\" or \"git diff-index --cached --quiet HEAD\" are the right\ncondition. git diff-files will compare the working copy to the index,\nso this sequence\n\n vi file1\n vi file2\n git add file1\n git ci\n\nwould call commit -a, and I think that's wrong.\n\nI also now realize that some use needs to be made of the arguments.\nAs I sent it the first time, \"git ci -m whatever\" doesn't work as it\nshould. Adding \"$@\" to the git commit call doesn't work either\nbecause it breaks \"git ci filename\" if there is no index (it calls\n\"git commit -a filename\").\n"},{"id":"140195","messageId":"87vdbitu9v.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004221651590.7232@xanadu.home","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T09:03:56Z","receivedAt":"2010-04-23T09:03:56Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Nicolas Pitre writes:\n\n> On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > On Thu, 22 Apr 2010, Goswin von Brederlow wrote:\n>> > Exact. It is therefore not progress to impose some inconvenience to one \n>> > work flow in order to make another one easier. And in this case we're \n>> > talking about the difference between having to type an additional -a vs \n>> > the risk of creating a commit with unexpected content.\n>> \n>> Is there a risk? You do get an editor with all the files affected listed\n>> giving you a big fat warning what you are about to commit. Yes I\n>> sometimes do start to commit wrongly too (no matter what RCS used) but\n>> then I just close the editor to abort and commit the things seperately.\n>\n> Yes, but this is a much greater burden to 1) not forget to empty the \n> editor, and 2) actually save the empty file. Simply exiting the editor \n> will cause unwanted commit.\n>\n> Compare that with simply adding -a to your commit command when told so.\n\nThat is not how it works in other RCS. Initialy the editor only contains\ncomments listing the affected files. If you do not alter the file then\nthe commit aborts. I agree that having to empty the file and save it\nwould be a greater burden.\n\n>> >> Alternatively an option to take all changes but only if the index is\n>> >> empty would be helpfull. Then people could define an alias for that or\n>> >> set the option in the config. Other than setting -a that would allow\n>> >> using an index when needed and commit everything in the normal case\n>> >> without having to change the command used to commit.\n>> >\n>> > But you're proposing to change the semantics for that command. And I \n>> > also suspect that you're trying to make the index more hidden while what \n>> > we're actually trying to do is to promote it.\n>> \n>> Yes, it would hide the index. But you are not just promoting it. You are\n>> forcing people to always use it, even if only through the -a option.\n>\n> Well, sure.\n>\n> And you might be glad that the -a option is there at all. When this was \n> debated, the concensus was that the index is what makes Git so \n> different, and actually *better* than the alternatives.\n>\n> Concerns were raised about natural human resistance to change and the \n> fact that some people would have problem adapting to a different model. \n> So the -a argument was added as a compromize, although the concensus was \n> much less strong in that case.\n>\n> And experience so far has shown that the vast majority of new Git users \n> started to really appreciate the index once they've past the initial \n> hurdle of getting used to a different concept.\n>\n> So we can say that Git's index is one of its major feature. You should \n> learn to use it or stick to -a, but please don't try to make Git into \n> what it was meant to be different from.\n>\n>> > What _you_ can do though, is this:\n>> >\n>> > \tgit config --global alias.ci \"commit -a\"\n>> \n>> But then when I accidentally use 'git ci' while having an index the\n>> index gets ignored and all changed files get commited in one big mess.\n>\n> Not at all. You will end up in the same text editor with the same \n> opportunity to abort the messed up commit as you are claiming above. \n> Except now this is your own burden instead of mine. See? One's gain is \n> another one's loss.\n>\n> However in this case this would happen because you mixed up an \n> index-using workflow with a non-index-using workflow. While with your \n> suggested change the messed up commit could occur without mixing up \n> workflows.\n\nNo, with my suggested change (either change of the default or the extra\noption) it would be smart enough to do the right thing on its own.\n\n> So either you use the index or you don't. And of course I'd strongly \n> suggest you truly consider using it.\n>\n>> Given how seldom I need an index (so far never) the risk of using 'git\n>> ci' accidentally is way to high. Same with typing -a. I do it so often\n>> that when I actualy don't want it I will probably type it anyway out of\n>> habbit.\n>\n> This is a strawman. If you do not use the index and never used it so \n> far, why are you so afraid of this ci alias? Please get over it.\n>\n>\n> Nicolas\n\nYou all say the index is such a great thing. So I might use it\neventually. Other people might use it 1 out of 10 times. Yet other\npeople use it 9 out of 10 times. Can you at least accept that the use of\nthe index feature is different for each person?\n\nMy suggested change, with the --a-if-empty option, would not impose\nanything on existing usage. But it would benefit those that rarely use\nan index and would like git to be smart enough to know when to use the\nindex and when not. Yes, it would mean the use of the index ideology is\nnot force upon people anymore. But isn't that a good thing? Free\nsoftware is about freedom. That should include the freedom not to use\nthe index method.\n\nMfG\n Goswin\n"},{"id":"140196","messageId":"87r5m6tu0l.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"vpq7hnzcgjq.fsf@bauges.imag.fr","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T09:09:30Z","receivedAt":"2010-04-23T09:09:30Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> Think of this sequence:\n>\n> There's another case where it would be hard to decide what's \"The\n> Right Thing\":\n>\n> vi existing-file.c # do some changes\n> vi new-file.c # create the file\n> git add new-file.c\n> git commit\n>\n> If you take the SVN semantics, the last \"git commit\" should commit the\n> changes to existing-file.c. But keeping the current Git semantics, it\n> doesn't. There are valid reasons why a user can type the above\n> sequence with today's Git, and changing it would be backward\n> incompatible, and would make the senario a lot more painfull.\n\nFor SVN users it gets much worse:\n\nvi existing-file.c # do some changes\nvi new-file.c # create the file\ngit add new-file.c\nvi new-file.c # do some more changes\ngit commit\n\nA SVN user would expect the current working copies of existing-file.c\nand new-file.c to be commited. Instead only new-file.c is commited and\nonly the fist modification.\n\nWhile this case is still highly confusing to non git users I do see that\nit can't be easily changed. And my suggestion doesn't change it. The\ncall to \"git add\" creates an index so the commit would only act on the\nindex.\n\nMfG\n Goswin\n"},{"id":"140197","messageId":"87mxwutts8.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"x2qc376da901004221448i373a342p1d7b763383e80472@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T09:14:31Z","receivedAt":"2010-04-23T09:14:31Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Adam Brewster writes:\n\n>>> What _you_ can do though, is this:\n>>>\n>>>       git config --global alias.ci \"commit -a\"\n>>\n>> But then when I accidentally use 'git ci' while having an index the\n>> index gets ignored and all changed files get commited in one big mess.\n>> Given how seldom I need an index (so far never) the risk of using 'git\n>> ci' accidentally is way to high. Same with typing -a. I do it so often\n>> that when I actualy don't want it I will probably type it anyway out of\n>> habbit.\n>>\n>> My way would be safe in that it will never ignore an index if there is\n>> one. And if it is a new option then it would not alter the existing\n>> semantic, just add to it. Call the option --smart-a or --a-if-empty.\n>>\n>\n> Consider\n>\n> $ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n> -a; else git commit; fi' > `git --exec-path`/git-ci\n> $ chmod 555 `git --exec-path`/git-ci\n>\n> Adam\n\n% if git diff-tree --quiet HEAD; then git commit -a; else git commit; fi\n7a15ef233c9ea900c9176f4a09260bb64a7e40cb\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n# modified: debian/changelog\n# modified: debian/control\n#\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n# debian/files\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n\nThat does not do the right thing but I was thinking along the same lines\nfor a personal fix.\n\nMfG\n Goswin\n"},{"id":"140198","messageId":"87iq7ittq6.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"20100422222723.GB12000@progeny.tock","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T09:15:45Z","receivedAt":"2010-04-23T09:15:45Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Jonathan Nieder writes:\n\n> Adam Brewster wrote:\n>\n>> Consider\n>> \n>> $ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n>> -a; else git commit; fi' > `git --exec-path`/git-ci\n>> $ chmod 555 `git --exec-path`/git-ci\n>\n> Or just put it in your $PATH. :)\n>\n> By the way, all this talk of “if there is an index” sounds funny to\n> my brainwashed ears. Every version control system I have tried uses\n> an index to ensure consistency during a commit; it’s just that most\n> of them hide it from the user.\n>\n> This may sound pedantic, I realize.\n>\n> Have fun,\n> Jonathan\n\nOther RCS use an index of files they track. Git uses an index of patch\nchunks to commit. Same name, totaly different concept.\n\nOr am I understanding that wrong?\n\nMfG\n Goswin\n"},{"id":"140200","messageId":"4BD166DA.1010803@dbservice.com","threadId":"23565","inReplyTo":"87r5m6tu0l.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2010-04-23T09:22:34Z","receivedAt":"2010-04-23T09:22:34Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"On 4/23/10 11:09 AM, Goswin von Brederlow wrote:\n> For SVN users it gets much worse:\n>\n> vi existing-file.c # do some changes\n> vi new-file.c # create the file\n> git add new-file.c\n> vi new-file.c # do some more changes\n> git commit\n>\n> A SVN user would expect the current working copies of existing-file.c\n> and new-file.c to be commited. Instead only new-file.c is commited and\n> only the fist modification.\n\nBut is compatibility with the SVN interface really what we want to aim \nfor? Just because their interface works that way doesn't mean it's the \ncorrect way.\n\ntom\n"},{"id":"140201","messageId":"87eii6tt9o.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"x2l2cfc40321004221538qade3dd4dkc149f2748b94ef81@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T09:25:39Z","receivedAt":"2010-04-23T09:25:39Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Jon Seymour writes:\n\n> On Fri, Apr 23, 2010 at 7:48 AM, Adam Brewster wrote:\n>\n>> Consider\n>>\n>> $ echo -e '#!/bin/bash\\nif git diff-tree --quiet HEAD; then git commit\n>> -a; else git commit; fi' > `git --exec-path`/git-ci\n>> $ chmod 555 `git --exec-path`/git-ci\n>>\n>> Adam\n>\n> Perhaps I am missing something, but I would have thought git\n> diff-files --quiet would be more useful in this context...\n>\n> jon.\n\n% git diff-files; git diff-files --quiet; echo $?\n:100644 100644 09f06ca1503da57f89331ddc44f0a3c60313c531 0000000000000000000000000000000000000000 M debian/changelog\n:100644 100644 978b107709d1e45b5240a86960587d2a61d8afe6 0000000000000000000000000000000000000000 M debian/control\n1\n\n% git add debian/control\n\n% git diff-files; git diff-files --quiet; echo $?\n:100644 100644 09f06ca1503da57f89331ddc44f0a3c60313c531 0000000000000000000000000000000000000000 M debian/changelog\n1\n\n% git add debian/changelog \n\n% git diff-files; echo $? \n0\n\nDoesn't tell me if there is an index prepared alraedy or not. Only tells\nme if there are changes that are not in the index.\n\nMfG\n Goswin\n"},{"id":"140202","messageId":"vpqvdbi7c30.fsf@bauges.imag.fr","threadId":"23565","inReplyTo":"87r5m6tu0l.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-23T09:27:47Z","receivedAt":"2010-04-23T09:27:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Goswin von Brederlow writes:\n\n> For SVN users it gets much worse:\n>\n> vi existing-file.c # do some changes\n> vi new-file.c # create the file\n> git add new-file.c\n> vi new-file.c # do some more changes\n> git commit\n>\n> A SVN user would expect the current working copies of existing-file.c\n> and new-file.c to be commited. Instead only new-file.c is commited and\n> only the fist modification.\n>\n> While this case is still highly confusing to non git users I do see that\n> it can't be easily changed. And my suggestion doesn't change it. The\n> call to \"git add\" creates an index so the commit would only act on the\n> index.\n\nBut then, you'd still have the confusion for people expecting the SVN\nsemantics. They'd use \"git commit-without-dash-a\" happily untill they\nhave to add a new file, and the day the do a \"git add\" on a new file,\ncommit doesn't add their changes to existing files, and ... WTF!?\n\nDon't get me wrong: I do agree that not everybody have a use for the\nindex. Typically, I teach Git to students, who are light-years away\nfrom understanding what \"clean commit, small and related changes\"\nmeans. They have no use for the index, they just use Git as a way to\nshare code, and possibly as a backup mechanism. I just teach them\n\"always use the -a option of 'git commit' for now, you'll learn about\nthe power of 'git commit-without-dash-a' later\". Unless when they\nforget to say \"-a\", it just works. And it even works when they add new\nfiles, when they resolve conflicts after a merge, ... which your\nproposal does not solve.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"140203","messageId":"buosk6m347u.fsf@dhlpc061.dev.necel.com","threadId":"23565","inReplyTo":"87vdbitu9v.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-23T09:31:17Z","receivedAt":"2010-04-23T09:31:17Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Goswin von Brederlow writes:\n> You all say the index is such a great thing. So I might use it\n> eventually. Other people might use it 1 out of 10 times. Yet other\n> people use it 9 out of 10 times. Can you at least accept that the use of\n> the index feature is different for each person?\n\nIn my case, I use the index extremely often, for complex commits that I\nwant to split up -- but I _also_ use \"-a\" maybe 30-40% of the time, for\nsimple commits that don't need splitting.\n\nI think the \"default to -a if index is empty and there are no args\"\nbehavior sounds perfect. It would have no real adverse effects as far\nas I can see, and would make git a little more convenient for everybody.\n\n-miles\n\n-- \nI'm beginning to think that life is just one long Yoko Ono album; no rhyme\nor reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff\n"},{"id":"140204","messageId":"p2qd2d39d861004230235tacb970bftc96f2c1473843b1c@mail.gmail.com","threadId":"23565","inReplyTo":"87r5m6tu0l.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2010-04-23T09:35:02Z","receivedAt":"2010-04-23T09:35:02Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Fri, Apr 23, 2010 at 11:09, Goswin von Brederlow wrote:\n\n> For SVN users it gets much worse:\n>\n> vi existing-file.c # do some changes\n> vi new-file.c      # create the file\n> git add new-file.c\n> vi new-file.c      # do some more changes\n> git commit\n>\n> A SVN user would expect the current working copies of existing-file.c\n> and new-file.c to be commited. Instead only new-file.c is commited and\n> only the fist modification.\n\nI come from CVS, i.e. a similar background.\n\n> While this case is still highly confusing to non git users I do see that\n> it can't be easily changed. And my suggestion doesn't change it. The\n> call to \"git add\" creates an index so the commit would only act on the\n> index.\n\nI wouldn't agree it's highly confusing. As soon as you understand why\n(and it shouldn't take long), it's a relief. With CVS I would\nconstantly make copies of my working tree so that I could sort out all\nthe different things I was working on at the same time (which is a\nnecessity when you work with development and bugfixing and customer\nreports with different priorities are dropping in). It's much easier\nnow (with Git) to do a couple of different things at the same time.\n\nBesides, I would argue that the SVN/CVS behaviour is creating problems\nalso for SVN/CVS users. Where I work it's not unusual that developers\naccidentally commit different changes in the same commit, making it\nhard to extract the one you want when you later wish to e.g. push a\nspecific change to a maintenance branch or hotfix tree.\n\nAnd git add --patch is also wonderful sometimes. (Unfortunately that\nwon't work on systems with pre-5.8 versions of Perl, which I just\nfound out - but that's another story.)\n\nI plan to create a short course for my fellow co-workers when we move\nmore stuff over from CVS to Git. Just an hour should do I think. I'll\nclarify how the index works very early on and I believe they'll all\n\"get it\" very quickly. I'll probably also take some parts from 'Git\nfrom the bottom up' by John Wiegley, at least I found (after having\nused Git for some time) that knowing how it works from blobs and up\nactually helps a lot.\n\nI won't join in on the discussion of any actual changes to Git, for\nthat I'm too fresh as Git user. I would only like to stress that I\nwouldn't want the current flexibility to get limited or changed to be\nmore like SVN/CVS -- I come from there, remember, and I don't see why\nI would wish to go back.\n\n-Tor\n"},{"id":"140205","messageId":"20100423093943.GB30346@atjola.homenet","threadId":"23565","inReplyTo":"87sk6n4426.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2010-04-23T09:39:43Z","receivedAt":"2010-04-23T09:39:43Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:\n> Is there a risk? You do get an editor with all the files affected listed\n> giving you a big fat warning what you are about to commit.\n\nAnd if I happen to have two unrelated changes in a single file that's\nworth nothing at all. For example, I might have changed the condition\nthat causes some message to be shown, and discovered a typo in the\nmessage itself and fixed it along the way. That needs two commits, but\nthe list of modified files doesn't tell that.\n\nOnly \"commit -v\" would help there, showing the diff in the editor. But\nreviewing the diff in the editor is a PITA and I lose the whole review\nprogress if I find something I don't want to commit and have to abort.\nUsing \"git add [-i|-p|-e]\", git helps me to keep track of the changes I\nalready reviewed and decided to commit.\n\nBjörn\n"},{"id":"140207","messageId":"20100423103919.GA19811@progeny.tock","threadId":"23565","inReplyTo":"87iq7ittq6.fsf@frosties.localdomain","subject":"The index (Re: Please default to 'commit -a' when no changes were added)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-23T10:39:19Z","receivedAt":"2010-04-23T10:39:19Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Goswin von Brederlow wrote:\n\n> Other RCS use an index of files they track. Git uses an index of patch\n> chunks to commit. Same name, totaly different concept.\n\nWhat you say is correct in terms of how some people use the tools.\nBut underneath, the index is a cache that tracks the content of all\nfiles. To make the index not match the work tree is to deliberately\nlet it go stale (or to cheat and poison it, or whatever).\n\nI am making an assumption about other version control systems and it\nis probably wrong for some. Here is the logic: suppose I\n\n 1. Make some changes to files.\n 2. Invoke “vcs commit”\n 3. Pull out the power plug.\n\nWhat happens? If the version control system is sane, then either the\nentire commit takes place or nothing visible happens; because\notherwise, the result is that I screwed everyone over. The easiest\nway to implement this is to make “vcs commit” two steps:\n\n 1. Prepare the proposed changes in a staging area.\n 2. Atomically commit them.\n\nTraditionally, “atomically” means “with a lock, on the remote server\nwhich has a steady power supply”.\n\nIn particular, the index I am talking about tends to be on the _remote_\nmachine. Making it local leads to a lot of improvements.\n\nEarly in the design of git’s user interface, it took some time to\nfigure out how visible to make the index [1]. Personally I am happier\nwith the modern approach of letting people dirty the index if they\nwant to, but if you believe that is wrong, maybe you would like to\nlook at the Cogito scripts for inspiration [2]. There are still many\nlessons to learn from them, I suspect. More importantly, it might be\nfun or interesting.\n\nHopefully that is a little clearer.\nJonathan\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/780/focus=918\nAs you can see, cogito, the most widely used front-end in early\nhistory, did hide the index from the user.\n[2] http://git.or.cz/cogito/\n(warning: they have not been maintained for a while)\n"},{"id":"140208","messageId":"87zl0u5r75.fsf@osv.gnss.ru","threadId":"23565","inReplyTo":"20100423093943.GB30346@atjola.homenet","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2010-04-23T11:44:14Z","receivedAt":"2010-04-23T11:44:14Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Björn Steinbrink writes:\n\n> On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:\n>> Is there a risk? You do get an editor with all the files affected listed\n>> giving you a big fat warning what you are about to commit.\n>\n> And if I happen to have two unrelated changes in a single file that's\n> worth nothing at all. For example, I might have changed the condition\n> that causes some message to be shown, and discovered a typo in the\n> message itself and fixed it along the way. That needs two commits, but\n> the list of modified files doesn't tell that.\n>\n> Only \"commit -v\" would help there, showing the diff in the editor. But\n> reviewing the diff in the editor is a PITA and I lose the whole review\n> progress if I find something I don't want to commit and have to abort.\n> Using \"git add [-i|-p|-e]\", git helps me to keep track of the changes I\n> already reviewed and decided to commit.\n\nAnd how do you check your changes for correctness before committing? I\nhave a habit to only commit the exact tree I've compiled, and I can\ncompile only the working tree, not the index, right? So for me,\ncommitting the index sounds to be a wrong idea (unless it matches the\nwork-tree).\n\nI think I'd like to have an ability to temporarily undo some of changes\nputting them on shelf for later re-application (sounds like extension to\nstash?). This way, when preparing perfect commit, I'd undo everything\nunrelated, check (build/run) the result, then commit. Then I'd re-do\neverything that was undone using single command that would take all the\nchanges from the shelf back to working tree. Repeat as appropriate.\nMultiple shelves would be the next improvement that will allow to\nimmediately sort the changes into different changesets during undoing.\nJust dreaming... At least that's roughly how I actually managed this\nwith CVS using patch and emacs, -- far from being pretty, but works.\n\n-- Sergei.\n"},{"id":"140209","messageId":"t2zfabb9a1e1004230457pae290977w730e1f0adf32017f@mail.gmail.com","threadId":"23565","inReplyTo":"87zl0u5r75.fsf@osv.gnss.ru","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-04-23T11:57:35Z","receivedAt":"2010-04-23T11:57:35Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\n2010/4/23 Sergei Organov :\n> And how do you check your changes for correctness before committing?\n\ngit stash save -k && make all test && git stash pop\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"140211","messageId":"87ocha5pir.fsf@osv.gnss.ru","threadId":"23565","inReplyTo":"t2zfabb9a1e1004230457pae290977w730e1f0adf32017f@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2010-04-23T12:20:28Z","receivedAt":"2010-04-23T12:20:28Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Sverre Rabbelier writes:\n> Heya,\n>\n> 2010/4/23 Sergei Organov :\n>> And how do you check your changes for correctness before committing?\n>\n> git stash save -k && make all test && git stash pop\n\nPerfect, thanks!\n\n-- Sergei.\n"},{"id":"140216","messageId":"87bpdamem8.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"20100423093943.GB30346@atjola.homenet","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T14:23:59Z","receivedAt":"2010-04-23T14:23:59Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Björn Steinbrink writes:\n\n> On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote:\n>> Is there a risk? You do get an editor with all the files affected listed\n>> giving you a big fat warning what you are about to commit.\n>\n> And if I happen to have two unrelated changes in a single file that's\n> worth nothing at all. For example, I might have changed the condition\n> that causes some message to be shown, and discovered a typo in the\n> message itself and fixed it along the way. That needs two commits, but\n> the list of modified files doesn't tell that.\n>\n> Only \"commit -v\" would help there, showing the diff in the editor. But\n> reviewing the diff in the editor is a PITA and I lose the whole review\n> progress if I find something I don't want to commit and have to abort.\n> Using \"git add [-i|-p|-e]\", git helps me to keep track of the changes I\n> already reviewed and decided to commit.\n>\n> Björn\n\nThen you would keep doing that or use git commit --interactive. The\nsuggested change would not affect you at all either way.\n\nMfG\n Goswin\n"},{"id":"140225","messageId":"25441792-181D-456D-8182-F33B49209EFF@wincent.com","threadId":"23565","inReplyTo":"87vdbitu9v.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-04-23T16:01:57Z","receivedAt":"2010-04-23T16:01:57Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:\n> \n> You all say the index is such a great thing. So I might use it\n> eventually. Other people might use it 1 out of 10 times. Yet other\n> people use it 9 out of 10 times. Can you at least accept that the use of\n> the index feature is different for each person?\n> \n> My suggested change, with the --a-if-empty option, would not impose\n> anything on existing usage. But it would benefit those that rarely use\n> an index and would like git to be smart enough to know when to use the\n> index and when not. Yes, it would mean the use of the index ideology is\n> not force upon people anymore. But isn't that a good thing? Free\n> software is about freedom. That should include the freedom not to use\n> the index method.\n\nNot really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.\n\nBut you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. \n\nAnd in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.\n\nIn the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less \"surprising\" for users coming from other systems, but we'd be throwing away something valuable in the process.\n\nI personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index \"the Git way\" bring, that it's hard to imagine how I ever lived without it.\n\nCheers,\nWincent\n"},{"id":"140226","messageId":"m2kb4087cc51004231000l5dba7fb9u8d41dc58109a264c@mail.gmail.com","threadId":"23565","inReplyTo":"4BD166DA.1010803@dbservice.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-23T17:00:51Z","receivedAt":"2010-04-23T17:00:51Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 04:22, Tomas Carnecky wrote:\n> But is compatibility with the SVN interface really what we want to aim for?\n> Just because their interface works that way doesn't mean it's the correct\n> way.\n\nYou--like a lot of others--didn't read the proposal and have not read\nGoswin's replies.\n"},{"id":"140232","messageId":"4BD1EE10.4010009@gmx.de","threadId":"23565","inReplyTo":"20100422155806.GC4801@progeny.tock","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2010-04-23T18:59:28Z","receivedAt":"2010-04-23T18:59:28Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"I'd also concur that \"default to commit -a\" would be a most undesireable\nastonishment for me. Please don't go that way. Thanks.\n(Not that I believe it stands a chance of upstream integration, but to avoid\ndownstream distro-specific shipwrecks.)\n\n-- \nMatthias Andree\n"},{"id":"140233","messageId":"k2ub4087cc51004231234z29228ac8ia0f62a4e16cedae4@mail.gmail.com","threadId":"23565","inReplyTo":"4BD1EE10.4010009@gmx.de","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-23T19:34:50Z","receivedAt":"2010-04-23T19:34:50Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 13:59, Matthias Andree wrote:\n> I'd also concur that \"default to commit -a\" would be a most undesireable\n\nThe proposal was not \"default to commit -a\" but rather \"default to\ncommit -a when the index has not been explicitly updated with\nsomething like git add\".\n\nJust sayin'.\n"},{"id":"140236","messageId":"87aastx6sa.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"25441792-181D-456D-8182-F33B49209EFF@wincent.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-23T20:17:41Z","receivedAt":"2010-04-23T20:17:41Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Wincent Colaiuta writes:\n\n> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:\n>> \n>> You all say the index is such a great thing. So I might use it\n>> eventually. Other people might use it 1 out of 10 times. Yet other\n>> people use it 9 out of 10 times. Can you at least accept that the use of\n>> the index feature is different for each person?\n>> \n>> My suggested change, with the --a-if-empty option, would not impose\n>> anything on existing usage. But it would benefit those that rarely use\n>> an index and would like git to be smart enough to know when to use the\n>> index and when not. Yes, it would mean the use of the index ideology is\n>> not force upon people anymore. But isn't that a good thing? Free\n>> software is about freedom. That should include the freedom not to use\n>> the index method.\n>\n> Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.\n>\n> But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. \n>\n> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.\n\nBut you are already rejecting it in the design phase before there even\nis a patch.\n\n> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less \"surprising\" for users coming from other systems, but we'd be throwing away something valuable in the process.\n\nIf I would ask to disable the indexing feature then you would have a\npoint. But I am not. I'm asking to add something that allows to use git\nin a less \"surprising\" mode that, with the --a-if-empty option, does not\nalter anything else. Git would still have all its great, big, shiny,\ndifferentiating features to set it apart from other SCMs without forcing\nthem down the users throat.\n\n> I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index \"the Git way\" bring, that it's hard to imagine how I ever lived without it.\n>\n> Cheers,\n> Wincent\n\nI personaly have to work with different SCMs every day and every time I\nhave to switch minds to work with each specific one. Making git commit\nwork less surprising would be one less thing to keep in mind.\n\nYou like that Git is different so don't use the --a-if-empty option. You\nwill have lost nothing by allowing that option in. So far I have read\narguments from people saying they don't want to USE the option. But no\narguments why there could not be such an option. And I'm not the only\none that would welcome such an option. Is there no room for a compromise?\n\nMfG\n Goswin\n"},{"id":"140237","messageId":"p2wb4087cc51004231326t1e92a59eg555024eaa4fd51e6@mail.gmail.com","threadId":"23565","inReplyTo":"87aastx6sa.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-23T20:26:38Z","receivedAt":"2010-04-23T20:26:38Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 15:17, Goswin von Brederlow wrote:\n> But you are already rejecting it in the design phase before there even\n> is a patch.\n> ...\n> You like that Git is different so don't use the --a-if-empty option. You\n> will have lost nothing by allowing that option in. So far I have read\n> arguments from people saying they don't want to USE the option. But no\n> arguments why there could not be such an option. And I'm not the only\n> one that would welcome such an option. Is there no room for a compromise?\n\nMy sincere advice is just to write the patch and submit it with an\nexample usage to illustrate your feature.\n\nProse aren't well received on this list (especially without concrete\ncode to reference).\n"},{"id":"140238","messageId":"h2r62a3a9cb1004231333o593a373bvecf8ce7a4e6cd734@mail.gmail.com","threadId":"23565","inReplyTo":"87aastx6sa.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Daniel Grace","fromEmail":"negativeview@gmail.com","sentAt":"2010-04-23T20:33:54Z","receivedAt":"2010-04-23T20:33:54Z","isPatch":false,"sender":{"key":"negativeview@gmail.com","avatar":"https://gravatar.com/avatar/3cdfd055fcddbe166daf37ce403bfce216b100e8fc783998f43938ff77c388dc?d=mp&s=160"},"body":"On Fri, Apr 23, 2010 at 3:17 PM, Goswin von Brederlow wrote:\n> Wincent Colaiuta writes:\n>> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:\n>> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.\n>\n> But you are already rejecting it in the design phase before there even\n> is a patch.\n\nThis is common in open-source. If you come to the mailing list talking\nabout a feature, without a patch, the maintainers let you know how\nlikely they are to want to write or maintain that feature. You haven't\ngiven them a patch they could trivially merge in, so it reads as if\nyou're asking them to write the feature. Why write a feature that they\nwould never use?\n\nWriting it yourself is one way to get a feature included that the\nmaintainers wouldn't use themselves. But you have to realize that\nthey're still thinking about having to maintain that feature. Every\nnew feature adds work to them, making sure that their future work does\nnot break it. There will be some features that are just deemed not\nworth that effort by the people that control the official repository.\nThis is why forking is sometimes (rarely, but sometimes) acceptable.\n\n>> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less \"surprising\" for users coming from other systems, but we'd be throwing away something valuable in the process.\n>\n> If I would ask to disable the indexing feature then you would have a\n> point. But I am not. I'm asking to add something that allows to use git\n> in a less \"surprising\" mode that, with the --a-if-empty option, does not\n> alter anything else. Git would still have all its great, big, shiny,\n> differentiating features to set it apart from other SCMs without forcing\n> them down the users throat.\n\nNothing is being forced down anyones throat by Git. Git doesn't\nsomehow force you to use Git from here into eternity. You state later\nthat you *have* to use many different systems. But it's not Git that\nforces you to do so.\n\n> I personaly have to work with different SCMs every day and every time I\n> have to switch minds to work with each specific one. Making git commit\n> work less surprising would be one less thing to keep in mind.\n\nThis sounds to me like you should try to simplify your setup. I know\nthat sometime it's not possible, but you're fighting an unwinnable\nbattle. If you're truly using that many different systems with\noverlapping functionality you are destined to be confused. Period.\nMost SCMs now do a good job of migrating data and in some cases (git\nsvn, for instance) sharing data on an ongoing basis. There are also\ntools around that handle multiple SCMs behind one consistent\ninterface.\n\n> You like that Git is different so don't use the --a-if-empty option. You\n> will have lost nothing by allowing that option in. So far I have read\n> arguments from people saying they don't want to USE the option. But no\n> arguments why there could not be such an option. And I'm not the only\n> one that would welcome such an option. Is there no room for a compromise?\n\nI'm not one of the maintainers, so maybe I'm speaking out of turn, but\nas I pointed out above, they are losing something for letting in\noptions. They will have entered into an implied contract with their\nusers to keep that feature working in the future, putting a burden on\nfuture development efforts. This is not without cost.\n\nDaniel\nhttp://www.doomstick.com\n"},{"id":"140239","messageId":"alpine.LFD.2.00.1004231639180.7232@xanadu.home","threadId":"23565","inReplyTo":"87aastx6sa.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-23T21:01:41Z","receivedAt":"2010-04-23T21:01:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 23 Apr 2010, Goswin von Brederlow wrote:\n\n> I personaly have to work with different SCMs every day and every time I\n> have to switch minds to work with each specific one. Making git commit\n> work less surprising would be one less thing to keep in mind.\n\nPlease make yourself some git aliases and your problem will be solved. \nAfter all, the alias mechanism was created for a reason.\n\n> You like that Git is different so don't use the --a-if-empty option. You\n> will have lost nothing by allowing that option in. So far I have read\n> arguments from people saying they don't want to USE the option. But no\n> arguments why there could not be such an option. And I'm not the only\n> one that would welcome such an option. Is there no room for a compromise?\n\nI suggest you have a look at all the examples (some are simple, some are \ncomplex) here: https://git.wiki.kernel.org/index.php/Aliases. It should \nbe simple to make an alias with all the safety valves you might think \nof, and then it could even be contributed to section 7 of that page.\n\n\nNicolas\n"},{"id":"140242","messageId":"4BD21CAB.8060903@gmx.de","threadId":"23565","inReplyTo":"k2ub4087cc51004231234z29228ac8ia0f62a4e16cedae4@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2010-04-23T22:18:19Z","receivedAt":"2010-04-23T22:18:19Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Am 23.04.2010 21:34, schrieb Michael Witten:\n> On Fri, Apr 23, 2010 at 13:59, Matthias Andree wrote:\n>> I'd also concur that \"default to commit -a\" would be a most undesireable\n> \n> The proposal was not \"default to commit -a\" but rather \"default to\n> commit -a when the index has not been explicitly updated with\n> something like git add\".\n\nWhich is the same:\n\ndefault (n) (5b) \"a selection automatically used by a computer program\nin the absence of a choice made by the user\" (Merriam-Webster)\n\nNo previous \"git add\" => default \"git commit -a\". Exactly what I don't\nwant. It makes the software appear at nondeterministic as you add to\nthe \"if\"s and \"but\"s, and it breaks established practice.\n\nIt is not desirable to break established workflows for the sake of\nnewcomers' convenience.\n\n"},{"id":"140243","messageId":"20100423222522.GA21224@thyrsus.com","threadId":"23565","inReplyTo":"4BD21CAB.8060903@gmx.de","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-23T22:25:22Z","receivedAt":"2010-04-23T22:25:22Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Matthias Andree :\n> Am 23.04.2010 21:34, schrieb Michael Witten:\n> > On Fri, Apr 23, 2010 at 13:59, Matthias Andree wrote:\n> >> I'd also concur that \"default to commit -a\" would be a most undesireable\n> > \n> > The proposal was not \"default to commit -a\" but rather \"default to\n> > commit -a when the index has not been explicitly updated with\n> > something like git add\".\n> \n> Which is the same:\n> \n> default (n) (5b) \"a selection automatically used by a computer program\n> in the absence of a choice made by the user\" (Merriam-Webster)\n> \n> No previous \"git add\" => default \"git commit -a\". Exactly what I don't\n> want. It makes the software appear at nondeterministic as you add to\n> the \"if\"s and \"but\"s, and it breaks established practice.\n> \n> It is not desirable to break established workflows for the sake of\n> newcomers' convenience.\n\nSpeaking as a relative newcomer, I concur. Commands that are simpler\nto mentally model, because they don't have a lot of exception cases,\nare better.\n-- \n\t\tEric S. Raymond\n"},{"id":"140245","messageId":"4BD220BD.8090808@gmx.de","threadId":"23565","inReplyTo":"87aastx6sa.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2010-04-23T22:35:41Z","receivedAt":"2010-04-23T22:35:41Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Am 23.04.2010 22:17, schrieb Goswin von Brederlow:\n> Wincent Colaiuta writes:\n> \n>> El 23/04/2010, a las 11:03, Goswin von Brederlow escribió:\n>>>\n>>> You all say the index is such a great thing. So I might use it\n>>> eventually. Other people might use it 1 out of 10 times. Yet other\n>>> people use it 9 out of 10 times. Can you at least accept that the use of\n>>> the index feature is different for each person?\n>>>\n>>> My suggested change, with the --a-if-empty option, would not impose\n>>> anything on existing usage. But it would benefit those that rarely use\n>>> an index and would like git to be smart enough to know when to use the\n>>> index and when not. Yes, it would mean the use of the index ideology is\n>>> not force upon people anymore. But isn't that a good thing? Free\n>>> software is about freedom. That should include the freedom not to use\n>>> the index method.\n>>\n>> Not really. Git is free in the sense that: (1) it costs nothing; and (2) you can modify the code to do anything you want.\n>>\n>> But you've also got to recognize that along with your freedom to make modifications, the maintainers are free to either accept or reject them too. \n>>\n>> And in the event that the changes you want aren't accepted, you're free to either fork the tool or pick another one which does conform better to your expectations.\n> \n> But you are already rejecting it in the design phase before there even\n> is a patch.\n> \n>> In the present case experience has shown that the index and the way it can be exploited are an incredibly useful thing. Not only that, it's a differentiating feature of Git and it sets it apart from other SCMs, in a good way. We could mindlessly homogenize to be more like other systems, or less \"surprising\" for users coming from other systems, but we'd be throwing away something valuable in the process.\n> \n> If I would ask to disable the indexing feature then you would have a\n> point. But I am not. I'm asking to add something that allows to use git\n> in a less \"surprising\" mode that, with the --a-if-empty option, does not\n> alter anything else. Git would still have all its great, big, shiny,\n> differentiating features to set it apart from other SCMs without forcing\n> them down the users throat.\n> \n>> I personally don't see the point in having a bunch of SCMs that are all exactly alike. I _like_ that Git's different, and over the years have become so used to the benefits that working with the index \"the Git way\" bring, that it's hard to imagine how I ever lived without it.\n>>\n>> Cheers,\n>> Wincent\n> \n> I personaly have to work with different SCMs every day and every time I\n> have to switch minds to work with each specific one. Making git commit\n> work less surprising would be one less thing to keep in mind.\n\nYou are trying to make Git more difficult to understand for the user.\nThis is easily perceived as non-determinism.\n\nBefore introducing a code branch (à la \"if $(git diff-index --quiet\nHEAD)\", think twice. It doubles testing efforts, it makes explanations\nlong-winded. What's so difficult about typing\n[Arrow-Up] [Space] [-] [a] [Enter] if git commit comes up empty.\n\nWith your option, I need to remember that Git is overzealous and will\ncommit the whole index if nothing is staged, possibly git reset HEAD^\nand clean up the mess. This is inconsistent and inefficient.\n\nTry git gui or git citool if you can't be bothered to remember how to\nadd changes to your commit. Git isn't alone. Think BitKeeper, DARCS.\nFor other systems, there are extensions to help with committing, and to\nemulate what DARCS has pioneered, for instance \"hg record\", an extension\nfor Mercurial.\n\n> You like that Git is different so don't use the --a-if-empty option. You\n\nNo. I for one like the ability to stage changes and commit logically\ncohesive changes without having to save files to temporary files.\n\n> will have lost nothing by allowing that option in. So far I have read\n> arguments from people saying they don't want to USE the option. But no\n> arguments why there could not be such an option. And I'm not the only\n> one that would welcome such an option. Is there no room for a compromise?\n\n\"Bloat\". If I were the maintainer, I'd point you to aliases. If Git\nitself can't do it, tossing a dozen shell lines into git's libexec would\ndo the job. git diff-index --quiet is your friend.\n\n"},{"id":"140247","messageId":"k2tb4087cc51004231626jb9420742z33e8e95be608ac78@mail.gmail.com","threadId":"23565","inReplyTo":"4BD21CAB.8060903@gmx.de","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-23T23:26:57Z","receivedAt":"2010-04-23T23:26:57Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 17:18, Matthias Andree wrote:\n> Am 23.04.2010 21:34, schrieb Michael Witten:\n>> On Fri, Apr 23, 2010 at 13:59, Matthias Andree wrote:\n>>> I'd also concur that \"default to commit -a\" would be a most undesireable\n>>\n>> The proposal was not \"default to commit -a\" but rather \"default to\n>> commit -a when the index has not been explicitly updated with\n>> something like git add\".\n>\n> Which is the same:\n>\n> default (n) (5b) \"a selection automatically used by a computer program\n> in the absence of a choice made by the user\" (Merriam-Webster)\n>\n> No previous \"git add\" => default \"git commit -a\".  Exactly what I don't\n> want.  It makes the software appear at nondeterministic as you add to\n> the \"if\"s and \"but\"s, and it breaks established practice.\n\nIt wasn't at all clear that's what you meant.\n\n> It is not desirable to break established workflows for the sake of\n> newcomers' convenience.\n\nIt's not entirely clear (to me) that Goswin's proposal really breaks\nestablished workflow.\n"},{"id":"140248","messageId":"s2mb4087cc51004231638u6f0110fcxd4369ff8d81c7c06@mail.gmail.com","threadId":"23565","inReplyTo":"20100423222522.GA21224@thyrsus.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-23T23:38:35Z","receivedAt":"2010-04-23T23:38:35Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 17:25, Eric Raymond wrote:\n> Commands that are simpler\n> to mentally model, because they don't have a lot of exception cases,\n> are better.\n\nThe UNIX philosophy: \"Provide mechanism, not policy.\"\n\nSome goofball touched upon this subject in a little-read book called\n\"The Art of Unix Programming\", specifically:\n\n What Unix Gets Wrong\n http://www.faqs.org/docs/artu/ch01s04.html\n\n ...\n\n But the cost of the mechanism-not-policy\n approach is that when the user can set policy,\n the user must set policy. Nontechnical end-users\n frequently find Unix's profusion of options and\n interface styles overwhelming and retreat to\n systems that at least pretend to offer them\n simplicity.\n\n In the short term, Unix's laissez-faire approach\n may lose it a good many nontechnical users. In\n the long term, however, it may turn out that this\n ‘mistake’ confers a critical advantage — because\n policy tends to have a short lifetime, mechanism\n a long one. Today's fashion in interface look-and-feel\n too often becomes tomorrow's evolutionary dead\n end (as people using obsolete X toolkits will tell\n you with some feeling!). So the flip side of the flip\n side is that the “mechanism, not policy” philosophy\n may enable Unix to renew its relevance long after\n competitors more tied to one set of policy or\n interface choices have faded from view.[6]\n\n:-D\n\nSincerely,\nMichael Witten\n"},{"id":"140251","messageId":"7vwrvxtyjm.fsf@alter.siamese.dyndns.org","threadId":"23565","inReplyTo":"87aastx6sa.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-24T01:43:57Z","receivedAt":"2010-04-24T01:43:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Goswin von Brederlow writes:\n\n> But you are already rejecting it in the design phase before there even\n> is a patch.\n\nWe do review both the design and the implementation on this list, and it\nactually is a *good* thing if a proposal is rejected when its design is\nflawed at the conceptual level.\n\nA perfect implementation of an undesirable design is just as undesirable\nas a buggy implementation of the same design. It is a change that we do\nnot want to have in the system.\n\nAs to this particular proposed change to commit everything only when there\nis no change between the index and the HEAD, I think it is a bad change.\nAs several people have already said, it adds unnecessary complexity to the\nend user's mental model.\n"},{"id":"140254","messageId":"20100424043821.GA21973@thyrsus.com","threadId":"23565","inReplyTo":"s2mb4087cc51004231638u6f0110fcxd4369ff8d81c7c06@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-24T04:38:21Z","receivedAt":"2010-04-24T04:38:21Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Michael Witten :\n> On Fri, Apr 23, 2010 at 17:25, Eric Raymond wrote:\n> > Commands that are simpler\n> > to mentally model, because they don't have a lot of exception cases,\n> > are better.\n> \n> The UNIX philosophy: \"Provide mechanism, not policy.\"\n\nAnd commands that are simple, orthogonal, and easy to mentally model do that.\nYou get to provide the policy you want by scripting them.\n-- \n\t\tEric S. Raymond\n"},{"id":"140258","messageId":"y2ib4087cc51004240205mc76bcb31n9ec618e24b388e4f@mail.gmail.com","threadId":"23565","inReplyTo":"20100424043821.GA21973@thyrsus.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2010-04-24T09:05:37Z","receivedAt":"2010-04-24T09:05:37Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Fri, Apr 23, 2010 at 23:38, Eric Raymond wrote:\n> And commands that are simple, orthogonal, and easy to mentally model do that.\n> You get to provide the policy you want by scripting them.\n\nJust to clarify, I wasn't trying to contradict your conclusions.\n"},{"id":"140259","messageId":"20100424090931.GA23202@thyrsus.com","threadId":"23565","inReplyTo":"y2ib4087cc51004240205mc76bcb31n9ec618e24b388e4f@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-24T09:09:31Z","receivedAt":"2010-04-24T09:09:31Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Michael Witten :\n> On Fri, Apr 23, 2010 at 23:38, Eric Raymond wrote:\n> > And commands that are simple, orthogonal, and easy to mentally model do that.\n> > You get to provide the policy you want by scripting them.\n> \n> Just to clarify, I wasn't trying to contradict your conclusions.\n\nI thought you might be, then realized you might not be, and tried to stick \nto saying nomething neutrally affirmative that would be appropriate in\neither case.\n-- \n\t\tEric S. Raymond\n"},{"id":"140260","messageId":"m3633hdw9u.fsf_-_@localhost.localdomain","threadId":"23565","inReplyTo":"20100422155806.GC4801@progeny.tock","subject":"'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-24T09:40:39Z","receivedAt":"2010-04-24T09:40:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonathan Nieder writes:\n\n> Starting out, I can see how it would be comforting to people if\n> ‘git commit’ would default to -a behavior if they ignore the index.\n> That is logically a different operation, though, so it would also send\n> a wrong message and make it harder in the long run to get used to the\n> interface.\n\nI agree that making 'git commit' do 'git commit -a' if there are no\nstaged changes would be a bad change.\n\n> Instead, I think it would be better to focus on making the error\n> message more helpful. Right now there is a screen full of status\n> before the advice, which might make it easy to get scared before\n> reading it.\n>\n> Here’s a very rough patch to suppress that screenful. What do you\n> think?\n\nIt's a pity that people didn't concentrate on this part: improving\nerror message...\n\n\nOn a bit unrelated note what I'd like to have is 'git commit -a'\n(optional) safety against accidentally getting rid of staged changes.\n\nI'd like for 'git commit -a' to *fail* if there are staged changes for\ntracked files, excluding added, removed and renamed files. If you\nhave some staged changes you would get an error message:\n\n $ git add tracked-file\n $ git commit -a\n fatal: There are staged changes to tracked files\n hint: To commit staged changes, use 'git commit'\n hint: To commit all changes, use 'git commit -f -a' \n\nPerhaps this behavior would be turned on only if some config option,\nlike commit.preserveIndex or something like that is set to true...\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"140261","messageId":"87fx2li36m.fsf@catnip.gol.com","threadId":"23565","inReplyTo":"m3633hdw9u.fsf_-_@localhost.localdomain","subject":"Re: 'commit -a' safety","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-24T09:56:49Z","receivedAt":"2010-04-24T09:56:49Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jakub Narebski writes:\n> I'd like for 'git commit -a' to *fail* if there are staged changes for\n> tracked files, excluding added, removed and renamed files. If you\n> have some staged changes you would get an error message:\n>\n> $ git add tracked-file\n> $ git commit -a\n> fatal: There are staged changes to tracked files\n> hint: To commit staged changes, use 'git commit'\n> hint: To commit all changes, use 'git commit -f -a' \n\nThat's bad because of the dual nature of \"git add\" -- someone may\nnormally use \"-a\" most of the time to commit changes, but has really no\nchoice other than git add to add a new file, So with this change, their\nnormal (and reasonable) habits would suddenly result in failure.\n\nI think it's sort of annoying that \"git add\" has such a dual meaning\n(instead of, for instance, having separate \"add\" and \"stage\" commands)\n-- it's one of the more confusing things about learning about git\n-- but oh well, it's unlikely to get changed at this point....\n\n-Miles\n\n-- \nDefenceless, adj. Unable to attack.\n"},{"id":"140262","messageId":"m2vdbhxj0v.fsf@igel.home","threadId":"23565","inReplyTo":"87fx2li36m.fsf@catnip.gol.com","subject":"Re: 'commit -a' safety","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-04-24T10:05:36Z","receivedAt":"2010-04-24T10:05:36Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Miles Bader writes:\n\n> I think it's sort of annoying that \"git add\" has such a dual meaning\n> (instead of, for instance, having separate \"add\" and \"stage\" commands)\n\n\"git add -N\" could be regarded as such a non-staging add command.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"140263","messageId":"201004241226.34884.jnareb@gmail.com","threadId":"23565","inReplyTo":"87fx2li36m.fsf@catnip.gol.com","subject":"Re: 'commit -a' safety","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-24T10:26:32Z","receivedAt":"2010-04-24T10:26:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 24 April 2010, Miles Bader wrote:\n> Jakub Narebski writes:\n\n> > I'd like for 'git commit -a' to *fail* if there are staged changes for\n> > tracked files, excluding added, removed and renamed files. If you\n> > have some staged changes you would get an error message:\n> >\n> > $ git add tracked-file\n> > $ git commit -a\n> > fatal: There are staged changes to tracked files\n> > hint: To commit staged changes, use 'git commit'\n> > hint: To commit all changes, use 'git commit -f -a' \n> \n> That's bad because of the dual nature of \"git add\" -- someone may\n> normally use \"-a\" most of the time to commit changes, but has really no\n> choice other than git add to add a new file, So with this change, their\n> normal (and reasonable) habits would suddenly result in failure.\n> \n> I think it's sort of annoying that \"git add\" has such a dual meaning\n> (instead of, for instance, having separate \"add\" and \"stage\" commands)\n> -- it's one of the more confusing things about learning about git\n> -- but oh well, it's unlikely to get changed at this point....\n\nFirst, this is to be optional safety, by default turned off. So if you\ndo not have problems with situation where you accidentally use \n'git commit -a' instead of 'git commit', committing not what you wanted\nand prepared, you simply do not turn it on.\n\n\nSecond, to be more exact the safety would be triggered only if staged\nchange _differs_ from what is in working area. Therefore\n\n $ git add file\n $ git commit -a\n\nwould not trigger this safety, while\n\n $ git add file\n $ edit file\n $ git commit -a\n fatal: There are staged changes\n\nwould trigger it.\n\n\nThird, there is \"git add -N\" to mark file as tracked, but not add its\ncurrent context.\n\n $ git add -N file\n $ edit file\n $ git commit -a\n\nshould not trigger this safety.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"140264","messageId":"AC853FF9-6723-4824-BB2C-E7E8F79AA95E@wincent.com","threadId":"23565","inReplyTo":"m3633hdw9u.fsf_-_@localhost.localdomain","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-04-24T11:10:24Z","receivedAt":"2010-04-24T11:10:24Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n\n> It's a pity that people didn't concentrate on this part: improving\n> error message...\n> \n> \n> On a bit unrelated note what I'd like to have is 'git commit -a'\n> (optional) safety against accidentally getting rid of staged changes.\n> \n> I'd like for 'git commit -a' to *fail* if there are staged changes for\n> tracked files, excluding added, removed and renamed files. If you\n> have some staged changes you would get an error message:\n> \n> $ git add tracked-file\n> $ git commit -a\n> fatal: There are staged changes to tracked files\n> hint: To commit staged changes, use 'git commit'\n> hint: To commit all changes, use 'git commit -f -a' \n> \n> Perhaps this behavior would be turned on only if some config option,\n> like commit.preserveIndex or something like that is set to true...\n\nFor me this is going to far. While we don't want to make it _easy_ for users to shoot themselves in the foot, neither do we want to make it difficult or impossible for them to get the tool to do things that _might_ be a mistake. And what's the risk here? Accidentally committing too much is not a destructive change, and can be easily undone.\n\nWhere do we stop here with the hand-holding? Would you also want a fatal error here?:\n\n$ git add foo\n$ git commit -- bar\nfatal: There are staged changes to tracked files\n\nIMO, the fact that the commit message editor is populated with a list of changed files that will be included in the commit is enough for people to see what's actually going to happen.\n\nCheers,\nWincent\n"},{"id":"140265","messageId":"201004241348.49397.jnareb@gmail.com","threadId":"23565","inReplyTo":"AC853FF9-6723-4824-BB2C-E7E8F79AA95E@wincent.com","subject":"Re: 'commit -a' safety","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-24T11:48:47Z","receivedAt":"2010-04-24T11:48:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 24. kwietnia 2010 13:10, Wincent Colaiuta napisał:\n> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n> \n> > It's a pity that people didn't concentrate on this part: improving\n> > error message...\n> > \n> > \n> > On a bit unrelated note what I'd like to have is 'git commit -a'\n> > (optional) safety against accidentally getting rid of staged\n> > changes. \n> > \n> > I'd like for 'git commit -a' to *fail* if there are staged changes for\n> > tracked files, excluding added, removed and renamed files. If you\n> > have some staged changes you would get an error message:\n> > \n> > $ git add tracked-file\n> > $ git commit -a\n> > fatal: There are staged changes to tracked files\n> > hint: To commit staged changes, use 'git commit'\n> > hint: To commit all changes, use 'git commit -f -a' \n> > \n> > Perhaps this behavior would be turned on only if some config option,\n> > like commit.preserveIndex or something like that is set to true...\n> \n> For me this is going to far. While we don't want to make it _easy_ for\n> users to shoot themselves in the foot, neither do we want to make it\n> difficult or impossible for them to get the tool to do things that\n> _might_ be a mistake. And what's the risk here? Accidentally\n> committing too much is not a destructive change, and can be easily\n> undone.\n\nWhat you cant recover by undoing commit is the state of index before\naccidental 'git commit -a' instead of 'git commit'.\n\n> \n> Where do we stop here with the hand-holding? Would you also want\n> a fatal error here?: \n> \n> $ git add foo\n $ edit foo # without this safety would not trigger for \"git commit -a\"\n> $ git commit bar\n> fatal: There are staged changes to tracked files\n\nNo, I wouldn't. First, there is much less chance of mistake here, IMHO,\nand second you don't loose staged changes to 'foo' here.\n\n> \n> IMO, the fact that the commit message editor is populated with a list\n> of changed files that will be included in the commit is enough for\n> people to see what's actually going to happen. \n\nNote that in original post there was patch restructuring a bit this info,\nfor relevant information to be more visible.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"140271","messageId":"q2ld2d39d861004240626hf7cfb5a4p1b6d7a594ef3d0fb@mail.gmail.com","threadId":"23565","inReplyTo":"k2ub4087cc51004231234z29228ac8ia0f62a4e16cedae4@mail.gmail.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2010-04-24T13:26:18Z","receivedAt":"2010-04-24T13:26:18Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Fri, Apr 23, 2010 at 21:34, Michael Witten wrote:\n\n> The proposal was not \"default to commit -a\" but rather \"default to\n> commit -a when the index has not been explicitly updated with\n> something like git add\".\n\nFor what it's worth, from another relative newcomer: The above would\nactually cause trouble sometimes for me. Having learned to use git\nadd+git commit, and working on several things at once:\n\nedit file1\nedit file2\nedit file3\ngit add file3\ngit commit -m\"fixed file3\"\n\nIn the above sequence (relative newcomer, but not entirely) I\noccasionally forget to do the 'git add file3' part (I just mistakenly\nthought I did). The way it works now means nothing happens, which is\ngood. The way I understand the proposal I would instead end up with a\ncommit of all my changed files, which is exactly not what I want.\nI can't stop thinking that it should be easy for anyone who wants the\nproposed behaviour to make an alias, or certainly a wrapper. Problem\nsolved, without changing the way it works now.\n\n-Tor\n"},{"id":"140272","messageId":"k2vfc339e4a1004240629sd0249654u17e5df1b3a77bff2@mail.gmail.com","threadId":"23565","inReplyTo":"201004241226.34884.jnareb@gmail.com","subject":"Re: 'commit -a' safety","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-24T13:29:57Z","receivedAt":"2010-04-24T13:29:57Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On Sat, Apr 24, 2010 at 7:26 PM, Jakub Narebski wrote:\n> Third, there is \"git add -N\" to mark file as tracked, but not add its\n> current context.\n>\n>  $ git add -N file\n>  $ edit file\n>  $ git commit -a\n\nMeh. It's going to still require people to change their habits, and\nwhile requiring people to use -N whenever they think they may want to\nuse \"commit -a\" later would work, it feels awkward and artificial.\n\nAll in all, it just doesn't smell clean, and I suspect that would\nprevent many people from enabling such a feature.\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"140279","messageId":"20100424142848.GA4461@gnu.kitenet.net","threadId":"23565","inReplyTo":"201004241348.49397.jnareb@gmail.com","subject":"Re: 'commit -a' safety","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2010-04-24T14:28:48Z","receivedAt":"2010-04-24T14:28:48Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jakub Narebski wrote:\n> What you cant recover by undoing commit is the state of index before\n> accidental 'git commit -a' instead of 'git commit'.\n\nHas a reflog equivilant for the index, to allow resetting it to a\nprevious state, ever been discussed? \n\nI don't grok its data structure -- could that be done efficiently?\n\n-- \nsee shy jo\n"},{"id":"140281","messageId":"20100424151103.GA19272@glandium.org","threadId":"23565","inReplyTo":"20100424142848.GA4461@gnu.kitenet.net","subject":"Re: 'commit -a' safety","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2010-04-24T15:11:03Z","receivedAt":"2010-04-24T15:11:03Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Apr 24, 2010 at 10:28:48AM -0400, Joey Hess wrote:\n> Jakub Narebski wrote:\n> > What you cant recover by undoing commit is the state of index before\n> > accidental 'git commit -a' instead of 'git commit'.\n> \n> Has a reflog equivilant for the index, to allow resetting it to a\n> previous state, ever been discussed? \n> \n> I don't grok its data structure -- could that be done efficiently?\n\nUpdating the index creates blobs, so the file states are definitely\nalready kept. What is missing is trees that could be referred to by a\nlog.\n\nMike\n"},{"id":"140285","messageId":"20100424164247.GM3563@machine.or.cz","threadId":"23565","inReplyTo":"AC853FF9-6723-4824-BB2C-E7E8F79AA95E@wincent.com","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-24T16:42:47Z","receivedAt":"2010-04-24T16:42:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n> > I'd like for 'git commit -a' to *fail* if there are staged changes for\n> > tracked files, excluding added, removed and renamed files.\n\nThanks for this suggestion, this is exactly what I wanted to propose!\n+1 here.\n\nI think this could even be made a default in some time, I don't see any\nuseful workflows this could prevent and adding -f is trivial enough for\nthose who really want to go forward.\n\n> For me this is going to far. While we don't want to make it _easy_ for users to shoot themselves in the foot, neither do we want to make it difficult or impossible for them to get the tool to do things that _might_ be a mistake. And what's the risk here? Accidentally committing too much is not a destructive change, and can be easily undone.\n\nHave you ever done this mistake? If you have done some extensive index\nediting, it is actually a major PITA to restore, and can be even\ndestructive if your index and working tree are too much out-of-sync\n(this does happen to me not so seldom while I also use -a a lot for\ntrivial commits).\n\n> IMO, the fact that the commit message editor is populated with a list of changed files that will be included in the commit is enough for people to see what's actually going to happen.\n\nBTW, I almost always use -m instead of the commit editor. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWhen I feel like exercising, I just lie down until the feeling\ngoes away. -- xed_over\n"},{"id":"140289","messageId":"8B19818F-6578-420B-974D-28C9E3283FD4@wincent.com","threadId":"23565","inReplyTo":"20100424164247.GM3563@machine.or.cz","subject":"Bug#578764: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-04-24T16:59:33Z","receivedAt":"2010-04-24T16:59:33Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 24/04/2010, a las 18:42, Petr Baudis escribió:\n\n> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n>> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n>>> I'd like for 'git commit -a' to *fail* if there are staged changes for\n>>> tracked files, excluding added, removed and renamed files.\n> \n> Thanks for this suggestion, this is exactly what I wanted to propose!\n> +1 here.\n> \n> I think this could even be made a default in some time, I don't see any\n> useful workflows this could prevent and adding -f is trivial enough for\n> those who really want to go forward.\n> \n>> For me this is going to far. While we don't want to make it _easy_ for users to shoot themselves in the foot, neither do we want to make it difficult or impossible for them to get the tool to do things that _might_ be a mistake. And what's the risk here? Accidentally committing too much is not a destructive change, and can be easily undone.\n> \n> Have you ever done this mistake? If you have done some extensive index\n> editing, it is actually a major PITA to restore, and can be even\n> destructive if your index and working tree are too much out-of-sync\n> (this does happen to me not so seldom while I also use -a a lot for\n> trivial commits).\n\nYes I have occasionally committed more than I meant to, but rarely much more, and almost never due to using \"git commit -a\", seeing as I hardly ever use it. I am of the \"commit early and often\" school, and my most common pattern is committing tiny batches of changes which I review frequently with \"git diff\" and then again by staging them with \"git add --patch\" (aliased as \"git patch\" seeing as I use it so often).\n\n>> IMO, the fact that the commit message editor is populated with a list of changed files that will be included in the commit is enough for people to see what's actually going to happen.\n> \n> BTW, I almost always use -m instead of the commit editor. ;-)\n\nAre you not a big fan of \"subject line + justification\" commit message format? Consider it one of the perks of using the format: your editor will show you a nice summary that gives you yet another chance to double-check what you're about to commit.\n\nCheers,\nWincent\n"},{"id":"140290","messageId":"20100424174712.GN10939@machine.or.cz","threadId":"23565","inReplyTo":"8B19818F-6578-420B-974D-28C9E3283FD4@wincent.com","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-24T17:47:13Z","receivedAt":"2010-04-24T17:47:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Apr 24, 2010 at 06:59:33PM +0200, Wincent Colaiuta wrote:\n> El 24/04/2010, a las 18:42, Petr Baudis escribió:\n> \n> > Have you ever done this mistake? If you have done some extensive index\n> > editing, it is actually a major PITA to restore, and can be even\n> > destructive if your index and working tree are too much out-of-sync\n> > (this does happen to me not so seldom while I also use -a a lot for\n> > trivial commits).\n> \n> Yes I have occasionally committed more than I meant to, but rarely much more, and almost never due to using \"git commit -a\", seeing as I hardly ever use it. I am of the \"commit early and often\" school, and my most common pattern is committing tiny batches of changes which I review frequently with \"git diff\" and then again by staging them with \"git add --patch\" (aliased as \"git patch\" seeing as I use it so often).\n\nI also commit early and often, but I just do the review with \"git diff\"\nand then commit right away, I guess I don't see much value to do another\npass staging everything using \"git add -p\".\n\n> >> IMO, the fact that the commit message editor is populated with a list of changed files that will be included in the commit is enough for people to see what's actually going to happen.\n> > \n> > BTW, I almost always use -m instead of the commit editor. ;-)\n> \n> Are you not a big fan of \"subject line + justification\" commit message format? Consider it one of the perks of using the format: your editor will show you a nice summary that gives you yet another chance to double-check what you're about to commit.\n\nI'm a huge fan of \"subject line + justification\", so I use multiple -m\nparameters; frequently, for simple changes subject line is enough, in\nmost of the other cases the justification is a one-liner as well, and\nonly in the rest of the cases I defer to the editor.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWhen I feel like exercising, I just lie down until the feeling\ngoes away. -- xed_over\n"},{"id":"140291","messageId":"alpine.LFD.2.00.1004241413030.7232@xanadu.home","threadId":"23565","inReplyTo":"201004241226.34884.jnareb@gmail.com","subject":"Re: 'commit -a' safety","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-24T18:23:00Z","receivedAt":"2010-04-24T18:23:00Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Apr 2010, Jakub Narebski wrote:\n\n> First, this is to be optional safety, by default turned off. So if you\n> do not have problems with situation where you accidentally use \n> 'git commit -a' instead of 'git commit', committing not what you wanted\n> and prepared, you simply do not turn it on.\n\nIn which case it is worthless. No one will turn this feature on if they \ndon't fully understand what it entails, and those who do understand it \nare probably not the people who would actually benefit from it.\n\n> Second, to be more exact the safety would be triggered only if staged\n> change _differs_ from what is in working area. Therefore\n> \n> $ git add file\n> $ git commit -a\n> \n> would not trigger this safety, while\n> \n> $ git add file\n> $ edit file\n> $ git commit -a\n> fatal: There are staged changes\n> \n> would trigger it.\n\nMuch better yet would be a warning at the top of the summary message in \nthe commit text editor. This way you won't introduce an incompatible \nand potentially annoying behavior that no one is likely to opt-in for, \nand the warning will give a hint that you might be losing some \nintermediate state if you don't abort the commit.\n\n\nNicolas\n"},{"id":"140292","messageId":"alpine.LFD.2.00.1004241430300.7232@xanadu.home","threadId":"23565","inReplyTo":"20100424164247.GM3563@machine.or.cz","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-24T18:35:17Z","receivedAt":"2010-04-24T18:35:17Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Apr 2010, Petr Baudis wrote:\n\n> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n> > El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n> > > I'd like for 'git commit -a' to *fail* if there are staged changes for\n> > > tracked files, excluding added, removed and renamed files.\n> \n> Thanks for this suggestion, this is exactly what I wanted to propose!\n> +1 here.\n> \n> I think this could even be made a default in some time, I don't see any\n> useful workflows this could prevent and adding -f is trivial enough for\n> those who really want to go forward.\n> \n> > For me this is going to far. While we don't want to make it _easy_ for users to shoot themselves in the foot, neither do we want to make it difficult or impossible for them to get the tool to do things that _might_ be a mistake. And what's the risk here? Accidentally committing too much is not a destructive change, and can be easily undone.\n> \n> Have you ever done this mistake? If you have done some extensive index\n> editing, it is actually a major PITA to restore, and can be even\n> destructive if your index and working tree are too much out-of-sync\n> (this does happen to me not so seldom while I also use -a a lot for\n> trivial commits).\n\nIn that case the deficiency is in the fact that no reflog preserves the \nintermediate state of the index, not the fact that you might be allowed \nto do it. Strictly speaking there is no intermediate ref to log, but a \nsynthetic commit could be created for this case just like a stash but \nstored in the current branch's reflog.\n\n\nNicolas\n"},{"id":"140293","messageId":"20100424185433.GN3563@machine.or.cz","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004241430300.7232@xanadu.home","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-04-24T18:54:33Z","receivedAt":"2010-04-24T18:54:33Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sat, Apr 24, 2010 at 02:35:17PM -0400, Nicolas Pitre wrote:\n> In that case the deficiency is in the fact that no reflog preserves the \n> intermediate state of the index, not the fact that you might be allowed \n> to do it. Strictly speaking there is no intermediate ref to log, but a \n> synthetic commit could be created for this case just like a stash but \n> stored in the current branch's reflog.\n\nPossibly, but I don't see how is this better than the check - it is less\nuser friendly, most importantly because user that has not seen this\ntwice has no idea that anything *was* saved to a reflog.\n\nAre there valid user scenarios where you customize your index, then want\nto override that using -a without thinking twice?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWhen I feel like exercising, I just lie down until the feeling\ngoes away. -- xed_over\n"},{"id":"140295","messageId":"alpine.LFD.2.00.1004241503370.7232@xanadu.home","threadId":"23565","inReplyTo":"20100424185433.GN3563@machine.or.cz","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-24T19:09:27Z","receivedAt":"2010-04-24T19:09:27Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Apr 2010, Petr Baudis wrote:\n\n> On Sat, Apr 24, 2010 at 02:35:17PM -0400, Nicolas Pitre wrote:\n> > In that case the deficiency is in the fact that no reflog preserves the \n> > intermediate state of the index, not the fact that you might be allowed \n> > to do it. Strictly speaking there is no intermediate ref to log, but a \n> > synthetic commit could be created for this case just like a stash but \n> > stored in the current branch's reflog.\n> \n> Possibly, but I don't see how is this better than the check - it is less\n> user friendly, most importantly because user that has not seen this\n> twice has no idea that anything *was* saved to a reflog.\n\nPossibly. But the fact that some data could be lost here is a flaw. \nThe reflog is the safety net making sure that whatever the user does is \nnot completely destructive.\n\n> Are there valid user scenarios where you customize your index, then want\n> to override that using -a without thinking twice?\n\nAdmittedly there aren't many. And in those few hypothetical cases then \nrequiring -f would be acceptable.\n\n\nNicolas\n"},{"id":"140297","messageId":"r2y8c9a061004241235n77ca3925q8fde8fc3b01e4e80@mail.gmail.com","threadId":"23565","inReplyTo":"20100424185433.GN3563@machine.or.cz","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-04-24T19:35:38Z","receivedAt":"2010-04-24T19:35:38Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Sat, Apr 24, 2010 at 11:54, Petr Baudis wrote:\n> Are there valid user scenarios where you customize your index, then want\n> to override that using -a without thinking twice?\n>\n\nDepends on what you consider \"customizing your index\". I add files to\nthe index all the time as I'm working on things, then commit -a at the\nend \"without thinking twice\".\n\nFor example:\n1) Hack on something.\n2) git add $thing\n3) Run full test-suite.\n4) Fix a failing module.\n5) git add $fixed-module-and-tests\n6) Repeat 3-5 until there's only one module failing.\n7) Fix last failing module.\n8) git commit -a\n\nI doubt I'm the only one that stages things as a way of marking them\nas \"done\", and using git commit -a to \"check-off\" the last \"todo\"\nitem.\n"},{"id":"140298","messageId":"alpine.LFD.2.00.1004241539270.7232@xanadu.home","threadId":"23565","inReplyTo":"r2y8c9a061004241235n77ca3925q8fde8fc3b01e4e80@mail.gmail.com","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-04-24T19:44:52Z","receivedAt":"2010-04-24T19:44:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Apr 2010, Jacob Helwig wrote:\n\n> On Sat, Apr 24, 2010 at 11:54, Petr Baudis wrote:\n> > Are there valid user scenarios where you customize your index, then want\n> > to override that using -a without thinking twice?\n> >\n> \n> Depends on what you consider \"customizing your index\". I add files to\n> the index all the time as I'm working on things, then commit -a at the\n> end \"without thinking twice\".\n> \n> For example:\n> 1) Hack on something.\n> 2) git add $thing\n> 3) Run full test-suite.\n> 4) Fix a failing module.\n> 5) git add $fixed-module-and-tests\n> 6) Repeat 3-5 until there's only one module failing.\n> 7) Fix last failing module.\n> 8) git commit -a\n> \n> I doubt I'm the only one that stages things as a way of marking them\n> as \"done\", and using git commit -a to \"check-off\" the last \"todo\"\n> item.\n\nSure. But do you happen to often \"commit -a\" more changes to an already \npreviously modified and staged (but not committed yet) file?\n\n\nNicolas\n"},{"id":"140299","messageId":"r2j8c9a061004241257ma6ad8fa6uec9498d3fe16e409@mail.gmail.com","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004241539270.7232@xanadu.home","subject":"Re: 'commit -a' safety (was: Re: Please default to 'commit -a' when no changes were added)","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-04-24T19:57:18Z","receivedAt":"2010-04-24T19:57:18Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Sat, Apr 24, 2010 at 12:44, Nicolas Pitre wrote:\n> On Sat, 24 Apr 2010, Jacob Helwig wrote:\n>\n>> On Sat, Apr 24, 2010 at 11:54, Petr Baudis wrote:\n>> > Are there valid user scenarios where you customize your index, then want\n>> > to override that using -a without thinking twice?\n>> >\n>>\n>> Depends on what you consider \"customizing your index\".  I add files to\n>> the index all the time as I'm working on things, then commit -a at the\n>> end \"without thinking twice\".\n>>\n>> For example:\n>> 1) Hack on something.\n>> 2) git add $thing\n>> 3) Run full test-suite.\n>> 4) Fix a failing module.\n>> 5) git add $fixed-module-and-tests\n>> 6) Repeat 3-5 until there's only one module failing.\n>> 7) Fix last failing module.\n>> 8) git commit -a\n>>\n>> I doubt I'm the only one that stages things as a way of marking them\n>> as \"done\", and using git commit -a to \"check-off\" the last \"todo\"\n>> item.\n>\n> Sure.  But do you happen to often \"commit -a\" more changes to an already\n> previously modified and staged (but not committed yet) file?\n>\n\nIt's not uncommon. It's not the 90% case, either.\n\nSpecifically, I'd do this if I needed to make additional changes to a\nfile that I originally thought was \"done\", while working on that last\nfailing module.\n"},{"id":"140303","messageId":"8739yktuvs.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004231639180.7232@xanadu.home","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-24T21:15:19Z","receivedAt":"2010-04-24T21:15:19Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Nicolas Pitre writes:\n\n> On Fri, 23 Apr 2010, Goswin von Brederlow wrote:\n>\n>> I personaly have to work with different SCMs every day and every time I\n>> have to switch minds to work with each specific one. Making git commit\n>> work less surprising would be one less thing to keep in mind.\n>\n> Please make yourself some git aliases and your problem will be solved. \n> After all, the alias mechanism was created for a reason.\n\nI would accept an alias. But so far two people have suggested an alias\nfor this and both have completly failed to achived the desired result.\n\nIf you know of a test to check if an index exists or not, preferably one\nthat does consider new files being added or files being removed as\n\"index exists\", then please do speak up.\n\n>> You like that Git is different so don't use the --a-if-empty option. You\n>> will have lost nothing by allowing that option in. So far I have read\n>> arguments from people saying they don't want to USE the option. But no\n>> arguments why there could not be such an option. And I'm not the only\n>> one that would welcome such an option. Is there no room for a compromise?\n>\n> I suggest you have a look at all the examples (some are simple, some are \n> complex) here: https://git.wiki.kernel.org/index.php/Aliases. It should \n> be simple to make an alias with all the safety valves you might think \n> of, and then it could even be contributed to section 7 of that page.\n\nNone of the examples have anything to do with checking for an index so\nthat page is rather useless. I know how to set an alias. I just don't\nknow what to put into it.\n\n> Nicolas\n\nMfG\n Goswin\n"},{"id":"140304","messageId":"20100424214024.GA8044@progeny.tock","threadId":"23565","inReplyTo":"8739yktuvs.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-24T21:40:25Z","receivedAt":"2010-04-24T21:40:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nGoswin von Brederlow wrote:\n\n> so far two people have suggested an alias\n> for this and both have completly failed to achived the desired result.\n\nI had thought Adam already suggested using ‘git diff-index --cached\n--quiet HEAD’ [1].\n\nYou can do so like this:\n\ncat <<-EOF >$HOME/bin/git-ci\n#!/bin/sh\ncleanindex() { git diff-index --cached --quiet HEAD; }\n\nif test \"$1\" != \"-h\"\nthen\n\techo >&2 usage: git ci &&\n\texit 129\nfi\nif test \"$#\" != 0\nthen\n\techo >&2 Please use git commit directly.\n\tif cleanindex\n\tthen\n\t\techo >&2 '(no staged changes)'\n\telse\n\t\tgit diff --cached --name-status\n\tfi\n\texit 129\nfi\nif cleanindex\nthen\n\texec git commit -a\nelse\n\texec git commit\nfi\nEOF\nchmod +x $HOME/bin/git-ci\n\nBut dense as I am, I still can’t imagine why\n\necho '[alias] ci = commit -a' >>$HOME/.gitconfig\n\nwouldn’t be better in every way (especially if Jakub’s\ncommit.preserveindex is enabled).\n\n> If you know of a test to check if an index exists or not, preferably one\n> that does consider new files being added or files being removed as\n> \"index exists\", then please do speak up.\n\ntest -e .git/index\n\nI know, not what you meant. But the condition you are looking for is\n“staged content does not match the last commit”, not “the tool has\nsuddenly entered a different mode”.\n\nHope that helps,\nJonathan\n\n[1] Well, he did:\nhttp://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145581\n"},{"id":"140305","messageId":"87tyr0sdv8.fsf@frosties.localdomain","threadId":"23565","inReplyTo":"20100424214024.GA8044@progeny.tock","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Goswin von Brederlow","fromEmail":"goswin-v-b@web.de","sentAt":"2010-04-24T22:08:11Z","receivedAt":"2010-04-24T22:08:11Z","isPatch":false,"sender":{"key":"goswin-v-b@web.de","avatar":null},"body":"Jonathan Nieder writes:\n\n> Hi again,\n>\n> Goswin von Brederlow wrote:\n>\n>> so far two people have suggested an alias\n>> for this and both have completly failed to achived the desired result.\n>\n> I had thought Adam already suggested using ‘git diff-index --cached\n> --quiet HEAD’ [1].\n>\n> You can do so like this:\n>\n> cat <<-EOF >$HOME/bin/git-ci\n> #!/bin/sh\n> cleanindex() { git diff-index --cached --quiet HEAD; }\n\nThanks. That is the missing test.\n\n> if test \"$1\" != \"-h\"\n> then\n> \techo >&2 usage: git ci &&\n> \texit 129\n> fi\n> if test \"$#\" != 0\n> then\n> \techo >&2 Please use git commit directly.\n> \tif cleanindex\n> \tthen\n> \t\techo >&2 '(no staged changes)'\n> \telse\n> \t\tgit diff --cached --name-status\n> \tfi\n> \texit 129\n> fi\n> if cleanindex\n> then\n> \texec git commit -a\n> else\n> \texec git commit\n> fi\n> EOF\n> chmod +x $HOME/bin/git-ci\n>\n> But dense as I am, I still can’t imagine why\n>\n> echo '[alias] ci = commit -a' >>$HOME/.gitconfig\n>\n> wouldn’t be better in every way (especially if Jakub’s\n> commit.preserveindex is enabled).\n\nBecause with the above test it knows when -a is wrong and won't use it.\n\n>> If you know of a test to check if an index exists or not, preferably one\n>> that does consider new files being added or files being removed as\n>> \"index exists\", then please do speak up.\n>\n> test -e .git/index\n>\n> I know, not what you meant. But the condition you are looking for is\n> “staged content does not match the last commit”, not “the tool has\n> suddenly entered a different mode”.\n>\n> Hope that helps,\n> Jonathan\n>\n> [1] Well, he did:\n> http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145581\n\nMust have overlooked that mail, sorry.\n"},{"id":"140306","messageId":"20100424224242.GA8325@progeny.tock","threadId":"23565","inReplyTo":"87tyr0sdv8.fsf@frosties.localdomain","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-24T22:42:42Z","receivedAt":"2010-04-24T22:42:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Goswin von Brederlow wrote:\n\n> Must have overlooked that mail, sorry.\n\nNo problem. Sorry for my impatience with the long thread. Out of\nthis discussion there have already emerged two ideas I like a lot:\n\n 1. a more noticeable safety for ‘git commit’ with no staged changes\n 2. Jakub’s safety for ‘git commit -a’ with staged changes\n\nThanks.\n"},{"id":"140309","messageId":"201004250147.16197.jnareb@gmail.com","threadId":"23565","inReplyTo":"20100424164247.GM3563@machine.or.cz","subject":"Re: 'commit -a' safety","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-24T23:47:14Z","receivedAt":"2010-04-24T23:47:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 24. kwietnia 2010 18:42, Petr Baudis napisał:\n> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n>> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n>>>\n>>> I'd like for 'git commit -a' to *fail* if there are staged changes for\n>>> tracked files, excluding added, removed and renamed files.\n> \n> Thanks for this suggestion, this is exactly what I wanted to propose!\n> +1 here.\n> \n> I think this could even be made a default in some time, I don't see any\n> useful workflows this could prevent and adding -f is trivial enough for\n> those who really want to go forward.\n\nIsn't it how (most of) backwards incompatibile changes are made, first\nadding an option for new behaviour, then later (optionally) changing\nthe default?\n \n>> For me this is going to far. While we don't want to make it _easy_\n>> for users to shoot themselves in the foot, neither do we want to make\n>> it difficult or impossible for them to get the tool to do things that\n>> _might_ be a mistake. And what's the risk here? Accidentally\n>> committing too much is not a destructive change, and can be easily\n>> undone. \n> \n> Have you ever done this mistake? If you have done some extensive index\n> editing, it is actually a major PITA to restore, and can be even\n> destructive if your index and working tree are too much out-of-sync\n> (this does happen to me not so seldom while I also use -a a lot for\n> trivial commits).\n\nThat is the situation this *optional* safety is meant to protect against:\nwhen somebody sometimes use \"git add\" + \"git commit\", but sometimes\nuse \"git commit -a\", to protect carefully index against accidental\n\"git commit -a\" instead of \"git commit\".\n\nIs it worth additional code complication? Shoult it be turned on by\ndefault? Does it promote unsafe workflow of committing untested changes?\n \n>> IMO, the fact that the commit message editor is populated with\n>> a list of changed files that will be included in the commit is enough\n>> for people to see what's actually going to happen. \n> \n> BTW, I almost always use -m instead of the commit editor. ;-)\n\nSo restructuring commit message template so the information is more\nvisible in the case of accidental \"git commit -a\" wouldn't always help...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"140310","messageId":"201004250216.18660.jnareb@gmail.com","threadId":"23565","inReplyTo":"alpine.LFD.2.00.1004241413030.7232@xanadu.home","subject":"Re: 'commit -a' safety","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-25T00:16:18Z","receivedAt":"2010-04-25T00:16:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 24 Apr 2010, Nicolas Pitre wrote:\n> On Sat, 24 Apr 2010, Jakub Narebski wrote:\n> \n> > First, this is to be optional safety, by default turned off. So if you\n> > do not have problems with situation where you accidentally use \n> > 'git commit -a' instead of 'git commit', committing not what you wanted\n> > and prepared, you simply do not turn it on.\n> \n> In which case it is worthless. No one will turn this feature on if they \n> don't fully understand what it entails, and those who do understand it \n> are probably not the people who would actually benefit from it.\n\nOne would turn it after losing carefully prepared index by running \n\"git commit -a\" when one meant \"git commit\" ;-)\n\nMore seriously, it could be made default if it is not too annoying.\n\n> > Second, to be more exact the safety would be triggered only if staged\n> > change _differs_ from what is in working area. Therefore\n> > \n> > $ git add file\n> > $ git commit -a\n> > \n> > would not trigger this safety, while\n> > \n> > $ git add file\n> > $ edit file\n> > $ git commit -a\n> > fatal: There are staged changes\n> > \n> > would trigger it.\n> \n> Much better yet would be a warning at the top of the summary message in \n> the commit text editor. This way you won't introduce an incompatible \n> and potentially annoying behavior that no one is likely to opt-in for, \n> and the warning will give a hint that you might be losing some \n> intermediate state if you don't abort the commit.\n\nAs Petr Baudis said, this actually work *if* you use editor to generate\ncommit message, and you have chance to see commit message template.\nAlso the information was considered not visible enought, hence patch\nat the beginning of the series.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"140312","messageId":"7voch8mj04.fsf@alter.siamese.dyndns.org","threadId":"23565","inReplyTo":"20100424164247.GM3563@machine.or.cz","subject":"Re: 'commit -a' safety","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-25T01:13:47Z","receivedAt":"2010-04-25T01:13:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n>> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n>> > I'd like for 'git commit -a' to *fail* if there are staged changes for\n>> > tracked files, excluding added, removed and renamed files.\n>\n> Thanks for this suggestion, this is exactly what I wanted to propose!\n\nI am somewhat torn.\n\nI have made mistake of running \"commit -a\" after I spent time sifting my\nchanges in the work tree. I can see that I would have been helped by it\nif the safety were there.\n\nBut at the same time, I also know that my development is often a cycle of\nchange then diff then add (to mark the part I am happy with), and when I\nam happy with the output from diff, I conclude it with \"commit -a\" to\nconclude the whole thing. I can see that I would be irritated to if that\nfinal step failed.\n\nBut I suspect the irritation would be relatively mild: \"ah, these days I\nshouldn't use 'commig -a' to conclude these incremental change-review-add\ncycle; instead, I should say 'add -u' then 'commit'\".\n"},{"id":"140313","messageId":"87y6gcgskz.fsf@catnip.gol.com","threadId":"23565","inReplyTo":"201004250216.18660.jnareb@gmail.com","subject":"Re: 'commit -a' safety","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-25T02:43:24Z","receivedAt":"2010-04-25T02:43:24Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jakub Narebski writes:\n> More seriously, it could be made default if it is not too annoying.\n\nBut the problem is that it _does_ sound annoying...\n\n-Miles\n\n-- \nPoliteness, n. The most acceptable hypocrisy.\n"},{"id":"140314","messageId":"87mxwsgser.fsf@catnip.gol.com","threadId":"23565","inReplyTo":"20100424214024.GA8044@progeny.tock","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-04-25T02:47:08Z","receivedAt":"2010-04-25T02:47:08Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n> But dense as I am, I still can’t imagine why\n>\n> echo '[alias] ci = commit -a' >>$HOME/.gitconfig\n>\n> wouldn’t be better in every way (especially if Jakub’s\n> commit.preserveindex is enabled).\n\nIf the latter is enabled, you can't use \"git add\" to add new files,\nyou'll have to remember to use \"add -N\" (or add some alias for that\ntoo).\n\n-Miles\n\n-- \n/\\ /\\\n(^.^)\n(\")\")\n*This is the cute kitty virus, please copy this into your sig so it can spread.\n"},{"id":"140315","messageId":"20100425033340.GA20921@progeny.tock","threadId":"23565","inReplyTo":"87mxwsgser.fsf@catnip.gol.com","subject":"Re: Please default to 'commit -a' when no changes were added","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-25T03:33:41Z","receivedAt":"2010-04-25T03:33:41Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Miles Bader wrote:\n> Jonathan Nieder writes:\n\n>> But dense as I am, I still can’t imagine why\n>>\n>> echo '[alias] ci = commit -a' >>$HOME/.gitconfig\n>>\n>> wouldn’t be better in every way (especially if Jakub’s\n>> commit.preserveindex is enabled).\n>\n> If the latter is enabled, you can't use \"git add\" to add new files,\n> you'll have to remember to use \"add -N\" (or add some alias for that\n> too).\n\nDidn’t he first [1] propose a variant in which using ‘git add -N’ was\nnot necessary? The rule was something like this: consider each entry.\nIf it\n\n - matches HEAD, or\n - matches the work tree, or\n - is an intent-to-add\n\nthen we say it is easily recoverable. If all index entries are\neasily recoverable, then let the commit -a go through.\n\nJonathan\n\n[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/698001/focus=145662\n"},{"id":"140318","messageId":"201004251001.08979.jnareb@gmail.com","threadId":"23565","inReplyTo":"7voch8mj04.fsf@alter.siamese.dyndns.org","subject":"Re: 'commit -a' safety","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-25T08:01:06Z","receivedAt":"2010-04-25T08:01:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Petr Baudis writes:\n>> On Sat, Apr 24, 2010 at 01:10:24PM +0200, Wincent Colaiuta wrote:\n>>> El 24/04/2010, a las 11:40, Jakub Narebski escribió:\n>>>>\n>>>> I'd like for 'git commit -a' to *fail* if there are staged changes for\n>>>> tracked files, excluding added, removed and renamed files.\n>>\n>> Thanks for this suggestion, this is exactly what I wanted to propose!\n> \n> I am somewhat torn.\n> \n> I have made mistake of running \"commit -a\" after I spent time sifting my\n> changes in the work tree. I can see that I would have been helped by it\n> if the safety were there.\n> \n> But at the same time, I also know that my development is often a cycle of\n> change then diff then add (to mark the part I am happy with), and when I\n> am happy with the output from diff, I conclude it with \"commit -a\" to\n> conclude the whole thing. I can see that I would be irritated to if that\n> final step failed.\n> \n> But I suspect the irritation would be relatively mild: \"ah, these days I\n> shouldn't use 'commig -a' to conclude these incremental change-review-add\n> cycle; instead, I should say 'add -u' then 'commit'\".\n\nOr, 'git commit -f -a' (which means 'git commit --force --all').\n\n-- \nJakub Narebski\nPoland\n"}]}