Hi Junio, On Fri, 18 Jan 2019, Junio C Hamano wrote: > "Matthew Kraai via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Matthew Kraai <mkraai@xxxxxxxxxxx> > > > > After `git add -N <file>`, the index is in a special state. A state for > > which the built-in stash was not prepared, as it failed to initialize > > the `rev` structure in that case before using `&rev.pending`. > > > > Detailed explanation: If `reset_tree()` returns a non-zero value, > > `stash_working_tree()` calls `object_array_clear()` with `&rev.pending`. > > If `rev` is not initialized, this causes a segmentation fault. > > It is a bit strange that the paragraph for "detailed explanation" is > shorter than the paragraph it attempts to clarify. > > Dropping those two words "Detailed explanation:" easily fixes > awkwardness ;-). If you must. For me, it is not the quantity, but the quality of the words that makes it a detailed explanation. You see, as a mathematician, I can give you a very condensed, super detailed, complicated proof for many a lemma which is substantially shorter than the understandable, English explanation that I would want to give to non-mathematicians. Likewise, if you take a step back, and try to forget for a moment that you are very familiar with Git's source code, you will without any doubt *have* to admit that the detailed explanation requires a *lot* of knowledge already, while the paragraph before that does not. So if you find that awkward, I respectfully disagree. And if you insist on removing those "two words" (to make the paragraph *even* shorter, which is apparently something you took exception with), I have no tools to stop you. Just let it be known that it is against the wish of the author of those lines. > > +test_expect_success 'stash --intent-to-add file' ' > > + git reset --hard && > > + echo new >file4 && > > + git add --intent-to-add file4 && > > + test_when_finished "git rm -f file4" && > > + test_must_fail git stash > > +' > > This still must fail because an index with an I-T-A cannot be > included in a stash, but test_must_fail will make sure that the > command does not suffer an uncontrolled crash. Good. Indeed. And Matthew even adopted your preferred strategy of combining the demonstration of the bug with the fix. In the meantime, I have found the totally intuitive (and equally documented) command line that I can use when I want to see whether a given branch is buggy and when I cannot simply `git cherry-pick <commit-demonstrating-a-bug>`: git cherry-pick <commit-fixing-the-bug-and-adding-a-test> git checkout HEAD^ -- :^/t/ Ciao, Johannes
