Re: [RFC] Define "precious" attribute and support it in `git clean`
- From
Josh Triplett <josh@joshtriplett.org>
- Date
- Oct 14, 2023, 05:59 UTC
- Message-ID
- <ZSouSI_zPusOefsv@localhost>
- In-Reply-To
- <xmqqttqytnqb.fsf@gitster.g>
On Tue, Oct 10, 2023 at 10:02:20AM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> Sebastian Thiel <sebastian.thiel@icloud.com> writes: > > > I'd like to propose adding a new standard gitattribute "precious". > > ;-). > > Over the years, I've seen many times scenarios that would have been > helped if we had not just "tracked? ignored? unignored?" but also > the fourth kind [*]. The word "ignored" (or "excluded") has always > meant "not tracked, not to be tracked, and expendable" to Git, and > "ignored but unexpendable" class was missing. I even used the term > "precious" myself in those discussions. At the concept level, I > support the effort 100%, but as always, the devil will be in the > details.
"I've already wanted this for years" is, honestly, the best response we could *possibly* have hoped for.
Show 9 quoted lines
> Scenarios that people wished for "precious" traditionally have been > > * You are working on 'master'. You have in your .gitignore or > .git/info/exclude a line to ignore path A, and have random > scribbles in a throw-away file there. There is another branch > 'seen', where they added some tracked contents at path A/B. You > do "git checkout seen" and your file A that is an expendable file, > because it is listed as ignored in .git/info/exclude, is removed > to make room for creating A/B.
Ouch, I hadn't even thought about the issue of branch-switching overwriting a file like that, but that's another great reason to have "precious". (I've been thinking about "precious" as primarily to protect files like `.config`, where they'd be unlikely to be checked in on any branch because they have an established purpose in the project. Though, of course, people *do* sometimes check in `.config` files in special-purpose branches that aren't meant for upstreaming.)
Show 9 quoted lines
> * Similar situation, but this time, 'seen' branch added a tracked > contents at path A. Again, "git checkout seen" will discard the > expendable file A and replace it with tracked contents. > > * Instead of "git checkout", you decide to merge the branch 'seen' > to the checkout of 'master', where you have an ignored path A. > Because merging 'seen' would need to bring the tracked contents > of either A/B (in the first scenario above) or A (in the second > scenario), your "expendable" A will be removed to make room.
+1
Show 18 quoted lines
> In previous discussions, nobody was disturbed that "git clean" was > unaware of the "precious" class, but if we were to have the > "precious" class in addition to "ignored" aka "expendable", I would > not oppose to teach "git clean" about it, too. > > There was an early and rough design draft there in > > https://lore.kernel.org/git/7vipsnar23.fsf@alter.siamese.dyndns.org/ > > which probably is worth a read, too. > > Even though I referred to the precious _attribute_ in some of these > discussions, between the attribute mechanism and the ignore > mechanism, I am actually leaning toward suggesting to extend the > exclude/ignore mechanism to introduce the "precious" class. That > way, we can avoid possible snafu arising from marking a path in > .gitignore as ignored, and in .gitattrbutes as precious, and have to > figure out how these two settings are to work together.
Sounds reasonable.
> In any case, the "precious" paths are expected to be small minority > of what people never want to "git add" or "git commit", so coming up > with a special syntax to be used in .gitignore, even if that special > syntax is ugly and cumbersome to type, would be perfectly OK.
[Following up both to this and to Sebastian's response.]
One potentially important question: should the behavior of old git be to treat precious files as ignored, or as not-ignored? If the syntax were something like
$.config
then old git would treat the file as not-ignored. If the syntax were something like
$precious .config
then old git would treat the file as ignored.
Seems like it would be obtrusive if `git status` in old git showed the file, and `git add .` in old git added it.