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

Re: [RFC PATCH] Introduce "precious" file concept

From
Duy Nguyen <pclouds@gmail.com>
Date
Nov 11, 2018, 15:41 UTC
Message-ID
<CACsJy8CYpuc7-CZhk7kQQVQFxOfLFZu4TVpG=b0a7j8P1J394Q@mail.gmail.com>
In-Reply-To
<871s7r4wuv.fsf@evledraar.gmail.com>

On Sun, Nov 11, 2018 at 1:33 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 26 quoted lines
> The users who need protection against git deleting their files the most
> are exactly the sort of users who aren't expert-level enough to
> understand the nuances of how the semantics of .gitignore and "precious"
> are going to interact before git eats their data.
>
> This is pretty apparent from the bug reports we're getting about
> this. None of them are:
>
>     "Hey, I 100% understood .gitignore semantics including this one part
>     of the docs where you say you'll do this, but just forgot one day
>     and deleted my work. Can we get some more safety?"
>
> But rather (with some hyperbole for effect):
>
>     "ZOMG git deleted my file! Is this a bug??"
>
> So I think we should have the inverse of this "precious"
> attribute". Just a change to the docs to say that .gitignore doesn't
> imply these eager deletion semantics on tree unpacking anymore, and if
> users want it back they can define a "garbage" attribute
> (s/precious/garbage/).
>
> That will lose no data, and in the very rare cases where a checkout of
> tracked files would overwrite an ignored pattern, we can just error out
> (as we do with the "Ok to overwrite" branch removed) and tell the user
> to delete the files to proceed.

There's also the other side of the coin. If this refuse to overwrite triggers too often, it can become an annoyance. So far I've seen two reports of accident overwriting which make me think turning precious to trashable may be too extreme. Plus ignored files are trashable by default (or at least by design so far), adding trashable attribute changes how we handle ignored files quite significantly.

-- 
Duy
Previous: Duy NguyenNext: Ævar Arnfjörð Bjarmason
Message 6 of 40 in “Introduce "precious" file concept”
  1. Introduce "precious" file conceptNguyễn Thái Ngọc Duy, Nov 11, 2018
  2. Bert WesargNov 11, 2018
  3. Ævar Arnfjörð BjarmasonNov 11, 2018
  4. Ævar Arnfjörð BjarmasonNov 11, 2018
  5. Duy NguyenNov 12, 2018
  6. Duy NguyenNov 11, 2018
  7. Ævar Arnfjörð BjarmasonNov 11, 2018
  8. Per LundbergNov 12, 2018
  9. Matthieu MoyNov 12, 2018
  10. Ævar Arnfjörð BjarmasonNov 12, 2018
  11. Junio C HamanoNov 12, 2018
  12. Ævar Arnfjörð BjarmasonNov 12, 2018
  13. Junio C HamanoNov 12, 2018
  14. Duy NguyenNov 12, 2018
  15. brian m. carlsonNov 12, 2018
  16. Per LundbergNov 26, 2018
  17. Ævar Arnfjörð BjarmasonNov 26, 2018
  18. Junio C HamanoNov 26, 2018
  19. Ævar Arnfjörð BjarmasonNov 27, 2018
  20. Junio C HamanoNov 28, 2018
  21. Ævar Arnfjörð BjarmasonNov 28, 2018
  22. Junio C HamanoNov 29, 2018
  23. Duy NguyenDec 1, 2018
  24. Duy NguyenNov 26, 2018
  25. Ævar Arnfjörð BjarmasonNov 26, 2018
  26. Duy NguyenNov 26, 2018
  27. Ævar Arnfjörð BjarmasonNov 26, 2018
  28. Duy NguyenNov 26, 2018
  29. Per LundbergNov 27, 2018
  30. Jacob KellerNov 27, 2018
  31. Per LundbergNov 27, 2018
  32. brian m. carlsonNov 28, 2018
  33. Per LundbergNov 28, 2018
  34. Duy NguyenNov 27, 2018
  35. Duy NguyenDec 6, 2018
  36. Eckhard MaaßNov 26, 2018
  37. Junio C HamanoNov 11, 2018
  38. 0/2 Precios files round twoNguyễn Thái Ngọc Duy, Nov 26, 2018
  39. 1/2 Introduce "precious" file conceptNguyễn Thái Ngọc Duy, Nov 26, 2018
  40. 2/2 unpack-trees: support core.allIgnoredFilesArePreciousWhenMergingNguyễn Thái Ngọc Duy, Nov 26, 2018

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.