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

Re: [PATCH v4] stash: avoid recursive hard reset on submodules

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 15, 2019, 01:35 UTC
Message-ID
<xmqqy2xmdc46.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<20191012153829.GB743557@OJAN-PAAVO.localdomain>
Jakob Jarmar <jakob.j@gmail.com> writes:
Show 15 quoted lines
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix should be to
> ensure that the call to git reset --hard never recurses into submodules.
>
> This matches the behavior of check_changes_tracked_files, which ignores
> submodules.
>
> Signed-off-by: Jakob Jarmar <jakob@jarmar.se>
> ---
>
> Notes:
>     1. Added space between function name and parentheses
>     2. Moved test_when_finished cleanup to top of setup_basic
Looks good; will queue.
Thanks.
Previous: Jakob Jarmar
Message 8 of 8 in “stash: avoid recursive hard reset on submodules”
  1. stash: avoid recursive hard reset on submodulesJakob Jarmar, Oct 10, 2019
  2. stash: avoid recursive hard reset on submodulesJakob Jarmar, Oct 11, 2019
  3. Junio C HamanoOct 11, 2019
  4. stash: avoid recursive hard reset on submodulesJakob Jarmar, Oct 11, 2019
  5. Junio C HamanoOct 12, 2019
  6. Jakob JarmarOct 12, 2019
  7. stash: avoid recursive hard reset on submodulesJakob Jarmar, Oct 12, 2019
  8. Junio C HamanoOct 15, 2019

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.