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

Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Dec 18, 2009, 19:04 UTC
Message-ID
<200912182004.25520.j.sixt@viscovery.net>
In-Reply-To
<7v4onoywws.fsf@alter.siamese.dyndns.org>
On Freitag, 18. Dezember 2009, Junio C Hamano wrote:
Show 6 quoted lines
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > You have queued 1/2 (filter-branch: remove an unnecessary use of
> > 'git read-tree') of this 2-patch series, but I haven't seen any comments
> > about this 2/2 nor is it queued. Did it fall through the cracks?
>
> No.  I think saying "is not allowed" is going a bit too far [*1*].
Yes, you said that, but in response to the footnote in 1/2.
> The 
> documentation does not list it as a commonly useful thing, that's all.

IMO, not only is it not useful, but it is also dangerous - it erases the index!

Show 6 quoted lines
> When a user wants to have an empty index, and does not want to touch files
> under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
> some religious reasons, "read-tree" without a tree would be one valid way
> to do so [*2*].
> *2* I suspect "rm --cached ." might be another, but it would probably be
> much more expensive.

For an operation like this, shouldn't we advocate this alternate instruction (which explicitly tells what is wanted) rather than the implicit and undocumented operation of parameter-less read-tree?

Show 6 quoted lines
> We need to make arguments like "'read-tree' given by mistake to empty the
> index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
> little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
> the best way to get an empty index" to weigh pros and cons between two
> possible approaches before deciding which way to go, but in a pre-release
> freeze, I wasn't in the mood to be one who is doing the arguments myself.

Sorry to drag you into this discussion, but I felt this change is maint-worthy (because the behavior is not only risky, but dangerous).

-- Hannes
Previous: Junio C HamanoNext: Sverre Rabbelier
Message 5 of 21 in “filter-branch: remove an unnecessary use of 'git read-tree'”
  1. 1/2 filter-branch: remove an unnecessary use of 'git read-tree'Johannes Sixt, Dec 15, 2009
  2. 2/2 read-tree: at least one tree-ish argument is requiredJohannes Sixt, Dec 15, 2009
  3. Johannes SixtDec 18, 2009
  4. Junio C HamanoDec 18, 2009
  5. Johannes SixtDec 18, 2009
  6. Sverre RabbelierDec 18, 2009
  7. Junio C HamanoDec 18, 2009
  8. Sverre RabbelierDec 18, 2009
  9. Junio C HamanoDec 18, 2009
  10. Sverre RabbelierDec 18, 2009
  11. Junio C HamanoDec 18, 2009
  12. Sverre RabbelierDec 18, 2009
  13. Johannes SixtDec 18, 2009
  14. Jakub NarebskiDec 18, 2009
  15. Junio C HamanoDec 18, 2009
  16. Nanako ShiraishiDec 19, 2009
  17. Junio C HamanoDec 19, 2009
  18. Junio C HamanoDec 19, 2009
  19. Johannes SchindelinDec 19, 2009
  20. Johannes SchindelinDec 15, 2009
  21. Junio C HamanoDec 16, 2009

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.