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

Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 12, 2009, 21:45 UTC
Message-ID
<7vtyvvn9wx.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20091212043259.3930.98779.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> It is strange and fragile that a mixed reset is disallowed in a bare
> repo but is allowed in a .git dir. So this patch simplifies things
> by only allowing soft resets when not in a working tree.

I would not mind what you said were "I find the difference strange", as it is a fairly subjective word. But if you say "fragile", you would need to defend the use of the word better. What kind of misuse does it invite, and what grave consequences such misuses would cause? I do not see any fragility and I would want to understand it better so that I can write about it in the Release Note to warn people and encourage them to upgrade.

More importantly, I think the difference between the two actually makes sense. A bare repository by definition does _not_ have any work tree so there is no point in having the index file in there. On the other hand, even though it is not necessary to "cd .git && git reset HEAD^", I don't see a strong reason why it needs to be disallowed.

On the other hand, I don't see a strong reason why such a use needs to be supported, other than "we've allowed it for a long time, and people may have hooks (they typically start in $GIT_DIR) that rely on it", which by itself is not something strong enough to veto the change. It is only a minor incompatibility and I can be persuaded to listen to a pros-and-cons argument.

An honest justification might have been "This change to disallow a mixed reset in $GIT_DIR of a repository with a work tree will break existing scripts, but I think it is not widely used _for such and such reasons_, and can easily be worked around. On the other hand, this change vastly simplifies the reimplementation of 'reset' _because X and Y and Z_".

> This patch is also needed to speed up "git reset" by using
> unpack_tree() directly (instead of execing "git read-tree").
It is very unclear _why_ it is "needed" from this description.
Previous: Christian CouderNext: Christian Couder
Message 3 of 18 in “"git reset --merge" related improvements”
  1. 0/7 "git reset --merge" related improvementsChristian Couder, Dec 12, 2009
  2. 1/7 reset: do not accept a mixed reset in a .git dirChristian Couder, Dec 12, 2009
  3. Junio C HamanoDec 12, 2009
  4. Christian CouderDec 15, 2009
  5. Junio C HamanoDec 15, 2009
  6. Junio C HamanoDec 15, 2009
  7. Christian CouderDec 16, 2009
  8. Junio C HamanoDec 15, 2009
  9. 2/7 reset: add a few tests for "git reset --merge"Christian Couder, Dec 12, 2009
  10. Junio C HamanoDec 12, 2009
  11. 3/7 reset: use "unpack_trees()" directly instead of "git read-tree"Christian Couder, Dec 12, 2009
  12. Junio C HamanoDec 12, 2009
  13. 4/7 reset: add option "--keep" to "git reset"Christian Couder, Dec 12, 2009
  14. Junio C HamanoDec 12, 2009
  15. Christian CouderDec 30, 2009
  16. 5/7 reset: add test cases for "--keep" optionChristian Couder, Dec 12, 2009
  17. 6/7 Documentation: reset: describe new "--keep" optionChristian Couder, Dec 12, 2009
  18. 7/7 Documentation: reset: add some tables to describe the different optionsChristian Couder, Dec 12, 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.