Re: [PATCH 0/2] Support `git reset --stdin`

From: Jeff King <peff@peff.net>
Date: Oct 11, 2016, 21:47 UTC
Message-ID: <20161011214713.y2fpjkrx6sspks4a@sigill.intra.peff.net>
In-Reply-To: <xmqqoa2q7elc.fsf@gitster.mtv.corp.google.com>

On Tue, Oct 11, 2016 at 02:36:31PM -0700, Junio C Hamano wrote:

Show 21 quoted lines

> > True. I'd have done something more like:
> >
> >   git ls-tree -r $paths | git update-index --index-info
> >
> > but there are some corner cases around deleting paths from the index.
> 
> Ah, I would think read-tree has the exact same issue, even if we
> added pathspec support, around removal.
> 
> So it is more like
> 
> 	(
> 		printf "0 0000000000000000000000000000000000000000\t%s\n" $paths
> 		git --literal-pathspecs ls-tree -r --ignore-missing $paths
> 	) | git update-index --index-info
> 
> which does not look too bad, even though this
> 
> 	printf "%s\n" $paths | git reset --stdin
> 
> does look shorter.

Of course neither of ours solutions works when "$paths" is coming on stdin, rather than in a variable, which I suspect was Dscho's original motivation. :)

One reason not to do the unconditional $z40 in yours is that without it, I would hope that update-index is smart enough not to discard the stat information for entries which are unchanged.

I suspect the best answer is more like:

  git diff-index --cached HEAD | git update-index --index-info

except that you have to munge the data in between, because update-index does not know how to pick the correct data out of the --raw diff output. But that's probably closer to what git-reset does internally.

Anyway, the existence of this discussion is probably a good argument in favor of Dscho's patch. I was mostly curious how close our plumbing tools could come.

-Peff