Re: [PATCH] gitignore: Move ignores from global to subdirectories

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Mon, Aug 31, 2020 at 10:04:54AM +0000, George Dunlap wrote:
> 
> Storing the extra paragraph in git is cheap; trying to reconstruct why 
> someone made a change 10 years after the fact is often difficult.  Probably 
> not worth a re-send ??? it can be moved into the commit message by the 
> committer; but if you???re going to send v2 anyway, might as well move it in.
> 

I'm pretty sure there will be at this point.  Just an issue of how many
more adjustments there will be.


On Mon, Aug 31, 2020 at 08:52:45AM +0200, Jan Beulich wrote:
> On 31.08.2020 08:37, Elliott Mitchell wrote:
> > On Fri, Aug 28, 2020 at 09:24:41AM +0200, Jan Beulich wrote:
> >> On 28.08.2020 04:57, Elliott Mitchell wrote:
> >>> Subdirectories which have .gitignore files should not be referenced in
> >>> the global .gitignore files.  Move several lines to appropriate subdirs.
> >>>
> >>> Signed-off-by: Elliott Mitchell <ehem+xen@xxxxxxx>
> >>>
> >>> ---
> >>> Hopefully the commit message covers it.  When moved to the subdirectories
> >>> I'm using "./<file>" as otherwise any file sharing the name in a deeper
> >>> subdirectory would be subject to the match.
> >>
> >> May I ask why this last sentence isn't part of the commit message?
> > 
> > My thinking is it was pretty straightforward to figure out when looking.
> > Not /quite/ obvious enough to avoid commenting in e-mail, but not quite
> > obscure enough to have in commit message.  This can go either way really.
> 
> Your statements below really look to me as if this wasn't this obvious
> at all - ...

Things were sufficiently obvious when it was important.  This though is
not an issue worthy of more discussion since I've got no real objection
to including the extra sentence.  I suspect there will be more changes
though...


> > The .gitignore files aren't very consistent.  I'm unsure whether it is
> > worth going after the inconsistencies, but it is certainly there.
> > 
> > Before this I noticed xen/xsm/flask/.gitignore had "/policy.c", which
> > overlapped with "xen/xsm/flask/policy.*" in the top-level .gitignore.
> > Checking the documentation on .gitignore files if it simply had
> > "policy.c", git would have ignored any file name "policy.c" in
> > subdirectories.
> > 
> > Is it better to prefix lines in the current directory with "./" versus
> > "/"?  (I kind of like "./" since it looks like a relative path, but it
> > *isn't* actually a relative path)
> 
> ... you even look to suggest here that there are two alternative
> forms which both have the same meaning. Personally I agree that
> ./ may be more "natural" to use than /, but the question then is
> what the conventions are. I can't answer this.
> 
> > Should files in subdirectories also include "./"?
> 
> If "no prefix at all" includes, as you say, also files in subdirs,
> then the answer probably is "depends".
> 
> > Preferences in sorting?
> 
> Alphabetical sorting is what we generally aim for here.

Going into specific example since those best demonstrate what I
observed.

Before this patch the top-level .gitignore included the lines:
@@
-tools/misc/cpuperf/cpuperf-perfcntr
-tools/misc/cpuperf/cpuperf-xen
-tools/misc/xc_shadow
-tools/misc/xen_cpuperf
-tools/misc/xen-cpuid
@@
-xen/xsm/flask/policy.*
-xen/xsm/flask/xenpolicy-*
 tools/flask/policy/policy.conf
 tools/flask/policy/xenpolicy-*
 xen/xen
@@

tools/misc/.gitignore had the single line:
xen-ucode

xen/xsm/flask/.gitignore had the single line:
/policy.c


You'll note from the second batch, .gitignore isn't consistently sorted.

xen/xsm/flask/.gitignore was actually good since it caused me to look at
the documentation for gitignore.  The effect is xen/xsm/flask/policy.c
is ignored, but xen/xsm/flask/policy/policy.c and
xen/xsm/flask/ss/policy.c will *not* be ignored.

tools/misc/.gitignore's format means if in the future subdirectories "a"
or "b" got created, tools/misc/a/xen-ucode and tools/misc/b/xen-ucode
*would* be ignored in addition to tools/misc/xen-ucode.  When looking at
the situation I decided this was /likely/ wrong, and so changed to
"./xen-ucode".

So there are a few variants of how tools/misc/.gitignore could look
after a patch.  Two sets of lines demonstrating the possibilities:

Example 0:
./cpuperf/cpuperf-perfcntr
./cpuperf/cpuperf-xen
./lowmemd
./xc_shadow

Example 1:
cpuperf/cpuperf-perfcntr
cpuperf/cpuperf-xen
/lowmemd
/xc_shadow

So which prefix is better for files in the current directory, "./" or
"/"?  "./" looks more like a reference to the current directory, "/" is
shorter and the single pre-existing example used the latter.

Should the paths "cpuperf/cpuperf-perfcntr" and "cpuperf/cpuperf-xen"
include that prefix?  I'm inclined towards having it everywhere for
greater consistency, but I'm not fully set in this strategy.


In other news, I think the tools/ and xen/ directories need their own
.gitignore files.  They are the largest portion of targeted filenames
and thus seem likely candidates for breaking off.

docs/ and stubdom/ are also candidates for similar action, though not as
big as the former.

This falls under the same heading of moving things from top-level
.gitignore to subdirectories, but since the above didn't already have
.gitignore files this could be worthy of a separate patch.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445