git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jade Lovelace <lists@jade.fyi>
Cc: git@vger.kernel.org,  sebastian.thiel@icloud.com,
	 newren@gmail.com, josh@joshtriplett.org
Subject: Re: Precious files and the .jj directory
Date: Tue, 22 Jul 2025 10:09:19 -0700	[thread overview]
Message-ID: <xmqqzfcwrw3k.fsf@gitster.g> (raw)
In-Reply-To: <CAFA9we_yDs9SPL2pJU_WiUz8CqvQ8ZPHwXBfTzHHbt-QGV34qA@mail.gmail.com> (Jade Lovelace's message of "Tue, 22 Jul 2025 00:31:11 -0700")

Jade Lovelace <lists@jade.fyi> writes:

> I'm aware of the many discussions about precious files [1] [2] [3],
> but I wanted to highlight a particularly pernicious category of
> precious files that are really hard to do the right thing about with
> Git: namely, other version control systems. In particular, as I
> learned in [4], `git clean -ixd` will of course list `.jj` to delete
> and delete it if you have it in gitignore. But yet having it untracked
> results in it possibly accidentally getting added and also clutters up
> `git status`.

Yes, that is a very concise summary of what happens if you do not
support "ignored but precious" as a class of files distinct from
"ignored and expendable".  Git only supports the latter and we wish
we had also the former is where we are, after "many discussions" you
have read.

> It's my understanding that git has more file deletion edge cases of
> gitignored files than of untracked ones so the latter is theoretically
> safer. Is that correct?

Sorry, but I am not sure what apples and oranges you are comparing.

You list a thing in the .gitignore file or the .git/info/exclude
file (collectively known as "exclude mechanism") and the thing
becomes "ignored an dexpendable".  Your "add" will warn when you try
to add it, because it is ignored.  Your "checkout", "merge", etc.,
will happily overwrite such a path when it needs to be removed to
make room, because it is expendable.

You do not tell about a thing to the exclude mechanism, and the
thing is "untracked, not ignored".  Your "add" will happily add such
a path, because it is not ignored.  Your "checkout" and others will
play safer and more careful, avoid removing it, stop operation that
needs to remove the path in order to continue, because it is not
expendable.

The only solution would be to add proper support for ignored but
precious, I would think.

      parent reply	other threads:[~2025-07-22 17:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22  7:31 Precious files and the .jj directory Jade Lovelace
2025-07-22 15:19 ` Elijah Newren
2025-07-24 23:10   ` Martin von Zweigbergk
2025-07-22 17:09 ` Junio C Hamano [this message]

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=xmqqzfcwrw3k.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=josh@joshtriplett.org \
    --cc=lists@jade.fyi \
    --cc=newren@gmail.com \
    --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).