Hi, On Sun, 25 Aug 2019, Philip Oakley wrote: > On 25/08/2019 20:09, SZEDER Gábor wrote: > > On Sun, Aug 25, 2019 at 02:20:32PM +0100, Philip Oakley wrote: > > > > > > On 25/08/2019 13:07, SZEDER Gábor wrote: > > > > On Mon, Jul 29, 2019 at 01:08:14PM -0700, Philip Oakley via GitGitGadget > > > > wrote: > > > > > Add the Microsoft .manifest pattern, and do not anchor the 'Debug' > > > > > and 'Release' entries at the top-level directory, to allow for > > > > > multiple projects (one per target). > > > > > > > > > > Signed-off-by: Philip Oakley <philipoakley@xxxxxxx> > > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > > --- > > > > > .gitignore | 5 +++-- > > > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/.gitignore b/.gitignore > > > > > index e096e0a51c..e7bb15d301 100644 > > > > > --- a/.gitignore > > > > > +++ b/.gitignore > > > > > @@ -230,6 +230,7 @@ > > > > > *.ipdb > > > > > *.dll > > > > > .vs/ > > > > > -/Debug/ > > > > > -/Release/ > > > > > +*.manifest > > > > This new line ignores the tracked file 'compat/win32/git.manifest' > > > > that was added fairly recently in fe90397604 (mingw: embed a manifest > > > > to trick UAC into Doing The Right Thing, 2019-06-27). > > > > > > > > I wonder whether that's intentional or accidental. This was an oversight of mine, my apologies. That line should go. > > > > I'm inclined to think that it's merely accidental, because, as far as > > > > I understand, this is an old-ish patch from times when there wasn't > > > > any 'git.manifest' file in tree, and simply noone noticed that in the > > > > meantime we got one. But I have no idea about how a Git build with > > > > Visual Studio is supposed to work, so it doesn't really matter what > > > > I'm inclined to think :) > > > > > > > At the time, it was just one of the many non-source files that were > > > generated by Visual Studio that cluttered the status list and also could > > > accidentally added to the tracked files. > > > > > > The newly added .manifest file does appear to be there to 'trick' the > > > Windows User Access Control (UAC) which otherwise can be an annoyance to > > > 'regular' users. > > Sorry, I'm not sure how to interpret your reply, and can't decide > > whether it tries to justify why that tracked file should be ignored, > > or explains that ignoring it was accidental. > > > > Anyway, ignoring that tracked file apparently triggered a nested > > worktree-related bug in 'git clean', which can lead to data loss: > > > > https://public-inbox.org/git/20190825185918.3909-1-szeder.dev@xxxxxxxxx/ Whoa. At least we found a bug via my oversight ;-) > Basically manifests are a build artefact from Visual Studio [1], so it was > just another file to be ignored, from a _source_ control control viewpoint. More precisely, manifest files are something specific to Windows, where you can embed metadata in an executable. Visual Studio auto-generated it under certain circumstances, but recent versions seem not to do that anymore. Ciao, Dscho > I hadn't fully appreciated the reason for your question, but I can now see how > the general 'ignore most, but keep an occasional' file type can be a problem > for the `git clean` filter, along with sub-module repos in sub-directories. It > probably extends beyond this special case .manifest file. > > I doubt that dscho wants to also do file renaming to achieve the trick that > added that file to avoid this. the clean command should never be ignoring (and > possibly deleting) tracked files. > > When clean hits a nested repo (maybe with .git directory - not sure of some of > the sub-module changes) then it should stop referring to that top level > gitignore, at least that's my expectation. The commit description in the > referenced patch appears to get the two parts inter-twined. > > Philip > [1] > https://docs.microsoft.com/en-us/cpp/build/manifest-generation-in-visual-studio?view=vs-2019 >
