{"thread":{"id":"34800","subject":"Officially start moving to the term 'staging area'","startedAt":"2013-08-29T18:01:29Z","lastAt":"2013-09-09T00:39:22Z","messageCount":58,"participants":["Felipe Contreras","Matthieu Moy","Junio C Hamano","René Scharfe","Drew Northup","Piotr Krukowiecki","David Aguilar","William Swanson","Ping Yin","Hilco Wijbenga","Philip Oakley","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"226196","messageId":"20130829180129.GA4880@nysa","threadId":"34800","inReplyTo":null,"subject":"Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:01:29Z","receivedAt":"2013-08-29T18:01:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nIt has been discussed many times in the past that 'index' is not an\nappropriate description for what the high-level user does with it, and\nit has been agreed that 'staging area' is the best term.\n\nThe term 'staging area' is more intuitive for newcomers which are more\nfamiliar with English than with Git, and it seems to be a\nstraightforward mental notion for people with different mother tongues.\n\nIn fact it is so intuitive that it's used already in a lot online\ndocumentation, and the people that do teach Git professionally use this\nterm, because it's easier for many kinds of audiences to grasp.\n\nThe meaning of the words 'cache' and 'index' doesn't represent correctly\nthe mental model of the high-level user:\n\ncache: a 'cache' is a place for easier access; a squirrel caches nuts\nso it doesn't have to go looking for them in the future when it might\nbe much more difficult. Git porcelain is not using the staging area\nfor easier future access; it's not a cache.\n\nindex: an 'index' is a guide of pointers to something else; a book\nindex has a list of entries so the reader can locate information\neasily without having to go through the whole book. Git porcelain is\nnot using the staging area to find out entries quicker; it's not an\nindex.\n\nstage: a 'stage' is a special area designated for convenience in order\nfor some activity to take place; an orator would prepare a stage in\norder for her speak to be successful, otherwise many people might not\nbe able to hear, or see her. Git porcelain is using the staging area\nprecisely as a special area to be separated from the working directory\nfor convenience.\n\nThe term 'stage' is a good noun itself, but also 'staging area', it\nhas a good verb; 'to stage', and a nice past-participle; 'staged'.\n\nThe first step in moving Git towards this term, is first to add --stage\noptions for every command that uses --index or --cache. However, there's\na problem with the 'git apply' command, because it treats --index and\n--cache differently. Different solutions were proposed, including a\nspecial --stage-only option, however, I think the best solution is a\n--[no-]work option to specify if the working directory should be touched\nor not, so --index becomes --staged, and --cached becomes --staged\n--no-work.\n\nIn addition, the 'git stage' command can be extended so the staging area\ncan be brought closer to the user, like other important Git concepts,\nlike 'git branch, 'git tag', and 'git remote'. For example, the command\n'git stage edit' (which allows the user to edit directly the diff from\nHEAD to the staging area) can have a home, where previously there was no\nplace. It would become natural then to do 'git stage diff', and then\n'git stage edit' (to edit the previous diff).\n\nAfter adding the new --stage options and making sure no functionality is\nlost, they can become the recommended ones in the documentation,\neventually, the old ones get deprecated, and eventually obsoleted.\n\nAlso, the documentation would need to be updated to replace many\ninstances of 'the index', with 'the staging area' in porcelain commands.\n\nMoreover, the --stage and --work options also make sense for 'git\nreset', and after these options are added, the complicated table to\nexplain the different behaviors between --soft, --mixed, and --hard\nbecomes so simple it's not needed any more:\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n A B C D --no-stage A B D\n\t\t\t\t--stage A D D\n\t\t\t\t--work D D D\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n A B C C --no-stage A B C\n\t\t\t\t--stage A C C\n\t\t\t\t--work C C C\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n B B C D --no-stage B B D\n\t\t\t\t--stage B D D\n\t\t\t\t--work D D D\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n B B C C --no-stage B B C\n\t\t\t\t--stage B C C\n\t\t\t\t--work C C C\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n B C C D --no-stage B C D\n\t\t\t\t--stage B D D\n\t\t\t\t--work D D D\n\n working stage HEAD target working stage HEAD\n ----------------------------------------------------\n B C C C --no-stage B C C\n\t\t\t\t--stage B C C\n\t\t\t\t--work C C C\n\nIt might be possible to do 'git reset --no-stage --work', to reset the\nworking directory, but leave the staging area alone.\n\nFor more reference about the previous discussions:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/197111\nhttp://thread.gmane.org/gmane.comp.version-control.git/166675\nhttp://thread.gmane.org/gmane.comp.version-control.git/115666\n\n-- \nFelipe Contreras\n"},{"id":"226205","messageId":"1377799744-5201-1-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"[PATCH 0/2] stage: proper 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:09:02Z","receivedAt":"2013-08-29T18:09:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThe first patch adds subcommands for the 'git stage' command; add, reset, diff,\nrm, apply. By default the add command is used, so 'git stage $file' remains the\nsame.\n\nThe second patch adds the incredibly useful 'git stage edit' command.\n\nFelipe Contreras (2):\n Add proper 'stage' command\n stage: add edit command\n\n Documentation/git-stage.txt | 50 +++++++++++--\n Makefile | 2 +-\n builtin.h | 1 +\n builtin/stage.c | 126 +++++++++++++++++++++++++++++++++\n contrib/completion/git-completion.bash | 26 ++++++-\n git.c | 2 +-\n 6 files changed, 199 insertions(+), 8 deletions(-)\n create mode 100644 builtin/stage.c\n\n-- \n1.8.4-fc\n"},{"id":"226206","messageId":"1377799744-5201-2-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377799744-5201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/2] Add proper 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:09:03Z","receivedAt":"2013-08-29T18:09:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n Documentation/git-stage.txt | 45 +++++++++++++++++++++++++----\n Makefile | 2 +-\n builtin.h | 1 +\n builtin/stage.c | 52 ++++++++++++++++++++++++++++++++++\n contrib/completion/git-completion.bash | 24 +++++++++++++++-\n git.c | 2 +-\n 6 files changed, 118 insertions(+), 8 deletions(-)\n create mode 100644 builtin/stage.c\n\ndiff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt\nindex ba3fe0d..318bf45 100644\n--- a/Documentation/git-stage.txt\n+++ b/Documentation/git-stage.txt\n@@ -3,20 +3,55 @@ git-stage(1)\n \n NAME\n ----\n-git-stage - Add file contents to the staging area\n+git-stage - manage the staging area\n \n \n SYNOPSIS\n --------\n [verse]\n-'git stage' args...\n-\n+'git stage' [options] [--] [...]\n+'git stage add' [options] [--] [...]\n+'git stage reset' [-q|--patch] [--] [...]\n+'git stage diff' [options] [] [--] [...]\n+'git stage rm' [options] [--] [...]\n+'git stage apply' [options] [--] [...]\n \n DESCRIPTION\n -----------\n \n-This is a synonym for linkgit:git-add[1]. Please refer to the\n-documentation of that command.\n+\n+COMMANDS\n+--------\n+\n+With no arguments, it's a synonym for linkgit:git-add[1].\n+\n+'add'::\n+\n+Adds file contents to the staging area. See linkgit:git-add[1].\n+\n+'reset'::\n+\n+Resets the staging area. See linkgit:git-reset[1].\n+\n+'diff'::\n+\n+View the changes you staged for the next commit. See linkgit:git-diff[1] --staged.\n+\n+'rm'::\n+\n+Remove files from the staging area only. See linkgit:git-rm[1] --staged.\n+\n+'apply'::\n+\n+Apply a patch to the staging area. See linkgit:git-rm[1] --staged.\n+\n+SEE ALSO\n+--------\n+linkgit:git-add[1]\n+linkgit:git-reset[1]\n+linkgit:git-diff[1]\n+linkgit:git-rm[1]\n+linkgit:git-apply[1]\n \n GIT\n ---\ndiff --git a/Makefile b/Makefile\nindex 3588ca1..1f7ddf3 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -598,7 +598,6 @@ BUILT_INS += git-merge-subtree$X\n BUILT_INS += git-peek-remote$X\n BUILT_INS += git-repo-config$X\n BUILT_INS += git-show$X\n-BUILT_INS += git-stage$X\n BUILT_INS += git-status$X\n BUILT_INS += git-whatchanged$X\n \n@@ -982,6 +981,7 @@ BUILTIN_OBJS += builtin/send-pack.o\n BUILTIN_OBJS += builtin/shortlog.o\n BUILTIN_OBJS += builtin/show-branch.o\n BUILTIN_OBJS += builtin/show-ref.o\n+BUILTIN_OBJS += builtin/stage.o\n BUILTIN_OBJS += builtin/stripspace.o\n BUILTIN_OBJS += builtin/symbolic-ref.o\n BUILTIN_OBJS += builtin/tag.o\ndiff --git a/builtin.h b/builtin.h\nindex 8afa2de..baf3a0f 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -113,6 +113,7 @@ extern int cmd_send_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_shortlog(int argc, const char **argv, const char *prefix);\n extern int cmd_show(int argc, const char **argv, const char *prefix);\n extern int cmd_show_branch(int argc, const char **argv, const char *prefix);\n+extern int cmd_stage(int argc, const char **argv, const char *prefix);\n extern int cmd_status(int argc, const char **argv, const char *prefix);\n extern int cmd_stripspace(int argc, const char **argv, const char *prefix);\n extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);\ndiff --git a/builtin/stage.c b/builtin/stage.c\nnew file mode 100644\nindex 0000000..3023d17\n--- /dev/null\n+++ b/builtin/stage.c\n@@ -0,0 +1,52 @@\n+/*\n+ * 'git stage' builtin command\n+ *\n+ * Copyright (C) 2013 Felipe Contreras\n+ */\n+\n+#include \"builtin.h\"\n+#include \"parse-options.h\"\n+\n+static const char *const stage_usage[] = {\n+\tN_(\"git stage [options] [--] ...\"),\n+\tN_(\"git stage add [options] [--] ...\"),\n+\tN_(\"git stage reset [-q|--patch] [--] ...\"),\n+\tN_(\"git stage diff [options] [ [--] ...\"),\n+\tN_(\"git stage rm [options] [--] ...\"),\n+\tNULL\n+};\n+\n+int cmd_stage(int argc, const char **argv, const char *prefix)\n+{\n+\tstruct option options[] = { OPT_END() };\n+\n+\targc = parse_options(argc, argv, prefix, options, stage_usage,\n+\t\t\tPARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN | PARSE_OPT_KEEP_DASHDASH);\n+\n+\tif (argc > 1) {\n+\t\tif (!strcmp(argv[1], \"add\"))\n+\t\t\treturn cmd_add(argc - 1, argv + 1, prefix);\n+\t\tif (!strcmp(argv[1], \"reset\"))\n+\t\t\treturn cmd_reset(argc - 1, argv + 1, prefix);\n+\t\tif (!strcmp(argv[1], \"diff\")) {\n+\t\t\targv[0] = \"diff\";\n+\t\t\targv[1] = \"--staged\";\n+\n+\t\t\treturn cmd_diff(argc, argv, prefix);\n+\t\t}\n+\t\tif (!strcmp(argv[1], \"rm\")) {\n+\t\t\targv[0] = \"rm\";\n+\t\t\targv[1] = \"--cached\";\n+\n+\t\t\treturn cmd_rm(argc, argv, prefix);\n+\t\t}\n+\t\tif (!strcmp(argv[1], \"apply\")) {\n+\t\t\targv[0] = \"apply\";\n+\t\t\targv[1] = \"--cached\";\n+\n+\t\t\treturn cmd_apply(argc, argv, prefix);\n+\t\t}\n+\t}\n+\n+\treturn cmd_add(argc, argv, prefix);\n+}\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 5da920e..8cf26e2 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1691,7 +1691,29 @@ _git_send_email ()\n \n _git_stage ()\n {\n-\t_git_add\n+\t__git_has_doubledash && return\n+\n+\tlocal subcommands=\"add reset diff rm apply\"\n+\tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n+\tif [ -z \"$subcommand\" ]; then\n+\t\t__gitcomp \"$subcommands\"\n+\t\treturn\n+\tfi\n+\n+\tcase \"$subcommand\" in\n+\tadd)\n+\t\t_git_add;;\n+\treset)\n+\t\t_git_reset;;\n+\tdiff)\n+\t\t_git_diff;;\n+\trm)\n+\t\t_git_rm;;\n+\tapply)\n+\t\t_git_apply;;\n+\t*)\n+\t\t_git_add;\n+\tesac\n }\n \n __git_config_get_set_variables ()\ndiff --git a/git.c b/git.c\nindex 2025f77..0e639aa 100644\n--- a/git.c\n+++ b/git.c\n@@ -409,7 +409,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"show\", cmd_show, RUN_SETUP },\n \t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n \t\t{ \"show-ref\", cmd_show_ref, RUN_SETUP },\n-\t\t{ \"stage\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"stage\", cmd_stage, RUN_SETUP | NEED_WORK_TREE },\n \t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\n \t\t{ \"stripspace\", cmd_stripspace },\n \t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n-- \n1.8.4-fc\n"},{"id":"226207","messageId":"1377799744-5201-3-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377799744-5201-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/2] stage: add edit command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:09:04Z","receivedAt":"2013-08-29T18:09:04Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n Documentation/git-stage.txt | 5 +++\n builtin/stage.c | 74 ++++++++++++++++++++++++++++++++++\n contrib/completion/git-completion.bash | 4 +-\n 3 files changed, 82 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt\nindex 318bf45..3e52a66 100644\n--- a/Documentation/git-stage.txt\n+++ b/Documentation/git-stage.txt\n@@ -15,6 +15,7 @@ SYNOPSIS\n 'git stage diff' [options] [] [--] [...]\n 'git stage rm' [options] [--] [...]\n 'git stage apply' [options] [--] [...]\n+'git stage edit'\n \n DESCRIPTION\n -----------\n@@ -45,6 +46,10 @@ Remove files from the staging area only. See linkgit:git-rm[1] --staged.\n \n Apply a patch to the staging area. See linkgit:git-rm[1] --staged.\n \n+'edit'::\n+\n+Manually edit the staging area (as a diff).\n+\n SEE ALSO\n --------\n linkgit:git-add[1]\ndiff --git a/builtin/stage.c b/builtin/stage.c\nindex 3023d17..d3c58d5 100644\n--- a/builtin/stage.c\n+++ b/builtin/stage.c\n@@ -6,6 +6,9 @@\n \n #include \"builtin.h\"\n #include \"parse-options.h\"\n+#include \"diff.h\"\n+#include \"diffcore.h\"\n+#include \"revision.h\"\n \n static const char *const stage_usage[] = {\n \tN_(\"git stage [options] [--] ...\"),\n@@ -16,6 +19,74 @@ static const char *const stage_usage[] = {\n \tNULL\n };\n \n+static int do_reset(const char *prefix)\n+{\n+\tconst char *argv[] = { \"reset\", \"--quiet\", NULL };\n+\treturn cmd_reset(2, argv, prefix);\n+}\n+\n+static int do_apply(const char *file, const char *prefix)\n+{\n+\tconst char *argv[] = { \"apply\", \"--recount\", \"--cached\", file, NULL };\n+\treturn cmd_apply(4, argv, prefix);\n+}\n+\n+static int edit(int argc, const char **argv, const char *prefix)\n+{\n+\tchar *file = git_pathdup(\"STAGE_EDIT.patch\");\n+\tint out;\n+\tstruct rev_info rev;\n+\tint ret = 0;\n+\tstruct stat st;\n+\n+\tread_cache();\n+\n+\tinit_revisions(&rev, prefix);\n+\trev.diffopt.context = 7;\n+\n+\targc = setup_revisions(argc, argv, &rev, NULL);\n+\tadd_head_to_pending(&rev);\n+\tif (!rev.pending.nr) {\n+\t\tstruct tree *tree;\n+\t\ttree = lookup_tree(EMPTY_TREE_SHA1_BIN);\n+\t\tadd_pending_object(&rev, &tree->object, \"HEAD\");\n+\t}\n+\n+\trev.diffopt.output_format = DIFF_FORMAT_PATCH;\n+\trev.diffopt.use_color = 0;\n+\tDIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES);\n+\n+\tout = open(file, O_CREAT | O_WRONLY, 0666);\n+\tif (out < 0)\n+\t\tdie(_(\"Could not open '%s' for writing.\"), file);\n+\trev.diffopt.file = xfdopen(out, \"w\");\n+\trev.diffopt.close_file = 1;\n+\n+\tif (run_diff_index(&rev, 1))\n+\t\tdie(_(\"Could not write patch\"));\n+\tif (launch_editor(file, NULL, NULL))\n+\t\texit(1);\n+\n+\tif (stat(file, &st))\n+\t\tdie_errno(_(\"Could not stat '%s'\"), file);\n+\n+\tret = do_reset(prefix);\n+\tif (ret)\n+\t\tgoto leave;\n+\n+\tif (!st.st_size)\n+\t\tgoto leave;\n+\n+\tret = do_apply(file, prefix);\n+\tif (ret)\n+\t\tgoto leave;\n+\n+leave:\n+\tunlink(file);\n+\tfree(file);\n+\treturn ret;\n+}\n+\n int cmd_stage(int argc, const char **argv, const char *prefix)\n {\n \tstruct option options[] = { OPT_END() };\n@@ -46,6 +117,9 @@ int cmd_stage(int argc, const char **argv, const char *prefix)\n \n \t\t\treturn cmd_apply(argc, argv, prefix);\n \t\t}\n+\t\tif (!strcmp(argv[1], \"edit\")) {\n+\t\t\treturn edit(argc - 1, argv + 1, prefix);\n+\t\t}\n \t}\n \n \treturn cmd_add(argc, argv, prefix);\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 8cf26e2..2b81e78 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1693,7 +1693,7 @@ _git_stage ()\n {\n \t__git_has_doubledash && return\n \n-\tlocal subcommands=\"add reset diff rm apply\"\n+\tlocal subcommands=\"add reset diff rm apply edit\"\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n \tif [ -z \"$subcommand\" ]; then\n \t\t__gitcomp \"$subcommands\"\n@@ -1711,6 +1711,8 @@ _git_stage ()\n \t\t_git_rm;;\n \tapply)\n \t\t_git_apply;;\n+\tedit)\n+\t\t;;\n \t*)\n \t\t_git_add;\n \tesac\n-- \n1.8.4-fc\n"},{"id":"226210","messageId":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"[PATCH 0/9] Add --stage and --work options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:31Z","receivedAt":"2013-08-29T18:14:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nSome commands (git diff) already have the --staged alias, this patch series\ndocument them, and do the same for the rest.\n\nAlso, add a --work (and --no-work) option, so that in addition to --stage, we\ncan replace --cached in 'git apply'.\n\nThe old options remain unchanged.\n\nFelipe Contreras (9):\n diff: document --staged\n grep: add --staged option\n rm: add --staged option\n stash: add --stage option to save\n stash: add --stage to pop and apply\n submodule: add --staged options\n apply: add --stage option\n apply: add --work, --no-work options\n completion: update --staged options\n\n Documentation/git-apply.txt | 11 +++++++++--\n Documentation/git-diff.txt | 4 ++--\n Documentation/git-grep.txt | 5 ++++-\n Documentation/git-rm.txt | 5 ++++-\n Documentation/git-stash.txt | 14 +++++++-------\n Documentation/git-submodule.txt | 8 ++++++--\n builtin/apply.c | 7 +++++++\n builtin/grep.c | 2 ++\n builtin/rm.c | 1 +\n contrib/completion/git-completion.bash | 10 +++++-----\n git-stash.sh | 12 +++++++++---\n git-submodule.sh | 10 +++++-----\n 12 files changed, 61 insertions(+), 28 deletions(-)\n\n-- \n1.8.4-fc\n"},{"id":"226211","messageId":"1377800080-5309-2-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/9] diff: document --staged","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:32Z","receivedAt":"2013-08-29T18:14:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym for --cached.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-diff.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt\nindex 78d6d50..646e5cd 100644\n--- a/Documentation/git-diff.txt\n+++ b/Documentation/git-diff.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n --------\n [verse]\n 'git diff' [options] [] [--] [...]\n-'git diff' [options] --cached [] [--] [...]\n+'git diff' [options] [--cached|--staged] [] [--] [...]\n 'git diff' [options] [--] [...]\n 'git diff' [options] \n 'git diff' [options] [--no-index] [--] \n@@ -33,7 +33,7 @@ If exactly two paths are given and at least one points outside\n the current repository, 'git diff' will compare the two files /\n directories. This behavior can be forced by --no-index.\n \n-'git diff' [--options] --cached [] [--] [...]::\n+'git diff' [--options] [--cached|--staged] [] [--] [...]::\n \n \tThis form is to view the changes you staged for the next\n \tcommit relative to the named . Typically you\n-- \n1.8.4-fc\n"},{"id":"226212","messageId":"1377800080-5309-3-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/9] grep: add --staged option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:33Z","receivedAt":"2013-08-29T18:14:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym for --cached.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-grep.txt | 5 ++++-\n builtin/grep.c | 2 ++\n 2 files changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt\nindex 8497aa4..9f7899c 100644\n--- a/Documentation/git-grep.txt\n+++ b/Documentation/git-grep.txt\n@@ -25,7 +25,7 @@ SYNOPSIS\n \t [-W | --function-context]\n \t [-f ] [-e] \n \t [--and|--or|--not|(|)|-e ...]\n-\t [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | ...]\n+\t [ [--[no-]exclude-standard] [--cached | --staged | --no-index | --untracked] | ...]\n \t [--] [...]\n \n DESCRIPTION\n@@ -60,6 +60,9 @@ OPTIONS\n \tInstead of searching tracked files in the working tree, search\n \tblobs registered in the index file.\n \n+--staged::\n+\tSynonym for `--cached`.\n+\n --no-index::\n \tSearch files in the current directory that is not managed by Git.\n \ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex d3b3b1d..b953911 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -640,6 +640,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \tstruct option options[] = {\n \t\tOPT_BOOLEAN(0, \"cached\", &cached,\n \t\t\tN_(\"search in index instead of in the work tree\")),\n+\t\tOPT_BOOLEAN(0, \"staged\", &cached,\n+\t\t\tN_(\"search in index instead of in the work tree\")),\n \t\tOPT_NEGBIT(0, \"no-index\", &use_index,\n \t\t\t N_(\"find in contents not managed by git\"), 1),\n \t\tOPT_BOOLEAN(0, \"untracked\", &untracked,\n-- \n1.8.4-fc\n"},{"id":"226213","messageId":"1377800080-5309-4-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/9] rm: add --staged option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:34Z","receivedAt":"2013-08-29T18:14:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym for --cached.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-rm.txt | 5 ++++-\n builtin/rm.c | 1 +\n 2 files changed, 5 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\nindex 1d876c2..156b40d 100644\n--- a/Documentation/git-rm.txt\n+++ b/Documentation/git-rm.txt\n@@ -8,7 +8,7 @@ git-rm - Remove files from the working tree and from the index\n SYNOPSIS\n --------\n [verse]\n-'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] ...\n+'git rm' [-f | --force] [-n] [-r] [--cached | --staged] [--ignore-unmatch] [--quiet] [--] ...\n \n DESCRIPTION\n -----------\n@@ -60,6 +60,9 @@ OPTIONS\n \tWorking tree files, whether modified or not, will be\n \tleft alone.\n \n+--staged::\n+\tSynonym for --cached.\n+\n --ignore-unmatch::\n \tExit with a zero status even if no files matched.\n \ndiff --git a/builtin/rm.c b/builtin/rm.c\nindex 0df0b4d..919911f 100644\n--- a/builtin/rm.c\n+++ b/builtin/rm.c\n@@ -268,6 +268,7 @@ static struct option builtin_rm_options[] = {\n \tOPT__DRY_RUN(&show_only, N_(\"dry run\")),\n \tOPT__QUIET(&quiet, N_(\"do not list removed files\")),\n \tOPT_BOOLEAN( 0 , \"cached\", &index_only, N_(\"only remove from the index\")),\n+\tOPT_BOOLEAN( 0 , \"staged\", &index_only, N_(\"only remove from the index\")),\n \tOPT__FORCE(&force, N_(\"override the up-to-date check\")),\n \tOPT_BOOLEAN('r', NULL, &recursive, N_(\"allow recursive removal\")),\n \tOPT_BOOLEAN( 0 , \"ignore-unmatch\", &ignore_unmatch,\n-- \n1.8.4-fc\n"},{"id":"226214","messageId":"1377800080-5309-5-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 4/9] stash: add --stage option to save","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:35Z","receivedAt":"2013-08-29T18:14:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"--no-stage is synonym for --keep-index.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-stash.txt | 6 +++---\n git-stash.sh | 8 +++++++-\n 2 files changed, 10 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt\nindex db7e803..75b4cc6 100644\n--- a/Documentation/git-stash.txt\n+++ b/Documentation/git-stash.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n 'git stash' drop [-q|--quiet] []\n 'git stash' ( pop | apply ) [--index] [-q|--quiet] []\n 'git stash' branch []\n-'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]\n+'git stash' [save [-p|--patch] [-k|--[no-]keep-index|--[no-]stage] [-q|--quiet]\n \t [-u|--include-untracked] [-a|--all] []]\n 'git stash' clear\n 'git stash' create []\n@@ -44,7 +44,7 @@ is also possible).\n OPTIONS\n -------\n \n-save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] []::\n+save [-p|--patch] [--[no-]keep-index|--[no-]stage] [-u|--include-untracked] [-a|--all] [-q|--quiet] []::\n \n \tSave your local modifications to a new 'stash', and run `git reset\n \t--hard` to revert them. The part is optional and gives\n@@ -54,7 +54,7 @@ save [-p|--patch] [--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--\n \tsubcommand from making an unwanted stash.\n +\n If the `--keep-index` option is used, all changes already added to the\n-index are left intact.\n+index are left intact. Same with `--no-stage`, which is a snynonym.\n +\n If the `--include-untracked` option is used, all untracked files are also\n stashed and then cleaned up with `git clean`, leaving the working directory\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 1e541a2..47220d0 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -7,7 +7,7 @@ USAGE=\"list []\n or: $dashless drop [-q|--quiet] []\n or: $dashless ( pop | apply ) [--index] [-q|--quiet] []\n or: $dashless branch []\n- or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]\n+ or: $dashless [save [--patch] [-k|--[no-]keep-index|--[no-]stage] [-q|--quiet]\n \t\t [-u|--include-untracked] [-a|--all] []]\n or: $dashless clear\"\n \n@@ -204,6 +204,12 @@ save_stash () {\n \t\t--no-keep-index)\n \t\t\tkeep_index=n\n \t\t\t;;\n+\t\t--stage)\n+\t\t\tkeep_index=n\n+\t\t\t;;\n+\t\t--no-stage)\n+\t\t\tkeep_index=t\n+\t\t\t;;\n \t\t-p|--patch)\n \t\t\tpatch_mode=t\n \t\t\t# only default to keep if we don't already have an override\n-- \n1.8.4-fc\n"},{"id":"226215","messageId":"1377800080-5309-6-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 5/9] stash: add --stage to pop and apply","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:36Z","receivedAt":"2013-08-29T18:14:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym of --index.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-stash.txt | 8 ++++----\n git-stash.sh | 4 ++--\n 2 files changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt\nindex 75b4cc6..b4066fd 100644\n--- a/Documentation/git-stash.txt\n+++ b/Documentation/git-stash.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n 'git stash' list []\n 'git stash' show []\n 'git stash' drop [-q|--quiet] []\n-'git stash' ( pop | apply ) [--index] [-q|--quiet] []\n+'git stash' ( pop | apply ) [--index|--stage] [-q|--quiet] []\n 'git stash' branch []\n 'git stash' [save [-p|--patch] [-k|--[no-]keep-index|--[no-]stage] [-q|--quiet]\n \t [-u|--include-untracked] [-a|--all] []]\n@@ -96,7 +96,7 @@ show []::\n \tit will accept any format known to 'git diff' (e.g., `git stash show\n \t-p stash@{1}` to view the second most recent stash in patch form).\n \n-pop [--index] [-q|--quiet] []::\n+pop [--index|--stage] [-q|--quiet] []::\n \n \tRemove a single stashed state from the stash list and apply it\n \ton top of the current working tree state, i.e., do the inverse\n@@ -110,12 +110,12 @@ and call `git stash drop` manually afterwards.\n If the `--index` option is used, then tries to reinstate not only the working\n tree's changes, but also the index's ones. However, this can fail, when you\n have conflicts (which are stored in the index, where you therefore can no\n-longer apply the changes as they were originally).\n+longer apply the changes as they were originally). `--stage` is a synonym.\n +\n When no `` is given, `stash@{0}` is assumed, otherwise `` must\n be a reference of the form `stash@{}`.\n \n-apply [--index] [-q|--quiet] []::\n+apply [--index|--stage] [-q|--quiet] []::\n \n \tLike `pop`, but do not remove the state from the stash list. Unlike `pop`,\n \t`` may be any commit that looks like a commit created by\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 47220d0..e2eb8dc 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -5,7 +5,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"list []\n or: $dashless show []\n or: $dashless drop [-q|--quiet] []\n- or: $dashless ( pop | apply ) [--index] [-q|--quiet] []\n+ or: $dashless ( pop | apply ) [--index|--stage] [-q|--quiet] []\n or: $dashless branch []\n or: $dashless [save [--patch] [-k|--[no-]keep-index|--[no-]stage] [-q|--quiet]\n \t\t [-u|--include-untracked] [-a|--all] []]\n@@ -373,7 +373,7 @@ parse_flags_and_rev()\n \t\t\t-q|--quiet)\n \t\t\t\tGIT_QUIET=-t\n \t\t\t;;\n-\t\t\t--index)\n+\t\t\t--index|--stage)\n \t\t\t\tINDEX_OPTION=--index\n \t\t\t;;\n \t\t\t-*)\n-- \n1.8.4-fc\n"},{"id":"226216","messageId":"1377800080-5309-7-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 6/9] submodule: add --staged options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:37Z","receivedAt":"2013-08-29T18:14:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym for --cached.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-submodule.txt | 8 ++++++--\n git-submodule.sh | 10 +++++-----\n 2 files changed, 11 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex bfef8a0..904e007 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -11,13 +11,13 @@ SYNOPSIS\n [verse]\n 'git submodule' [--quiet] add [-b ] [-f|--force] [--name ]\n \t [--reference ] [--depth ] [--] []\n-'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n+'git submodule' [--quiet] status [--cached|--staged] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n 'git submodule' [--quiet] deinit [-f|--force] [--] ...\n 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]\n \t [-f|--force] [--rebase] [--reference ] [--depth ]\n \t [--merge] [--recursive] [--] [...]\n-'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n+'git submodule' [--quiet] summary [--cached|--staged|--files] [(-n|--summary-limit) ]\n \t [commit] [--] [...]\n 'git submodule' [--quiet] foreach [--recursive] \n 'git submodule' [--quiet] sync [--] [...]\n@@ -248,6 +248,10 @@ OPTIONS\n \tcommands typically use the commit found in the submodule HEAD, but\n \twith this option, the commit stored in the index is used instead.\n \n+\n+--staged::\n+\tSynonym for `--cached`.\n+\n --files::\n \tThis option is only valid for the summary command. This command\n \tcompares the commit in the index with that in the submodule HEAD\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 2979197..823b783 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -6,11 +6,11 @@\n \n dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b ] [-f|--force] [--name ] [--reference ] [--] []\n- or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n+ or: $dashless [--quiet] status [--cached|--staged] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n or: $dashless [--quiet] deinit [-f|--force] [--] ...\n or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n- or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n+ or: $dashless [--quiet] summary [--cached|--staged|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n or: $dashless [--quiet] sync [--recursive] [--] [...]\"\n OPTIONS_SPEC=\n@@ -972,7 +972,7 @@ cmd_summary() {\n \twhile test $# -ne 0\n \tdo\n \t\tcase \"$1\" in\n-\t\t--cached)\n+\t\t--cached|--staged)\n \t\t\tcached=\"$1\"\n \t\t\t;;\n \t\t--files)\n@@ -1181,7 +1181,7 @@ cmd_status()\n \t\t-q|--quiet)\n \t\t\tGIT_QUIET=1\n \t\t\t;;\n-\t\t--cached)\n+\t\t--cached|--staged)\n \t\t\tcached=1\n \t\t\t;;\n \t\t--recursive)\n@@ -1348,7 +1348,7 @@ do\n \t\tesac\n \t\tbranch=\"$2\"; shift\n \t\t;;\n-\t--cached)\n+\t--cached|--staged)\n \t\tcached=\"$1\"\n \t\t;;\n \t--)\n-- \n1.8.4-fc\n"},{"id":"226217","messageId":"1377800080-5309-8-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 7/9] apply: add --stage option","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:38Z","receivedAt":"2013-08-29T18:14:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Synonym for --index.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-apply.txt | 5 ++++-\n builtin/apply.c | 2 ++\n 2 files changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt\nindex f605327..ce44327 100644\n--- a/Documentation/git-apply.txt\n+++ b/Documentation/git-apply.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git apply' [--stat] [--numstat] [--summary] [--check] [--index] [--3way]\n \t [--apply] [--no-add] [--build-fake-ancestor=] [-R | --reverse]\n \t [--allow-binary-replacement | --binary] [--reject] [-z]\n-\t [-p] [-C] [--inaccurate-eof] [--recount] [--cached]\n+\t [-p] [-C] [--inaccurate-eof] [--recount] [--cached|--staged]\n \t [--ignore-space-change | --ignore-whitespace ]\n \t [--whitespace=(nowarn|warn|fix|error|error-all)]\n \t [--exclude=] [--include=] [--directory=]\n@@ -67,6 +67,9 @@ OPTIONS\n \tup-to-date, it is flagged as an error. This flag also\n \tcauses the index file to be updated.\n \n+--staged::\n+\tSynonym for --index.\n+\n --cached::\n \tApply a patch without touching the working tree. Instead take the\n \tcached data, apply the patch, and store the result in the index\ndiff --git a/builtin/apply.c b/builtin/apply.c\nindex 50912c9..42b5a4b 100644\n--- a/builtin/apply.c\n+++ b/builtin/apply.c\n@@ -4377,6 +4377,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)\n \t\t\tN_(\"instead of applying the patch, see if the patch is applicable\")),\n \t\tOPT_BOOLEAN(0, \"index\", &check_index,\n \t\t\tN_(\"make sure the patch is applicable to the current index\")),\n+\t\tOPT_BOOLEAN(0, \"stage\", &check_index,\n+\t\t\tN_(\"make sure the patch is applicable to the current index\")),\n \t\tOPT_BOOLEAN(0, \"cached\", &cached,\n \t\t\tN_(\"apply a patch without touching the working tree\")),\n \t\tOPT_BOOLEAN(0, \"apply\", &force_apply,\n-- \n1.8.4-fc\n"},{"id":"226218","messageId":"1377800080-5309-9-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 8/9] apply: add --work, --no-work options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:39Z","receivedAt":"2013-08-29T18:14:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"'git apply', 'git apply --index', 'git apply --cached' do different\nthings, but what they do is not precisely clear, specially since no\nother commands has similar distinctions.\n\nWith --no-work (--work being the default), it's clear what the option\nwould do; modify, or not, the working directory.\n\nSo, --work (the default), doesn't cause any changes, and --no-work\nenables the current --cache if used with --index.\n\nEventually --work might replace --cache, if these options are\nstandarized in the whole git toolset.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-apply.txt | 6 +++++-\n builtin/apply.c | 5 +++++\n 2 files changed, 10 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt\nindex ce44327..6167061 100644\n--- a/Documentation/git-apply.txt\n+++ b/Documentation/git-apply.txt\n@@ -16,7 +16,7 @@ SYNOPSIS\n \t [--ignore-space-change | --ignore-whitespace ]\n \t [--whitespace=(nowarn|warn|fix|error|error-all)]\n \t [--exclude=] [--include=] [--directory=]\n-\t [--verbose] [...]\n+\t [--verbose] [--no-work] [...]\n \n DESCRIPTION\n -----------\n@@ -75,6 +75,10 @@ OPTIONS\n \tcached data, apply the patch, and store the result in the index\n \twithout using the working tree. This implies `--index`.\n \n+--[no-]work::\n+\tApply a patch with or without touching the working tree, essentially\n+\t`--no-work` plus `--index` are the equivalent of `--cached`.\n+\n -3::\n --3way::\n \tWhen the patch does not apply cleanly, fall back on 3-way merge if\ndiff --git a/builtin/apply.c b/builtin/apply.c\nindex 42b5a4b..a3dd89d 100644\n--- a/builtin/apply.c\n+++ b/builtin/apply.c\n@@ -4350,6 +4350,7 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)\n \tint errs = 0;\n \tint is_not_gitdir = !startup_info->have_repository;\n \tint force_apply = 0;\n+\tint work = 1;\n \n \tconst char *whitespace_option = NULL;\n \n@@ -4381,6 +4382,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)\n \t\t\tN_(\"make sure the patch is applicable to the current index\")),\n \t\tOPT_BOOLEAN(0, \"cached\", &cached,\n \t\t\tN_(\"apply a patch without touching the working tree\")),\n+\t\tOPT_BOOLEAN(0, \"work\", &work,\n+\t\t\tN_(\"modify the working tree\")),\n \t\tOPT_BOOLEAN(0, \"apply\", &force_apply,\n \t\t\tN_(\"also apply the patch (use with --stat/--summary/--check)\")),\n \t\tOPT_BOOL('3', \"3way\", &threeway,\n@@ -4433,6 +4436,8 @@ int cmd_apply(int argc, const char **argv, const char *prefix_)\n \targc = parse_options(argc, argv, prefix, builtin_apply_options,\n \t\t\tapply_usage, 0);\n \n+\tif (check_index && !work)\n+\t\tcached = 1;\n \tif (apply_with_reject && threeway)\n \t\tdie(\"--reject and --3way cannot be used together.\");\n \tif (cached && threeway)\n-- \n1.8.4-fc\n"},{"id":"226219","messageId":"1377800080-5309-10-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800080-5309-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 9/9] completion: update --staged options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:14:40Z","receivedAt":"2013-08-29T18:14:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n contrib/completion/git-completion.bash | 10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 5da920e..4adc4ed 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -881,7 +881,7 @@ _git_apply ()\n \t\t__gitcomp \"\n \t\t\t--stat --numstat --summary --check --index\n \t\t\t--cached --index-info --reverse --reject --unidiff-zero\n-\t\t\t--apply --no-add --exclude=\n+\t\t\t--apply --no-add --exclude= --staged\n \t\t\t--ignore-whitespace --ignore-space-change\n \t\t\t--whitespace= --inaccurate-eof --verbose\n \t\t\t\"\n@@ -1294,7 +1294,7 @@ _git_grep ()\n \tcase \"$cur\" in\n \t--*)\n \t\t__gitcomp \"\n-\t\t\t--cached\n+\t\t\t--cached --staged\n \t\t\t--text --ignore-case --word-regexp --invert-match\n \t\t\t--full-name --line-number\n \t\t\t--extended-regexp --basic-regexp --fixed-strings\n@@ -2229,7 +2229,7 @@ _git_rm ()\n {\n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--cached --dry-run --ignore-unmatch --quiet\"\n+\t\t__gitcomp \"--cached --staged --dry-run --ignore-unmatch --quiet\"\n \t\treturn\n \t\t;;\n \tesac\n@@ -2296,7 +2296,7 @@ _git_show_branch ()\n \n _git_stash ()\n {\n-\tlocal save_opts='--keep-index --no-keep-index --quiet --patch'\n+\tlocal save_opts='--keep-index --no-keep-index --stage --no-stage --quiet --patch'\n \tlocal subcommands='save list show apply clear drop pop create branch'\n \tlocal subcommand=\"$(__git_find_on_cmdline \"$subcommands\")\"\n \tif [ -z \"$subcommand\" ]; then\n@@ -2316,7 +2316,7 @@ _git_stash ()\n \t\t\t__gitcomp \"$save_opts\"\n \t\t\t;;\n \t\tapply,--*|pop,--*)\n-\t\t\t__gitcomp \"--index --quiet\"\n+\t\t\t__gitcomp \"--index --stage --quiet\"\n \t\t\t;;\n \t\tshow,--*|drop,--*|branch,--*)\n \t\t\t;;\n-- \n1.8.4-fc\n"},{"id":"226221","messageId":"1377800397-5434-1-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"[PATCH 0/3] reset: refactor into --stage and --work","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:19:54Z","receivedAt":"2013-08-29T18:19:54Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThis patch series is not really necessary for the whole --stage series, but it\nmakes sense while we are at it.\n\nFelipe Contreras (3):\n reset: add --stage and --work options\n reset: allow --keep with --stage\n completion: update 'git reset' new stage options\n\n Documentation/git-reset.txt | 8 ++++++++\n builtin/reset.c | 27 +++++++++++++++++++++++++++\n contrib/completion/git-completion.bash | 3 ++-\n 3 files changed, 37 insertions(+), 1 deletion(-)\n\n-- \n1.8.4-fc\n"},{"id":"226222","messageId":"1377800397-5434-2-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800397-5434-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 1/3] reset: add --stage and --work options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:19:55Z","receivedAt":"2013-08-29T18:19:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n Documentation/git-reset.txt | 8 ++++++++\n builtin/reset.c | 20 ++++++++++++++++++++\n 2 files changed, 28 insertions(+)\n\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex f445cb3..5cd75a8 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -11,6 +11,7 @@ SYNOPSIS\n 'git reset' [-q] [] [--] ...\n 'git reset' (--patch | -p) [] [--] [...]\n 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] []\n+'git reset' [--stage | --work] [-q] []\n \n DESCRIPTION\n -----------\n@@ -81,6 +82,13 @@ but carries forward unmerged index entries.\n \tdifferent between and HEAD.\n \tIf a file that is different between and HEAD has local changes,\n \treset is aborted.\n+\n+--stage::\n+\tReset the index, basically `--mixed`. `--no-stage` is the equivalent of\n+\t`--soft`.\n+\n+--work::\n+\tResets the working tree, basically `--hard`.\n --\n \n If you want to undo a commit other than the latest on a branch,\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex afa6e02..fbc1abc 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -23,6 +23,7 @@\n \n static const char * const git_reset_usage[] = {\n \tN_(\"git reset [--mixed | --soft | --hard | --merge | --keep] [-q] []\"),\n+\tN_(\"git reset [--stage | --work] [-q] []\"),\n \tN_(\"git reset [-q] [--] ...\"),\n \tN_(\"git reset --patch [] [--] [...]\"),\n \tNULL\n@@ -243,6 +244,7 @@ static int update_refs(const char *rev, const unsigned char *sha1)\n int cmd_reset(int argc, const char **argv, const char *prefix)\n {\n \tint reset_type = NONE, update_ref_status = 0, quiet = 0;\n+\tint stage = -1, working_tree = -1;\n \tint patch_mode = 0, unborn;\n \tconst char *rev;\n \tunsigned char sha1[20];\n@@ -258,6 +260,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\t\t\tN_(\"reset HEAD, index and working tree\"), MERGE),\n \t\tOPT_SET_INT(0, \"keep\", &reset_type,\n \t\t\t\tN_(\"reset HEAD but keep local changes\"), KEEP),\n+\t\tOPT_BOOL(0, \"stage\", &stage, N_(\"reset index\")),\n+\t\tOPT_BOOL(0, \"work\", &working_tree, N_(\"reset working tree\")),\n \t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, N_(\"select hunks interactively\")),\n \t\tOPT_END()\n \t};\n@@ -290,6 +294,22 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\thashcpy(sha1, tree->object.sha1);\n \t}\n \n+\tif (stage >= 0 || working_tree >= 0) {\n+\t\tif (reset_type != NONE)\n+\t\t\tdie(_(\"--{stage,work} are incompatible with --{hard,mixed,soft,merge}\"));\n+\n+\t\tif (working_tree == 1) {\n+\t\t\tif (stage == 0)\n+\t\t\t\tdie(_(\"--no-stage doesn't make sense with --work\"));\n+\t\t\treset_type = HARD;\n+\t\t} else {\n+\t\t\tif (stage == 1)\n+\t\t\t\treset_type = NONE;\n+\t\t\telse\n+\t\t\t\treset_type = SOFT;\n+\t\t}\n+\t}\n+\n \tif (patch_mode) {\n \t\tif (reset_type != NONE)\n \t\t\tdie(_(\"--patch is incompatible with --{hard,mixed,soft}\"));\n-- \n1.8.4-fc\n"},{"id":"226223","messageId":"1377800397-5434-3-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800397-5434-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 2/3] reset: allow --keep with --stage","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:19:56Z","receivedAt":"2013-08-29T18:19:56Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n Documentation/git-reset.txt | 2 +-\n builtin/reset.c | 13 ++++++++++---\n 2 files changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt\nindex 5cd75a8..a1419c9 100644\n--- a/Documentation/git-reset.txt\n+++ b/Documentation/git-reset.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n 'git reset' [-q] [] [--] ...\n 'git reset' (--patch | -p) [] [--] [...]\n 'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] []\n-'git reset' [--stage | --work] [-q] []\n+'git reset' [--stage | --work | --keep] [-q] []\n \n DESCRIPTION\n -----------\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex fbc1abc..dde03a7 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -23,7 +23,7 @@\n \n static const char * const git_reset_usage[] = {\n \tN_(\"git reset [--mixed | --soft | --hard | --merge | --keep] [-q] []\"),\n-\tN_(\"git reset [--stage | --work] [-q] []\"),\n+\tN_(\"git reset [--stage | --work | --keep] [-q] []\"),\n \tN_(\"git reset [-q] [--] ...\"),\n \tN_(\"git reset --patch [] [--] [...]\"),\n \tNULL\n@@ -295,8 +295,15 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t}\n \n \tif (stage >= 0 || working_tree >= 0) {\n-\t\tif (reset_type != NONE)\n+\t\tint keep = 0;\n+\n+\t\tif (reset_type == KEEP) {\n+\t\t\tif (working_tree == 1)\n+\t\t\t\tdie(_(\"--keep is incompatible with --work\"));\n+\t\t\tkeep = 1;\n+\t\t} else if (reset_type != NONE) {\n \t\t\tdie(_(\"--{stage,work} are incompatible with --{hard,mixed,soft,merge}\"));\n+\t\t}\n \n \t\tif (working_tree == 1) {\n \t\t\tif (stage == 0)\n@@ -304,7 +311,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\t\treset_type = HARD;\n \t\t} else {\n \t\t\tif (stage == 1)\n-\t\t\t\treset_type = NONE;\n+\t\t\t\treset_type = keep ? KEEP : NONE;\n \t\t\telse\n \t\t\t\treset_type = SOFT;\n \t\t}\n-- \n1.8.4-fc\n"},{"id":"226224","messageId":"1377800397-5434-4-git-send-email-felipe.contreras@gmail.com","threadId":"34800","inReplyTo":"1377800397-5434-1-git-send-email-felipe.contreras@gmail.com","subject":"[PATCH 3/3] completion: update 'git reset' new stage options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:19:57Z","receivedAt":"2013-08-29T18:19:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n contrib/completion/git-completion.bash | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 4adc4ed..24b2c22 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2207,7 +2207,8 @@ _git_reset ()\n \n \tcase \"$cur\" in\n \t--*)\n-\t\t__gitcomp \"--merge --mixed --hard --soft --patch\"\n+\t\t__gitcomp \"--merge --mixed --hard --soft --patch --keep --merge\n+\t\t\t--stage --no-stage --work --no-work\"\n \t\treturn\n \t\t;;\n \tesac\n-- \n1.8.4-fc\n"},{"id":"226228","messageId":"vpqk3j4s5ut.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"1377799744-5201-3-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 2/2] stage: add edit command","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T18:35:06Z","receivedAt":"2013-08-29T18:35:06Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> +'edit'::\n> +\n> +Manually edit the staging area (as a diff).\n> +\n\nThat sounds interesting. It reminds me \"git add --edit\", but they are\ndifferent ('stage edit' edits the patch with HEAD, 'add --edit' edits\nthe patch with the worktree).\n\nCan we find a consistent user-interface where \"git add --edit\" and \"git\nstage edit\" have a closer syntax? Maybe \"git stage edit --work\" as a\nsynonym for \"git add --edit\"?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226229","messageId":"xmqqeh9c4a2t.fsf@gitster.dls.corp.google.com","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-29T18:37:46Z","receivedAt":"2013-08-29T18:37:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> It has been discussed many times in the past that 'index' is not an\n> appropriate description for what the high-level user does with it, and\n> it has been agreed that 'staging area' is the best term.\n\n\"add\" is the verb, not \"index\" (which is a noun that refers\nto the thing that keeps track of what will be written as a tree to\nbe committed next).\n\nAnd it will stay that way.\n\nIIRC, when this was discussed, many non-native speakers had trouble\nwith the verb \"to stage\", not just from i18n/l10n point of view.\n"},{"id":"226230","messageId":"vpq8uzks5ou.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"1377799744-5201-2-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 1/2] Add proper 'stage' command","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T18:38:41Z","receivedAt":"2013-08-29T18:38:41Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> +COMMANDS\n> +--------\n> +\n> +With no arguments, it's a synonym for linkgit:git-add[1].\n\nThis would not be very useful since \"git add\" errors out when called\nwithout arguments ;-).\n\nThe accurate description of your code would be closer to \"When the first\nargument is not a subcommand, it's a synonym for linkgit:git-add[1].\".\nI'm not sure I like it, as it creates ambiguities (e.g. need to spell\n\"git stage -- diff\" to add a file called \"diff\". Not a strong objection\nthough, as we already have refs Vs filename ambiguities in many places.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226231","messageId":"vpq4na8s5n6.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"1377800080-5309-5-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH 4/9] stash: add --stage option to save","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T18:39:41Z","receivedAt":"2013-08-29T18:39:41Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> +index are left intact. Same with `--no-stage`, which is a snynonym.\n\ns/snynonym/synonym/\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226235","messageId":"521f960477ebf_16921225e74769a3@nysa.mail","threadId":"34800","inReplyTo":"vpqk3j4s5ut.fsf@anie.imag.fr","subject":"Re: [PATCH 2/2] stage: add edit command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:42:12Z","receivedAt":"2013-08-29T18:42:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > +'edit'::\n> > +\n> > +Manually edit the staging area (as a diff).\n> > +\n> \n> That sounds interesting. It reminds me \"git add --edit\", but they are\n> different ('stage edit' edits the patch with HEAD, 'add --edit' edits\n> the patch with the worktree).\n\nThat's not the only difference; 'add --edit' is incremental.\n\n> Can we find a consistent user-interface where \"git add --edit\" and \"git\n> stage edit\" have a closer syntax? Maybe \"git stage edit --work\" as a\n> synonym for \"git add --edit\"?\n\nWell, the action is adding changes to the staging area. To me, I'm not editing\nthe stage, I'm editing the change I'm adding to the stage, so 'git stage\n--edit' is perfectly fine.\n\n-- \nFelipe Contreras\n"},{"id":"226237","messageId":"521f9739dad63_16921225e7477096@nysa.mail","threadId":"34800","inReplyTo":"vpq8uzks5ou.fsf@anie.imag.fr","subject":"Re: [PATCH 1/2] Add proper 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:47:21Z","receivedAt":"2013-08-29T18:47:21Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > +COMMANDS\n> > +--------\n> > +\n> > +With no arguments, it's a synonym for linkgit:git-add[1].\n> \n> This would not be very useful since \"git add\" errors out when called\n> without arguments ;-).\n\nRight.\n\n> The accurate description of your code would be closer to \"When the first\n> argument is not a subcommand, it's a synonym for linkgit:git-add[1].\".\n> I'm not sure I like it, as it creates ambiguities (e.g. need to spell\n> \"git stage -- diff\" to add a file called \"diff\". Not a strong objection\n> though, as we already have refs Vs filename ambiguities in many places.\n\nYes, I thought really hard about this, but I think it's the best alternative.\nIn adition, we could stat to see if there's a file with the same name as the\nassumed subcommand, and warn about the ambiguity, and the recommended way to\nadd the file.\n\n-- \nFelipe Contreras\n"},{"id":"226236","messageId":"vpqli3kqqkp.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T18:50:30Z","receivedAt":"2013-08-29T18:50:30Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> It has been discussed many times in the past that 'index' is not an\n> appropriate description for what the high-level user does with it, and\n> it has been agreed that 'staging area' is the best term.\n\nThanks for working on this. No time for a really detailed review, but a\nfew remarks.\n\n> The term 'staging area' is more intuitive [...]\n>\n> The first step in moving Git towards this term, is first to add --stage\n> options for every command that uses --index or --cache.\n\nThese explanations make sense. I think it would be better to put part of\nit in commit messages, so that future contributors can \"git blame\" the\ndoc/implem of these --stage and find them (i.e. avoid the\nmisunderstanding that occured with \"git stage\" command which was\nproposed for removal).\n\n> After adding the new --stage options and making sure no functionality is\n> lost, they can become the recommended ones in the documentation,\n> eventually, the old ones get deprecated, and eventually obsoleted.\n\nSame: putting this in the commit message would cast in stone that we\nwant to obsolete the old ones.\n\n(But that was nice to have this cover-letter)\n\n> Moreover, the --stage and --work\n\n--work alone sounds weird. At least to me, it does not immediately imply\n\"working tree\". It is tempting to call the option --work-tree, but git\nalready has a global option with that name (git --work-tree=foo bar).\n\nPerhaps --worktree to limit the confusion?\n\n> reset', and after these options are added, the complicated table to\n> explain the different behaviors between --soft, --mixed, and --hard\n> becomes so simple it's not needed any more:\n\nI didn't understand the table, but yes, the --soft, --mixed, and --hard\nis terrible, I need to read the doc whenever I do something non-trivial\nwith reset :-(.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226244","messageId":"521f998d25eb4_174378fe7481879@nysa.mail","threadId":"34800","inReplyTo":"vpqli3kqqkp.fsf@anie.imag.fr","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T18:57:17Z","receivedAt":"2013-08-29T18:57:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > It has been discussed many times in the past that 'index' is not an\n> > appropriate description for what the high-level user does with it, and\n> > it has been agreed that 'staging area' is the best term.\n> \n> Thanks for working on this. No time for a really detailed review, but a\n> few remarks.\n> \n> > The term 'staging area' is more intuitive [...]\n> >\n> > The first step in moving Git towards this term, is first to add --stage\n> > options for every command that uses --index or --cache.\n> \n> These explanations make sense. I think it would be better to put part of\n> it in commit messages, so that future contributors can \"git blame\" the\n> doc/implem of these --stage and find them (i.e. avoid the\n> misunderstanding that occured with \"git stage\" command which was\n> proposed for removal).\n\nYes, but which commit? All of them? Perhaps it would make sense to add a link\nto the cover e-mail, or add an explanation in Documentation/gitstagingarea.txt\nor something.\n\n> > Moreover, the --stage and --work\n> \n> --work alone sounds weird. At least to me, it does not immediately imply\n> \"working tree\". It is tempting to call the option --work-tree, but git\n> already has a global option with that name (git --work-tree=foo bar).\n\nYes, --work sounds weird, but so does --cherry. I thought about --wt, but I\nfelt --work was more understandable, and --work-tree doesn't really give much\nmore value, except more characters to type =/\n\n> > reset', and after these options are added, the complicated table to\n> > explain the different behaviors between --soft, --mixed, and --hard\n> > becomes so simple it's not needed any more:\n> \n> I didn't understand the table, but yes, the --soft, --mixed, and --hard\n> is terrible, I need to read the doc whenever I do something non-trivial\n> with reset :-(.\n\nMe too, I always got 'git reset --hard', now I get 'git reset', but that's\nabout it, for the rest I have to read the documentation. Also, 'git stage\nreset' makes it even easier.\n\n-- \nFelipe Contreras\n"},{"id":"226246","messageId":"vpqli3kpavc.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"521f998d25eb4_174378fe7481879@nysa.mail","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T19:15:03Z","receivedAt":"2013-08-29T19:15:03Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> Matthieu Moy wrote:\n>> These explanations make sense. I think it would be better to put part of\n>> it in commit messages, so that future contributors can \"git blame\" the\n>> doc/implem of these --stage and find them (i.e. avoid the\n>> misunderstanding that occured with \"git stage\" command which was\n>> proposed for removal).\n>\n> Yes, but which commit? All of them? Perhaps it would make sense to add a link\n> to the cover e-mail, or add an explanation in Documentation/gitstagingarea.txt\n> or something.\n\nPutting the explanation about --stage in the first commit about it, and\nthen saying something like \"continue the work on --stage\" in the next\nmessages would make sense to me.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226247","messageId":"vpqfvtspakd.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"521f998d25eb4_174378fe7481879@nysa.mail","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T19:21:38Z","receivedAt":"2013-08-29T19:21:38Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> add an explanation in Documentation/gitstagingarea.txt\n> or something.\n\nThere's Documentation/gitcli.txt, that will need updating anyway (at the\nbottom, it talks about --cached and --index).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226253","messageId":"CAMP44s3=gRwORdxYiXnioufg8Ag3tmuZth5_-+NbJWV_v1FDxA@mail.gmail.com","threadId":"34800","inReplyTo":"xmqqeh9c4a2t.fsf@gitster.dls.corp.google.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T19:57:04Z","receivedAt":"2013-08-29T19:57:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 29, 2013 at 1:37 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> It has been discussed many times in the past that 'index' is not an\n>> appropriate description for what the high-level user does with it, and\n>> it has been agreed that 'staging area' is the best term.\n>\n> \"add\" is the verb,\n\nAdd changes to what? The user needs to know that.\n\n> not \"index\" (which is a noun that refers\n> to the thing that keeps track of what will be written as a tree to\n> be committed next).\n\nHow Git creates trees is irrelevant to the high-level user, all that\nis relevant is what happens from the users's point of view, and from\nthe user's point of view he is adding changes to an area that contains\nthe changes that will be part of the next commit.\n\n*Everyone* has agreed that the best name for that is the \"staging area\".\n\n> And it will stay that way.\n\nWe'll see about that. If it stays that way, it's because you are not\nlistening to what *everyone*, including users, developers, and\nteachers of Git, are saying.\n\n> IIRC, when this was discussed, many non-native speakers had trouble\n> with the verb \"to stage\", not just from i18n/l10n point of view.\n\nWell, you recall incorrectly.\n\nThere was *A SINGLE* non-native speaker that complained, about\n\"stage\", not \"staging area\", Ævar Arnfjörð Bjarmason, and he even said\nhe had already translated index/cache to \"the commit area\"[1].\n\nAgain, *everyone* has agreed that index needs to be renamed, and\n\"staging area\" is the best option.\n\nDo I really need to go through all the discussions and list each and\nevery person that participated in them, and show to you how everyone\nagreed? Can't you just go and read them again? There was a single\nperson that didn't like the term \"staging area\", but he accepted that\nindex is definitely not the right term (Drew Northup).\n\nHere are the threads once again:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/197111\nhttp://thread.gmane.org/gmane.comp.version-control.git/166675\nhttp://thread.gmane.org/gmane.comp.version-control.git/115666\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/197217\n\n-- \nFelipe Contreras\n"},{"id":"226255","messageId":"521FA90A.9040903@web.de","threadId":"34800","inReplyTo":"521f998d25eb4_174378fe7481879@nysa.mail","subject":"Re: Officially start moving to the term 'staging area'","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2013-08-29T20:03:22Z","receivedAt":"2013-08-29T20:03:22Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.08.2013 20:57, schrieb Felipe Contreras:\n> Matthieu Moy wrote:\n>> Felipe Contreras writes:\n>>> Moreover, the --stage and --work\n>>\n>> --work alone sounds weird. At least to me, it does not immediately imply\n>> \"working tree\". It is tempting to call the option --work-tree, but git\n>> already has a global option with that name (git --work-tree=foo bar).\n>\n> Yes, --work sounds weird, but so does --cherry. I thought about --wt, but I\n> felt --work was more understandable, and --work-tree doesn't really give much\n> more value, except more characters to type =/\n\nIf you have a --work-tree option then parseopt accepts --work as well, \nunless it's ambiguous, i.e. another option starts with --work, too. So \nyou can have a descriptive, extra-long option and type just a few \ncharacters at the same time.\n\nRené\n"},{"id":"226256","messageId":"CAMP44s3m_7UffHfie8=_izPt5tCw+9SXPa4sqoHuphuVyTHqcw@mail.gmail.com","threadId":"34800","inReplyTo":"521FA90A.9040903@web.de","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T20:36:48Z","receivedAt":"2013-08-29T20:36:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:\n> Am 29.08.2013 20:57, schrieb Felipe Contreras:\n>>\n>> Matthieu Moy wrote:\n>>\n>>> Felipe Contreras writes:\n>>>>\n>>>> Moreover, the --stage and --work\n>>>\n>>>\n>>> --work alone sounds weird. At least to me, it does not immediately imply\n>>> \"working tree\". It is tempting to call the option --work-tree, but git\n>>> already has a global option with that name (git --work-tree=foo bar).\n>>\n>>\n>> Yes, --work sounds weird, but so does --cherry. I thought about --wt, but\n>> I\n>> felt --work was more understandable, and --work-tree doesn't really give\n>> much\n>> more value, except more characters to type =/\n>\n>\n> If you have a --work-tree option then parseopt accepts --work as well,\n> unless it's ambiguous, i.e. another option starts with --work, too. So you\n> can have a descriptive, extra-long option and type just a few characters at\n> the same time.\n\nRight, but what do we use in the documentation? Writing --work-tree in\nthe 'git reset' table for example would be rather ugly. I'm fine with\n--work-tree, but I think it would be weird to have short-hands in the\ndocumentation, although not entirely bad.\n\n-- \nFelipe Contreras\n"},{"id":"226261","messageId":"vpqwqn4nr9g.fsf@anie.imag.fr","threadId":"34800","inReplyTo":"521f998d25eb4_174378fe7481879@nysa.mail","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-08-29T21:03:55Z","receivedAt":"2013-08-29T21:03:55Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> Matthieu Moy wrote:\n>\n>> --work alone sounds weird. At least to me, it does not immediately imply\n>> \"working tree\". It is tempting to call the option --work-tree, but git\n>> already has a global option with that name (git --work-tree=foo bar).\n>\n> Yes, --work sounds weird, but so does --cherry. I thought about --wt, but I\n> felt --work was more understandable, and --work-tree doesn't really give much\n> more value,\n\nI think it does: I understand --work as \"the verb to work\", so \n\"git reset --work\" sounds like \"tell 'git reset' to work\", while\n\"git reset --work-tree\" sounds like \"tell git to reset the work tree\".\n\n> except more characters to type =/\n\nThen, we can have --work-tree and a short version -w.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"226273","messageId":"CAM9Z-nmXPgfbXezbORb=NCqQuW4p3Dka+bHVdt_n7Sh=jehY7A@mail.gmail.com","threadId":"34800","inReplyTo":"xmqqeh9c4a2t.fsf@gitster.dls.corp.google.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2013-08-29T21:55:44Z","receivedAt":"2013-08-29T21:55:44Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> It has been discussed many times in the past that 'index' is not an\n>> appropriate description for what the high-level user does with it, and\n>> it has been agreed that 'staging area' is the best term.\n>\n> \"add\" is the verb, not \"index\" (which is a noun that refers\n> to the thing that keeps track of what will be written as a tree to\n> be committed next).\n>\n> And it will stay that way.\n>\n> IIRC, when this was discussed, many non-native speakers had trouble\n> with the verb \"to stage\", not just from i18n/l10n point of view.\n\nI agree with Junio. This effort is better spent making the\ndocumentation clearer and more succinct. The reality is that a user\nneeds to build a model in their mind of what they are doing which maps\nenough (completely is not required) to what is actually going on to\nget work done. If the documentation or the instruction is getting in\nthe way of that in the name of simplifying the presentation then the\npresentation is wrong.\n\nWe add content snapshots to the index of content (creating\n\"temporary\"--they will be garbage collected eventually if they become\norphans--objects into the store at the same time). We build commits\nfrom those snapshots (in whole or in part, typically only using the\nmost recent snapshots of new things added to the index) and save those\nin the object store with the content and tree objects. Sometimes we\ncreate tag objects to record something special about commits, trees,\nand content blobs.\n\nThat's the real model (with some rough edges). Explaining what that\nhas to do with distributed version control is the hard part.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"226274","messageId":"CAMP44s3ABKMAhp_P+QZBWOfjp_wPkqB0A63v6n2mKZv_Ln+qKg@mail.gmail.com","threadId":"34800","inReplyTo":"CAM9Z-nmXPgfbXezbORb=NCqQuW4p3Dka+bHVdt_n7Sh=jehY7A@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-29T22:10:58Z","receivedAt":"2013-08-29T22:10:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote:\n> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>>\n>>> It has been discussed many times in the past that 'index' is not an\n>>> appropriate description for what the high-level user does with it, and\n>>> it has been agreed that 'staging area' is the best term.\n>>\n>> \"add\" is the verb, not \"index\" (which is a noun that refers\n>> to the thing that keeps track of what will be written as a tree to\n>> be committed next).\n>>\n>> And it will stay that way.\n>>\n>> IIRC, when this was discussed, many non-native speakers had trouble\n>> with the verb \"to stage\", not just from i18n/l10n point of view.\n>\n> I agree with Junio.\n\nAll right, you are the only person (presumably other than Junio) that\nthinks \"index\" is the right name for what high-level users should be\nfamiliar with.\n\n> This effort is better spent making the\n> documentation clearer and more succinct. The reality is that a user\n> needs to build a model in their mind of what they are doing which maps\n> enough (completely is not required) to what is actually going on to\n> get work done. If the documentation or the instruction is getting in\n> the way of that in the name of simplifying the presentation then the\n> presentation is wrong.\n>\n> We add content snapshots to the index of content (creating\n> \"temporary\"--they will be garbage collected eventually if they become\n> orphans--objects into the store at the same time). We build commits\n> from those snapshots (in whole or in part, typically only using the\n> most recent snapshots of new things added to the index) and save those\n> in the object store with the content and tree objects. Sometimes we\n> create tag objects to record something special about commits, trees,\n> and content blobs.\n>\n> That's the real model (with some rough edges). Explaining what that\n> has to do with distributed version control is the hard part.\n\nThe user doesn't need to know the format of the index, or the packs,\nin fact, they don't even need to know the index or packs even exist.\n\nAll the user needs to know about this is that there's an area where\ncontents of the next commit are being prepared, and \"staging area\" is\nthe best name for that mental area. How that area is actually\nimplemented (the index) is not relevant to the user.\n\nEveryone agrees on that, except you, and possibly Junio.\n\n-- \nFelipe Contreras\n"},{"id":"226293","messageId":"b677f1ae-662f-4728-b625-189bc392c74d@email.android.com","threadId":"34800","inReplyTo":"CAM9Z-nmXPgfbXezbORb=NCqQuW4p3Dka+bHVdt_n7Sh=jehY7A@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-08-30T05:16:34Z","receivedAt":"2013-08-30T05:16:34Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Drew Northup napisał:\n>I agree with Junio. This effort is better spent making the\n>documentation clearer and more succinct. The reality is that a user\n>needs to build a model in their mind of what they are doing which maps\n>enough (completely is not required) to what is actually going on to\n>get work done. If the documentation or the instruction is getting in\n>the way of that in the name of simplifying the presentation then the\n>presentation is wrong.\n\nWhy do you think the \"stage\" model do not map enough? \n\n\n>We add content snapshots to the index of content (creating\n>\"temporary\"--they will be garbage collected eventually if they become\n>orphans--objects into the store at the same time). We build commits\n>from those snapshots (in whole or in part, typically only using the\n>most recent snapshots of new things added to the index) and save those\n>in the object store with the content and tree objects. Sometimes we\n>create tag objects to record something special about commits, trees,\n>and content blobs.\n\nThe above can be rewritten to use the 'staging area' concept just fine. And I don't think you should say to inexperienced users things like 'tree objects'.\n\nA good exercise would be to take documentation of some command and show that it can or can't be rewritten to use the other term. \n\nInstead of 'indexing' or 'staging' content you could also use term 'mark'. You mark content to add, for removal, you can diff it or revert. \n\n\n\n>\n>That's the real model (with some rough edges). Explaining what that\n>has to do with distributed version control is the hard part.\n\n\n-- \nPiotr Krukowiecki \n"},{"id":"226362","messageId":"CAMP44s0yxaS3YeF5gprTecfa0rzLso96cE9gWM629iM0Sc5+Bg@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s3=gRwORdxYiXnioufg8Ag3tmuZth5_-+NbJWV_v1FDxA@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-30T19:11:11Z","receivedAt":"2013-08-30T19:11:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 29, 2013 at 2:57 PM, Felipe Contreras\n wrote:\n\n> Again, *everyone* has agreed that index needs to be renamed, and\n> \"staging area\" is the best option.\n>\n> Do I really need to go through all the discussions and list each and\n> every person that participated in them, and show to you how everyone\n> agreed? Can't you just go and read them again? There was a single\n> person that didn't like the term \"staging area\", but he accepted that\n> index is definitely not the right term (Drew Northup).\n>\n> Here are the threads once again:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/197111\n> http://thread.gmane.org/gmane.comp.version-control.git/166675\n> http://thread.gmane.org/gmane.comp.version-control.git/115666\n\nI take it you still haven't read those threads, and you don't plan to.\nSo I have to go through each and every comment and summarize what each\nperson concluded.\n\nHopefully you would come back to me before I waste my time, but it\nseems there's no other way to make you see the reality of what was\nactually already discussed and agreed.\n\n-- \nFelipe Contreras\n"},{"id":"226368","messageId":"CAMP44s0Lv+HTFt6RxyRehfA_NpSPtnr2v4EnAO_vxQcOtQZLbQ@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s3=gRwORdxYiXnioufg8Ag3tmuZth5_-+NbJWV_v1FDxA@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-30T20:28:18Z","receivedAt":"2013-08-30T20:28:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 29, 2013 at 2:57 PM, Felipe Contreras\n wrote:\n> On Thu, Aug 29, 2013 at 1:37 PM, Junio C Hamano wrote:\n\n>> IIRC, when this was discussed, many non-native speakers had trouble\n>> with the verb \"to stage\", not just from i18n/l10n point of view.\n>\n> Well, you recall incorrectly.\n>\n> There was *A SINGLE* non-native speaker that complained, about\n> \"stage\", not \"staging area\", Ævar Arnfjörð Bjarmason, and he even said\n> he had already translated index/cache to \"the commit area\"[1].\n\nActually, not only did Ævar not have a problem with \"staging area\",\nbut he told you this argument about i18n/l10n didn't make sense at\nall, and you agreed:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/197371\n\nIn fact, all non-native speakers said they liked the term \"staging\narea\", like everybody else.\n\nSo please enlighten us, which non-native speakers had a problem from\nthe translation point of view, and why does it matter?\n\n-- \nFelipe Contreras\n"},{"id":"226369","messageId":"CAMP44s2cba_UGmYJuwf9kw-OG4FQz6eRefRC0xa7pnx6ctFRjw@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s0yxaS3YeF5gprTecfa0rzLso96cE9gWM629iM0Sc5+Bg@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-30T20:40:39Z","receivedAt":"2013-08-30T20:40:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Aug 30, 2013 at 2:11 PM, Felipe Contreras\n wrote:\n> On Thu, Aug 29, 2013 at 2:57 PM, Felipe Contreras\n> wrote:\n\n>> Here are the threads once again:\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/197111\n>> http://thread.gmane.org/gmane.comp.version-control.git/166675\n>> http://thread.gmane.org/gmane.comp.version-control.git/115666\n>\n> I take it you still haven't read those threads, and you don't plan to.\n> So I have to go through each and every comment and summarize what each\n> person concluded.\n>\n> Hopefully you would come back to me before I waste my time, but it\n> seems there's no other way to make you see the reality of what was\n> actually already discussed and agreed.\n\nSo here's the summary, as I said, *everybody* is in favor of \"staging\narea\" or something other than \"index\", with the exception of Drew\nNorthup, I've put a summary of the conclusion of each person that\nvoiced an opinion on the matter, and I've CC'ed them here, so they can\nreiterate their opinion, or clarify it.\n\nJunio, do you accept that virtually *everyone* is in favor of \"staging\narea\" now?\n\n== Against ==\n\nDrew Northup:\nindex is good\n\n== For ==\n\nJay Soffian:\nstaging area is better\n\nPete Harlan:\nAghiles:\n\"staging area\" is good for teaching\n\nPiotr Krukowiecki:\n\"staging area\" makes sense\n\nJonathan Nieder:\n\"staging area\" is better than \"index\"\n\nJeff King:\n\"staging area\" makes perfect sense\n\nMiles Bader:\n\"staging area\" is good\n\nPhil Hord:\n\"staging area\" is better than index/cache\n\nVictor Engmark:\nmaybe \"git bucket\"\n\nDavid (bouncingcats):\nmaybe \"precommit\"\n\nAlexey Feldgendler:\n\"staging area\" translates better into Russian (than precommit)\n\nAlexei Sholik:\n\"staging area\" is better\n\nZbigniew Jędrzejewski-Szmek:\n\"staging area\" is better\n\nÆvar Arnfjörð Bjarmason:\nIn Icelandic \"index/stage\" is translated to \"the commit area\"\n\nSebastien Douche:\n\"stage\" is better than \"cache\"/\"index\"\n\nThiago Farina:\n\"precommit\" is better\n\nMark Lodato:\n\"staging\" is the most appropriate\n\nPhilip Oakley:\n\"staging area\" is OK\n\nMatthieu Moy:\nsomething needs to be done\n\n-- \nFelipe Contreras\n"},{"id":"226370","messageId":"CAMP44s12m5EMe+SWb4YB1kXfPX1qOOxP5244KCU_Sm3CKaqYAg@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s2cba_UGmYJuwf9kw-OG4FQz6eRefRC0xa7pnx6ctFRjw@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-30T20:42:31Z","receivedAt":"2013-08-30T20:42:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Aug 30, 2013 at 3:40 PM, Felipe Contreras\n wrote:\n> On Fri, Aug 30, 2013 at 2:11 PM, Felipe Contreras\n> wrote:\n>> On Thu, Aug 29, 2013 at 2:57 PM, Felipe Contreras\n>> wrote:\n>\n>>> Here are the threads once again:\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/197111\n>>> http://thread.gmane.org/gmane.comp.version-control.git/166675\n>>> http://thread.gmane.org/gmane.comp.version-control.git/115666\n>>\n>> I take it you still haven't read those threads, and you don't plan to.\n>> So I have to go through each and every comment and summarize what each\n>> person concluded.\n>>\n>> Hopefully you would come back to me before I waste my time, but it\n>> seems there's no other way to make you see the reality of what was\n>> actually already discussed and agreed.\n>\n> So here's the summary, as I said, *everybody* is in favor of \"staging\n> area\" or something other than \"index\", with the exception of Drew\n> Northup, I've put a summary of the conclusion of each person that\n> voiced an opinion on the matter, and I've CC'ed them here, so they can\n> reiterate their opinion, or clarify it.\n>\n> Junio, do you accept that virtually *everyone* is in favor of \"staging\n> area\" now?\n\nTo avoid bonces, please remove victor.engmark@terreactive.ch and\nalexeyf@opera.com from the CC list.\n\n-- \nFelipe Contreras\n"},{"id":"226406","messageId":"52219F6E.6090605@web.de","threadId":"34800","inReplyTo":"CAMP44s3m_7UffHfie8=_izPt5tCw+9SXPa4sqoHuphuVyTHqcw@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2013-08-31T07:46:54Z","receivedAt":"2013-08-31T07:46:54Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 29.08.2013 22:36, schrieb Felipe Contreras:\n> On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:\n>> If you have a --work-tree option then parseopt accepts --work as well,\n>> unless it's ambiguous, i.e. another option starts with --work, too. So you\n>> can have a descriptive, extra-long option and type just a few characters at\n>> the same time.\n>\n> Right, but what do we use in the documentation? Writing --work-tree in\n> the 'git reset' table for example would be rather ugly. I'm fine with\n> --work-tree, but I think it would be weird to have short-hands in the\n> documentation, although not entirely bad.\n\nI don't see what's so ugly about it.\n\nThe git command itself has a --work-tree parameter for specifying the \nlocation of the checked-out files, however. It could be confusing to \nhave the same parameter do different things:\n\n\t$ git reset --work-tree=/some/where reset --work-tree\n\nPerhaps a note in the documentation is enough to clear this up.\n\n\nIn general I think that the full long option should be mentioned in \nsynopsis and description, while abbreviated parameters could be used in \nan example. The ability to understand unambiguous shortened options is \na general feature and doesn't have to be explained in the manpage for a \nspecific command.\n\nNB: It would be nice to have more commands use parseopt, for that \nfeature alone.\n\nRené\n"},{"id":"226407","messageId":"CAMP44s36Kyiu5VnfN9+V3BwJZSMdOdGazCPXUnxUYqLQpzUOPw@mail.gmail.com","threadId":"34800","inReplyTo":"52219F6E.6090605@web.de","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-31T07:53:08Z","receivedAt":"2013-08-31T07:53:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Aug 31, 2013 at 2:46 AM, René Scharfe wrote:\n> Am 29.08.2013 22:36, schrieb Felipe Contreras:\n>>\n>> On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:\n>>>\n>>> If you have a --work-tree option then parseopt accepts --work as well,\n>>> unless it's ambiguous, i.e. another option starts with --work, too. So\n>>> you\n>>> can have a descriptive, extra-long option and type just a few characters\n>>> at\n>>> the same time.\n>>\n>>\n>> Right, but what do we use in the documentation? Writing --work-tree in\n>> the 'git reset' table for example would be rather ugly. I'm fine with\n>> --work-tree, but I think it would be weird to have short-hands in the\n>> documentation, although not entirely bad.\n>\n> I don't see what's so ugly about it.\n\nMaybe not so much.\n\n> The git command itself has a --work-tree parameter for specifying the\n> location of the checked-out files, however. It could be confusing to have\n> the same parameter do different things:\n>\n> $ git reset --work-tree=/some/where reset --work-tree\n\nI don't see what's confusing about that, one option is for git core,\nthe other is for the subcommand.\n\n> In general I think that the full long option should be mentioned in synopsis\n> and description, while abbreviated parameters could be used in an example.\n> The ability to understand unambiguous shortened options is a general feature\n> and doesn't have to be explained in the manpage for a specific command.\n>\n> NB: It would be nice to have more commands use parseopt, for that feature\n> alone.\n\nIndeed.\n\n-- \nFelipe Contreras\n"},{"id":"226459","messageId":"CAJDDKr4ryTtS9U-ZMky5YvWTSOKPk1n80Ot=h6rwzExOvsSTcg@mail.gmail.com","threadId":"34800","inReplyTo":"52219F6E.6090605@web.de","subject":"Re: Officially start moving to the term 'staging area'","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-09-01T03:46:46Z","receivedAt":"2013-09-01T03:46:46Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sat, Aug 31, 2013 at 12:46 AM, René Scharfe wrote:\n> Am 29.08.2013 22:36, schrieb Felipe Contreras:\n>>\n>> On Thu, Aug 29, 2013 at 3:03 PM, René Scharfe wrote:\n>>>\n>>> If you have a --work-tree option then parseopt accepts --work as well,\n>>> unless it's ambiguous, i.e. another option starts with --work, too. So\n>>> you\n>>> can have a descriptive, extra-long option and type just a few characters\n>>> at\n>>> the same time.\n>>\n>>\n>> Right, but what do we use in the documentation? Writing --work-tree in\n>> the 'git reset' table for example would be rather ugly. I'm fine with\n>> --work-tree, but I think it would be weird to have short-hands in the\n>> documentation, although not entirely bad.\n>\n>\n> I don't see what's so ugly about it.\n>\n> The git command itself has a --work-tree parameter for specifying the\n> location of the checked-out files, however. It could be confusing to have\n> the same parameter do different things:\n>\n> $ git reset --work-tree=/some/where reset --work-tree\n>\n> Perhaps a note in the documentation is enough to clear this up.\n\nI agree that this is confusing for people not deeply versed in Git jargon.\nWe also know that no one reads documentation.\n\nMaybe a better word can be found? How about \"git reset --files\"?\n-- \nDavid\n"},{"id":"226695","messageId":"CAM9Z-nmLQUrJk73pi_0a1_ccGMnqU_t=uOZze622_GEtWfMvQQ@mail.gmail.com","threadId":"34800","inReplyTo":"b677f1ae-662f-4728-b625-189bc392c74d@email.android.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2013-09-04T04:23:46Z","receivedAt":"2013-09-04T04:23:46Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Fri, Aug 30, 2013 at 1:16 AM, Piotr Krukowiecki\n wrote:\n> Drew Northup napisał:\n>>I agree with Junio. This effort is better spent making the\n>>documentation clearer and more succinct. The reality is that a user\n>>needs to build a model in their mind of what they are doing which maps\n>>enough (completely is not required) to what is actually going on to\n>>get work done. If the documentation or the instruction is getting in\n>>the way of that in the name of simplifying the presentation then the\n>>presentation is wrong.\n>\n> Why do you think the \"stage\" model do not map enough?\n\nWhen I try to explain how to use git to complete VCS newbies in\ngeneral they find the \"snapshot\" model more mentally sensible than the\n\"staging area\" model. (In other words, the user doesn't care how, if,\nor where the program is maintaining state.) The \"snapshot\" model does\nnot require knowledge of the index and does not get in the way of\nlater on learning more advanced concepts which benefit from the index\nbeing explained as what it is--explanations which quite frequently\nbring up the \"staging area\" model (but in that case as a portion of\nthe index used to store snapshot state information).\n\n>>We add content snapshots to the index of content (creating\n>>\"temporary\"--they will be garbage collected eventually if they become\n>>orphans--objects into the store at the same time). We build commits\n>>from those snapshots (in whole or in part, typically only using the\n>>most recent snapshots of new things added to the index) and save those\n>>in the object store with the content and tree objects. Sometimes we\n>>create tag objects to record something special about commits, trees,\n>>and content blobs.\n>\n> The above can be rewritten to use the 'staging area' concept just\n> fine. And I don't think you should say to inexperienced users things\n> like 'tree objects'.\n\nAt what time did I say specifically what I tell newbies? I did not do\nso. Please refrain from making that sort of assumption. In any case,\nno, you cannot rewrite that to use \"staging area\" in place of \"index\"\nwithout introducing a different mental model and new concept into the\ntext (a model which happens to be incomplete, but not incorrect). That\nminimalist summary was written for the technically-minded people here\non this list debating the issue of communications with the users--the\nbane of all programmers' lives.\n\n> A good exercise would be to take documentation of some command\n> and show that it can or can't be rewritten to use the other term.\n\nThat may be a good exercise in matters of philosophy, but you will\nfind few outside of the world of programming who would agree with that\ncharacterization of the optimization of technical writing. (In the\nEnglish language in particular it is folly due to the extreme\nvariation of available terms and metaphors with nearly identical\ndenotations and greatly varying connotations.)\n\n> Instead of 'indexing' or 'staging' content you could also use term 'mark'.\n> You mark content to add, for removal, you can diff it or revert.\n\nSo far as I am concerned the introduction of a specific \"staging area\"\n(as if it has a distinct physical presence) is superfluous to that.\n\n>>That's the real model (with some rough edges). Explaining what that\n>>has to do with distributed version control is the hard part.\n\nAgain, let us keep our argument focused on communications with users.\nRenaming core objects is just going to sow confusion without fixing\nthe user communication issue. That's what I meant the first time I\nwrote what I quote directly above and I'm sticking to it.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"226697","messageId":"CAM9Z-nnjb1wUDH9e=E38QnWvPK44xZqvza77yNLrDpjpj47BKw@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s3ABKMAhp_P+QZBWOfjp_wPkqB0A63v6n2mKZv_Ln+qKg@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2013-09-04T04:45:03Z","receivedAt":"2013-09-04T04:45:03Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Thu, Aug 29, 2013 at 6:10 PM, Felipe Contreras\n wrote:\n> On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote:\n>> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote:\n>>> Felipe Contreras writes:\n>>>\n>>>> It has been discussed many times in the past that 'index' is not an\n>>>> appropriate description for what the high-level user does with it, and\n>>>> it has been agreed that 'staging area' is the best term.\n>>>\n>>> \"add\" is the verb, not \"index\" (which is a noun that refers\n>>> to the thing that keeps track of what will be written as a tree to\n>>> be committed next).\n>>>\n>>> And it will stay that way.\n\n>> I agree with Junio.\n>\n> All right, you are the only person (presumably other than Junio) that\n> thinks \"index\" is the right name for what high-level users should be\n> familiar with.\n\nIf that were true it would never have gotten that name. \"Add\" is the\nverb, as we are adding a snapshot. New users don't care how that works\nfor the most part. Just telling them \"it keeps track of it itself\" is\nusually good enough. If the user is asking for more detail at that\npoint it is probably because he isn't as much interested in how to use\nit as he is in how it works. At that point we're better off just\ngiving him the actual explanation instead of getting caught up in the\nstaging area vs index fight (which seems odd to me as the index\ncontains the entries which act as a \"staging area\"--a superset /\nsubset relation).\n\n>> We add content snapshots to the index of content (creating\n>> \"temporary\"--they will be garbage collected eventually if they become\n>> orphans--objects into the store at the same time). We build commits\n>> from those snapshots (in whole or in part, typically only using the\n>> most recent snapshots of new things added to the index) and save those\n>> in the object store with the content and tree objects. Sometimes we\n>> create tag objects to record something special about commits, trees,\n>> and content blobs.\n>>\n>> That's the real model (with some rough edges). Explaining what that\n>> has to do with distributed version control is the hard part.\n>\n> The user doesn't need to know the format of the index, or the packs,\n> in fact, they don't even need to know the index or packs even exist.\n\nI never implied that the end user does need to know these things.\n(Note the use of \"We\"--as in \"we who are having this conversation.\")\n\n> All the user needs to know about this is that there's an area where\n> contents of the next commit are being prepared, and \"staging area\" is\n> the best name for that mental area. How that area is actually\n> implemented (the index) is not relevant to the user.\n\nPart of what I am arguing is that the mental area doesn't need to\nexist at all. The \"staging area\" is a part of the index. It is not the\nwhole thing. There is no one-off complete replacement of one with the\nother. Most new users won't care about either, just that it happens\nsomehow and that git keeps track of that state itself. We need not\nchange any core items to achieve that.\n\n> Everyone agrees on that, except you, and possibly Junio.\n\nWe don't have enough information to say that. Seriously, this is\nnowhere near as certain as climate change.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"226698","messageId":"CABjHNoR637ecLnnLwhj59ddnhy8Lcyk+2YzAqN=nxWN7-BkivA@mail.gmail.com","threadId":"34800","inReplyTo":"20130829180129.GA4880@nysa","subject":"Re: Officially start moving to the term 'staging area'","fromName":"William Swanson","fromEmail":"swansontec@gmail.com","sentAt":"2013-09-04T06:08:44Z","receivedAt":"2013-09-04T06:08:44Z","isPatch":false,"sender":{"key":"swansontec@gmail.com","avatar":"https://gravatar.com/avatar/c347fab0a8fe77e4159deb7c2b7195ebbee19b091aed98503ad83438e6bea851?d=mp&s=160"},"body":"On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras\n wrote:\n> It has been discussed many times in the past that 'index' is not an\n> appropriate description for what the high-level user does with it, and\n> it has been agreed that 'staging area' is the best term.\n\nI realize Git is not a democracy, but if the vote of a humble user\ncounts for anything, I agree that \"index\" is a terrible name.\n\nI was very excited when Felipe first started this thread, since I\nthought Git might finally fix one of it's biggest long-standing\nusability problems. Calling this thing the \"index\" is like calling an\nimportant variable \"someValue.\" While the name may be technically\ncorrect, it's way too generic to be useful. A name like \"staging area\"\nmay not capture the whole idea, but at least it provides a good clue\nabout what it does and how you might use it.\n\nIf we change this, I'm pretty sure most of the Internet will rejoice.\nOnly a few old-timers will be grumpy, but that's just because they\ndon't like change in general. I have never met anybody (outside this\nthread) who thought the current name was a good idea.\n\n-William\n"},{"id":"226704","messageId":"CAA01CsqNKMqExq1PYanotzQ-wTcf=7c5BQ_49xGu4QasXSCoeQ@mail.gmail.com","threadId":"34800","inReplyTo":"CAM9Z-nmLQUrJk73pi_0a1_ccGMnqU_t=uOZze622_GEtWfMvQQ@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-09-04T07:13:55Z","receivedAt":"2013-09-04T07:13:55Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Just wanted to point to a Dr. Dobb's article from Monday:\nhttp://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2\n\nThe author does not use the use the word \"index\" at all. Instead he\nwrites in following way:\n\n---------------------------------------------------------------------------------------\nStaging Changes\n\nOne of Git's best features is that it offers a staging process. You\ncan stage the modified files that you want to commit. Other version\ncontrol systems await your one command before your files are changed\nin the repository — generally the remote repository for the entire\nteam. When you commit files in Git, files are held in a staging area.\nYou will later commit all the files from the staging area to the\nlarger repository.\n\nSo, let's say you wanted to make a change involving files A and B. You\nchanged file A. You then remembered something unrelated to do with\nfile Z and you modified that. Then you went back to your initial\nchange, modifying file B. Git allows you to add files A and B to\nstaging, while leaving file Z \"unstaged.\" Then you can push only the\nstaged files to your repository. But you don't! You realize you need\nto make a change to file C as well. You \"add\" it. Now files A,B, and C\nare staged, and Z is still unstaged. You commit the staged changes\nonly.\n\n[...]\n---------------------------------------------------------------------------------------\n\n\nSorry for not responding to your comments Drew, no time at the moment.\n\n-- \nPiotr Krukowiecki\n"},{"id":"226728","messageId":"CAM9Z-nnGV4hMG1bAY9u+U+qU5vwi95RWFLj2-75AQUZc5mQDtw@mail.gmail.com","threadId":"34800","inReplyTo":"CAA01CsqNKMqExq1PYanotzQ-wTcf=7c5BQ_49xGu4QasXSCoeQ@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2013-09-04T13:36:19Z","receivedAt":"2013-09-04T13:36:19Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Wed, Sep 4, 2013 at 3:13 AM, Piotr Krukowiecki\n wrote:\n> Just wanted to point to a Dr. Dobb's article from Monday:\n> http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2\n>\n> The author does not use the use the word \"index\" at all. Instead he\n> writes in following way:\n>\n> ---------------------------------------------------------------------------------------\n\n> ---------------------------------------------------------------------------------------\n>\n>\n> Sorry for not responding to your comments Drew, no time at the moment.\n\nNP. What he writes [in that quote at least] is entirely reasonable. In\nfact, oddly enough (as I presume you meant it as a refutation), it can\nbe seen to support my argument: don't mess with the core code much (if\nat all) but fix the documentation. That's all that I've been arguing\nsince day one. We don't need to make big huge changes in every part of\nthe Git metaphor set to better explain what is going on to newbies and\ncasual users. (Aside from the fact that there's a huge body of\nexisting documentation, tools, and usage patterns that depends on the\ncurrently predominant model.)\n\nI still argue that for a not insignificant group of users--people who\nare happy with the current paradigm and therefore aren't making a lot\nof noise--the current core metaphor is actually useful despite the\nname being more than just a tad bit unfortunate. Alas, for dealing\nwith some of the advanced usage explanations it can be argued that the\n\"staging area\" metaphor (it implies _completed_ bundles ready to\npackage into commits and ship--I envision shipping trailers being\nfilled with _immutable_ boxes and attached to trucks) is actually\nharmful, but we can talk about that if there's a need.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"226942","messageId":"CACSwcnR+rHVDVHu8rwATU+VbGE-9zP=xB8Y-udPGoP6KvhprCA@mail.gmail.com","threadId":"34800","inReplyTo":"CABjHNoR637ecLnnLwhj59ddnhy8Lcyk+2YzAqN=nxWN7-BkivA@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2013-09-06T15:45:44Z","receivedAt":"2013-09-06T15:45:44Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Wed, Sep 4, 2013 at 2:08 PM, William Swanson wrote:\n> On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras\n> wrote:\n>> It has been discussed many times in the past that 'index' is not an\n>> appropriate description for what the high-level user does with it, and\n>> it has been agreed that 'staging area' is the best term.\n>\n> I realize Git is not a democracy, but if the vote of a humble user\n> counts for anything, I agree that \"index\" is a terrible name.\n\n+1 for staging area\n\n>\n> I was very excited when Felipe first started this thread, since I\n> thought Git might finally fix one of it's biggest long-standing\n> usability problems.\n\nthe same feeling.\n"},{"id":"226954","messageId":"CAE1pOi1epmm2ESb0ocAhPFCfs6LVctFOXnt2vwPNp2Lxuq2=+w@mail.gmail.com","threadId":"34800","inReplyTo":"CACSwcnR+rHVDVHu8rwATU+VbGE-9zP=xB8Y-udPGoP6KvhprCA@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2013-09-06T17:14:45Z","receivedAt":"2013-09-06T17:14:45Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 6 September 2013 08:45, Ping Yin wrote:\n> On Wed, Sep 4, 2013 at 2:08 PM, William Swanson wrote:\n>> On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras\n>> wrote:\n>>> It has been discussed many times in the past that 'index' is not an\n>>> appropriate description for what the high-level user does with it, and\n>>> it has been agreed that 'staging area' is the best term.\n>>\n>> I realize Git is not a democracy, but if the vote of a humble user\n>> counts for anything, I agree that \"index\" is a terrible name.\n>\n> +1 for staging area\n\nAs yet another \"just a user\", I'd like to add my enthusiastic support\nfor \"to stage\" and \"staging area\".\n\nI'm guessing that a lot of Git devs/long time users are simply so used\nto its interface that they may not see its sharp corners any more. :-)\nThat's quite natural and bound to happen to anyone who works with a\nparticular tool for a long time. Still, (e.g.) \"git add -A\" removing\nfiles (as useful as that is) is just weird. And, in general, the user\nshould not need to know how Git is implemented.\n\n>> I was very excited when Felipe first started this thread, since I\n>> thought Git might finally fix one of it's biggest long-standing\n>> usability problems.\n>\n> the same feeling.\n\nDitto. :-)\n"},{"id":"227044","messageId":"CAMP44s2b6jFcVpdkQi5F3CWwYin6V-n==x0xSW4otsuYiW-+3g@mail.gmail.com","threadId":"34800","inReplyTo":"CAA01CsqNKMqExq1PYanotzQ-wTcf=7c5BQ_49xGu4QasXSCoeQ@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T01:18:09Z","receivedAt":"2013-09-08T01:18:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 4, 2013 at 2:13 AM, Piotr Krukowiecki\n wrote:\n> Just wanted to point to a Dr. Dobb's article from Monday:\n> http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2\n>\n> The author does not use the use the word \"index\" at all. Instead he\n> writes in following way:\n\nSame goes for the ProGit book, which is quite famous:\nhttp://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository\nhttp://git-scm.com/book/en/Git-Tools-Interactive-Staging\n\n-- \nFelipe Contreras\n"},{"id":"227045","messageId":"CAMP44s2+nHEOupOa79EpDSLZeZhwQrT380r4KzVL9xAb1hzvMg@mail.gmail.com","threadId":"34800","inReplyTo":"CAM9Z-nnGV4hMG1bAY9u+U+qU5vwi95RWFLj2-75AQUZc5mQDtw@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T01:27:04Z","receivedAt":"2013-09-08T01:27:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Sep 4, 2013 at 8:36 AM, Drew Northup wrote:\n> On Wed, Sep 4, 2013 at 3:13 AM, Piotr Krukowiecki\n> wrote:\n>> Just wanted to point to a Dr. Dobb's article from Monday:\n>> http://www.drdobbs.com/tools/getting-started-with-git-the-fundamental/240160261?pgno=2\n>>\n>> The author does not use the use the word \"index\" at all. Instead he\n>> writes in following way:\n>>\n>> ---------------------------------------------------------------------------------------\n> \n>> ---------------------------------------------------------------------------------------\n>>\n>>\n>> Sorry for not responding to your comments Drew, no time at the moment.\n>\n> NP. What he writes [in that quote at least] is entirely reasonable. In\n> fact, oddly enough (as I presume you meant it as a refutation), it can\n> be seen to support my argument: don't mess with the core code much (if\n> at all) but fix the documentation. That's all that I've been arguing\n> since day one. We don't need to make big huge changes in every part of\n> the Git metaphor set to better explain what is going on to newbies and\n> casual users.\n\nBut he is using the term \"staging area\", forget about my patches to\nthe code, are you agreeing we should fix the documentation to use the\nterm \"staging area\" as Dr. Dobb did?\n\n> (Aside from the fact that there's a huge body of\n> existing documentation, tools, and usage patterns that depends on the\n> currently predominant model.)\n\nMost of the online documentation doesn't use the term \"index\", they\nuse \"staging area\", as the link just described above.\n\n> I still argue that for a not insignificant group of users--people who\n> are happy with the current paradigm and therefore aren't making a lot\n> of noise--the current core metaphor is actually useful despite the\n> name being more than just a tad bit unfortunate. Alas, for dealing\n> with some of the advanced usage explanations it can be argued that the\n> \"staging area\" metaphor (it implies _completed_ bundles ready to\n> package into commits and ship--I envision shipping trailers being\n> filled with _immutable_ boxes and attached to trucks) is actually\n> harmful, but we can talk about that if there's a need.\n\nNobody thinks of the staging area that way, just you.\n\nThe staging area is an area that contains the preparation for the next\ncommit to be made. There's no ships, or trailers, or bundles.\nEverybody understands that, and find the term \"staging area\" fit for\nthat description. Except you.\n\n-- \nFelipe Contreras\n"},{"id":"227046","messageId":"CAMP44s1j+ayX=cy7QJ7WXdiD9P1M6n7NgNk=oGuv1XC=dqMXVA@mail.gmail.com","threadId":"34800","inReplyTo":"CAM9Z-nmLQUrJk73pi_0a1_ccGMnqU_t=uOZze622_GEtWfMvQQ@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T01:33:03Z","receivedAt":"2013-09-08T01:33:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 3, 2013 at 11:23 PM, Drew Northup wrote:\n> On Fri, Aug 30, 2013 at 1:16 AM, Piotr Krukowiecki\n> wrote:\n>> Drew Northup napisał:\n>>>I agree with Junio. This effort is better spent making the\n>>>documentation clearer and more succinct. The reality is that a user\n>>>needs to build a model in their mind of what they are doing which maps\n>>>enough (completely is not required) to what is actually going on to\n>>>get work done. If the documentation or the instruction is getting in\n>>>the way of that in the name of simplifying the presentation then the\n>>>presentation is wrong.\n>>\n>> Why do you think the \"stage\" model do not map enough?\n>\n> When I try to explain how to use git to complete VCS newbies in\n> general they find the \"snapshot\" model more mentally sensible than the\n> \"staging area\" model. (In other words, the user doesn't care how, if,\n> or where the program is maintaining state.)\n\nThe snapshot concept is totally orthogonal from the staging area\nconcept. Git works in snapshots, which are frozen images of how the\ncontent tree was at a certain point in time; IOW; a commit.\n\n_How_ that snapshot is created is an entirely different topic, and the\nstaging area is a tool to create the desired snapshots. The user might\ndecide to never use that tool (i.e. always run git commit -a), but the\nconcept of snapshots remain. So, clearly, one concept has absolutely\nnothing to do with the other.\n\n>>>We add content snapshots to the index of content (creating\n>>>\"temporary\"--they will be garbage collected eventually if they become\n>>>orphans--objects into the store at the same time). We build commits\n>>>from those snapshots (in whole or in part, typically only using the\n>>>most recent snapshots of new things added to the index) and save those\n>>>in the object store with the content and tree objects. Sometimes we\n>>>create tag objects to record something special about commits, trees,\n>>>and content blobs.\n>>\n>> The above can be rewritten to use the 'staging area' concept just\n>> fine. And I don't think you should say to inexperienced users things\n>> like 'tree objects'.\n>\n> At what time did I say specifically what I tell newbies? I did not do\n> so. Please refrain from making that sort of assumption. In any case,\n> no, you cannot rewrite that to use \"staging area\" in place of \"index\"\n> without introducing a different mental model and new concept into the\n> text (a model which happens to be incomplete, but not incorrect). That\n> minimalist summary was written for the technically-minded people here\n> on this list debating the issue of communications with the users--the\n> bane of all programmers' lives.\n\nYou are mixing useful mental models for the majority of Git users, and\ntechnical implementation details.\n\nYou say what you wrote is for technically-minded people, and those\npeople are not relevant for this discussion, because we are not\ntalking about the implementation details, we are talking about the\nvast majority of Git users, so stop with the red herrings.\n\nThe \"mental model\" of staging area is an area that is used for\npreparation for something, and that's *exactly* what the vast majority\nof users think of the index as a high-level concept.\n\n> Again, let us keep our argument focused on communications with users.\n> Renaming core objects is just going to sow confusion without fixing\n> the user communication issue. That's what I meant the first time I\n> wrote what I quote directly above and I'm sticking to it.\n\nThe vast majority of Git users have absolutely no clue about what's\nthe index. That's why online documentation uses the term \"staging\narea\", so in fact we would be reducing confusion, by a lot.\n\n-- \nFelipe Contreras\n"},{"id":"227047","messageId":"CAMP44s1pcHHpU6bGfReMtdfOv3cUbFaw2fpCFZR_oyogqYFZPA@mail.gmail.com","threadId":"34800","inReplyTo":"CAM9Z-nnjb1wUDH9e=E38QnWvPK44xZqvza77yNLrDpjpj47BKw@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T02:09:28Z","receivedAt":"2013-09-08T02:09:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Sep 3, 2013 at 11:45 PM, Drew Northup wrote:\n> On Thu, Aug 29, 2013 at 6:10 PM, Felipe Contreras\n> wrote:\n>> On Thu, Aug 29, 2013 at 4:55 PM, Drew Northup wrote:\n>>> On Thu, Aug 29, 2013 at 2:37 PM, Junio C Hamano wrote:\n>>>> Felipe Contreras writes:\n>>>>\n>>>>> It has been discussed many times in the past that 'index' is not an\n>>>>> appropriate description for what the high-level user does with it, and\n>>>>> it has been agreed that 'staging area' is the best term.\n>>>>\n>>>> \"add\" is the verb, not \"index\" (which is a noun that refers\n>>>> to the thing that keeps track of what will be written as a tree to\n>>>> be committed next).\n>>>>\n>>>> And it will stay that way.\n>\n>>> I agree with Junio.\n>>\n>> All right, you are the only person (presumably other than Junio) that\n>> thinks \"index\" is the right name for what high-level users should be\n>> familiar with.\n>\n> If that were true it would never have gotten that name.\n\nThis is fallacious on so many levels. First, there's the concept of\nlegacy; what the developers of today think, is different than what the\ndevelopers of the past did, there might be more, there might be less,\nthere might be different people, or they might have changed their\nmind, so what old developers thought doesn't reflect what the\ndevelopers today think. Second, there's this thing called \"idea\", and\nnobody is born with all the ideas in the world and history; ideas\npresent themselves, and if nobody chose the new term, it might have\nbeen because they simply didn't think about it. Third, they might have\nnot thought enough about the name in the first place, they thought\n\"index\" was good enough, and could be fixed later if need be. Fourth,\nonly the developers were involved in picking the name, not users, so\nwhat the vast majority of users thought didn't factor into the name.\n\nSo yeah, you are totally wrong.\n\n> \"Add\" is the verb, as we are adding a snapshot.\n\nAdd a snapshot to where? To the repository? To a temporary stash? To\nan online location.\n\nThe concept of \"adding a snapshot\" is meaningless.\n\n> New users don't care how that works\n> for the most part. Just telling them \"it keeps track of it itself\" is\n> usually good enough.\n\nEverything in a computer \"keeps track of it itself\", that's what a Von\nNeumann computer does, because it has memory. When you type a\ncharacter it's kept in track, when you save a file it's kept in track.\n\nKnowing that something \"is kept in track\" is not useful at all.\n\n> If the user is asking for more detail at that\n> point it is probably because he isn't as much interested in how to use\n> it as he is in how it works.\n\nWrong. The user might be interested in knowing what the hell you are\ntalking about.\n\nAdding what to what, and for what purpose.\n\n> At that point we're better off just\n> giving him the actual explanation instead of getting caught up in the\n> staging area vs index fight (which seems odd to me as the index\n> contains the entries which act as a \"staging area\"--a superset /\n> subset relation).\n\nWrong. An index has absolutely nothing to do with a staging area. I\nalready explained multiple times the difference; an index is\ninformation used to quickly find things, a staging area is used to put\nthings in preparation of something.\n\nEven we are to use the index, the user needs to know what is being\nindexed to what, for example, in a book index, words are being indexed\nto their page numbers. It turns out we can't do that, because\ntechnically Git does not have an index, but rather a manifest, or a\nregistry, or more generally, working tree metadata.\n\nBut that is not relevant, because we don't need to explain what each\nevery field in .git/index is, and it's binary format is, all we need\nto do is explain what it's used for; it's used to prepare the contents\nof the next commit, in other words; it's used as a staging area.\n\nSo when you \"add to the staging area\" you know what you add, to what,\nand for what purpose.\n\n>>> We add content snapshots to the index of content (creating\n>>> \"temporary\"--they will be garbage collected eventually if they become\n>>> orphans--objects into the store at the same time). We build commits\n>>> from those snapshots (in whole or in part, typically only using the\n>>> most recent snapshots of new things added to the index) and save those\n>>> in the object store with the content and tree objects. Sometimes we\n>>> create tag objects to record something special about commits, trees,\n>>> and content blobs.\n>>>\n>>> That's the real model (with some rough edges). Explaining what that\n>>> has to do with distributed version control is the hard part.\n>>\n>> The user doesn't need to know the format of the index, or the packs,\n>> in fact, they don't even need to know the index or packs even exist.\n>\n> I never implied that the end user does need to know these things.\n> (Note the use of \"We\"--as in \"we who are having this conversation.\")\n\nWe who are having this conversation are irrelevant. Stop with the red herrings.\n\nWe are talking about the vast majority of users and what's best for *them*.\n\n>> All the user needs to know about this is that there's an area where\n>> contents of the next commit are being prepared, and \"staging area\" is\n>> the best name for that mental area. How that area is actually\n>> implemented (the index) is not relevant to the user.\n>\n> Part of what I am arguing is that the mental area doesn't need to\n> exist at all. The \"staging area\" is a part of the index.\n\nAgain, the term \"index\" and the term \"staging area\" in the English\nlanguage have absolutely nothing to do one with the other.\n\n>> Everyone agrees on that, except you, and possibly Junio.\n>\n> We don't have enough information to say that. Seriously, this is\n> nowhere near as certain as climate change.\n\nShow me a single person except you and Junio that doesn't like the\nterm \"staging area\". Until you do, the claim remains; virtually\neveryone agrees.\n\n-- \nFelipe Contreras\n"},{"id":"227100","messageId":"B771340AAC04409CB0EF716FE6FC1C88@PhilipOakley","threadId":"34800","inReplyTo":"CAMP44s1j+ayX=cy7QJ7WXdiD9P1M6n7NgNk=oGuv1XC=dqMXVA@mail.gmail.com","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-09-08T07:49:12Z","receivedAt":"2013-09-08T07:49:12Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Sunday, September 08, 2013 2:33 AM\n[snip...]\n> The snapshot concept is totally orthogonal from the staging area\n> concept. Git works in snapshots, which are frozen images of how the\n> content tree was at a certain point in time; IOW; a commit.\n\n(I feel that) In most peoples minds the need for a staging area, and the \nuse of snapshots, are related. Part of that relationship, often not \nnoticed by those folks, is that they are 'orthogonal' to *each other*. \nThus orthogonality means both un-related, and related at the same time \n(aren't we humans peculiar!). They are cleaved to each other.\n\nWhen trying to explain staging/index I tend to use the analogy of an old \nstyle office (I am almost that old) where one has an In tray and an Out \ntray on one's desk (and one parked WIP for lunch time desk tidy), and \nthe staging area is the basket at the end marked 'For Filing'. When the \n'For Filing' basket is ready, one called the filing clerk to dictate the \ncover note and away it went, commited to some remote filing repository. \nOh how things have changed ;-)\n\n>\n> _How_ that snapshot is created is an entirely different topic, and the\n> staging area is a tool to create the desired snapshots. The user might\n> decide to never use that tool (i.e. always run git commit -a), but the\n> concept of snapshots remain. So, clearly, one concept has absolutely\n> nothing to do with the other.\n>\n\nThe point would be that we allow a particular snapshot to be selected, \nand that the git commit -a is but one (common) method. Commit -a is like \njumping in the car for a quick trip to the shops, while the selective \nstaging of content is like packing for a holiday.\n"},{"id":"227118","messageId":"CAMP44s2ANuLL_gPrn8Od3nwQimd+JQASW4wF-xVJRF0eA+WkRA@mail.gmail.com","threadId":"34800","inReplyTo":"B771340AAC04409CB0EF716FE6FC1C88@PhilipOakley","subject":"Re: Officially start moving to the term 'staging area'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T09:27:50Z","receivedAt":"2013-09-08T09:27:50Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> Sent: Sunday, September 08, 2013 2:33 AM\n> [snip...]\n>\n>> The snapshot concept is totally orthogonal from the staging area\n>> concept. Git works in snapshots, which are frozen images of how the\n>> content tree was at a certain point in time; IOW; a commit.\n>\n>\n> (I feel that) In most peoples minds the need for a staging area, and the use\n> of snapshots, are related. Part of that relationship, often not noticed by\n> those folks, is that they are 'orthogonal' to *each other*. Thus\n> orthogonality means both un-related, and related at the same time (aren't we\n> humans peculiar!). They are cleaved to each other.\n\nNot really. You can argue that a movie is a sequence of snapshots, 24\nof them per second, but most people don't think of it that way. You\ncan also argue that every change you do on a file is a snapshot, but\nagain, people don't think of it that way. Yes, you can argue that the\nindex is a snapshot, but it doesn't help to think of it that way. And\nif you try to argue that way, then every waking moment is a snapshot,\nwhat is NOT a snapshot?\n\nThe useful concept of snapshot is a moment in time stored for\nposterity, in that sense a photo is a snapshot, a backup is a\nsnapshot, and a commit is a snapshot, but the staging area is not,\nbecause it will be gone.\n\nIn fact, I just thought of another concept; a draft.\n\n> When trying to explain staging/index I tend to use the analogy of an old\n> style office (I am almost that old) where one has an In tray and an Out tray\n> on one's desk (and one parked WIP for lunch time desk tidy), and the staging\n> area is the basket at the end marked 'For Filing'. When the 'For Filing'\n> basket is ready, one called the filing clerk to dictate the cover note and\n> away it went, commited to some remote filing repository. Oh how things have\n> changed ;-)\n\nBut that doesn't work well. You didn't add and remove things for the\n'For Filing' as you worked, did you? Even if it did work, I don't\nthink it would be particularly useful to most people today.\n\nI think a much more fitting analogy is a mail draft; you add and\nremove things, change them, review, you can take as much time as you\nwant, and at the end of the day you can discard the whole thing.\nNothing gets done until you press 'send', which is analogous to\n'commit'.\n\n>> _How_ that snapshot is created is an entirely different topic, and the\n>> staging area is a tool to create the desired snapshots. The user might\n>> decide to never use that tool (i.e. always run git commit -a), but the\n>> concept of snapshots remain. So, clearly, one concept has absolutely\n>> nothing to do with the other.\n>>\n>\n> The point would be that we allow a particular snapshot to be selected, and\n> that the git commit -a is but one (common) method. Commit -a is like jumping\n> in the car for a quick trip to the shops, while the selective staging of\n> content is like packing for a holiday.\n\nI still don't see it. When you do 'git commit' you don't have an array\nof snapshots to choose from, you just have one, and it's not\nparticularly static, as you can add and remove things from it, so it's\nnot really a snapshot of your working directory even, because you can\nadd things that where never there.\n\nAnd then if the staging area is a snapshot, then what is a commit?\nAnother snapshot? Then what is the difference between the two? One is\npermanent and the other temporary? Well, then saying \"snapshot\"\nwouldn't be enough to describe the staging area, you would need to say\n\"preliminary snapshot\", which doesn't really make sense, as those are\ncalled previews, not snapshots. But why bother with \"snapshot\", we can\nuse \"preliminary commit\". But again, it sounds weird using the word\ncommit to something that can and is meant to change, unlike git\ncommits, and incidentally, unlike snapshots.\n\n-- \nFelipe Contreras\n"},{"id":"227165","messageId":"CAMP44s01CqJoDupmiD4K85Y1p9jF0PrT3v5owrS5WQkKQ-kkXA@mail.gmail.com","threadId":"34800","inReplyTo":"CALkWK0=P0xZAk95Jmw9mRUCwPQP7NmVHsuPaWNg+D2v3wP9=-w@mail.gmail.com","subject":"Re: [PATCH 1/3] reset: add --stage and --work options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-08T22:55:24Z","receivedAt":"2013-09-08T22:55:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 5:05 PM, Ramkumar Ramachandra wrote:\n> Felipe Contreras wrote:\n>>\n>> @@ -290,6 +294,22 @@ int cmd_reset(int argc, const char **argv, const char\n>> *prefix)\n>> hashcpy(sha1, tree->object.sha1);\n>> }\n>>\n>> + if (stage >= 0 || working_tree >= 0) {\n>> + if (reset_type != NONE)\n>> + die(_(\"--{stage,work} are incompatible with\n>> --{hard,mixed,soft,merge}\"));\n>> +\n>> + if (working_tree == 1) {\n>> + if (stage == 0)\n>> + die(_(\"--no-stage doesn't make sense with\n>> --work\"));\n>> + reset_type = HARD;\n>> + } else {\n>> + if (stage == 1)\n>> + reset_type = NONE;\n>> + else\n>> + reset_type = SOFT;\n>> + }\n>> + }\n>> +\n>\n>\n> Not making sense at this point. Why does --stage set a reset_type?\n\nYeah, we would need another patch to cleanup the variable names, but\nfor now it's better to minimize the changes.\n\nEither way it doesn't matter because Junio is determined to stand\nalone versus the rest of the world in this issue.\n\n-- \nFelipe Contreras\n"},{"id":"227174","messageId":"CALkWK0kSBXCmCcDJ0p+CJMF4V1+RC2s_toRY_wNnZJOA164HNA@mail.gmail.com","threadId":"34800","inReplyTo":"CAMP44s01CqJoDupmiD4K85Y1p9jF0PrT3v5owrS5WQkKQ-kkXA@mail.gmail.com","subject":"Re: [PATCH 1/3] reset: add --stage and --work options","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-09-09T00:15:58Z","receivedAt":"2013-09-09T00:15:58Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Felipe Contreras wrote:\n> Either way it doesn't matter because Junio is determined to stand\n> alone versus the rest of the world in this issue.\n\nWhich is why he's the maintainer. Send in incremental updates, and he\nshould be fine.\n"},{"id":"227180","messageId":"CAMP44s3rc9nTCbez-jcvfV18g1ded5pfUjb_uCyJpYD86vZBvg@mail.gmail.com","threadId":"34800","inReplyTo":"CALkWK0kSBXCmCcDJ0p+CJMF4V1+RC2s_toRY_wNnZJOA164HNA@mail.gmail.com","subject":"Re: [PATCH 1/3] reset: add --stage and --work options","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-09-09T00:39:22Z","receivedAt":"2013-09-09T00:39:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Sep 8, 2013 at 7:15 PM, Ramkumar Ramachandra wrote:\n> Felipe Contreras wrote:\n>> Either way it doesn't matter because Junio is determined to stand\n>> alone versus the rest of the world in this issue.\n>\n> Which is why he's the maintainer. Send in incremental updates, and he\n> should be fine.\n\nI mean he is against the whole \"index\" -> \"staging area\" concept\nagainst everybody else, so adding --stage options is out of the\nquestion for him. So he is ignoring the whole patch series.\n\n-- \nFelipe Contreras\n"}]}