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

Re: [PATCH 0/2] read-tree: improve untracked file support

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
May 1, 2019, 14:58 UTC
Message-ID
<d4c36a24-b40c-a6ca-7a05-572ab93a0101@gmail.com>
In-Reply-To
<CACsJy8CNUEBXmBcQnRHqdeFJtTvBuZ9thP7QPAw-ZOD+2ty3VA@mail.gmail.com>
On 01/05/2019 11:31, Duy Nguyen wrote:
Show 15 quoted lines
> On Wed, May 1, 2019 at 5:14 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>>
>> These two patches teach read-tree how to avoid overwriting untracked
>> files when doing '--reset -u' and also how to respect all of git's
>> standard excludes files. I'd like to see the porcelain commands stop
>> overwriting untracked files, this is a first step on the way. I'm not
>> sure if we want to add options to the porcelain commands to protect
>> untracked files or just change their behavior and add an option to
>> override that. I'm leaning towards the latter but I'd be interested to
>> hear what others think.
> 
> For new commands like git-restore, it's definitely a good thing to not
> overwrite untracked files.

I agree, unfortunately this series does not help with git-restore, only git-switch. For restore on an index without conflicts I think it could just use the pathspec in struct unpack_trees_options and set opts.rest = UNPACK_RESET_PROTECT_UNTRACKED but that does not help if we want to handle conflicted paths differently to non-conflicted paths.

Show 6 quoted lines
> For existing commands I guess we have to go
> over them one by one. For "git reset --hard", it should really just
> overwrite whatever needed to get back to the known good state. "git
> checkout -f" , not so sure (seems weird that we need force-level-two
> option to override the protection provided by -f, if we change default
> behavior)

I think it's fine for "checkout -f" to overwrite untracked files (and if "switch --discard-changes" does not then there is no pressing need to add such a mode to checkout), --force is a good name for an option that nukes everything that gets in it's way. For "reset --hard" I'm not so sure, if I have changes to an untracked file I don't wont them overwritten by default. There is no porcelain equivalent to "read-tree --reset --protect-untracked -u" and I was hoping "reset --hard" may become that porcelain equivalent with a new --force or --overwrite-untracked option.

For the various "foo --abort" some (most?) are using "reset --merge" which I think declines to overwrite untracked files but rebase uses "reset --hard" which I'd like to change to protect untracked files in the same way that rebase does for the initial checkout and when picking commits. I haven't thought about stash.

Best Wishes
Phillip
Previous: Duy NguyenNext: Duy Nguyen
Message 9 of 12 in “read-tree: improve untracked file support”
  1. 0/2 read-tree: improve untracked file supportPhillip Wood, May 1, 2019
  2. 1/2 read-tree --reset: add --protect-untrackedPhillip Wood, May 1, 2019
  3. Duy NguyenMay 1, 2019
  4. Duy NguyenMay 1, 2019
  5. Duy NguyenMay 2, 2019
  6. Phillip WoodMay 3, 2019
  7. 2/2 read-tree: add --exclude-standardPhillip Wood, May 1, 2019
  8. Duy NguyenMay 1, 2019
  9. Phillip WoodMay 1, 2019
  10. Duy NguyenMay 2, 2019
  11. Phillip WoodMay 7, 2019
  12. Duy NguyenMay 7, 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.