{"thread":{"id":"33522","subject":"[Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","startedAt":"2013-04-16T18:09:25Z","lastAt":"2013-04-17T17:37:25Z","messageCount":12,"participants":["Ramkumar Ramachandra","Junio C Hamano","Brandon Casey"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"214510","messageId":"1366135765-18437-1-git-send-email-artagnon@gmail.com","threadId":"33522","inReplyTo":null,"subject":"[Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T18:09:25Z","receivedAt":"2013-04-16T18:09:25Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"While a 'git stash show stash^{/quuxery}' works just fine, a 'git\nstash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a\nstash reference'.  This confusing behavior arises from the differences\nin logic that 'show' and 'pop' internally employ to validate the\nspecified ref.  Document this bug by adding a failing testcase for it.\n\nSigned-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n---\n So sorry about misspelling Junio's address in my previous email.\n Please respond to this one instead.\n\n So if you look at git-stash.sh:377, you'll notice that it's doing a\n the shell substitution \"${REV%@*}\" to figure out whether the stash\n ref is a valid ref.  This hacky myopic design has to be done away\n with immediately, and we should really compare the SHA-1 hex of the\n specified ref with those in the stash reflog.\n\n The only reason I haven't written a fix yet is because I'm not sure\n why you need this convoluted IS_STASH_LIKE and IS_STASH_REF logic in\n the first place.  Can someone enlighten me as to what is going on?\n\n t/t3903-stash.sh | 9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/t/t3903-stash.sh b/t/t3903-stash.sh\nindex 5dfbda7..04ba983 100755\n--- a/t/t3903-stash.sh\n+++ b/t/t3903-stash.sh\n@@ -583,6 +583,15 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '\n \tgit stash drop\n '\n \n+test_expect_failure 'valid ref of the form stash^{/message}' '\n+\tgit stash clear &&\n+\techo bar > file &&\n+\tgit add file &&\n+\tgit stash save \"quuxery\" &&\n+\tgit stash show stash^{/quuxery} &&\n+\tgit stash pop stash^{/quuxery}\n+'\n+\n test_expect_success 'stash branch should not drop the stash if the branch exists' '\n \tgit stash clear &&\n \techo foo >file &&\n-- \n1.8.2.1.390.g924f6c3.dirty\n"},{"id":"214517","messageId":"7vmwsyl3mv.fsf@alter.siamese.dyndns.org","threadId":"33522","inReplyTo":"1366135765-18437-1-git-send-email-artagnon@gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T18:41:28Z","receivedAt":"2013-04-16T18:41:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> While a 'git stash show stash^{/quuxery}' works just fine, a 'git\n> stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a\n> stash reference'.  This confusing behavior arises from the differences\n> in logic that 'show' and 'pop' internally employ to validate the\n> specified ref.  Document this bug by adding a failing testcase for it.\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n>  So sorry about misspelling Junio's address in my previous email.\n>  Please respond to this one instead.\n>\n>  So if you look at git-stash.sh:377, you'll notice that it's doing a\n>  the shell substitution \"${REV%@*}\" to figure out whether the stash\n>  ref is a valid ref.  This hacky myopic design has to be done away\n>  with immediately, and we should really compare the SHA-1 hex of the\n>  specified ref with those in the stash reflog.\n>\n>  The only reason I haven't written a fix yet is because I'm not sure\n>  why you need this convoluted IS_STASH_LIKE and IS_STASH_REF logic in\n>  the first place.  Can someone enlighten me as to what is going on?\n\nI think they were an attempt to catch command line argument errors\nearly to be helpful to the end users.\n\nSee ef763129d105 (detached-stash: introduce parse_flags_and_revs\nfunction, 2010-08-21).  As the advertised and originally intended\nuse for stash was to name them with \"stash@{number}\", chomping at\nthe first at-sign to make sure it names refs/stash does not sound\ntoo bad a check.\n\nI do not think anybody considered the approach to look at the commit\nobject name and making sure it appears in the reflog that implements\nthe stash. It sounds like a more robust check if done right.\n"},{"id":"214518","messageId":"CA+sFfMfkoBcoPvJSYBGUe46EbMfiC7q6tVZs6db2NHrEb2gb7Q@mail.gmail.com","threadId":"33522","inReplyTo":"1366135765-18437-1-git-send-email-artagnon@gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-04-16T18:57:49Z","receivedAt":"2013-04-16T18:57:49Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Tue, Apr 16, 2013 at 11:09 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> While a 'git stash show stash^{/quuxery}' works just fine, a 'git\n> stash pop stash^{/quuxery}' complains with: 'stash^{/quuxery} is not a\n> stash reference'.\n\nI don't think it is appropriate to use the ^{/<text>} notation with stashes.\n\nThe stash is implemented using the reflog.  The ^{/<text>} notation\nsearches the commit history, not the reflog.  So I think it will be\nable to match the first entry in your stash stack, but not any of the\nother ones.\n\nTry inserting another stash (see below) on top of the one that\ncontains the string \"quuxery\" and I think you'll find that your 'git\nstash show stash^{/quuxery}' no longer works.\n\nAn extension to the reflog dwimery that implements @{/<text>} could be\ninteresting though.\n\n> This confusing behavior arises from the differences\n> in logic that 'show' and 'pop' internally employ to validate the\n> specified ref.  Document this bug by adding a failing testcase for it.\n>\n> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>\n> ---\n>  So sorry about misspelling Junio's address in my previous email.\n>  Please respond to this one instead.\n>\n>  So if you look at git-stash.sh:377, you'll notice that it's doing a\n>  the shell substitution \"${REV%@*}\" to figure out whether the stash\n>  ref is a valid ref.\n\n> This hacky myopic design has to be done away\n>  with immediately, and we should really compare the SHA-1 hex of the\n>  specified ref with those in the stash reflog.\n\nJust a bit of advice, maybe you should think about softening your tone\na bit hmm?  I find this last sentence to be somewhat repelling and\ntend to refrain from responding to such.\n\n>  The only reason I haven't written a fix yet is because I'm not sure\n>  why you need this convoluted IS_STASH_LIKE and IS_STASH_REF logic in\n>  the first place.  Can someone enlighten me as to what is going on?\n\n>  t/t3903-stash.sh | 9 +++++++++\n>  1 file changed, 9 insertions(+)\n>\n> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh\n> index 5dfbda7..04ba983 100755\n> --- a/t/t3903-stash.sh\n> +++ b/t/t3903-stash.sh\n> @@ -583,6 +583,15 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '\n>         git stash drop\n>  '\n>\n> +test_expect_failure 'valid ref of the form stash^{/message}' '\n> +       git stash clear &&\n> +       echo bar > file &&\n> +       git add file &&\n> +       git stash save \"quuxery\" &&\n\n            # Save another stash here\n\n            echo bash >file\n            git add file\n            git stash save \"something\"\n\n            # Now git stash show stash^{/quuxery} no longer works.\n\n> +       git stash show stash^{/quuxery} &&\n> +       git stash pop stash^{/quuxery}\n> +'\n> +\n>  test_expect_success 'stash branch should not drop the stash if the branch exists' '\n>         git stash clear &&\n>         echo foo >file &&\n\n-Brandon\n"},{"id":"214521","messageId":"7veheal28i.fsf@alter.siamese.dyndns.org","threadId":"33522","inReplyTo":"CA+sFfMfkoBcoPvJSYBGUe46EbMfiC7q6tVZs6db2NHrEb2gb7Q@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T19:11:41Z","receivedAt":"2013-04-16T19:11:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey <drafnel@gmail.com> writes:\n\n> The stash is implemented using the reflog.  The ^{/<text>} notation\n> searches the commit history, not the reflog.  So I think it will be\n> able to match the first entry in your stash stack, but not any of the\n> other ones.\n\nGood point, together with...\n\n> An extension to the reflog dwimery that implements @{/<text>} could be\n> interesting though.\n\n\"log -g --grep=<text>\" gives you a way to eyeball, but with\n@{/<text>} you _might_ have a good way to name the revision.\n\nI am not however so sure if it is useful outside the context of the\nstash, because the ones you would want to recover from a normal\nreflog is most likely the older version of what you already amended,\nso the latest hit will likely be the post-amend version, not the one\ncloser to the original.  You would end up eyeballing the output of\n\"log --oneline -g -grep=<text>\" and cutting from it.\n\n> Just a bit of advice, maybe you should think about softening your tone\n> a bit hmm?  I find this last sentence to be somewhat repelling and\n> tend to refrain from responding to such.\n\nOh, so it wasn't just me.  I was about to say something similar,\nalong the lines of \"people whom you just called myopic, because you\ndid not understand the rationale behind their past work, are less\nlikely to be inclined to help you. you would have more luck if you\nask them nicely.\", but I've long given up on helping him be a better\ncommunity member and deleted that part.\n"},{"id":"214529","messageId":"CA+sFfMc1Brgf3mewjizv-F9Fir+wJ56fV18s--CE1h0gsuvcrw@mail.gmail.com","threadId":"33522","inReplyTo":"7veheal28i.fsf@alter.siamese.dyndns.org","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-04-16T19:52:20Z","receivedAt":"2013-04-16T19:52:20Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Tue, Apr 16, 2013 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Brandon Casey <drafnel@gmail.com> writes:\n>\n>> The stash is implemented using the reflog.  The ^{/<text>} notation\n>> searches the commit history, not the reflog.  So I think it will be\n>> able to match the first entry in your stash stack, but not any of the\n>> other ones.\n>\n> Good point, together with...\n>\n>> An extension to the reflog dwimery that implements @{/<text>} could be\n>> interesting though.\n>\n> \"log -g --grep=<text>\" gives you a way to eyeball, but with\n> @{/<text>} you _might_ have a good way to name the revision.\n>\n> I am not however so sure if it is useful outside the context of the\n> stash, because the ones you would want to recover from a normal\n> reflog is most likely the older version of what you already amended,\n> so the latest hit will likely be the post-amend version, not the one\n> closer to the original.  You would end up eyeballing the output of\n> \"log --oneline -g -grep=<text>\" and cutting from it.\n\nYeah, I think that's true.  I can't think of a reason, at the moment,\nwhere it would be useful outside of with 'git stash'.  I mainly wanted\nto spell out \"@{/<text>}\" so that the mental link could be made back\nto the code in git-stash that removes the \"@*\" suffix.\n\n-Brandon\n"},{"id":"214530","messageId":"CALkWK0mdNWxTVf9rhRO7Z8qnGT9J4R3UicGUNKdBkZuOctoBRQ@mail.gmail.com","threadId":"33522","inReplyTo":"7veheal28i.fsf@alter.siamese.dyndns.org","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T19:53:38Z","receivedAt":"2013-04-16T19:53:38Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Brandon Casey writes:\n>> Just a bit of advice, maybe you should think about softening your tone\n>> a bit hmm?  I find this last sentence to be somewhat repelling and\n>> tend to refrain from responding to such.\n>\n> Oh, so it wasn't just me.  I was about to say something similar,\n> along the lines of \"people whom you just called myopic, because you\n> did not understand the rationale behind their past work, are less\n> likely to be inclined to help you. you would have more luck if you\n> ask them nicely.\", but I've long given up on helping him be a better\n> community member and deleted that part.\n\nI'm truly sorry.\n\nI've only had a cursory look at git-stash.sh, and was merely saying\nwhat came to my mind first after a cursory glance: it wasn't an\nopinion of any sort.  A lot of things I say are stupid in retrospect:\nI'm not ashamed to admit it; I'm an inexperienced kid, and I make lots\nof mistakes.  And please don't interpret my comments as attacking the\npeople who wrote the code: in a community like ours, I don't believe\nin associating blame to any one person; I believe that all of us are\nequally responsible for all parts of the code as a collective; if\nsomething doesn't match what I expect, why didn't I participate in the\ndiscussion of the patch that led up to it?\n\nI complain very loudly about little things that annoy me, and I think\nthis is a good attribute.  People who are generally happy with the\ncurrent state of affairs cannot make a big difference.  This does not\nmean that I go on a stubborn rampage breaking backward compatibility\neverywhere, but rather that I raise the kind of questions that other\npeople normally don't.\n\nI do not blame people for who they are: they are just a product of\ntheir histories; a sum of absorbed influences.  It is, therefore,\nirrational to be rude to someone.  If someone is not behaving as I\nexpect them to, I send them a polite off-list email pointing out what\nI think their negative attributes  are, and attempt to nudge them in\nthe desired direction.\n\nI'll try to be a better community member in the future.\n"},{"id":"214531","messageId":"CALkWK0=L4mqVBqDMWgzN+BT5bnEF0L6d=GPXvrNhPL_Asvdq8Q@mail.gmail.com","threadId":"33522","inReplyTo":"CA+sFfMfkoBcoPvJSYBGUe46EbMfiC7q6tVZs6db2NHrEb2gb7Q@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T20:11:30Z","receivedAt":"2013-04-16T20:11:30Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Brandon Casey wrote:\n>             # Save another stash here\n>\n>             echo bash >file\n>             git add file\n>             git stash save \"something\"\n>\n>             # Now git stash show stash^{/quuxery} no longer works.\n\nAh, yes.  My stupidity.  Why was I expecting ^{/quuxery} to dig\nthrough the reflog?\n\n> An extension to the reflog dwimery that implements @{/<text>} could be\n> interesting though.\n\nYeah, this sounds interesting.\n\nMy initial itch that led up to this: I wanted a way to stash something\naway and recover it at a later time predictably for rebase.autostash\n(there might have been other stash invocations in between).\nOriginally, I thought I'd need a refs/stashes/* or something of the\nsort to solve this problem, but git-stash.sh hard-codes refs/stash\neverywhere (and so do other things like reflog).  So, I was thinking\nabout retrieving it based on commit message, but the solution is still\nshort of ideal.  What are your thoughts on my original refs/stashes/*\nidea?\n"},{"id":"214532","messageId":"CALkWK0=JdJGf7+yWvi2xkoruixK5G5mnQXm8pFhK60NQB2qX0Q@mail.gmail.com","threadId":"33522","inReplyTo":"7vmwsyl3mv.fsf@alter.siamese.dyndns.org","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-16T20:23:21Z","receivedAt":"2013-04-16T20:23:21Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I do not think anybody considered the approach to look at the commit\n> object name and making sure it appears in the reflog that implements\n> the stash. It sounds like a more robust check if done right.\n\nActually, if you think about it, there is really only one way to\nspecify revisions in the stash's reflog: stash@*.  Since these\ncommits don't have to be reachable from any refs in the general case,\nall the other revision syntaxes are useless.  So, I would argue that\n\"${REV%@*}\" is sufficient and correct*: anything beyond it is an\nunnecessary overhead.\n\nHowever, the initial bug is still valid:  show should not show\nsomething that pop cannot operate on.\n\n* although I'd have been more comfortable if we had a neater way to specify that\n"},{"id":"214540","messageId":"7vobdejic0.fsf@alter.siamese.dyndns.org","threadId":"33522","inReplyTo":"CALkWK0=JdJGf7+yWvi2xkoruixK5G5mnQXm8pFhK60NQB2qX0Q@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T21:06:55Z","receivedAt":"2013-04-16T21:06:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Junio C Hamano wrote:\n>> I do not think anybody considered the approach to look at the commit\n>> object name and making sure it appears in the reflog that implements\n>> the stash. It sounds like a more robust check if done right.\n>\n> Actually, if you think about it, there is really only one way to\n> specify revisions in the stash's reflog: stash@*.\n> ...\n> * although I'd have been more comfortable if we had a neater way to specify that\n\nYup.  \"git stash pop +4\", without a must-be-it token \"stash\" or\nmandatory \"@{}\" frill would have been much nicer.\n"},{"id":"214544","messageId":"CA+sFfMd-pfmPXNCoAfH59om1cdYh1=bJ7yb-BGZHjkra5Gm_uw@mail.gmail.com","threadId":"33522","inReplyTo":"CALkWK0=L4mqVBqDMWgzN+BT5bnEF0L6d=GPXvrNhPL_Asvdq8Q@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-04-16T21:29:51Z","receivedAt":"2013-04-16T21:29:51Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Tue, Apr 16, 2013 at 1:11 PM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Brandon Casey wrote:\n>>             # Save another stash here\n>>\n>>             echo bash >file\n>>             git add file\n>>             git stash save \"something\"\n>>\n>>             # Now git stash show stash^{/quuxery} no longer works.\n>\n> Ah, yes.  My stupidity.  Why was I expecting ^{/quuxery} to dig\n> through the reflog?\n>\n>> An extension to the reflog dwimery that implements @{/<text>} could be\n>> interesting though.\n>\n> Yeah, this sounds interesting.\n>\n> My initial itch that led up to this: I wanted a way to stash something\n> away and recover it at a later time predictably for rebase.autostash\n> (there might have been other stash invocations in between).\n> Originally, I thought I'd need a refs/stashes/* or something of the\n> sort to solve this problem, but git-stash.sh hard-codes refs/stash\n> everywhere (and so do other things like reflog).  So, I was thinking\n> about retrieving it based on commit message, but the solution is still\n> short of ideal.  What are your thoughts on my original refs/stashes/*\n> idea?\n\nYou can create a stash without modifying the refs/stash reflog using\n'sha1=`git stash create`' and then later apply it using 'git stash\napply --index $sha1'.  You'll have to reset the work directory\nyourself though since 'git stash create' does not do so.  The stash\ncreated this way is just a dangling commit so it will have a lifetime\naccording to the gc.pruneexpire (default 2 weeks currently).\n\n-Brandon\n"},{"id":"214588","messageId":"CALkWK0kJOSBN8XTJKBLOqi4tUjjm9unr=No65TtW9V0qvKmV-A@mail.gmail.com","threadId":"33522","inReplyTo":"CA+sFfMd-pfmPXNCoAfH59om1cdYh1=bJ7yb-BGZHjkra5Gm_uw@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-17T08:31:06Z","receivedAt":"2013-04-17T08:31:06Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"So, I read through git-stash.sh a little more, and found the following:\n\n1. Any stash that can be shown can be applied, but not necessarily\npopped or dropped (as the documentation indicates).  The reason for\nthis is simple: a pop/drop attempts to clear the entry in the stash\nreflog as well, but all stashes need to have a corresponding reflog\nentry (for instance, those created with 'stash create').\n\n2. IS_STASH_LIKE is a misnomer: all it checks is that the given <rev>\nis a merge commit.  As a result, you can 'stash show' and 'stash\napply' any merge commit.  Should we attempt to tighten this somehow,\nor are we okay with the stash being just another merge commit?  Check\nfor a special commit message perhaps?\n\nBrandon Casey wrote:\n> You can create a stash without modifying the refs/stash reflog using\n> 'sha1=`git stash create`' and then later apply it using 'git stash\n> apply --index $sha1'.  You'll have to reset the work directory\n> yourself though since 'git stash create' does not do so.  The stash\n> created this way is just a dangling commit so it will have a lifetime\n> according to the gc.pruneexpire (default 2 weeks currently).\n\nThanks, but I was worried more about reachability of the commit: if I\ncreate a ref to it in refs/stashes/* like I suggested, it wouldn't\nexpire until that ref was gone.  Then again, I suppose a ref is\nunnecessary for a temporary stash.  Yeah, I can store the SHA-1 hex of\nthe dangling commit in my caller's $state_dir, and apply it from there\nlater.\n"},{"id":"214623","messageId":"7vbo9df48a.fsf@alter.siamese.dyndns.org","threadId":"33522","inReplyTo":"CALkWK0kJOSBN8XTJKBLOqi4tUjjm9unr=No65TtW9V0qvKmV-A@mail.gmail.com","subject":"Re: [Resend PATCH] t3903 (stash): add failing test for ref of form ^{/message}","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-17T17:37:25Z","receivedAt":"2013-04-17T17:37:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> 1. Any stash that can be shown can be applied, but not necessarily\n> popped or dropped (as the documentation indicates).  The reason for\n> this is simple: a pop/drop attempts to clear the entry in the stash\n> reflog as well, but all stashes need to have a corresponding reflog\n> entry (for instance, those created with 'stash create').\n\nCorrect.\n\nTo show or apply, you only need a product of \"stash create\" that may\nnot be linked anywhere in the refs or reflogs.  But you can only pop\nor drop something on the stash reflog.\n\n> 2. IS_STASH_LIKE is a misnomer: all it checks is that the given <rev>\n> is a merge commit.\n\nThe purpose of the logic is to reject a mistake to name stuff that\nis clearly not a product of \"stash create\".  The name is just being\nhumble by not claiming \"I know this is definitely a product of\nstash-create\" but merely hinting \"This smells like such an object\";\nI am not sure if that is a \"misnomer\".\n\nYou are free to try to think of a way to tighten the implemention to\nreject a random two-or-three parent merge commit that is not a\nproduct of \"stash create\".  People already have looked at this code\nsince it was written, and didn't find a reasonable way to tighten it\nwithout triggering false negatives, so I wouldn't be surprised if\nanybody tried it again today and failed.\n"}]}