All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Eric Engestrom <eric.engestrom@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH libdrm 2/2] gitignore: add _build
Date: Fri, 19 Oct 2018 10:19:30 -0700	[thread overview]
Message-ID: <20181019171930.GD4548@ldmartin-desk.jf.intel.com> (raw)
In-Reply-To: <20181016163815.lo2uegmu3eqjlvg7@intel.com>

On Tue, Oct 16, 2018 at 05:38:15PM +0100, Eric Engestrom wrote:
> On Tuesday, 2018-10-16 08:24:02 -0700, Lucas De Marchi wrote:
> > On 10/16/18 4:26 AM, Eric Engestrom wrote:
> > > On Monday, 2018-10-15 16:48:07 -0700, Lucas De Marchi wrote:
> > > > This is the directory used by meson/autotools (at least in the
> > > > .gitlab-ci configuration) so ignore the whole dir.
> > > 
> > > This is extremely specific to this one case; what does this change for
> > > the gitlab ci?
> > 
> > In order to test locally my changes I always copy and paste the line from
> > the CI configuration. And there we are using _build.
> 
> I understand better now, thanks :)
> 
> > Maybe we
> > should be using build there and add it to gitignore? We ignore .o, .lo,
> > .libs, .deps and build-aux dir. IMO we should ignore the whole build dir now
> > that we build out of tree - and _build (or build) dir is the most common to
> > use.
> 
> Those were autotools-generated files with partially-predictable names
> that were scattered across the source directory; this is considered bad
> practice nowadays and modern build systems don't do that anymore,
> instead letting the user choose a directory and putting everything in
> there. We could add all of these scattered generated files to the
> .gitignore, because we knew what the filenames looked like.

yeah, my point is entirely like we should support the new build system just like or
better than we support the old one.

> 
> With the new method, each user puts their build in their chosen folder,
> and while most of us usually chose something with "build" in the name,
> there is no structure to this anymore. It's best to simply add your
> preferred build-dir-naming-scheme to your clone's ignore list
> (.git/info/exclude), which I think is what most of us do (mine has
> a /build-*/ line for instance). You can also look at core.excludesfile
> if you want to add a global .gitignore for your machine.

I think that for specific cases that are different from what the majority use (or
at least what we have documented) could go indeed in that file. No reason to make
it always go there IMO.

> 
> That said, adding one more line to this file doesn't hurt, so you can do
> that if you want, I'm not nack'ing it, but we just can't open the door
> to everyone adding their own personal naming scheme to the upstream
> .gitignore :)

Agree. So what could we add to the .gitignore?

_build  (what we have in CI)
build   (what a lot of people use)
builddir (what we have in the README)

or 
/_build*
/build*

to cover all the common uses (and guarantee it's ignored only in the git root dir)


Lucas De Marchi



> 
> > 
> > And it looks like I forgot one patch adding patches/ to the gitignore as
> > well (it was what made me look into the gitignore in the first place) :-/.
> > Same reason as why  it was applied to igt for example: it's common to have a
> > patches/ directory to maintain wip patches.
> > 
> > Lucas De Marchi
> > 
> > > 
> > > > 
> > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> > > > ---
> > > >   .gitignore | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/.gitignore b/.gitignore
> > > > index 49cced50..54365c7c 100644
> > > > --- a/.gitignore
> > > > +++ b/.gitignore
> > > > @@ -24,6 +24,7 @@
> > > >   Makefile
> > > >   Makefile.in
> > > >   TAGS
> > > > +_build
> > > >   aclocal.m4
> > > >   autom4te.cache
> > > >   bsd-core/*/@
> > > > -- 
> > > > 2.19.1.1.g8c3cf03f71
> > > > 
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-10-19 17:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 23:48 [PATCH libdrm 1/2] gitignore: sort file Lucas De Marchi
2018-10-15 23:48 ` [PATCH libdrm 2/2] gitignore: add _build Lucas De Marchi
2018-10-16 11:26   ` Eric Engestrom
2018-10-16 15:24     ` Lucas De Marchi
2018-10-16 16:38       ` Eric Engestrom
2018-10-19 17:19         ` Lucas De Marchi [this message]
2018-12-17 17:43           ` Emil Velikov
2018-12-17 23:38             ` Lucas De Marchi
2018-10-16 11:24 ` [PATCH libdrm 1/2] gitignore: sort file Eric Engestrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181019171930.GD4548@ldmartin-desk.jf.intel.com \
    --to=lucas.demarchi@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric.engestrom@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.