{"thread":{"id":"16082","subject":"[PATCH] git-diff: Add --staged as a synonym for --cached.","startedAt":"2008-10-29T16:15:36Z","lastAt":"2008-11-12T23:42:00Z","messageCount":29,"participants":["David Symonds","Jeff King","Johannes Schindelin","Junio C Hamano","Björn Steinbrink","Avery Pennarun","Miles Bader"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"94192","messageId":"1225296936-1357-1-git-send-email-dsymonds@gmail.com","threadId":"16082","inReplyTo":null,"subject":"[PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-10-29T16:15:36Z","receivedAt":"2008-10-29T16:15:36Z","isPatch":true,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"---\n Consider this as a replacement to the previous git-staged series.\n\n Documentation/git-diff.txt |    1 +\n builtin-diff.c             |    5 +++--\n 2 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt\nindex c53eba5..a2f192f 100644\n--- a/Documentation/git-diff.txt\n+++ b/Documentation/git-diff.txt\n@@ -33,6 +33,7 @@ forced by --no-index.\n \tcommit relative to the named <commit>.  Typically you\n \twould want comparison with the latest commit, so if you\n \tdo not give <commit>, it defaults to HEAD.\n+\t--staged is a synonym of --cached.\n \n 'git diff' [--options] <commit> [--] [<path>...]::\n \ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex 2de5834..7ceceeb 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -118,7 +118,7 @@ static int builtin_diff_index(struct rev_info *revs,\n \tint cached = 0;\n \twhile (1 < argc) {\n \t\tconst char *arg = argv[1];\n-\t\tif (!strcmp(arg, \"--cached\"))\n+\t\tif (!strcmp(arg, \"--cached\") || !strcmp(arg, \"--staged\"))\n \t\t\tcached = 1;\n \t\telse\n \t\t\tusage(builtin_diff_usage);\n@@ -320,7 +320,8 @@ int cmd_diff(int argc, const char **argv, const char *prefix)\n \t\t\tconst char *arg = argv[i];\n \t\t\tif (!strcmp(arg, \"--\"))\n \t\t\t\tbreak;\n-\t\t\telse if (!strcmp(arg, \"--cached\")) {\n+\t\t\telse if (!strcmp(arg, \"--cached\") ||\n+\t\t\t\t !strcmp(arg, \"--staged\")) {\n \t\t\t\tadd_head_to_pending(&rev);\n \t\t\t\tif (!rev.pending.nr)\n \t\t\t\t\tdie(\"No HEAD commit to compare with (yet)\");\n-- \n1.6.0\n"},{"id":"94195","messageId":"20081029164253.GA3172@sigill.intra.peff.net","threadId":"16082","inReplyTo":"1225296936-1357-1-git-send-email-dsymonds@gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-29T16:42:53Z","receivedAt":"2008-10-29T16:42:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 29, 2008 at 09:15:36AM -0700, David Symonds wrote:\n\n>  Consider this as a replacement to the previous git-staged series.\n\nI think this is a much more sensible (actual) approach.\n\n> diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt\n> index c53eba5..a2f192f 100644\n> --- a/Documentation/git-diff.txt\n> +++ b/Documentation/git-diff.txt\n> @@ -33,6 +33,7 @@ forced by --no-index.\n>  \tcommit relative to the named <commit>.  Typically you\n>  \twould want comparison with the latest commit, so if you\n>  \tdo not give <commit>, it defaults to HEAD.\n> +\t--staged is a synonym of --cached.\n\nHmm. I wonder if it would make it more sense to make the \"official\" name\n--staged, and leave --cached forever as a synonym. If the goal is giving\nsane names to end users, then we should probably advertise the sane\nones.\n\nOTOH, maybe it is better to start slow, let people who are doing\ntraining materials mention --staged, and see how that works.\n\n> @@ -118,7 +118,7 @@ static int builtin_diff_index(struct rev_info *revs,\n>  \tint cached = 0;\n>  \twhile (1 < argc) {\n>  \t\tconst char *arg = argv[1];\n> -\t\tif (!strcmp(arg, \"--cached\"))\n> +\t\tif (!strcmp(arg, \"--cached\") || !strcmp(arg, \"--staged\"))\n>  \t\t\tcached = 1;\n>  \t\telse\n>  \t\t\tusage(builtin_diff_usage);\n\nI had to investigate this hunk closely, as it really looks at first\nglance (from the function name, and the fact that there are two hunks,\none here and one for cmd_diff) that this is impacting diff-index\n--cached, but it's not. We just checked --cached in two different places\ninside git-diff (but at least one of them is prefixed by a comment that\nincludes the world \"Eek.\").\n\n-Peff\n"},{"id":"94196","messageId":"ee77f5c20810290950k6d7acfcbt90b6280c290bd532@mail.gmail.com","threadId":"16082","inReplyTo":"20081029164253.GA3172@sigill.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-10-29T16:50:49Z","receivedAt":"2008-10-29T16:50:49Z","isPatch":true,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Wed, Oct 29, 2008 at 9:42 AM, Jeff King <peff@peff.net> wrote:\n\n> Hmm. I wonder if it would make it more sense to make the \"official\" name\n> --staged, and leave --cached forever as a synonym. If the goal is giving\n> sane names to end users, then we should probably advertise the sane\n> ones.\n\nI agree. If there's some consensus, I can make that shift, keeping\n--cached as a backward-compatibility synonym.\n\n\nDave.\n"},{"id":"94198","messageId":"alpine.DEB.1.00.0810291804400.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16082","inReplyTo":"ee77f5c20810290950k6d7acfcbt90b6280c290bd532@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-29T17:06:09Z","receivedAt":"2008-10-29T17:06:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Oct 2008, David Symonds wrote:\n\n> On Wed, Oct 29, 2008 at 9:42 AM, Jeff King <peff@peff.net> wrote:\n> \n> > Hmm. I wonder if it would make it more sense to make the \"official\" \n> > name --staged, and leave --cached forever as a synonym. If the goal is \n> > giving sane names to end users, then we should probably advertise the \n> > sane ones.\n> \n> I agree. If there's some consensus, I can make that shift, keeping \n> --cached as a backward-compatibility synonym.\n\nYes, I would like that, too.\n\nHowever, note that we have to hash out what to do about the convention \nthat --cached traditionally means that only the staging area (formerly \nknown as \"the index\") is affected, while --index means that the command \ntouches the working directory, too.\n\nCiao,\nDscho\n"},{"id":"94200","messageId":"20081029171122.GA12167@sigill.intra.peff.net","threadId":"16082","inReplyTo":"alpine.DEB.1.00.0810291804400.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-29T17:11:22Z","receivedAt":"2008-10-29T17:11:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 29, 2008 at 06:06:09PM +0100, Johannes Schindelin wrote:\n\n> However, note that we have to hash out what to do about the convention \n> that --cached traditionally means that only the staging area (formerly \n> known as \"the index\") is affected, while --index means that the command \n> touches the working directory, too.\n\nIf we assume that we have only the word \"stage\" and variations\navailable, then there aren't too many options.\n\n  only the staging area:\n    --stage-only, --staged-only\n\n  both:\n    --staged (as opposed to --staged-only) --stage-and-worktree (too\n    long), --both (not descriptive enough), --stage-too (yuck)\n\n-Peff\n"},{"id":"94637","messageId":"7vprle1qdl.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"20081029171122.GA12167@sigill.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T08:30:46Z","receivedAt":"2008-11-02T08:30:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> If we assume that we have only the word \"stage\" and variations\n> available, then there aren't too many options.\n>\n>   only the staging area:\n>     --stage-only, --staged-only\n>\n>   both:\n>     --staged (as opposed to --staged-only) --stage-and-worktree (too\n>     long), --both (not descriptive enough), --stage-too (yuck)\n\nA flag \"--staged\" that means \"staged changes and changes in the work tree\"\nis no worse than the current \"--index\".  If we were to shoot for clarity,\nhow about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?\n\nI am actually actively unhappy about the latter, but I like more\ndescriptive --staged-only for the former a lot better.\n"},{"id":"94656","messageId":"20081102123519.GA21251@atjola.homenet","threadId":"16082","inReplyTo":"20081029171122.GA12167@sigill.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-11-02T12:35:19Z","receivedAt":"2008-11-02T12:35:19Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.10.29 13:11:22 -0400, Jeff King wrote:\n> On Wed, Oct 29, 2008 at 06:06:09PM +0100, Johannes Schindelin wrote:\n> \n> > However, note that we have to hash out what to do about the convention \n> > that --cached traditionally means that only the staging area (formerly \n> > known as \"the index\") is affected, while --index means that the command \n> > touches the working directory, too.\n> \n> If we assume that we have only the word \"stage\" and variations\n> available, then there aren't too many options.\n> \n>   only the staging area:\n>     --stage-only, --staged-only\n> \n>   both:\n>     --staged (as opposed to --staged-only) --stage-and-worktree (too\n>     long), --both (not descriptive enough), --stage-too (yuck)\n\nHm, I don't think that would work out nicely with stash. --keep-index\nwould become --keep-staged-only, which is IMHO pretty confusing, as the\ndefault is to keep nothing. And even if you add another option to keep\nall changes, so that the current state is just put onto the stash, but\nthe working tree and index are unchanged, you would have --keep-staged\nand --keep-staged-only. Not really any better.\n\nAdmittedly, --keep-index is quite different from --index, but if you're\ngoing to change the CLI to hide the word \"index\", that option needs to\nbe changed as well and the usage of the new terms should be unified.\n\nLooking at --cached/--index we have basically three things:\n\n  --cached to refer to the state of the index (diff, grep, [stash], ...)\n  --cached to _work on_ the index only (rm, apply, ...)\n  --index to _work on_ both the index and the working tree (apply, ...)\n\nMaybe that could be translated to:\n\n  --staged: refer to the state of the index\n  --stage: in addition to changing the working tree, also stage the changes\n  --stage-only: only stage the changes, don't change the working tree\n\nThat would give us, for example:\ngit diff --staged\ngit grep --staged\n\ngit apply --stage\ngit apply --stage-only\ngit rm --stage-only\n\ngit stash --keep-staged\n\nA quick look through Documentation/ revealed only one problematic case,\nwhich is ls-files that already has a --stage option. And that looks like\na dealbreaker :-(\n\nBjörn\n"},{"id":"94675","messageId":"7vljw2yo93.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"20081102123519.GA21251@atjola.homenet","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-02T18:30:16Z","receivedAt":"2008-11-02T18:30:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n\n> Looking at --cached/--index we have basically three things:\n>\n>   --cached to refer to the state of the index (diff, grep, [stash], ...)\n>   --cached to _work on_ the index only (rm, apply, ...)\n>   --index to _work on_ both the index and the working tree (apply, ...)\n\nI think the earlier two are the same thing.  The only difference between\nthem is that in the first one, the definition of your \"work on\" happens to\nbe a read-only operation.  Am I mistaken?\n\n> A quick look through Documentation/ revealed only one problematic case,\n> which is ls-files that already has a --stage option. And that looks like\n> a dealbreaker :-(\n\n'ls-files' is primarily about the index contents and all else is a fluff\n;-)\n\nYou could say --show-stage-too if you wanted to, but the command is a\nplumbing to begin with, so perhaps if we can identify the cases where\npeople need to use the command and enhance some Porcelain (likely\ncandidate is 'status' or perhaps 'status --short') to give the information\npeople use ls-files for, we hopefully wouldn't have to change ls-files\nitself at all.\n\nThe only case I use ls-files these days when I am _using_ git (as opposed\nto developing/debugging git) is \"git ls-files -u\" to get the list of still\nunmerged paths during a conflicted merge.\n"},{"id":"94677","messageId":"20081102185434.GB21251@atjola.homenet","threadId":"16082","inReplyTo":"7vljw2yo93.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-11-02T18:54:34Z","receivedAt":"2008-11-02T18:54:34Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.11.02 10:30:16 -0800, Junio C Hamano wrote:\n> Björn Steinbrink <B.Steinbrink@gmx.de> writes:\n> \n> > Looking at --cached/--index we have basically three things:\n> >\n> >   --cached to refer to the state of the index (diff, grep, [stash], ...)\n> >   --cached to _work on_ the index only (rm, apply, ...)\n> >   --index to _work on_ both the index and the working tree (apply, ...)\n> \n> I think the earlier two are the same thing.  The only difference between\n> them is that in the first one, the definition of your \"work on\" happens to\n> be a read-only operation.  Am I mistaken?\n\nYeah, I actually wanted to change that \"work on\" to a simple \"change\",\nbut forgot to do that before sending... :-(\n\nThe idea was that currently \"--cached\" can be \"passive\" (just look at\nthe index instead of the working tree) or \"active\" (change the index\ninstead of the working tree). Thus there could be three \"flag words\",\nand their usage can be unified, including stash.\n\n\"git diff [my] --staged [changes]\"\n\"git stash [but] --keep-staged [changes]\"\n\"git apply [and] --stage my_patch\"\n\"git rm [but] --stage-only some_file\"\n\nOK, the last one is still not even close to a proper sentence, and but I\nguess you get the idea ;-)\n\n> > A quick look through Documentation/ revealed only one problematic case,\n> > which is ls-files that already has a --stage option. And that looks like\n> > a dealbreaker :-(\n> \n> 'ls-files' is primarily about the index contents and all else is a fluff\n> ;-)\n> \n> You could say --show-stage-too if you wanted to, but the command is a\n> plumbing to begin with, so perhaps if we can identify the cases where\n> people need to use the command and enhance some Porcelain (likely\n> candidate is 'status' or perhaps 'status --short') to give the information\n> people use ls-files for, we hopefully wouldn't have to change ls-files\n> itself at all.\n> \n> The only case I use ls-files these days when I am _using_ git (as opposed\n> to developing/debugging git) is \"git ls-files -u\" to get the list of still\n> unmerged paths during a conflicted merge.\n\nHeh, that's probably the one thing for which I use \"git status\" the\nmost.\n\nBjörn\n"},{"id":"94724","messageId":"20081103070430.GC10772@coredump.intra.peff.net","threadId":"16082","inReplyTo":"7vprle1qdl.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-03T07:04:30Z","receivedAt":"2008-11-03T07:04:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 02, 2008 at 01:30:46AM -0700, Junio C Hamano wrote:\n\n> A flag \"--staged\" that means \"staged changes and changes in the work tree\"\n> is no worse than the current \"--index\".  If we were to shoot for clarity,\n\nWell, there is another flag state to be considered, of course, which is\n\"no flag\".  So I think \"--staged\" is fine to mean the working tree and\nstaged, as long as the default (i.e., no option given) is to operate on\nthe working tree.\n\nI can't think offhand of any commands that violate that assumption.\n\n> how about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?\n> \n> I am actually actively unhappy about the latter, but I like more\n> descriptive --staged-only for the former a lot better.\n\nAgreed. --staged-only is fine to me, but --staged-and-unstaged just\nseems too long.\n\n-Peff\n"},{"id":"94726","messageId":"20081103071420.GD10772@coredump.intra.peff.net","threadId":"16082","inReplyTo":"7vljw2yo93.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-03T07:14:20Z","receivedAt":"2008-11-03T07:14:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 02, 2008 at 10:30:16AM -0800, Junio C Hamano wrote:\n\n> > Looking at --cached/--index we have basically three things:\n> >\n> >   --cached to refer to the state of the index (diff, grep, [stash], ...)\n> >   --cached to _work on_ the index only (rm, apply, ...)\n> >   --index to _work on_ both the index and the working tree (apply, ...)\n> \n> I think the earlier two are the same thing.  The only difference between\n> them is that in the first one, the definition of your \"work on\" happens to\n> be a read-only operation.  Am I mistaken?\n\nI think that is somewhat the case for \"grep\", for example. But the\nconfusion is that diff is really a different beast, because you are\ncomparing two _different_ locations.\n\nSo \"git diff --staged\", while it makes sense to us (since we are asking\n\"what is staged\"), is not consistent with the discussed rules. In\nparticular:\n\n  1. It operates on just the \"stage\" and not the working tree, so it\n     should be \"--staged-only\". But the only there is nonsensical.\n\n  2. The default is _already_ operating on the staging area, so you are\n     really switching up the working tree for the HEAD in what you are\n     diffing. So in that sense, it doesn't convey the change in\n     operation very well.\n\nAnd I am not proposing a change here (except to perhaps \"git diff\n--staged\" instead of \"--cached\"). Just pointing out that it does not\nfollow the \"--staged operates on both, --staged-only operates on just\nthe index\" rule.\n\nHrm. For that matter, grep is a bit different, too. Since I would expect\n\"git grep --staged\" to find only staged things, not things in both the\nworking tree and the index. So perhaps there is a difference between\ncommands that modify and commands that inspect.\n\n-Peff\n"},{"id":"95405","messageId":"ee77f5c20811101537u6061e5b4w420e9692e0cefad3@mail.gmail.com","threadId":"16082","inReplyTo":"20081103071420.GD10772@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-11-10T23:37:37Z","receivedAt":"2008-11-10T23:37:37Z","isPatch":true,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Mon, Nov 3, 2008 at 6:14 PM, Jeff King <peff@peff.net> wrote:\n\n> And I am not proposing a change here (except to perhaps \"git diff\n> --staged\" instead of \"--cached\"). Just pointing out that it does not\n> follow the \"--staged operates on both, --staged-only operates on just\n> the index\" rule.\n\nSo apart from the wider discussion, I think this patch by itself is a\nnice step forward towards improving the UI of this part of git. Is\nthere any further discussion on this one alone?\n\n\nDave.\n"},{"id":"95418","messageId":"20081111001534.GB26223@coredump.intra.peff.net","threadId":"16082","inReplyTo":"ee77f5c20811101537u6061e5b4w420e9692e0cefad3@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-11T00:15:34Z","receivedAt":"2008-11-11T00:15:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 11, 2008 at 10:37:37AM +1100, David Symonds wrote:\n\n> > And I am not proposing a change here (except to perhaps \"git diff\n> > --staged\" instead of \"--cached\"). Just pointing out that it does not\n> > follow the \"--staged operates on both, --staged-only operates on just\n> > the index\" rule.\n> \n> So apart from the wider discussion, I think this patch by itself is a\n> nice step forward towards improving the UI of this part of git. Is\n> there any further discussion on this one alone?\n\nI think --staged for --cached is definitely an improvement. Even if we\ndon't have a set rule for \"this is when you use --staged, and this is\nwhen you use --staged-only\", I think everyone so far agrees that any\nsuch rule will have to incorporate \"diff --staged\" somehow, since it\nreads pretty clearly.\n\nSo yes, I would like to see this applied.  However, there are two\npossible improvements:\n\n  1. Your documentation update says --staged is a synonym. Should\n     --staged perhaps be the \"new\" way of doing this, and --cached is\n     left as a historical alias? IOW, point users at the name we think\n     is more sensible.\n\n  2. Part of the point of this is to avoid using the world \"cached\" in\n     instructional materials. The tutorial and user manual should\n     probably be updated to use --staged (and it is reasonably safe to\n     do so immediately, since they are tied to the installed git\n     version; I hope Scott will update his materials eventually, but\n     lagging makes sense there as people will still be using existing\n     versions for some time).\n\n     And of course, such updates would be a small part of any larger\n     decision to call the index something else (the \"stage\" or\n     whatever) in those materials, but I think your point is to do this\n     one positive thing and not wait for the other bits.\n\n-Peff\n"},{"id":"95421","messageId":"7vljvr2hjn.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"ee77f5c20811101537u6061e5b4w420e9692e0cefad3@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-11T01:11:08Z","receivedAt":"2008-11-11T01:11:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Symonds\" <dsymonds@gmail.com> writes:\n\n> On Mon, Nov 3, 2008 at 6:14 PM, Jeff King <peff@peff.net> wrote:\n>\n>> And I am not proposing a change here (except to perhaps \"git diff\n>> --staged\" instead of \"--cached\"). Just pointing out that it does not\n>> follow the \"--staged operates on both, --staged-only operates on just\n>> the index\" rule.\n>\n> So apart from the wider discussion, I think this patch by itself is a\n> nice step forward towards improving the UI of this part of git. Is\n> there any further discussion on this one alone?\n\nI do not think anybody is fundamentally opposed to introduce a consistent\nset of new synonyms.  I do not think anybody disagrees that the word\n\"stage\" will be involved in that set, either.\n\nI however have a suspicion that people would regret having applied this\n\"diff --staged\" patch, after they realize that other commands need two\noptions \"--staged-only\" and \"--staged-too\", and would wish this patch were\nto introduce a synonym \"diff --staged-only\", not \"diff --staged\", for\nuniformity's sake.\n\nI doubt \"Is there any further discussion on THIS ONE ALONE?\" is a valid\nquestion to ask.  What are the other command options we are introducing\nsynonyms for?  There is no need for two variants of staged for \"diff\" (you\ndon't have --staged-too option but instead you give a committish argument,\ne.g. HEAD), so --staged-only can be abbreviated to --staged without\nrisking any ambiguity.  But at least a fully-spelled-out --staged-only\nshould also be accepted, shouldn't it?\n"},{"id":"95422","messageId":"20081111012210.GA26920@coredump.intra.peff.net","threadId":"16082","inReplyTo":"7vljvr2hjn.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-11T01:22:10Z","receivedAt":"2008-11-11T01:22:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 10, 2008 at 05:11:08PM -0800, Junio C Hamano wrote:\n\n> I doubt \"Is there any further discussion on THIS ONE ALONE?\" is a valid\n> question to ask.  What are the other command options we are introducing\n> synonyms for?  There is no need for two variants of staged for \"diff\" (you\n> don't have --staged-too option but instead you give a committish argument,\n> e.g. HEAD), so --staged-only can be abbreviated to --staged without\n> risking any ambiguity.  But at least a fully-spelled-out --staged-only\n> should also be accepted, shouldn't it?\n\nI'm not sure that \"staged-only\" really makes sense here. In modification\ncommands like \"apply\", it is about \"do this one thing to the working\ntree, to both the index and the working tree, or to just the index\".\n\nBut here, you are selecting two points for comparison. So while it is\ntempting to say \"the default for diff just happens to work on the index\nand the working tree, so we don't need --staged-too\", I don't think that\nis right. Doing \"--staged-only\" is _not_ about saying \"do the thing we\nwould have done to the working tree and the index to just the index.\" It\nis about \"use HEAD as one of the points instead of the working tree\n(and reverse the order of points :) )\".\n\nTo me, what is really being asked with \"git diff --staged\" (or \"git\ndiff --cached\" for that matter), is \"what is staged?\" That is, diff is\nnot about an operation on a data location (like HEAD, index, or working\ntree), but rather an operatoin on a data _relationship_. So you ask for\n\"what is not staged\" (the relationship between index and working tree),\n\"what is staged\" (the relationship between HEAD and index), \"what is\ndifferent between the working tree and HEAD\", or \"what is different\nbetween these two trees\".\n\n-Peff\n"},{"id":"95427","messageId":"32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com","threadId":"16082","inReplyTo":"20081103071420.GD10772@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-11T04:04:42Z","receivedAt":"2008-11-11T04:04:42Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Nov 3, 2008 at 2:14 AM, Jeff King <peff@peff.net> wrote:\n> So \"git diff --staged\", while it makes sense to us (since we are asking\n> \"what is staged\"), is not consistent with the discussed rules. In\n> particular:\n>\n>  1. It operates on just the \"stage\" and not the working tree, so it\n>     should be \"--staged-only\". But the only there is nonsensical.\n>\n>  2. The default is _already_ operating on the staging area, so you are\n>     really switching up the working tree for the HEAD in what you are\n>     diffing. So in that sense, it doesn't convey the change in\n>     operation very well.\n>\n> And I am not proposing a change here (except to perhaps \"git diff\n> --staged\" instead of \"--cached\"). Just pointing out that it does not\n> follow the \"--staged operates on both, --staged-only operates on just\n> the index\" rule.\n>\n> Hrm. For that matter, grep is a bit different, too. Since I would expect\n> \"git grep --staged\" to find only staged things, not things in both the\n> working tree and the index. So perhaps there is a difference between\n> commands that modify and commands that inspect.\n\nSpeaking just for myself, I would find this all a lot less confusing\nif \"staged\" were a refspec of some sort, not an option at all.\n\n   git diff HEAD..STAGED\n   git diff STAGED..WORKTREE\n   git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --\npath/to/files\n\ngit-rev-parse already gives us a nice syntax for including/excluding\nparticular trees as much as we like; the only problem is you can't\ntalk about the work tree or index as if they were revisions.\n\nHave fun,\n\nAvery\n"},{"id":"95438","messageId":"buoej1iak1p.fsf@dhapc248.dev.necel.com","threadId":"16082","inReplyTo":"32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-11T05:49:54Z","receivedAt":"2008-11-11T05:49:54Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"\"Avery Pennarun\" <apenwarr@gmail.com> writes:\n> Speaking just for myself, I would find this all a lot less confusing\n> if \"staged\" were a refspec of some sort, not an option at all.\n>\n>    git diff HEAD..STAGED\n>    git diff STAGED..WORKTREE\n>    git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --\n> path/to/files\n\nAnother thing that seems strange to me is that the operation of diffing\nHEAD..STAGED is so verbose -- currently it's \"git diff --cached\", with\nno short option.\n\nSurely this is very common operation... I rather often want to see\ndetails of what's staged for commit...\n\n-Miles\n\n-- \nIf you can't beat them, arrange to have them beaten.  [George Carlin]\n"},{"id":"95521","messageId":"7v63mtu5fy.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"20081111012210.GA26920@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-12T00:57:21Z","receivedAt":"2008-11-12T00:57:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> To me, what is really being asked with \"git diff --staged\" (or \"git\n> diff --cached\" for that matter), is \"what is staged?\"\n\nOk, \"what is staged (in index)?\", relative to the named commit which\ndefaults to HEAD, is a good argument.  Let's apply it.\n"},{"id":"95541","messageId":"20081112083353.GB3817@coredump.intra.peff.net","threadId":"16082","inReplyTo":"32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-12T08:33:53Z","receivedAt":"2008-11-12T08:33:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:\n\n> Speaking just for myself, I would find this all a lot less confusing\n> if \"staged\" were a refspec of some sort, not an option at all.\n> \n>    git diff HEAD..STAGED\n>    git diff STAGED..WORKTREE\n>    git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --\n> path/to/files\n\nI agree that such a thing is reasonably intuitive. I have thought about\n\"magic\" refspecs before; my local git has an \"EMPTY\" refspec which\npoints to the empty tree for diffing. However, that was trivial to\nimplement (since it turns into a sha1), and yours is very hard (since\nyou will have to pass these \"pretend\" objects around).\n\nSo I think it is a neat idea, but I am not volunteering to work on it.\n:)\n\n-Peff\n"},{"id":"95554","messageId":"20081112110629.GA20473@coredump.intra.peff.net","threadId":"16082","inReplyTo":"alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-12T11:06:29Z","receivedAt":"2008-11-12T11:06:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:\n\n> Just in case anybody thought about creating tree objects on the fly and \n> use their SHA-1s: that won't fly, as you can have unmerged entries in the \n> index.  So STAGED.. is a _fundamentally_ different thing from HEAD^..\n\nI thought about that at first, too, but the working tree is even more\npainful. You would have to hash every changed file on the filesystem to\ncreate the tree object.\n\n-Peff\n"},{"id":"95553","messageId":"alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de","threadId":"16082","inReplyTo":"20081112083353.GB3817@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-12T11:10:57Z","receivedAt":"2008-11-12T11:10:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 12 Nov 2008, Jeff King wrote:\n\n> On Mon, Nov 10, 2008 at 11:04:42PM -0500, Avery Pennarun wrote:\n> \n> > Speaking just for myself, I would find this all a lot less confusing \n> > if \"staged\" were a refspec of some sort, not an option at all.\n> > \n> >    git diff HEAD..STAGED\n> >    git diff STAGED..WORKTREE\n> >    git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --\n> > path/to/files\n> \n> I agree that such a thing is reasonably intuitive. I have thought about \n> \"magic\" refspecs before; my local git has an \"EMPTY\" refspec which \n> points to the empty tree for diffing. However, that was trivial to \n> implement (since it turns into a sha1), and yours is very hard (since \n> you will have to pass these \"pretend\" objects around).\n> \n> So I think it is a neat idea, but I am not volunteering to work on it.\n> :)\n\nJust in case anybody thought about creating tree objects on the fly and \nuse their SHA-1s: that won't fly, as you can have unmerged entries in the \nindex.  So STAGED.. is a _fundamentally_ different thing from HEAD^..\n\nMaybe we could play tricks with a special staged_commit (pretending to be \na commit with SHA-1 000000... so that git log STAGED.. would do the same \nas plain git log, the rationale being that STAGED is no commit, so ^STAGED \nshould be a nop).\n\n\"git diff\" would then have some special handling for the case that there \nare exactly two revs, exactly one of them negative, and exactly one of \nthem being the staged_commit, passing off to the respective diff backends.\n\nCiao,\nDscho\n"},{"id":"95570","messageId":"32541b130811120739t95455d8n9b8056a8033491c3@mail.gmail.com","threadId":"16082","inReplyTo":"20081112110629.GA20473@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-12T15:39:21Z","receivedAt":"2008-11-12T15:39:21Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Nov 12, 2008 at 6:06 AM, Jeff King <peff@peff.net> wrote:\n> On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:\n>\n>> Just in case anybody thought about creating tree objects on the fly and\n>> use their SHA-1s: that won't fly, as you can have unmerged entries in the\n>> index.  So STAGED.. is a _fundamentally_ different thing from HEAD^..\n>\n> I thought about that at first, too, but the working tree is even more\n> painful. You would have to hash every changed file on the filesystem to\n> create the tree object.\n\nIs that so bad?  You have to read all those files anyway in order to do a diff.\n\nAvery\n"},{"id":"95571","messageId":"32541b130811120746m7b0eadd3y1240d1252dbd441d@mail.gmail.com","threadId":"16082","inReplyTo":"alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-12T15:46:50Z","receivedAt":"2008-11-12T15:46:50Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Nov 12, 2008 at 6:10 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Just in case anybody thought about creating tree objects on the fly and\n> use their SHA-1s: that won't fly, as you can have unmerged entries in the\n> index.  So STAGED.. is a _fundamentally_ different thing from HEAD^..\n\nHmm, I tried it to see, and \"git diff --cached branchname\" when there\nare unmerged entries looks like this (one line):\n\n* Unmerged path /whatever/file\n\nWhich is pretty unhelpful anyhow (although I don't know what would be\nbetter).  I can think of several ways to produce the same output,\nincluding using a magic SHA-1 that means \"unmerged\", or using a\ndifferent filemode for unmerged files in the tree object, or actually\nincluding all three versions of the file in the tree object, each with\na different mode.  I admit that sounds pretty gross, though.\n\n> Maybe we could play tricks with a special staged_commit (pretending to be\n> a commit with SHA-1 000000... so that git log STAGED.. would do the same\n> as plain git log, the rationale being that STAGED is no commit, so ^STAGED\n> should be a nop).\n\nI might have imagined STAGED to be a child commit of HEAD (or rather,\nits parents should be the same as if you did 'git commit'), but I\ndon't really know for sure.  In such a case, ^STAGED would definitely\nhave a meaning.\n\nHave fun,\n\nAvery\n"},{"id":"95615","messageId":"20081112191512.GA21401@coredump.intra.peff.net","threadId":"16082","inReplyTo":"32541b130811120739t95455d8n9b8056a8033491c3@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-12T19:15:13Z","receivedAt":"2008-11-12T19:15:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 12, 2008 at 10:39:21AM -0500, Avery Pennarun wrote:\n\n> > I thought about that at first, too, but the working tree is even more\n> > painful. You would have to hash every changed file on the filesystem to\n> > create the tree object.\n> \n> Is that so bad?  You have to read all those files anyway in order to\n> do a diff.\n\nI don't know for sure, as I haven't tried it. But you would need to read\nthem twice (once to hash, and then once to diff) plus the extra\ncomputation time of hashing. So assuming you have a decent cache, you\npay the disk access only once.\n\nMaybe it would be negligible, but I would have to see numbers to be\nconvinced either way.\n\n-Peff\n"},{"id":"95619","messageId":"7vljvooi8w.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"20081112191512.GA21401@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-12T19:29:35Z","receivedAt":"2008-11-12T19:29:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Nov 12, 2008 at 10:39:21AM -0500, Avery Pennarun wrote:\n>\n>> > I thought about that at first, too, but the working tree is even more\n>> > painful. You would have to hash every changed file on the filesystem to\n>> > create the tree object.\n>> \n>> Is that so bad?  You have to read all those files anyway in order to\n>> do a diff.\n>\n> I don't know for sure, as I haven't tried it. But you would need to read\n> them twice (once to hash, and then once to diff) plus the extra\n> computation time of hashing. So assuming you have a decent cache, you\n> pay the disk access only once.\n>\n> Maybe it would be negligible, but I would have to see numbers to be\n> convinced either way.\n\nI think you guys are barking up a wrong tree.\n\nThe staged state, the work tree state and the committed states are three\nconceptually different things.  Making them stand out as distinct entities\nat the UI level is a _good thing_.\n\nIntroducing STAGED or WORKTREE psuedonym to deliberately muddy the\ndistinction goes against helping the users form a clear vision of what\ns/he is working on at the conceptual level.\n"},{"id":"95620","messageId":"20081112193747.GA21567@coredump.intra.peff.net","threadId":"16082","inReplyTo":"7vljvooi8w.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-12T19:37:47Z","receivedAt":"2008-11-12T19:37:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 12, 2008 at 11:29:35AM -0800, Junio C Hamano wrote:\n\n> I think you guys are barking up a wrong tree.\n> \n> The staged state, the work tree state and the committed states are three\n> conceptually different things.  Making them stand out as distinct entities\n> at the UI level is a _good thing_.\n\nI'm not sure I agree. They _are_ different things, but in the case of\ndiff, you are really treating each of them like a tree (which makes\nrange operators a little silly, but then that is a silliness already\npresent in \"git diff tree1..tree2\").\n\nBut again, I would not be convinced this is a good direction until I\nsaw:\n\n - the actual design, especially to what degree any ugliness is exposed\n   when we realize that they _aren't_ trees. IOW, how badly does this\n   abstraction leak?\n\n - numbers showing that it isn't going to perform significantly worse\n\nAnd I'm still not volunteering to work on it, so somebody else will have\nto come up with those things. ;)\n\n-Peff\n"},{"id":"95624","messageId":"7vbpwkogxq.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"20081112193747.GA21567@coredump.intra.peff.net","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-12T19:57:53Z","receivedAt":"2008-11-12T19:57:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I'm not sure I agree. They _are_ different things, but in the case of\n> diff, you are really treating each of them like a tree (which makes\n> range operators a little silly, but then that is a silliness already\n> present in \"git diff tree1..tree2\").\n\nIt is not _little_ silly, but quite silly.  It is a historical accident\nand I personally suggest against using it when I teach git to others.\n\nAnd we are _not_ treating each of them like a tree.  We might be treating\nthem as collection of paths (and the range operator is about commits).\n\n> But again, I would not be convinced this is a good direction until I\n> saw:\n> ...\n> And I'm still not volunteering to work on it, so somebody else will have\n> to come up with those things. ;)\n\nEven if they would, I do not think it is a good direction to go.  It makes\nthe UI less intuitive and harder to learn.\n"},{"id":"95640","messageId":"32541b130811121439tbfc54aeq2999dbebf149d5bc@mail.gmail.com","threadId":"16082","inReplyTo":"7vbpwkogxq.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-12T22:39:05Z","receivedAt":"2008-11-12T22:39:05Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Nov 12, 2008 at 2:57 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> I'm not sure I agree. They _are_ different things, but in the case of\n>> diff, you are really treating each of them like a tree (which makes\n>> range operators a little silly, but then that is a silliness already\n>> present in \"git diff tree1..tree2\").\n>\n> It is not _little_ silly, but quite silly.  It is a historical accident\n> and I personally suggest against using it when I teach git to others.\n\nI assume the reason is that \"git diff tree1..tree2\" works with the\ndifferences between tree1 and tree2, much like \"git log tree1..tree2\"\ndoes.  On the other hand, \"git log tree1 tree2\" is something\ncompletely different.\n\nSo at least in my mental model, it's \"git diff tree1 tree2\" that's out\nof place, not really the one with the range specifier.\n\nApparently what's intuitive to one person isn't always intuitive to the next.\n\nAvery\n"},{"id":"95646","messageId":"7vk5b8ldfb.fsf@gitster.siamese.dyndns.org","threadId":"16082","inReplyTo":"32541b130811121439tbfc54aeq2999dbebf149d5bc@mail.gmail.com","subject":"Re: [PATCH] git-diff: Add --staged as a synonym for --cached.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-12T23:42:00Z","receivedAt":"2008-11-12T23:42:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" <apenwarr@gmail.com> writes:\n\n> I assume the reason is that \"git diff tree1..tree2\" works with the\n> differences between tree1 and tree2, much like \"git log tree1..tree2\"\n> does.\n\nActually, that perception is already confused.  The analogue to \"log A..B\"\nis expressed as \"diff A...B\", and not \"diff A..B\".\n\nThat is one of the reasons why I tend to teach against using \"diff A..B\"\nunless you know what it is doing. I'd suggest to get out of that habit\nbefore you confuse yourself even more ;-).\n\nThe _only_ reason diff takes A..B and A...B syntax is because the command\nline parameter parser was easy to write that way.  IOW, it was an artifact\nof the implementation convenience.\n"}]}