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

Re: reproducible unexpected behavior for 'git reset'

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 11, 2011, 21:54 UTC
Message-ID
<7vwrfoa3fg.fsf@alter.siamese.dyndns.org>
In-Reply-To
<75BBC138-2BD7-41F9-9D84-CEFF23CDC235@johnnowak.com>
John Nowak <john@johnnowak.com> writes:
> I am able to reproduce a scenario where, after a 'commit' and a 'stash
> pop' that results in a merge conflict, I need to 'reset' a file twice in
> order to get the index back to HEAD.

Thanks, you found a bug in "git reset [<commit>] -- path" codepath, it seems, when dealing with an unmerged path.

Previous: John NowakNext: Junio C Hamano
Message 2 of 9 in “reproducible unexpected behavior for 'git reset'”
  1. John NowakJul 10, 2011
  2. Junio C HamanoJul 11, 2011
  3. Junio C HamanoJul 11, 2011
  4. Junio C HamanoJul 14, 2011
  5. 0/2 refactoring diff-indexJunio C Hamano, Jul 19, 2011
  6. 1/2 diff-lib: simplify do_diff_cache()Junio C Hamano, Jul 19, 2011
  7. Jeff KingJul 19, 2011
  8. Junio C HamanoJul 19, 2011
  9. 2/2 diff-lib: refactor run_diff_index() and do_diff_cache()Junio C Hamano, Jul 19, 2011

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.