{"thread":{"id":"18735","subject":"[RFC/PATCH 1/2] git: remote stage","startedAt":"2009-04-05T13:48:49Z","lastAt":"2009-04-07T15:01:17Z","messageCount":38,"participants":["Felipe Contreras","Junio C Hamano","Nicolas Sebrecht","Jay Soffian","Markus Heidelberg","Björn Steinbrink","Sverre Rabbelier","Johannes Schindelin","David Aguilar","David Kågedal","Matthieu Moy","Stefan Karpinski","Octavio Alvarez"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"110415","messageId":"1238939331-10152-1-git-send-email-felipe.contreras@gmail.com","threadId":"18735","inReplyTo":null,"subject":"[RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T13:48:49Z","receivedAt":"2009-04-05T13:48:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThe 'stage' is probably the most novel-yet-missunderstood feature of git, and\nsomehow the user interface is not exploiting it properly, even to the point\nwhere it doesn't even have a consistent name (stage, index, cache, etc)\n\nThis patch series is one approach that has been working reasonably well for me,\nwhich is to replace the 'git stage' command to map different actions that can\nbe executed with it.\n\nFor example 'git stage diff' is more natural (at least to me) than 'git diff\n--cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.\n\nThis is the list of actions I've mapped:\n\n * add: git stage = git stage add (git add)\n * rm: (git rm --cached)\n * diff: (git rm --cached)\n * import: stage all files; modified, deleted, new\n * ls: (git ls-files --stage)\n\nFelipe Contreras (2):\n  git: remote stage\n  Add new 'git stage' script\n\n Documentation/git-stage.txt |   19 -------------------\n Makefile                    |    2 +-\n git-stage.sh                |   28 ++++++++++++++++++++++++++++\n git.c                       |    1 -\n 4 files changed, 29 insertions(+), 21 deletions(-)\n delete mode 100644 Documentation/git-stage.txt\n create mode 100644 git-stage.sh\n"},{"id":"110413","messageId":"1238939331-10152-2-git-send-email-felipe.contreras@gmail.com","threadId":"18735","inReplyTo":"1238939331-10152-1-git-send-email-felipe.contreras@gmail.com","subject":"[RFC/PATCH 1/2] git: remote stage","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T13:48:50Z","receivedAt":"2009-04-05T13:48:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n Documentation/git-stage.txt |   19 -------------------\n Makefile                    |    1 -\n git.c                       |    1 -\n 3 files changed, 0 insertions(+), 21 deletions(-)\n delete mode 100644 Documentation/git-stage.txt\n\ndiff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt\ndeleted file mode 100644\nindex 7f251a5..0000000\n--- a/Documentation/git-stage.txt\n+++ /dev/null\n@@ -1,19 +0,0 @@\n-git-stage(1)\n-==============\n-\n-NAME\n-----\n-git-stage - Add file contents to the staging area\n-\n-\n-SYNOPSIS\n---------\n-[verse]\n-'git stage' args...\n-\n-\n-DESCRIPTION\n------------\n-\n-This is a synonym for linkgit:git-add[1].  Please refer to the\n-documentation of that command.\ndiff --git a/Makefile b/Makefile\nindex 7867eac..0c3de6b 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -345,7 +345,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 \ndiff --git a/git.c b/git.c\nindex c2b181e..ebc3ccb 100644\n--- a/git.c\n+++ b/git.c\n@@ -267,7 +267,6 @@ static void handle_internal_command(int argc, const char **argv)\n \tconst char *cmd = argv[0];\n \tstatic struct cmd_struct commands[] = {\n \t\t{ \"add\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"stage\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n \t\t{ \"annotate\", cmd_annotate, RUN_SETUP },\n \t\t{ \"apply\", cmd_apply },\n \t\t{ \"archive\", cmd_archive },\n-- \n1.6.2.2.406.g45db3f\n"},{"id":"110414","messageId":"1238939331-10152-3-git-send-email-felipe.contreras@gmail.com","threadId":"18735","inReplyTo":"1238939331-10152-2-git-send-email-felipe.contreras@gmail.com","subject":"[RFC/PATCH 2/2] Add new 'git stage' script","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T13:48:51Z","receivedAt":"2009-04-05T13:48:51Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n Makefile     |    1 +\n git-stage.sh |   28 ++++++++++++++++++++++++++++\n 2 files changed, 29 insertions(+), 0 deletions(-)\n create mode 100644 git-stage.sh\n\ndiff --git a/Makefile b/Makefile\nindex 0c3de6b..a1837fc 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -291,6 +291,7 @@ SCRIPT_SH += git-rebase.sh\n SCRIPT_SH += git-repack.sh\n SCRIPT_SH += git-request-pull.sh\n SCRIPT_SH += git-sh-setup.sh\n+SCRIPT_SH += git-stage.sh\n SCRIPT_SH += git-stash.sh\n SCRIPT_SH += git-submodule.sh\n SCRIPT_SH += git-web--browse.sh\ndiff --git a/git-stage.sh b/git-stage.sh\nnew file mode 100644\nindex 0000000..a5b3ad8\n--- /dev/null\n+++ b/git-stage.sh\n@@ -0,0 +1,28 @@\n+#!/bin/sh\n+\n+case \"$1\" in\n+add)\n+        shift\n+        git add $@\n+        ;;\n+rm)\n+        shift\n+        git rm --cached $@\n+        ;;\n+diff)\n+        shift\n+        git diff --cached $@\n+        ;;\n+import)\n+        shift\n+        git ls-files --modified --others --exclude-standard -z | \\\n+        git update-index --add --remove -z --stdin\n+        ;;\n+ls)\n+        shift\n+        git ls-files --stage $@\n+        ;;\n+*)\n+        git add $@\n+        ;;\n+esac\n-- \n1.6.2.2.406.g45db3f\n"},{"id":"110427","messageId":"7vmyausz3h.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"1238939331-10152-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-05T19:02:42Z","receivedAt":"2009-04-05T19:02:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> This is the list of actions I've mapped:\n>\n>  * add: git stage = git stage add (git add)\n>  * rm: (git rm --cached)\n>  * diff: (git rm --cached)\n>  * import: stage all files; modified, deleted, new\n>  * ls: (git ls-files --stage)\n\nI do not think these are good ideas at all, as it just spreads more\nconfusion, not less.\n"},{"id":"110433","messageId":"94a0d4530904051228m4e57ec90y810dded41f47e443@mail.gmail.com","threadId":"18735","inReplyTo":"7vmyausz3h.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T19:28:24Z","receivedAt":"2009-04-05T19:28:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> This is the list of actions I've mapped:\n>>\n>>  * add: git stage = git stage add (git add)\n>>  * rm: (git rm --cached)\n>>  * diff: (git rm --cached)\n>>  * import: stage all files; modified, deleted, new\n>>  * ls: (git ls-files --stage)\n>\n> I do not think these are good ideas at all, as it just spreads more\n> confusion, not less.\n\nDo you agree that there's already a lot of confusion? (stage, cache,\nindex, etc.)\n\nAnd do you agree that many git newbies don't use the stage? Actually\nmost of them don't even know what it is, and just do \"git commit -a\".\n\nIf so, how do you think these issues should be handled?\n\n-- \nFelipe Contreras\n"},{"id":"110437","messageId":"7v7i1yrj3t.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"94a0d4530904051228m4e57ec90y810dded41f47e443@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-05T19:33:26Z","receivedAt":"2009-04-05T19:33:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>> This is the list of actions I've mapped:\n>>>\n>>>  * add: git stage = git stage add (git add)\n>>>  * rm: (git rm --cached)\n>>>  * diff: (git rm --cached)\n>>>  * import: stage all files; modified, deleted, new\n>>>  * ls: (git ls-files --stage)\n>>\n>> I do not think these are good ideas at all, as it just spreads more\n>> confusion, not less.\n>\n> Do you agree that there's already a lot of confusion? (stage, cache,\n> index, etc.)\n>\n> And do you agree that many git newbies don't use the stage? Actually\n> most of them don't even know what it is, and just do \"git commit -a\".\n>\n> If so, how do you think these issues should be handled?\n\nPerhaps not spreading \"stage\" even wider?  That is the newest confusing\nterm that caused the most harm.\n"},{"id":"110438","messageId":"20090405193448.GB12929@vidovic","threadId":"18735","inReplyTo":"94a0d4530904051228m4e57ec90y810dded41f47e443@mail.gmail.com","subject":"[RFC/PATCH 0/2] Re: New 'stage' command","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s-dev@laposte.net","sentAt":"2009-04-05T19:34:48Z","receivedAt":"2009-04-05T19:34:48Z","isPatch":true,"sender":{"key":"nicolas.s-dev@laposte.net","avatar":null},"body":"On Sun, Apr 05, 2009 at 10:28:24PM +0300, Felipe Contreras wrote:\n\n> > I do not think these are good ideas at all, as it just spreads more\n> > confusion, not less.\n\nAgreed.\n\n> Do you agree that there's already a lot of confusion? (stage, cache,\n> index, etc.)\n> \n> And do you agree that many git newbies don't use the stage? Actually\n> most of them don't even know what it is, and just do \"git commit -a\".\n> \n> If so, how do you think these issues should be handled?\n\nRead the documentation? Read tutorials?\n\n-- \nNicolas Sebrecht\n"},{"id":"110442","messageId":"7vzleuq3ci.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"7v7i1yrj3t.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-05T19:59:09Z","receivedAt":"2009-04-05T19:59:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>\n>>>> This is the list of actions I've mapped:\n>>>>\n>>>>  * add: git stage = git stage add (git add)\n>>>>  * rm: (git rm --cached)\n>>>>  * diff: (git rm --cached)\n>>>>  * import: stage all files; modified, deleted, new\n>>>>  * ls: (git ls-files --stage)\n>>>\n>>> I do not think these are good ideas at all, as it just spreads more\n>>> confusion, not less.\n>>\n>> Do you agree that there's already a lot of confusion? (stage, cache,\n>> index, etc.)\n>>\n>> And do you agree that many git newbies don't use the stage? Actually\n>> most of them don't even know what it is, and just do \"git commit -a\".\n>>\n>> If so, how do you think these issues should be handled?\n>\n> Perhaps not spreading \"stage\" even wider?  That is the newest confusing\n> term that caused the most harm.\n\nThis probably needs clarification for new people who do not know the\nhistory.\n\nBefore Linus published the very original git, he was designing a system\nthat can work with the tarball+patches workflow, and dircache (which was\nthe name of the .git directory) was a mechanism to give various snapshots\na faster access by using the git object machinery by \"caching\" the result\nof applying sequence of patches to certain point of history.  The file\ninside the .dircache that records the object names that correspond to the\nstate in the work tree state was .dircache/index.\n\nWe've been living with the cache/index, and many user visible actions have\nbeen called in sentences like \"adding contents to the cache\" or \"comparing\nwith the index\" that used cache/index more or less interchangeably.  Later\nwe started to standardizing on the term \"index\" primarily because that is\nthe entity on the filesystem the end user is aware of (as opposed to\n\"cache\" that still live throughout the code).\n\nSome operations however needed to have two modes of operation, one being\nworking on both work tree files and the index and another being working\nonly on the index.  Most of the time, the former was the default (and the\nonly mode implemented) and the latter mode needed an explicit option to\nask for.  --cached is used when you ask them to ignore work tree\n(i.e. \"git apply --cached\", \"git diff --cached\").  Unfortunately apply has\na third variant that works only on the work tree and because it is meant\nas a replacement of GNU patch that works outside a git repository, that\nmode is the default, and you need to ask with \"git apply --index\" to\naffect both the index and the work tree.\n\nIf we were already well into \"standardize on index, not telling the\nend-users about cache\" journey back then, and --cached should have been\ncalled --index-only, but unfortunately the history was the other way\naround.\n\nLater, some outside people started \"git training industry\" without talking\nwith the git development community and started using a new term \"to stage\"\nas a verb to describe \"add to the index\".  Addition of \"git diff --staged\"\nwas supposed to lesson the confusion resulted from this mess, but as we\ncan see from your patch it had a reverse effect.\n\nI do not think \"to stage\" as the name of the _concept_ is a bad thing\nper-se.  But the name of the concept and the command verb (and option\nname) does not have to agree with each other.\n\n    cf. http://gitster.livejournal.com/19427.html\n\nIn retrospect, I think it might have been less problematic if we firmly\nrejected \"stage\" as an option name, but instead renamed the --cached\noption to --index-only and made the former a synonym to the latter to\nreally standardize on \"index\".  I think it still is Ok to use the word \"to\nstage\" to colloquially call the act of \"adding to index\", but if we did\nnot add that to the UI but kept it strictly at the concept level, it would\nhave made the UI less confusing, not more.\n"},{"id":"110454","messageId":"94a0d4530904051341s7e8718c2uced945a16c26670e@mail.gmail.com","threadId":"18735","inReplyTo":"7vzleuq3ci.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T20:41:03Z","receivedAt":"2009-04-05T20:41:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Apr 5, 2009 at 10:59 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>>>\n>>>>> This is the list of actions I've mapped:\n>>>>>\n>>>>>  * add: git stage = git stage add (git add)\n>>>>>  * rm: (git rm --cached)\n>>>>>  * diff: (git rm --cached)\n>>>>>  * import: stage all files; modified, deleted, new\n>>>>>  * ls: (git ls-files --stage)\n>>>>\n>>>> I do not think these are good ideas at all, as it just spreads more\n>>>> confusion, not less.\n>>>\n>>> Do you agree that there's already a lot of confusion? (stage, cache,\n>>> index, etc.)\n>>>\n>>> And do you agree that many git newbies don't use the stage? Actually\n>>> most of them don't even know what it is, and just do \"git commit -a\".\n>>>\n>>> If so, how do you think these issues should be handled?\n>>\n>> Perhaps not spreading \"stage\" even wider?  That is the newest confusing\n>> term that caused the most harm.\n>\n> This probably needs clarification for new people who do not know the\n> history.\n\nThanks for the clarification.\n\n<snip/>\n\nConsider this:\n\n== cache ==\n\nThis word is barely used in the English language, perhaps only used in\ncomputing nowadays. The 'cache' is often referred to a place for\ntemporary storage, the purpose being rapid access. It is usually\ntransparent to the user.\n\nGit uses the term in a completely different manner and the --cached\noption is used in important command such as rm and diff. However,\npeople rarely use the term \"git cache\", probably because it\nimmediately evokes multiple caches for better performances.\n\n== index ==\n\nIt is unclear to me what the word means in English language, but it is\ngenerally used as a list of things, the purpose being for easy\nretrieval.\n\nAgain, git is using the term in a different manner, however it is the\nmost widely used term to identify the concept \"the git index\",\nprobably due to the fact that the word \"index\" evokes a single entity.\nBut for some reason it's not used in any important commands as\n'--index' or '--indexed'.\n\n== stage ==\n\nThe word \"stage\" is used widely in the English language, and it\nimmediately evokes a theatrical stage. Generally, it means a different\n(upper) level.\n\nIn git it is barely used, mostly on the \"documentation industry\"\nprobably because it's easier to understand for most people (even\nnon-native-English speakers).\n\n\nIdeally the term should evoke the concept of a *single* area that has\nno other purpose to differentiate from the contents of the working\ndirectory. Also, the action to add and remove content from this area\nshould sound natural.\n\nThat rules out \"cache\" since \"uncache\" makes no sense. Something\nsimilar happens with \"unindex\", although it doesn't sound completely\nbad. On the other hand \"stage\" and \"unstage\" sound perfectly fine.\n\n> I do not think \"to stage\" as the name of the _concept_ is a bad thing\n> per-se.  But the name of the concept and the command verb (and option\n> name) does not have to agree with each other.\n>\n>    cf. http://gitster.livejournal.com/19427.html\n>\n> In retrospect, I think it might have been less problematic if we firmly\n> rejected \"stage\" as an option name, but instead renamed the --cached\n> option to --index-only and made the former a synonym to the latter to\n> really standardize on \"index\".  I think it still is Ok to use the word \"to\n> stage\" to colloquially call the act of \"adding to index\", but if we did\n> not add that to the UI but kept it strictly at the concept level, it would\n> have made the UI less confusing, not more.\n\nWhy is it so natural to co-relate \"stage\" to \"adding to the index\"?\nWould such a relation make sense outside of the git world? No. It is\nnatural to you because you already know what is the \"git index\"... it\nis a *staging* area for commit preparation, logically it's natural to\nco-relate this area with the action \"to stage\".\n\nPlease note it is not an _indexing_ area, nor a _caching_ area.\n\nI agree that the internal (plumbing) term does not need to match the\nconceptual term (used in documentation, tutorials, etc.), but the\nhigher level (porcelain) term *must* match in order for new comers to\ngrasp it quickly and avoid confusion.\n\nI understand there are historic reasons for the names \"cache\" and\n\"index\" and those should be thought before considering any change.\n\nBut also consider that I'm not proposing any big change... the term\n\"stage\" is already being used, and there's already a \"git stage\"\ncommand. I'm only proposing to add a few more options :)\n\nI would be very pleased if you could at least try the patch for a few\ndays, and try \"git stage diff\" (or \"git s diff\" with an alias). I've\nbecome very fond of \"git s\" \"git s diff\" and \"git s -p -u\".\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"110456","messageId":"76718490904051355p2f92d445j860c56638118a604@mail.gmail.com","threadId":"18735","inReplyTo":"94a0d4530904051341s7e8718c2uced945a16c26670e@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-04-05T20:55:58Z","receivedAt":"2009-04-05T20:55:58Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Apr 5, 2009 at 4:41 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> == stage ==\n>\n> The word \"stage\" is used widely in the English language, and it\n> immediately evokes a theatrical stage. Generally, it means a different\n> (upper) level.\n>\n> In git it is barely used, mostly on the \"documentation industry\"\n> probably because it's easier to understand for most people (even\n> non-native-English speakers).\n\nWould an index by any other name smell as sweet?\n\nhttp://www.merriam-webster.com/dictionary/staging%20area\n\n:-)\n\nj.\n"},{"id":"110472","messageId":"200904052358.53028.markus.heidelberg@web.de","threadId":"18735","inReplyTo":"1238939331-10152-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Markus Heidelberg","fromEmail":"markus.heidelberg@web.de","sentAt":"2009-04-05T21:58:52Z","receivedAt":"2009-04-05T21:58:52Z","isPatch":true,"sender":{"key":"markus.heidelberg@web.de","avatar":"https://avatars.githubusercontent.com/u/6334512?v=4"},"body":"Felipe Contreras, 05.04.2009:\n> For example 'git stage diff' is more natural (at least to me) than 'git diff\n> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.\n\nNot for me. If I want to GET a diff, I want to use a command \"diff\", so\n\"git diff\" is more obvious.\nThe next step is to say WHAT exactly to diff. Therefor options to the\n\"diff\" command are more logically to me from a hierarchic POV. And here\nI don't think options like \"--cached\" or \"sha1..sha2\", despite having\ndifferent style, make any difference.\n\nMarkus\n"},{"id":"110473","messageId":"94a0d4530904051506x5cf7fa09o6b0168a4c440e1f8@mail.gmail.com","threadId":"18735","inReplyTo":"76718490904051355p2f92d445j860c56638118a604@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T22:06:06Z","receivedAt":"2009-04-05T22:06:06Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Apr 5, 2009 at 11:55 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Sun, Apr 5, 2009 at 4:41 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n>> == stage ==\n>>\n>> The word \"stage\" is used widely in the English language, and it\n>> immediately evokes a theatrical stage. Generally, it means a different\n>> (upper) level.\n>>\n>> In git it is barely used, mostly on the \"documentation industry\"\n>> probably because it's easier to understand for most people (even\n>> non-native-English speakers).\n>\n> Would an index by any other name smell as sweet?\n\nYeap, almost. Do you have in mind any other word that would fit?\n\n-- \nFelipe Contreras\n"},{"id":"110479","messageId":"94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com","threadId":"18735","inReplyTo":"200904052358.53028.markus.heidelberg@web.de","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-05T22:35:24Z","receivedAt":"2009-04-05T22:35:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg\n<markus.heidelberg@web.de> wrote:\n> Felipe Contreras, 05.04.2009:\n>> For example 'git stage diff' is more natural (at least to me) than 'git diff\n>> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.\n>\n> Not for me. If I want to GET a diff, I want to use a command \"diff\", so\n> \"git diff\" is more obvious.\n> The next step is to say WHAT exactly to diff. Therefor options to the\n> \"diff\" command are more logically to me from a hierarchic POV. And here\n> I don't think options like \"--cached\" or \"sha1..sha2\", despite having\n> different style, make any difference.\n\nWell, it's a matter of preference, and you would not loose the option\nto do it the way you like. But actually, \"git diff --cached\" is a\ndifferent action; you can't do \"git diff --cached HEAD^..\" for\nexample.\n\nConsider \"git rm foo.c\" vs \"git rm --cached foo.c\"... both commands\nare removing a file, the only difference is that one is removing from\nthe staging area while the other is removing it from the working\ndirectory. Now think about \"git branch -d bar\", following the \"first I\nspecify the action, and then the object\" thinking, would it make sense\nto have \"git rm --branch bar\"? Probably not; if you want to do stuff\nwith branches, you use \"git branch\", similarly, if you want to do\nstuff with the staging area, why not use \"git stage\"?\n\n-- \nFelipe Contreras\n"},{"id":"110482","messageId":"20090405230655.GB20356@atjola.homenet","threadId":"18735","inReplyTo":"94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-04-05T23:06:55Z","receivedAt":"2009-04-05T23:06:55Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:\n> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg\n> <markus.heidelberg@web.de> wrote:\n> > Felipe Contreras, 05.04.2009:\n> >> For example 'git stage diff' is more natural (at least to me) than 'git diff\n> >> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.\n> >\n> > Not for me. If I want to GET a diff, I want to use a command \"diff\", so\n> > \"git diff\" is more obvious.\n> > The next step is to say WHAT exactly to diff. Therefor options to the\n> > \"diff\" command are more logically to me from a hierarchic POV. And here\n> > I don't think options like \"--cached\" or \"sha1..sha2\", despite having\n> > different style, make any difference.\n> \n> Well, it's a matter of preference, and you would not loose the option\n> to do it the way you like. But actually, \"git diff --cached\" is a\n> different action; you can't do \"git diff --cached HEAD^..\" for\n> example.\n\nSure you can. It diffs the index against HEAD^\n\n> Consider \"git rm foo.c\" vs \"git rm --cached foo.c\"... both commands\n> are removing a file, the only difference is that one is removing from\n> the staging area while the other is removing it from the working\n> directory.\n\nThe working tree _and_ the index. To delete it only from the working\ntree you need \"rm\", not \"git rm\".\n\n> Now think about \"git branch -d bar\", following the \"first I\n> specify the action, and then the object\" thinking, would it make sense\n> to have \"git rm --branch bar\"? Probably not; if you want to do stuff\n> with branches, you use \"git branch\", similarly, if you want to do\n> stuff with the staging area, why not use \"git stage\"?\n\nIf you're going that way, you'll also need \"clone create\", \"working-tree\ngrep\", \"repo/remote fetch/pull/push\", etc.\n\n\"git branch\", \"git tag\", \"git remote\" and maybe \"git status\" are the\n\"outsiders\", in that the commands (in some forms) end up as \"git\n<object> <action>\" form. The rest is \"git <action> <object>\".\n\nSo \"git stage <action>\" would extend the minority, and not lead to\nunification.\n\nBjörn\n"},{"id":"110483","messageId":"200904060117.24810.markus.heidelberg@web.de","threadId":"18735","inReplyTo":"94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Markus Heidelberg","fromEmail":"markus.heidelberg@web.de","sentAt":"2009-04-05T23:17:24Z","receivedAt":"2009-04-05T23:17:24Z","isPatch":true,"sender":{"key":"markus.heidelberg@web.de","avatar":"https://avatars.githubusercontent.com/u/6334512?v=4"},"body":"Felipe Contreras, 06.04.2009:\n> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg\n> <markus.heidelberg@web.de> wrote:\n> > Felipe Contreras, 05.04.2009:\n> >> For example 'git stage diff' is more natural (at least to me) than 'git diff\n> >> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.\n> >\n> > Not for me. If I want to GET a diff, I want to use a command \"diff\", so\n> > \"git diff\" is more obvious.\n> > The next step is to say WHAT exactly to diff. Therefor options to the\n> > \"diff\" command are more logically to me from a hierarchic POV. And here\n> > I don't think options like \"--cached\" or \"sha1..sha2\", despite having\n> > different style, make any difference.\n> \n> Well, it's a matter of preference, and you would not loose the option\n> to do it the way you like.\n\nI know, but that's not the topic.\n\n> But actually, \"git diff --cached\" is a\n> different action; you can't do \"git diff --cached HEAD^..\" for\n> example.\n\nAnd I neither could I do \"git stage diff HEAD^..\"\n\n> Consider \"git rm foo.c\" vs \"git rm --cached foo.c\"... both commands\n> are removing a file, the only difference is that one is removing from\n> the staging area while the other is removing it from the working\n> directory. Now think about \"git branch -d bar\", following the \"first I\n> specify the action, and then the object\" thinking, would it make sense\n> to have \"git rm --branch bar\"? Probably not;\n\nRight, the argumentation with first the action doesn't fly any more.\nI guess it has to be considered what makes sense to have as command.\n\"rm\" (not git-rm) is such a well-known tool for deleting files so it\nprobably doesn't make sense to have a command git-rm-files instead.\n\n> if you want to do stuff\n> with branches, you use \"git branch\", similarly, if you want to do\n> stuff with the staging area, why not use \"git stage\"?\n\nSo git-diff for working with diffs, git-branch for working with\nbranches and git-rm/git-add for working on file level makes sense for\nme. Whether the a command can work with both the working tree and the\nindex doesn't seem to make a difference for me.\n\nMarkus\n"},{"id":"110485","messageId":"fabb9a1e0904051622k66352ea4v542ecd99bd5d9c6@mail.gmail.com","threadId":"18735","inReplyTo":"200904060117.24810.markus.heidelberg@web.de","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-04-05T23:22:41Z","receivedAt":"2009-04-05T23:22:41Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n<markus.heidelberg@web.de> wrote:\n> Felipe Contreras, 06.04.2009:\n>> But actually, \"git diff --cached\" is a\n>> different action; you can't do \"git diff --cached HEAD^..\" for\n>> example.\n>\n> And I neither could I do \"git stage diff HEAD^..\"\n\nI rest my case ;). That's the whole point Felipe is trying to make here.\n$ git diff --cached\n$ git diff HEAD^..\n\nThat's two different modes of operation with the only difference being\na switch ('--cached'), which changes what is, and what is not valid\nafter that.\n\nWhereas with\n$ git stage diff\n\nThere is no confusion that 'HEAD^..' is not a valid argument, as there\nis no command in 'git stage diff' to which it _is_ a valid argument.\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"110486","messageId":"200904060123.58602.markus.heidelberg@web.de","threadId":"18735","inReplyTo":"20090405230655.GB20356@atjola.homenet","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Markus Heidelberg","fromEmail":"markus.heidelberg@web.de","sentAt":"2009-04-05T23:23:58Z","receivedAt":"2009-04-05T23:23:58Z","isPatch":true,"sender":{"key":"markus.heidelberg@web.de","avatar":"https://avatars.githubusercontent.com/u/6334512?v=4"},"body":"Björn Steinbrink, 06.04.2009:\n> On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:\n> > Well, it's a matter of preference, and you would not loose the option\n> > to do it the way you like. But actually, \"git diff --cached\" is a\n> > different action; you can't do \"git diff --cached HEAD^..\" for\n> > example.\n> \n> Sure you can. It diffs the index against HEAD^\n\nNo, note the \"..\"\n\nMarkus\n"},{"id":"110490","messageId":"alpine.DEB.1.00.0904060141190.10279@pacific.mpi-cbg.de","threadId":"18735","inReplyTo":"fabb9a1e0904051622k66352ea4v542ecd99bd5d9c6@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-05T23:45:42Z","receivedAt":"2009-04-05T23:45:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 6 Apr 2009, Sverre Rabbelier wrote:\n\n> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n> <markus.heidelberg@web.de> wrote:\n> > Felipe Contreras, 06.04.2009:\n> >> But actually, \"git diff --cached\" is a different action; you can't do \n> >> \"git diff --cached HEAD^..\" for example.\n> >\n> > And I neither could I do \"git stage diff HEAD^..\"\n> \n> I rest my case ;). That's the whole point Felipe is trying to make here.\n> $ git diff --cached\n> $ git diff HEAD^..\n> \n> [...]\n\nCould you post at some stage what the current state of this discussion is, \nso that people who do not have time to read all those mails, let alone \nfire off 10+ mails per hour, can comment about their view of things?\n\nSo far, it seems that the view of only a handful is represented in that \nthread.\n\nThanks,\nDscho\n"},{"id":"110506","messageId":"20090406032457.GA14758@gmail.com","threadId":"18735","inReplyTo":"fabb9a1e0904051622k66352ea4v542ecd99bd5d9c6@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-04-06T03:24:58Z","receivedAt":"2009-04-06T03:24:58Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On  0, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> Heya,\n> \n> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n> <markus.heidelberg@web.de> wrote:\n> > Felipe Contreras, 06.04.2009:\n> >> But actually, \"git diff --cached\" is a\n> >> different action; you can't do \"git diff --cached HEAD^..\" for\n> >> example.\n> >\n> > And I neither could I do \"git stage diff HEAD^..\"\n> \n> I rest my case ;). That's the whole point Felipe is trying to make here.\n> $ git diff --cached\n> $ git diff HEAD^..\n> \n> That's two different modes of operation with the only difference being\n> a switch ('--cached'), which changes what is, and what is not valid\n> after that.\n> \n> Whereas with\n> $ git stage diff\n> \n> There is no confusion that 'HEAD^..' is not a valid argument, as there\n> is no command in 'git stage diff' to which it _is_ a valid argument.\n\nHello\n\nHere's an interesting email from a while back:\n\nhttp://kerneltrap.org/mailarchive/git/2008/10/29/3857134\n\nThe above mentions the following suggestion:\n\n    git diff STAGE WORKTREE   (like \"git diff\" today)\n    git diff HEAD WORKTREE    (like \"git diff HEAD\" today)\n    git diff WORKTREE HEAD    (like \"git diff -R HEAD\" today)\n    git diff HEAD STAGE       (like \"git diff --cached\" today)\n    git diff commit STAGE     (like \"git diff --cached commit\" today)\n\n\n>From a consistency and usability perspective, the above\nexample seems very appealing because:\n\na) it does not introduce any new commands, and\n\nb) it is consistent with the way git-diff's command-line\n   interface works today.\n\nAll we'd have to do is teach git-diff to special-case\n'STAGE' and 'WORKTREE'.  Now, whether we'd want to do\nthat is a completely different discussion, but I figured I'd\nthrow the old thread out there.\n\n\n-- \n\n\tDavid\n"},{"id":"110513","messageId":"7v63hie4yh.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"20090406032457.GA14758@gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-06T05:17:26Z","receivedAt":"2009-04-06T05:17:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar <davvid@gmail.com> writes:\n\n> On  0, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n>> Heya,\n>> \n>> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n>> <markus.heidelberg@web.de> wrote:\n>> > Felipe Contreras, 06.04.2009:\n>> >> But actually, \"git diff --cached\" is a\n>> >> different action; you can't do \"git diff --cached HEAD^..\" for\n>> >> example.\n>> >\n>> > And I neither could I do \"git stage diff HEAD^..\"\n>> \n>> I rest my case ;). That's the whole point Felipe is trying to make here.\n>> $ git diff --cached\n>> $ git diff HEAD^..\n>> \n>> That's two different modes of operation with the only difference being\n>> a switch ('--cached'), which changes what is, and what is not valid\n>> after that.\n>> \n>> Whereas with\n>> $ git stage diff\n>> \n>> There is no confusion that 'HEAD^..' is not a valid argument, as there\n>> is no command in 'git stage diff' to which it _is_ a valid argument.\n>\n> Hello\n>\n> Here's an interesting email from a while back:\n>\n> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134\n>\n> The above mentions the following suggestion:\n>\n>     git diff STAGE WORKTREE   (like \"git diff\" today)\n>     git diff HEAD WORKTREE    (like \"git diff HEAD\" today)\n>     git diff WORKTREE HEAD    (like \"git diff -R HEAD\" today)\n>     git diff HEAD STAGE       (like \"git diff --cached\" today)\n>     git diff commit STAGE     (like \"git diff --cached commit\" today)\n>\n>\n> From a consistency and usability perspective, the above\n> example seems very appealing because:\n>\n> a) it does not introduce any new commands, and\n>\n> b) it is consistent with the way git-diff's command-line\n>    interface works today.\n>\n> All we'd have to do is teach git-diff to special-case\n> 'STAGE' and 'WORKTREE'.  Now, whether we'd want to do\n> that is a completely different discussion, but I figured I'd\n> throw the old thread out there.\n\nHow would you express operations the current --index option does in such a\nscheme?  Yet another WORKTREEANDTHEINDEX token?\n"},{"id":"110517","messageId":"20090406055301.GA17080@gmail.com","threadId":"18735","inReplyTo":"7v63hie4yh.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-04-06T05:53:01Z","receivedAt":"2009-04-06T05:53:01Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On  0, Junio C Hamano <gitster@pobox.com> wrote:\n> David Aguilar <davvid@gmail.com> writes:\n> \n> > On  0, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> >> Heya,\n> >> \n> >> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n> >> <markus.heidelberg@web.de> wrote:\n> >> > Felipe Contreras, 06.04.2009:\n> >> >> But actually, \"git diff --cached\" is a\n> >> >> different action; you can't do \"git diff --cached HEAD^..\" for\n> >> >> example.\n> >> >\n> >> > And I neither could I do \"git stage diff HEAD^..\"\n> >> \n> >> I rest my case ;). That's the whole point Felipe is trying to make here.\n> >> $ git diff --cached\n> >> $ git diff HEAD^..\n> >> \n> >> That's two different modes of operation with the only difference being\n> >> a switch ('--cached'), which changes what is, and what is not valid\n> >> after that.\n> >> \n> >> Whereas with\n> >> $ git stage diff\n> >> \n> >> There is no confusion that 'HEAD^..' is not a valid argument, as there\n> >> is no command in 'git stage diff' to which it _is_ a valid argument.\n> >\n> > Here's an interesting email from a while back:\n> >\n> > http://kerneltrap.org/mailarchive/git/2008/10/29/3857134\n> >\n> > The above mentions the following suggestion:\n> >\n> >     git diff STAGE WORKTREE   (like \"git diff\" today)\n> >     git diff HEAD WORKTREE    (like \"git diff HEAD\" today)\n> >     git diff WORKTREE HEAD    (like \"git diff -R HEAD\" today)\n> >     git diff HEAD STAGE       (like \"git diff --cached\" today)\n> >     git diff commit STAGE     (like \"git diff --cached commit\" today)\n> >\n> > From a consistency and usability perspective, the above\n> > example seems very appealing because:\n> > ...\n> > All we'd have to do is teach git-diff to special-case\n> > 'STAGE' and 'WORKTREE'.  Now, whether we'd want to do\n> > that is a completely different discussion, but I figured I'd\n> > throw the old thread out there.\n> \n> How would you express operations the current --index option does in such a\n> scheme?  Yet another WORKTREEANDTHEINDEX token?\n\n\nIs it a trick question?\ngit-diff doesn't have an --index option, only --staged.\n\nAh, I know the answer:\n\nhttp://kerneltrap.org/mailarchive/git/2008/11/12/4072144\nhttp://kerneltrap.org/mailarchive/git/2008/11/12/4067114\nhttp://kerneltrap.org/mailarchive/git/2008/11/2/3896104\n\nI did say it *seemed* appealing, not that it actually was ;)\n\n\nAlrighty.. my only purpose was to bring up the old thread\nsince I think many ideas were fleshed out back when\n'git diff --staged' was introduced.\n\nHow useful it is in the context of this discussion about a\nnew 'stage' command is questionable, so I'll shut up now =)\n\n-- \n\n\tDavid\n"},{"id":"110520","messageId":"7vab6ucnkc.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"20090406055301.GA17080@gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-06T06:18:27Z","receivedAt":"2009-04-06T06:18:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar <davvid@gmail.com> writes:\n\n> Ah, I know the answer:\n>\n> http://kerneltrap.org/mailarchive/git/2008/11/12/4072144\n> http://kerneltrap.org/mailarchive/git/2008/11/12/4067114\n> http://kerneltrap.org/mailarchive/git/2008/11/2/3896104\n>\n> I did say it *seemed* appealing, not that it actually was ;)\n\nHeh, I forgot all about that.\n\nWhat is sad about it is that I back then predicted that we will regret\n\"diff --staged\".\n\n  http://kerneltrap.org/mailarchive/git/2008/11/11/4056664\n"},{"id":"110550","messageId":"94a0d4530904060237u6d1cafb6x49999000526ead00@mail.gmail.com","threadId":"18735","inReplyTo":"alpine.DEB.1.00.0904060141190.10279@pacific.mpi-cbg.de","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-06T09:37:32Z","receivedAt":"2009-04-06T09:37:32Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 6, 2009 at 2:45 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Mon, 6 Apr 2009, Sverre Rabbelier wrote:\n>\n>> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg\n>> <markus.heidelberg@web.de> wrote:\n>> > Felipe Contreras, 06.04.2009:\n>> >> But actually, \"git diff --cached\" is a different action; you can't do\n>> >> \"git diff --cached HEAD^..\" for example.\n>> >\n>> > And I neither could I do \"git stage diff HEAD^..\"\n>>\n>> I rest my case ;). That's the whole point Felipe is trying to make here.\n>> $ git diff --cached\n>> $ git diff HEAD^..\n>>\n>> [...]\n>\n> Could you post at some stage what the current state of this discussion is,\n> so that people who do not have time to read all those mails, let alone\n> fire off 10+ mails per hour, can comment about their view of things?\n>\n> So far, it seems that the view of only a handful is represented in that\n> thread.\n\nSo far it seems nobody likes the idea. Junio has explained why things\nare the way they are, but he hasn't answered my arguments, including\nthe fact that this doesn't change anything, it merely adds options to\nan already existing command.\n\nThis is the mail that hasn't been answered yet:\nhttp://article.gmane.org/gmane.comp.version-control.git/115705\n\n-- \nFelipe Contreras\n"},{"id":"110551","messageId":"20090406094815.GC20356@atjola.homenet","threadId":"18735","inReplyTo":"200904060123.58602.markus.heidelberg@web.de","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-04-06T09:48:15Z","receivedAt":"2009-04-06T09:48:15Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.04.06 01:23:58 +0200, Markus Heidelberg wrote:\n> Björn Steinbrink, 06.04.2009:\n> > On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:\n> > > Well, it's a matter of preference, and you would not loose the option\n> > > to do it the way you like. But actually, \"git diff --cached\" is a\n> > > different action; you can't do \"git diff --cached HEAD^..\" for\n> > > example.\n> > \n> > Sure you can. It diffs the index against HEAD^\n> \n> No, note the \"..\"\n\nOh, d'oh... Sorry, and thanks!\n\nBjörn\n"},{"id":"110571","messageId":"871vs5kjfw.fsf@krank.kagedal.org","threadId":"18735","inReplyTo":"7v63hie4yh.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2009-04-06T13:20:19Z","receivedAt":"2009-04-06T13:20:19Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> David Aguilar <davvid@gmail.com> writes:\n>\n>> Hello\n>>\n>> Here's an interesting email from a while back:\n\nThanks, I would have brought it back up myself if you hadn't.\n\n>> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134\n>>\n>> The above mentions the following suggestion:\n>>\n>>     git diff STAGE WORKTREE   (like \"git diff\" today)\n>>     git diff HEAD WORKTREE    (like \"git diff HEAD\" today)\n>>     git diff WORKTREE HEAD    (like \"git diff -R HEAD\" today)\n>>     git diff HEAD STAGE       (like \"git diff --cached\" today)\n>>     git diff commit STAGE     (like \"git diff --cached commit\" today)\n>>\n>>\n>> From a consistency and usability perspective, the above\n>> example seems very appealing because:\n>>\n>> a) it does not introduce any new commands, and\n>>\n>> b) it is consistent with the way git-diff's command-line\n>>    interface works today.\n>>\n>> All we'd have to do is teach git-diff to special-case\n>> 'STAGE' and 'WORKTREE'.  Now, whether we'd want to do\n>> that is a completely different discussion, but I figured I'd\n>> throw the old thread out there.\n>\n> How would you express operations the current --index option does in such a\n> scheme?  Yet another WORKTREEANDTHEINDEX token?\n\nWhat do you mean? This was a suggestion for how git diff should\nwork. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n\nI think this is a basic usability issue for a high-level porcelain\ncommand such as diff. Having the command syntax \"git diff <something>\n<somethingelse>\" makes sure you never wonder what you are\ndiffing. \"git diff --cached\" makes me wonder what the index is diffed\nagainst every time I see it.\n\nWe wouldn't have to use the \"STAGE\" or \"WORKTREE\" names, of course. It\ndoesn't have to look like refspecs even. The last example already has\na syntax that matches the suggestion:\n\n     git diff --cached <commit>\n\nSo, extrapolating this to \"git diff --worktree --cached\" would mean\nwhat \"git diff -R\" means today etc.\n\nThe obvious objection is that \"git diff --cached <foo>\" would mean the\ninverse of \"git diff <foo> --cached\", but maybe that isn't so\nunexpected by the user after all?\n\n-- \nDavid Kågedal\n"},{"id":"110579","messageId":"87vdphj3u3.fsf@krank.kagedal.org","threadId":"18735","inReplyTo":"871vs5kjfw.fsf@krank.kagedal.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2009-04-06T13:42:44Z","receivedAt":"2009-04-06T13:42:44Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"David Kågedal <davidk@lysator.liu.se> writes:\n\n> We wouldn't have to use the \"STAGE\" or \"WORKTREE\" names, of course. It\n> doesn't have to look like refspecs even. The last example already has\n> a syntax that matches the suggestion:\n>\n>      git diff --cached <commit>\n>\n> So, extrapolating this to \"git diff --worktree --cached\" would mean\n> what \"git diff -R\" means today etc.\n\nBTW, I don't really care much about whether it's spelled \"cached\"\n\"index\" \"staged\" or \"dumbledore\". I just want some regularity in the\ndiff command. I'll happily let someone else figure out the taxonomy.\n\n-- \nDavid Kågedal\n"},{"id":"110614","messageId":"7vy6ud4otd.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"871vs5kjfw.fsf@krank.kagedal.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-06T18:30:54Z","receivedAt":"2009-04-06T18:30:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal <davidk@lysator.liu.se> writes:\n\n> What do you mean? This was a suggestion for how git diff should\n> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n\nYou are talking only about \"git diff\".  I am talking about the whole git\nsuite, because you have to worry about how such a proposal would affect\nother parts of the UI.\n\nFor example, what, if anything, should be done to \"git grep --cached\" and\n\"git apply --index\"?  Leave them unchanged and only change \"git diff\"?\n\n> I think this is a basic usability issue for a high-level porcelain\n> command such as diff.\n\nI do not think there is any usability issue.  Why do you think saying\nSTAGE in all capital makes it easier to _use_ instead of saying --cached\n(or --index-only)?  In either way, you need to understand the underlying\nconcept, such as:\n\n - there are three distinct kinds of states: a committed state, the state\n   in the index (aka \"what you have staged so far to the index\"), and the\n   state in your work tree.\n\n - many commands understand that you want to operate on and/or inspect\n   states in one or more of these states.  They default to what is often\n   used (e.g. \"git diff\" compares the index and the work tree, \"git grep\"\n   looks in the work tree, \"git apply\" patches the work tree [*1*]), but\n   you can tell them to use different entities via options and arguments.\n\nHow does it help understanding any of the above to introduce STAGE?\n\nThe only difference I see is that you change \"via options and arguments\"\nto \"via arguments of different kinds, either a real commit object name or\nsome fake token that stands for the index or the work tree state\".\n\nSpelled out more explicitly, the current \"options and arguments\" works\nthis way:\n\n   - when you want to work with a committed state (or more in general,\n     with a tree-ish), you give the name of the commit;\n\n   - when you want to work with the index, you say --cached;\n\n   - when you want to work with both the index and the work tree at the\n     same time, you say --index.\n\n   - for all commands, working with work tree is the default, so there is\n     no --work-tree option (we could add one, if you really want).\n\nand the STAGE would work something like this:\n\n   - when you want to work with a committed state (or more in general,\n     with a tree-ish), you give the name of the commit;\n\n   - when you want to work with the index, you say STAGE; not that you\n     cannot have a ref called STAGE and if you have a file in the work\n     tree whose name is STAGE you need to say \"git command ... -- STAGE\"\n     to name the file, or \"git command ... STAGE --\" to clarify that you\n     do not mean the file but you mean to use the fake toekn STAGE.\n\n   - when you want to work with both the index and the work tree at the\n     same time, you say STAGEANDWORKTREE (the same disambiguation caveat\n     applies).\n\n   - for all commands, working with work tree is the default, but you can\n     still say WORKTREE (the same disambiguation caveat applies).\n\nIf anything, I think these capitalized fake tokens spread more confusion.\n\nSure, \"git diff HEAD STAGED\" and \"git diff HEAD WORKTREE\" may make the\ncommand lines look as if what these fake tokens represent are \"sort of\"\ncommits, but that is only true while you are using a command that has\nmodes to work on the index and/or on the work tree.\n\nThese fake tokens do not work everywhere, and it is not an implementation\nlimit.  Fundamentally they cannot work everywhere.\n\nThink.  What does \"git log STAGE\" mean?  Can you explain why it does not\nmake any sense?\n\nThe user needs to be aware that the index is NOT a commit to understand\nwhy such a command line doesn't make sense _anyway_.\n\nI think it is counterproductive for the learning curve of new people to\nmake these different concepts look as if they belong to the same family by\nusing STAGE (that look too similar to HEAD).  You seem to think it would\nmake it easier for them to learn if these different concepts are not\npresented as different.  But they are different, and if new people start\nwith a false impression that these are \"sort of\" commits, they need to\nunlearn that at some point, and that \"some point\" is not \"advanced use\".\nEven bog standard \"git log\" exposes why hiding the conceptual differences\nbetween these three states does not work.\n\nTeach that different things are different, and express that in the UI.\nThat would avoid the confusion down the line.\n\n\n[Footnote]\n\n*1* \"git apply\" was originally done to replace use of \"GNU patch\" in\nLinus's workflow because \"patch\" was deliberately too lenient, and as\nsuch, it does not look at the index by default.  In a git repository, as\nlong as a patch does not contain creation of new files, this is a good\ndefault, too.  You can \"git apply incoming.patch && git diff -U20\" to see\nwhat the patch does in wider context, for example.  If \"git apply --index\"\nwere the default, the same can be done with \"git diff -U20 HEAD\" and it\nwon't risk forgetting new files.  But it is a huge backward incompatible\nchange that won't happen without deep thought.\n"},{"id":"110620","messageId":"94a0d4530904061213pabd87aj9db577aaa231945c@mail.gmail.com","threadId":"18735","inReplyTo":"7vy6ud4otd.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-06T19:13:26Z","receivedAt":"2009-04-06T19:13:26Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> David Kågedal <davidk@lysator.liu.se> writes:\n>\n>> What do you mean? This was a suggestion for how git diff should\n>> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n>\n> You are talking only about \"git diff\".  I am talking about the whole git\n> suite, because you have to worry about how such a proposal would affect\n> other parts of the UI.\n\nHow do currently do you something like this:\ngit diff HEAD^..STAGE\n\nYou can't.\n\nThis is not an issue for any other git commands, that's why --stage,\n--cache, --index make sense for _other_ commands, not 'git diff'.\n\n-- \nFelipe Contreras\n"},{"id":"110621","messageId":"20090406192514.GI20356@atjola.homenet","threadId":"18735","inReplyTo":"94a0d4530904061213pabd87aj9db577aaa231945c@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-04-06T19:25:14Z","receivedAt":"2009-04-06T19:25:14Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.04.06 22:13:26 +0300, Felipe Contreras wrote:\n> On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> > David Kågedal <davidk@lysator.liu.se> writes:\n> >\n> >> What do you mean? This was a suggestion for how git diff should\n> >> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n> >\n> > You are talking only about \"git diff\".  I am talking about the whole git\n> > suite, because you have to worry about how such a proposal would affect\n> > other parts of the UI.\n> \n> How do currently do you something like this:\n> git diff HEAD^..STAGE\n\ngit diff --cached HEAD^\n\nThe \"hard\" (and pretty weird) one would be \"git diff STAGE..HEAD^\",\nwhich is:\n\ngit diff -R --cached HEAD^\n\nBjörn\n"},{"id":"110629","messageId":"vpqiqlh1p8t.fsf@bauges.imag.fr","threadId":"18735","inReplyTo":"7vy6ud4otd.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-04-06T20:49:54Z","receivedAt":"2009-04-06T20:49:54Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>  - there are three distinct kinds of states: a committed state, the state\n>    in the index (aka \"what you have staged so far to the index\"), and the\n>    state in your work tree.\n>\n>  - many commands understand that you want to operate on and/or inspect\n>    states in one or more of these states.  They default to what is often\n>    used (e.g. \"git diff\" compares the index and the work tree, \"git grep\"\n>    looks in the work tree, \"git apply\" patches the work tree [*1*]), but\n>    you can tell them to use different entities via options and arguments.\n>\n> How does it help understanding any of the above to introduce STAGE?\n\nFor the first, if there are three kinds of states, I would find it\nnatural to have three kinds of ways to talk about these states.\n\nSure, it doesn't change the second, since it makes things more\nexplicit, it doesn't make them more concise.\n\n>    - when you want to work with the index, you say --cached;\n\nBut that doesn't apply to \"git diff\". Both \"git diff\" and \"git diff\n--cached\" work with the index. \"git diff\" works with the index and work\ntree, while \"git diff --cached\" work with the index and HEAD.\n\n>    - when you want to work with both the index and the work tree at the\n>      same time, you say --index.\n\n... which is everything but intuitive. The option name doesn't tell\nthe user what the command is doing. First thing is that with Git, the\nuser has to learn 3 words for one concept (index, cache, staging\narea). And then, he has to learn that although people use \"index\" and\n\"cache\" as synomyms, --index and --cached have different meanings.\nAnd that one can also have a --cache, and that it's possible to have a\n--stage too, but with different meaning.\n\nI can understand the historical reasons, but I think finding a way to\nget rid of this historical terminology mess should be encourraged.\n\n>    - for all commands, working with work tree is the default, so there is\n>      no --work-tree option (we could add one, if you really want).\n\nExcept \"git checkout\", which takes the index by default, and\na commit if specified. It makes sense since checking-out from the\nworking tree doesn't make sense, but it is a special case, and\nlearning the general rules you give doesn't tell the user what \"git\ncheckout\" does.\n\nExcept \"git ls-files\", too. And I may have missed some.\n\nSee, you complain about special cases with the proposal, but the\ncurrent UI _has_ tons of special cases like this.\n\n> and the STAGE would work something like this:\n>\n>    - when you want to work with a committed state (or more in general,\n>      with a tree-ish), you give the name of the commit;\n\nIt's not just \"I want to work with\". It's also about the role of the\nthings you want to work with.\n\n\"git diff WORKTREE STAGE\" would mean \"diff from the worktree to the\nstaging area\", while \"git diff STAGE WORKTREE\" would mean the other\nway around.\n\n> Think.  What does \"git log STAGE\" mean?  Can you explain why it does not\n> make any sense?\n\nIt could make sense. Actually, gitk does show the work-tree and the\nindex in a way similar to commits. Fundamentally, I don't see a\ndifference between \"git log\" and \"gitk\" except that gitk is graphical.\n\nSure, STAGE and WORKTREE cannot have a commit message, and hardly have\nan author, but I could very well imagine \"git log --stat WORKTREE\"\nshowing roughly what \"git diff --stat; git diff --stat --cached; git\nlog --stat HEAD\" does today. I don't know how usefull this would be,\nbut I wouldn't say it doesn't make sense either.\n\n-- \nMatthieu\n"},{"id":"110644","messageId":"7vfxgl46zz.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"vpqiqlh1p8t.fsf@bauges.imag.fr","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-07T00:55:44Z","receivedAt":"2009-04-07T00:55:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> writes:\n\n> But that doesn't apply to \"git diff\". Both \"git diff\" and \"git diff\n> --cached\" work with the index.\n\nIt is so often used against HEAD that it is the default for --cached mode.\nIf it confuses your students, do not teach them \"git diff --cached\"\nwithout teaching \"git diff --cached HEAD\" first.\n\n> ... which is everything but intuitive. The option name doesn't tell\n> the user what the command is doing.\n\nSurely, I already said that --cached vs --index are not the best words,\ndidn't I?\n\nBut the point was that introducing STAGE and other \"ref-looking tokens\"\nnot only does not help the situation at all, but makes it worse.\n\n> I can understand the historical reasons, but I think finding a way to\n> get rid of this historical terminology mess should be encourraged.\n\nNo, you should aim higher, if you are trying to change things.\n\nFind a way to convey the concepts better, and come up with a way (i.e. set\nof options---as I already explained why ref looking tokens is inferiour\nthan explicit options) that does not break the backward compatibility, and\nhelp new people learn.  I am not interested in the \"ref-looking tokens\"\nbecause they fail the latter test.\n\n>>    - for all commands, working with work tree is the default, so there is\n>>      no --work-tree option (we could add one, if you really want).\n>\n> Except \"git checkout\", which takes the index by default, and\n> a commit if specified. It makes sense since checking-out from the\n> working tree doesn't make sense,...\n\nYou say \"except X\" but you need to qualify \"but that default makes sense\nfor X\".  I'd say that is true for all X---so you are saying the default is\nsensible, which is good.\n\n> Except \"git ls-files\", too....\n\nIt is a plumbing that only works with the index.  What's your problem?\n\n> See, you complain about special cases with the proposal, but the\n> current UI _has_ tons of special cases like this.\n\nThe two example you quoted above are neither tons nor special cases.  And\nI am not saying that \"ref-looking tokens are bad because there are special\ncases\" anyway.\n"},{"id":"110645","messageId":"7v8wmd46p9.fsf@gitster.siamese.dyndns.org","threadId":"18735","inReplyTo":"87skkligzb.fsf@krank.kagedal.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-07T01:02:10Z","receivedAt":"2009-04-07T01:02:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal <davidk@lysator.liu.se> writes:\n\n>>    - when you want to work with both the index and the work tree at the\n>>      same time, you say STAGEANDWORKTREE (the same disambiguation caveat\n>>      applies).\n>\n> No, where did this come from?\n\n\"git apply STAGEANDWORKTREE this.patch\".  I do not want \"for diff you can\nuse these metavariables to name two things compared, but you can do so\nonly for diff\".\n\n>> Think.  What does \"git log STAGE\" mean?  Can you explain why it does not\n>> make any sense?\n>\n> As I already explained, you read way to much into my message.\n\nI think the fundamental difference between us is that you are too attached\nto the notion of \"for diff you can use these metavariables to name two\nthings compared\".  That by itself looks very nice if you only look at the\ndiff command line, but I do not want \"but you can do so only for diff, so\nyou have to unlearn the metavariables and do thing in different ways for\nother commands\" part.\n"},{"id":"110647","messageId":"d4bc1a2a0904061836t295d5cf8w39500d63acfc80ab@mail.gmail.com","threadId":"18735","inReplyTo":"7vy6ud4otd.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Stefan Karpinski","fromEmail":"stefan.karpinski@gmail.com","sentAt":"2009-04-07T01:36:06Z","receivedAt":"2009-04-07T01:36:06Z","isPatch":true,"sender":{"key":"stefan.karpinski@gmail.com","avatar":"https://gravatar.com/avatar/780cfb8dd7d7dc749d7276a4ca2ec24e7f0482cfce509717c5ddd165fd2cc9d9?d=mp&s=160"},"body":"On Mon, Apr 6, 2009 at 11:30 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> David Kågedal <davidk@lysator.liu.se> writes:\n>\n>> What do you mean? This was a suggestion for how git diff should\n>> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n>\n> You are talking only about \"git diff\".  I am talking about the whole git\n> suite, because you have to worry about how such a proposal would affect\n> other parts of the UI.\n>\n> For example, what, if anything, should be done to \"git grep --cached\" and\n> \"git apply --index\"?  Leave them unchanged and only change \"git diff\"?\n>\n>> I think this is a basic usability issue for a high-level porcelain\n>> command such as diff.\n>\n> I do not think there is any usability issue.  Why do you think saying\n> STAGE in all capital makes it easier to _use_ instead of saying --cached\n> (or --index-only)?  In either way, you need to understand the underlying\n> concept, such as:\n\nThere is most definitely a usability issue here. I use git every day\nand I *cannot* for the life of me remember all the inconsistent\nstage-related oddball commands. I have a number of aliases for them\n(similar to what Felipe is proposing) which are the only way I can\nremember them. Whenever I find myself using a git repo without those\naliases, I have to fire up the man pages. Trying to explain all of\nthis to coworkers that use git—honestly, I don't even try to go there.\n"},{"id":"110672","messageId":"op.urz95k0q4oyyg1@localhost.localdomain","threadId":"18735","inReplyTo":"7vy6ud4otd.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Octavio Alvarez","fromEmail":"alvarezp@alvarezp.ods.org","sentAt":"2009-04-07T07:38:18Z","receivedAt":"2009-04-07T07:38:18Z","isPatch":true,"sender":{"key":"alvarezp@alvarezp.ods.org","avatar":null},"body":"On Mon, 06 Apr 2009 11:30:54 -0700, Junio C Hamano <gitster@pobox.com> wrote:\n>    - when you want to work with the index, you say --cached;\n>\n>    - when you want to work with both the index and the work tree at the\n>      same time, you say --index.\n\nThis is where I also think the options are messed up.\n\nIf I want to work with the \"index\", shouldn't I use... uhh... \"--index\"?\n\nIf I want to work with both, shouldn't I use something like \"--both\"?\n\n\"And if --index works with the workcopy and index, will --cache use both,\nthe workcopy and the cache?\"\n\nTo a new user like me, these options don't look like they refer to different\nactions, but to different existing things. Those options say that there is\nan index, and there is a cache.\n\n(Now I learned all of this through reading the docs which is not hard, but\nreading this from the man pages is not intuitive at all.)\n"},{"id":"110687","messageId":"op.ur0czewh4oyyg1@localhost.localdomain","threadId":"18735","inReplyTo":"7v8wmd46p9.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Octavio Alvarez","fromEmail":"alvarezp@alvarezp.ods.org","sentAt":"2009-04-07T08:39:04Z","receivedAt":"2009-04-07T08:39:04Z","isPatch":true,"sender":{"key":"alvarezp@alvarezp.ods.org","avatar":null},"body":"On Mon, 06 Apr 2009 18:02:10 -0700, Junio C Hamano <gitster@pobox.com> wrote:\n\n> David Kågedal <davidk@lysator.liu.se> writes:\n>\n>>>    - when you want to work with both the index and the work tree at the\n>>>      same time, you say STAGEANDWORKTREE (the same disambiguation  \n>>> caveat\n>>>      applies).\n>>\n>> No, where did this come from?\n>\n> \"git apply STAGEANDWORKTREE this.patch\".  I do not want \"for diff you can\n> use these metavariables to name two things compared, but you can do so\n> only for diff\".\n\nThat example is broken. git apply doesn't even take an arbitrary treeish.\n\n>>> Think.  What does \"git log STAGE\" mean?  Can you explain why it does  \n>>> not\n>>> make any sense?\n\ngitk actually does this. Even more, gitk shows them in this order:\nSTAGE^ would be HEAD.\nWORKTREE^ would be STAGE.\n\nMakes sense.\n\n(Not that I think git log should do the same.)\n\nThe difference between git diff and git reset is that git diff should take\na range of trees, not a range of commits as parameters. OTOH, git reset\ndoesn't know or care about trees, it needs commits.\n\ngit checkout WORKTREE:file makes sense, even though it is useless, but\nthat's why it git checout STAGE:file makes sense: it should accept any tree\ninstead of a commit.\n\ngit apply doesn't even take commits. It *could* take trees if it\nautomagically created a branch on the commit, though. Either that,\nor git-apply shouldn't exist at all.\n\nIt's similar with git reset. You wouldn't use STAGE or WORKTREE here because\na commit is actually necessary, but according option names like: --stage\n--worktree --both --none are better than --hard, --soft and --mixed.\n\nSo, if the man page for git-reset says \"commit-id\" and the man page for\ngit diff says \"tree-id..tree-id\", I don't see any kind of confusion.\ngit checkout could too. git reset and git log are to say \"commit-id\",\nbut support clearer options.\n\nWORKTREE, STAGE are trees as commits are also trees, but not all trees are\ncommits.\n"},{"id":"110691","messageId":"94a0d4530904070301k62687e2i772637068494ab74@mail.gmail.com","threadId":"18735","inReplyTo":"20090406192514.GI20356@atjola.homenet","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-07T10:01:35Z","receivedAt":"2009-04-07T10:01:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Apr 6, 2009 at 10:25 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> On 2009.04.06 22:13:26 +0300, Felipe Contreras wrote:\n>> On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> > David Kågedal <davidk@lysator.liu.se> writes:\n>> >\n>> >> What do you mean? This was a suggestion for how git diff should\n>> >> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n>> >\n>> > You are talking only about \"git diff\".  I am talking about the whole git\n>> > suite, because you have to worry about how such a proposal would affect\n>> > other parts of the UI.\n>>\n>> How do currently do you something like this:\n>> git diff HEAD^..STAGE\n>\n> git diff --cached HEAD^\n>\n> The \"hard\" (and pretty weird) one would be \"git diff STAGE..HEAD^\",\n> which is:\n>\n> git diff -R --cached HEAD^\n\nSorry, that's what I meant.\n\nSo it's possible, but completely unintuitive, and different from other\nuse cases.\n\n-- \nFelipe Contreras\n"},{"id":"110701","messageId":"alpine.DEB.1.00.0904071443530.6897@intel-tinevez-2-302","threadId":"18735","inReplyTo":"94a0d4530904070301k62687e2i772637068494ab74@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-07T12:45:45Z","receivedAt":"2009-04-07T12:45:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Apr 2009, Felipe Contreras wrote:\n\n> On Mon, Apr 6, 2009 at 10:25 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:\n> > On 2009.04.06 22:13:26 +0300, Felipe Contreras wrote:\n> >> On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> >> > David Kågedal <davidk@lysator.liu.se> writes:\n> >> >\n> >> >> What do you mean? This was a suggestion for how git diff should\n> >> >> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.\n> >> >\n> >> > You are talking only about \"git diff\".  I am talking about the whole git\n> >> > suite, because you have to worry about how such a proposal would affect\n> >> > other parts of the UI.\n> >>\n> >> How do currently do you something like this:\n> >> git diff HEAD^..STAGE\n> >\n> > git diff --cached HEAD^\n> >\n> > The \"hard\" (and pretty weird) one would be \"git diff STAGE..HEAD^\",\n> > which is:\n> >\n> > git diff -R --cached HEAD^\n> \n> Sorry, that's what I meant.\n> \n> So it's possible, but completely unintuitive, and different from other\n> use cases.\n\nAt least it is consistent.\n\nYou are always able to say \"-R\" if you want to have the reverse diff, this \nis commonly known from GNU diff and other diff implementations.\n\nAlso, \"git diff --cached\" is _only_ a shortcut for \"git diff --cached \nHEAD\".  This is yet another proof that you should not teach the shortcuts \nfirst, it _harms_ understanding.\n\nCiao,\nDscho\n"},{"id":"110710","messageId":"op.ur0uofkh4oyyg1@localhost.localdomain","threadId":"18735","inReplyTo":"878wmcj1fs.fsf@krank.kagedal.org","subject":"Re: [RFC/PATCH 0/2] New 'stage' command","fromName":"Octavio Alvarez","fromEmail":"alvarezp@alvarezp.ods.org","sentAt":"2009-04-07T15:01:17Z","receivedAt":"2009-04-07T15:01:17Z","isPatch":true,"sender":{"key":"alvarezp@alvarezp.ods.org","avatar":null},"body":"On Tue, 07 Apr 2009 01:46:47 -0700, David Kågedal <davidk@lysator.liu.se> wrote:\n\n> \"Octavio Alvarez\" <alvarezp@alvarezp.ods.org> writes:\n>\n>> The difference between git diff and git reset is that git diff should  \n>> take\n>> a range of trees, not a range of commits as parameters. OTOH, git reset\n>> doesn't know or care about trees, it needs commits.\n>\n> No, git diff doesn't take a range. It takes two trees (including the\n> work \"tree\" and the index \"tree\"). The A..B syntax is nonsense for git\n> diff, but I believe it supported for historical reasons.\n>\n\nThanks.\n\nI correct by s/range of// but the case persists.\n"}]}