git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Matthew Kraai via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>,
	Matthew Kraai <mkraai@its.jnj.com>
Subject: Re: [PATCH 1/1] stash: fix segmentation fault when files were added with intent
Date: Mon, 21 Jan 2019 16:14:52 +0100 (STD)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1901211556150.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqq5zulk88e.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Fri, 18 Jan 2019, Junio C Hamano wrote:

> "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.

> > +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

  reply	other threads:[~2019-01-21 15:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18  9:50 [PATCH 0/1] built-in stash: fix segmentation fault when files were added with intent Johannes Schindelin via GitGitGadget
2019-01-18  9:50 ` [PATCH 1/1] " Matthew Kraai via GitGitGadget
2019-01-18 20:42   ` Junio C Hamano
2019-01-21 15:14     ` Johannes Schindelin [this message]
2019-01-22 18:33       ` Junio C Hamano
2019-01-23 11:38         ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1901211556150.41@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=mkraai@its.jnj.com \
    --cc=ungureanupaulsebastian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).