git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/1] stash: fix segmentation fault when files were added with intent

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 21, 2019, 15:14 UTC
Message-ID
<nycvar.QRO.7.76.6.1901211556150.41@tvgsbejvaqbjf.bet>
In-Reply-To
<xmqq5zulk88e.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Fri, 18 Jan 2019, Junio C Hamano wrote:
Show 17 quoted lines
> "Matthew Kraai via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > From: Matthew Kraai <mkraai@its.jnj.com>
> >
> > 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.

Show 11 quoted 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

Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 6 in “built-in stash: fix segmentation fault when files were added with intent”
  1. 0/1 built-in stash: fix segmentation fault when files were added with intentJohannes Schindelin via GitGitGadget, Jan 18, 2019
  2. 1/1 stash: fix segmentation fault when files were added with intentMatthew Kraai via GitGitGadget, Jan 18, 2019
  3. Junio C HamanoJan 18, 2019
  4. Johannes SchindelinJan 21, 2019
  5. Junio C HamanoJan 22, 2019
  6. Johannes SchindelinJan 23, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.