Re: [PATCH v3 03/11] read-tree, merge-recursive: overwrite ignored files by default

From: Elijah Newren <newren@gmail.com>
Date: Dec 13, 2021, 20:10 UTC
Message-ID: <CABPp-BEZj4opBu+wo2whOCHrck1qMjZXfDY9tAE5FbB=Wr9F_w@mail.gmail.com>
In-Reply-To: <CA+6di1m91q70PfaFq0DKMsmd_Tb6XBB7H9AYPhwawX12cZgtGQ@mail.gmail.com>

On Mon, Dec 13, 2021 at 9:12 AM Jack O'Connor <oconnor663@gmail.com> wrote:

Show 19 quoted lines

>
> > read-tree, merge-recursive: overwrite ignored files by default
>
> When this patch shipped in v1.34, a test broke in a project of mine
> (https://github.com/buildinspace/peru/blob/e9ba6e0024ea08105a8d027f958899cca39aeb9a/tests/test_cache.py#L111-L117)
> that was relying on git read-tree *not* to respect .gitignore files.
> (Obligatory https://xkcd.com/1172.) That peru tool is using git
> plumbing commands to manage trees of files, but it tries to keep this
> implementation detail internal, and behaving differently in the
> presence of a .gitignore file belonging to the user would leak this
> internal implementation detail. I've been trying to figure out a way
> to reproduce the Git 1.33 behavior in Git 1.34, but so far I haven't
> found any flags or configs to do that. (For example, putting !* in
> .git/info/exclude doesn't seem to help, I think because a .gitignore
> file in the working tree takes precedence.) Can anyone suggest another
> workaround?
>
> This is my first mail to this list, so please let me know if I mess up
> the etiquette.

Your email is fine.  :-)  Interesting usage case; thanks for sending it along.

Digging a bit into your repository, it appears this all started because you noticed that checkout would overwrite ignored files, and so you switched to reset --keep (in your 637d5c042262 (make cache export refuse to pave .gitgnored files, 2014-07-22)) and then to read-tree (in your 057d1af600f9 (Rewrite `export_tree` to allow deleted files., 2014-08-05)) to avoid having ignored files be overwritten. You could have stuck with `git checkout` all along, and just passed it the --no-overwrite-ignore flag. You probably just missed the existence of that flag, because Duy forgot to document it for 8 years (see git.git's commit 9d223d43e5 ("doc: document --overwrite-ignore", 2019-03-29)) Going back to checkout might provide you a workaround. (Also, another random thing I noticed while looking at your repo: `--diff-filter=d` is a much better way of checking for not-deleted-changes than using `--diff-filter=ACMRTUXB`. Note the lowercase 'd' rather than uppercase.)

Your report suggests more places should accept the --no-overwrite-ignore flag, which I alluded to as a possibility in the sixth patch in the series ("Remove ignored files by default when they are in the way"[1]) and the comments in the cover letter about precious ignored files (under "SIDENOTE about treating ignored files as precious"[2]). And perhaps we could have a core.overwriteIgnore config option for setting a different global default (also as alluded to in my cover letter). Doing things would provide additional workarounds, and finally provide the "precious ignored" concept that has been discussed occasionally. I think it's not too hard to do that on top of my previous patch series. I'll try to take a look after some other in-flight series finally land.

[1] https://lore.kernel.org/git/b7fe354effff8da3de53bd9cc40a03b5fd455f67.1632760428.git.gitgitgadget@gmail.com/ [2] https://lore.kernel.org/git/pull.1036.v3.git.1632760428.gitgitgadget@gmail.com/