Re: [PATCH 1/1] Introduce "precious" file concept
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 22, 2019, 09:46 UTC
- Message-ID
- <CACsJy8C377NmLv9edNYjinKAQf-P1y5+Nwhdj3vRkz_E__x43Q@mail.gmail.com>
- In-Reply-To
- <B168DCB1-7A69-4729-89C7-B513464DD468@gmx.net>
On Wed, Feb 20, 2019 at 6:11 PM Clemens Buchacher <drizzd@gmx.net> wrote:
Show 17 quoted lines
> >And requiring to mark trashable files manually duplicates a > >lot of ignore patterns. Have a look at any .gitignore file, the > >majority of them is for discardable files because "ignored" class was > >created with those in mind (*.o and friends). So now you would need to > >add more or less the same set of ignore rules in .gitattributes to > >mark them trashable, and gitignore/gitattributes rules are not exactly > >compatible, you can't just blindly copy them over. Every time you add > >one more .gitignore rule, there's a good chance you need to add a > >similar rule for trashable attribute. > > I agree that ignored precious files are typically a small subset of the ignore files. Maintaining separate rules for ignored files and for trashable files would result in a lot of duplication. > > On the other hand, how frequently do we really have to trash ignored files? Trashing a file should only be necessary if a tracked file overwrites an ignored file. When does this happen? I don't think it will happen for *.o files. So in most cases, there is simply no need to specify which files are precious. The default could simply be that all files are precious. > > To support more complex use cases, we could specify precious files in addition to ignored files. Only if we specify precious files (and/or enable the ignored-are-trashable config option on a repository level), all other files become trashable. > > Functionally this is equivalent the newbie option which you suggest, but I think it is not an issue of newbie vs experienced users but an issue of common vs special use cases.
So far the two conflicting cases are "git checkout/merge" and "git clean". Ignored files are valuable by default in the former, while it's expendable by default in the latter.
So if you add this ignored-are-trashable config key (defaults to false), git-clean -if will not do anything anymore. We _could_ advice the user to turn the config on (with all the consequences). I don't know if we have any other use cases that deserve the same advice.
Another option is simply leave the expendable/precious nature of ignored files undefined like it is now and handle case by case:
- git-clean learns to use a new attribute "clean". Undefined attribute is seen as +clean. To keep some files "precious" you update .gitattributes and add -clean rules. - git merge/checkout learns another attribute, checkout-overwrite-ignore? Undefined attribute is seen as -checkout-overwrite-ignore (i.e. abort the operation).
We stay away from any generic attribute name in this direction to make clear it's only applicable to specific use cases.
-- Duy