From: Junio C Hamano <gitster@pobox.com>
To: Sebastian Thiel <sebastian.thiel@icloud.com>
Cc: git@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>
Subject: Re: [RFC] Define "precious" attribute and support it in `git clean`
Date: Tue, 10 Oct 2023 10:02:20 -0700 [thread overview]
Message-ID: <xmqqttqytnqb.fsf@gitster.g> (raw)
In-Reply-To: <79901E6C-9839-4AB2-9360-9EBCA1AAE549@icloud.com> (Sebastian Thiel's message of "Tue, 10 Oct 2023 14:37:36 +0200")
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.
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.
* 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.
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.
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.
[Reference]
* https://lore.kernel.org/git/7viptp9jos.fsf@alter.siamese.dyndns.org/
* https://lore.kernel.org/git/xmqqva534vnb.fsf@gitster-ct.c.googlers.com/
next prev parent reply other threads:[~2023-10-10 17:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 12:37 [RFC] Define "precious" attribute and support it in `git clean` Sebastian Thiel
2023-10-10 13:38 ` Kristoffer Haugsbakk
2023-10-10 14:10 ` Josh Triplett
2023-10-10 17:07 ` Junio C Hamano
2023-10-12 8:47 ` Josh Triplett
2023-10-10 19:10 ` Kristoffer Haugsbakk
2023-10-12 9:04 ` Josh Triplett
2023-10-10 17:02 ` Junio C Hamano [this message]
2023-10-11 10:06 ` Richard Kerry
2023-10-11 22:40 ` Jeff King
2023-10-11 23:35 ` Junio C Hamano
2023-10-12 10:55 ` Sebastian Thiel
2023-10-12 16:58 ` Junio C Hamano
2023-10-13 9:09 ` Sebastian Thiel
2023-10-13 16:39 ` Junio C Hamano
2023-10-14 7:30 ` Sebastian Thiel
2023-10-13 10:06 ` Phillip Wood
2023-10-14 16:10 ` Junio C Hamano
2023-10-13 11:25 ` Oswald Buddenhagen
2023-10-14 5:59 ` Josh Triplett
2023-10-14 17:41 ` Junio C Hamano
2023-10-15 6:44 ` Elijah Newren
2023-10-15 7:33 ` Sebastian Thiel
2023-10-15 16:31 ` Junio C Hamano
2023-10-16 6:02 ` Sebastian Thiel
2023-10-23 7:15 ` Sebastian Thiel
2023-10-29 6:44 ` Elijah Newren
2023-10-11 21:41 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqttqytnqb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=josh@joshtriplett.org \
--cc=sebastian.thiel@icloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).