[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/11] Major rework of top-level .gitignore



On Thu, Sep 10, 2020 at 08:10:08AM +0200, Jan Beulich wrote:
> On 09.09.2020 03:28, Elliott Mitchell wrote:
> > The top-level .gitignore file for Xen has gotten rather messy.  Looks
> > like at times a few people may have added some blank lines looking
> > towards some later cleanup.  Alas no one ever got around to that later
> > cleanup.
> > 
> > When looking at one portion of the situation I ended up doing some
> > cleanup and it got out of hand.  Hence I'm not sending in these patches
> > which hopefully make things better.
> > 
> > Please note these are somewhat better than work-in-progress status.
> > There are several places I'm unsure of which direction to go in.  Likely
> > several of these will need more or less information in their commit
> > messages.
> > 
> > Overall pattern is first some initial cleanup on the top-level
> > .gitignore.  It is easier to spot targeted file matches which overlapped
> > general globs before breaking things apart.  This is followed by breaking
> > all targeted matches off of the global .gitignore file.  Lastly the
> > global .gitignore file was sorted and I've commented on a few of the
> > things which remain.
> > 
> > Recent versions of `git` include a "check-ignore" command.  For testing
> > new patterns `git check-ignore -vn --no-index <pattern>` will tell you
> > whether a given filename would be ignored without "add -f".
> > 
> > I think patches 01 and 02 are near ready for being committed.
> 
> Provided we as a community basically agree on the splitting. I'm
> not sure I've read this out of prior discussion.

Looking at things, I think this is the way to go.  The older OCAML pieces
needs some ignores which are distinct from what C or Python need.
Several portions of Xen appear to need some local patterns which differ
from what is in the general portion.

The downside of splitting is it makes it harder to identify patterns
which everyone has implemented variants of and should be moved to a
general pattern in the top-level .gitignore file.

> >  Patches
> > 03-09 need varying degrees of polish before being in an official tree.
> > Patches 10 and 11 are pretty well initial rough outlines.
> > 
> > Elliott Mitchell (11):
> >   gitignore: Move ignores from global to subdirectories
> >   gitignore: Remove entries duplicating global entries
> >   gitignore: Add/Generalize entries
> >   gitignore: Create .gitignore file for tools/firmware/
> >   gitignore: Create .gitignore file for tools/ocaml/
> >   gitignore: Create .gitignore file for xen/
> >   gitignore: Create .gitignore file for docs/
> >   gitignore: Create .gitignore file for stubdom/
> >   gitignore: Create .gitignore file for config/
> >   gitignore: Create .gitignore file for tools/
> >   gitignore: RFC Prelimiary final cleanup of top-level .gitignore
> 
> I'm confused about whether what I have in my inbox is complete and
> consistent: 01-11 don't look to be "in reply to" this one, and they
> all pre-date this mail by a varying number of days (Aug 27 ... Sep 3).
> Additionally, unlike what happens for every other sender these days,
> I've also got two copies of most (but not all) of them. Prior to our
> mail setup over here having changed over a year ago this was the
> normal way when I was Cc-ed on patches, but the server nowadays
> de-duplicates the mails. So something is likely odd with your setup.

I think there is a distinct chance I screwed up and got things mixed
together (joy! more strong evidence I'm not all here, now to win that
war to put me back together).


-- 
(\___(\___(\______          --=> 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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.