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@iee.org>
> > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > > > ---
> > > > >   .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@gmail.com/

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
>