git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Raúl Núñez de Arenas Coronado" <raulnac@gmail.com>
Cc: git@vger.kernel.org,  Elijah Newren <newren@gmail.com>,
	Phillip Wood <phillip.wood@dunelm.org.uk>,
	Sebastian Thiel <sebastian.thiel@icloud.com>
Subject: Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory
Date: Mon, 22 Jan 2024 13:42:05 -0800	[thread overview]
Message-ID: <xmqq5xzlrqoi.fsf@gitster.g> (raw)
In-Reply-To: <CAGF1KhU=o2rb-tCjZAG278kgoW50NYymsJakUwiMxWTQ33gQYA@mail.gmail.com> ("Raúl Núñez de Arenas Coronado"'s message of "Mon, 22 Jan 2024 22:07:03 +0100")

Raúl Núñez de Arenas Coronado <raulnac@gmail.com> writes:

> ... I was thinking about what git itself
> does when ignoring files, especially when dealing with .gitgnore files
> in subdirectories, but clearly this needs a different policy, yes.

What "git" internally does is the equivalent of using the
"--exclude-per-directory" option to honor ".gitignore" in the
subdirectories, and in addition use ".git/info/exclude" as another
source, pretty much the same way as "--exclude-from" reads it.

> What I needed from this command is a way of backing up some ignored
> files. These files should not go into the repository, but I'm using
> them temporarily for development so it is a good idea to back them up.
> I'll just backup the entire repository instead, is not a big deal :))

The current mechanism can be used to list "ignored" files that must
be left out of the project (e.g. the most obvious one being object
files "*.o") but these "ignored" files are considered "expendable"
(i.e. Git is allowed to remove it as needed, e.g., when switching
branches and need to make room---if you have an untracked file F
that is ignored, checking out a branch that has a file F/G requires
the file F to disappear so that a directory can be created there).

We have been discussing to extend the mechanism so that we can have
"precious" files, which also will be left out of the project (e.g.,
"git add ." will not add to the index, just like an ignored file)
but are not considered "expendable".  If file F is "precious":

 - "git add ." will not add F to the index

 - "git status" will not say F is left untracked and can be added

 - "git clean -f" will not remove it.

 - checking out a branch with a tracked file F/G will *fail*, to
   prevent the loss of file.

No code yet, but the design consensus is almost there.  Once it
appears, you should be able to say "give me the list of tracked and
precious paths---I do not care about ignored ones that are expendable,
because they can be recreated mechanically and that is why they are
marked ignored", and from such a list of files, you should be able
to drive your back-up solution.

[jc: cc'ed those who are involved in the "precious" discussion].



  reply	other threads:[~2024-01-22 21:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAGF1KhWNaO_TUuCPo2L_HzNnR+FnB1Q4H6_xQ2owoH+SnynzEg@mail.gmail.com>
2024-01-22 20:45 ` Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory Raúl Núñez de Arenas Coronado
2024-01-22 20:52   ` Junio C Hamano
2024-01-22 21:07     ` Raúl Núñez de Arenas Coronado
2024-01-22 21:42       ` Junio C Hamano [this message]
2024-01-23  6:08         ` Raúl Núñez de Arenas Coronado
2024-01-22 21:34   ` Jeff King
2024-01-22 21:45     ` Junio C Hamano
2024-01-22 21:59       ` Jeff King
2024-01-24  2:58         ` Elijah Newren
2024-01-24 17:06           ` Junio C Hamano
2024-01-24 18:57             ` Jeff King
2024-01-23  5:40     ` Raúl Núñez de Arenas Coronado
2024-01-24  1:09       ` Jeff King
2024-01-24 14:22         ` Raúl Núñez de Arenas Coronado

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=xmqq5xzlrqoi.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=raulnac@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).