mingw.org-wsl .gitignore

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

mingw.org-wsl .gitignore

Earnie Boyd
I'm adding the following entries:

obscure/*
junk/*
temp/*
ChangeEntry*
ChangeItem*

The file already contains:

Makefile
aclocal.m4
configure
.*.swp
*~
*.log
*.bak
autom4te.cache
missing
depcomp
install-sh


Any discussion for these?  Are there more or less entries needed?
What about hg, what should be added?

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Keith Marshall-3
On 09/10/12 14:15, Earnie Boyd wrote:
> I'm adding the following entries:
>
> obscure/*
> junk/*
> temp/*

These seem reasonable, but can you not simply ignore the directories?

> ChangeEntry*
> ChangeItem*

I'll need to research your earlier posts, to fully understand your
intent for these; if you don't want them tracked, then okay.

> The file already contains:
>
> Makefile

Yes, this is a generated file, so shouldn't be tracked following an
in-source configure.

> aclocal.m4

Uhmm, no.  This is a fundamental, maintainer written component of the
build system; it should be tracked.

> configure

Yep.  Another generated file, so shouldn't be tracked.

> .*.swp
> *~
> *.log
> *.bak

All temporaries, or generated, so correct to ignore.

> autom4te.cache

Here, you are correctly ignoring a named directory; (hence my query
above, but certainly okay).  This is a "must-ignore", because it's
always generated in source, when you run autoconf.

> missing
> depcomp
> install-sh

Aren't these build-aux candidates?  We can either import each of them
individually, and explicitly, or we can import all of build-aux as a
submodule.  Either way, it seems wrong to ignore them.

> Any discussion for these?

See inline comments above.

> Are there more or less entries needed?

I'd also add config.status; it's generated during an in-source run of
configure.

> What about hg, what should be added?

.hgignore: should be tracked.  Same content, but slightly different
syntax.  I'll formulate it when I need it, if no one else gets there
first.  (You can find an example in the mingw-get repository).

--
Regards,
Keith.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Earnie Boyd
On Tue, Oct 9, 2012 at 4:01 PM, Keith Marshall wrote:
> On 09/10/12 14:15, Earnie Boyd wrote:
>> I'm adding the following entries:
>>
>> obscure/*
>> junk/*
>> temp/*
>
> These seem reasonable, but can you not simply ignore the directories?
>

Hmm, probably.  It just seems to have a clearer meaning when seeing it.

>> ChangeEntry*
>> ChangeItem*
>
> I'll need to research your earlier posts, to fully understand your
> intent for these; if you don't want them tracked, then okay.
>

See the "RFC: Repository workflow ..." subject.

>> The file already contains:
>>
>> Makefile
>
> Yes, this is a generated file, so shouldn't be tracked following an
> in-source configure.
>
>> aclocal.m4
>
> Uhmm, no.  This is a fundamental, maintainer written component of the
> build system; it should be tracked.
>

It is also a generated one but we're not using Automake for this one
so I'll remove it.

>> configure
>
> Yep.  Another generated file, so shouldn't be tracked.
>
>> .*.swp
>> *~
>> *.log
>> *.bak
>
> All temporaries, or generated, so correct to ignore.
>
>> autom4te.cache
>
> Here, you are correctly ignoring a named directory; (hence my query
> above, but certainly okay).  This is a "must-ignore", because it's
> always generated in source, when you run autoconf.
>

Rather obvious it needs to be ignored.

>> missing
>> depcomp
>> install-sh
>
> Aren't these build-aux candidates?  We can either import each of them
> individually, and explicitly, or we can import all of build-aux as a
> submodule.  Either way, it seems wrong to ignore them.
>

Yes, but they are generated again by Automake (I started to use it and
chose later not to).  I'll remove it.  I am using the build-aux as a
sub-module.

>> Any discussion for these?
>
> See inline comments above.
>
>> Are there more or less entries needed?
>
> I'd also add config.status; it's generated during an in-source run of
> configure.
>

Yes, I should add config.status.

>> What about hg, what should be added?
>
> .hgignore: should be tracked.  Same content, but slightly different
> syntax.  I'll formulate it when I need it, if no one else gets there
> first.  (You can find an example in the mingw-get repository).

I'll take a look, I'll definitely add .hgignore to .gitignore.  The
.hgignore file can be added later.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Charles Wilson-8
In reply to this post by Keith Marshall-3
On 10/9/2012 4:01 PM, Keith Marshall wrote:
>> aclocal.m4
>
> Uhmm, no.  This is a fundamental, maintainer written component of the
> build system; it should be tracked.

Not if automake/aclocal is used. In that case, aclocal.m4 is generated
and acinclude.m4 is handwritten. Dunno if that applies in this case.

>> missing
>> depcomp
>> install-sh
>
> Aren't these build-aux candidates?  We can either import each of them
> individually, and explicitly, or we can import all of build-aux as a
> submodule.  Either way, it seems wrong to ignore them.

They are build-aux candidates. The files are maintained by the automake
project, and will get copied into AC_CONFIG_AUX_DIR by automake/autoreconf.

I repeat my original statement that IF automake is used, then build-aux/
ought contain neither tracked files nor a submodule, but instead should
be an empty dir populated by running automake --add-missing --copy (or
autoreconf -i)

Now, if automake is not in use, well...I prefer explicitly tracked files
to submodules, because the former gives greater control over OUR build
system, and the latter...submodules suck. :-)

--
Chuck


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Keith Marshall-3
In reply to this post by Earnie Boyd
On 09/10/12 23:16, Earnie Boyd wrote:

> On Tue, Oct 9, 2012 at 4:01 PM, Keith Marshall wrote:
>> On 09/10/12 14:15, Earnie Boyd wrote:
>>> I'm adding the following entries:
>>>
>>> obscure/*
>>> junk/*
>>> temp/*
>>
>> These seem reasonable, but can you not simply ignore the directories?
>
> Hmm, probably.  It just seems to have a clearer meaning when seeing it.

To you, maybe; the converse seems more rational to me, but it's not an
especially important issue.

>>> ChangeEntry*
>>> ChangeItem*
>>
>> I'll need to research your earlier posts, to fully understand your
>> intent for these; if you don't want them tracked, then okay.
>
> See the "RFC: Repository workflow ..." subject.

Thanks.  I'd seen the reference on a cursory initial read, but felt I
needed more time to digest it.  Personally, I don't see the need for
these latter two[*], but if you find them useful, that's okay.

[*] I normally just accumulate branch specific ChangeLog entries in
place, on their respective branches.  Sure, that normally creates merge
conflicts, but, perhaps because hg is more helpful[**] than git during
merges, I've never found that to be a significant problem.

[**] hg offers to resolve conflicts interactively, during the merge
operation itself; with vim configured as my editor, I see a three-way
vimdiff of the two parent heads vs. the merged result, and it doesn't
usually entail too much effort to refine this.

>>> aclocal.m4
>>
>> Uhmm, no.  This is a fundamental, maintainer written component of the
>> build system; it should be tracked.
>
> It is also a generated one

No, it isn't in this context.

> but we're not using Automake for this one so I'll remove it.

Strictly, it may be generated if you use the aclocal tool (from the
automake suite).  That may seem a pedantic distinction; the important
point is that, in this case, it's hand crafted, so removal of the
.gitignore reference is appropriate.  Thanks.

>>> autom4te.cache
>>
>> Here, you are correctly ignoring a named directory; (hence my query
>> above, but certainly okay).  This is a "must-ignore", because it's
>> always generated in source, when you run autoconf.
>
> Rather obvious it needs to be ignored.

Sure, but my points were rather:

1) Inconsistency in convention for specifying ignored directories; (bare
dirname vs. dirname/* notation).

2) Unlike other generated files, which appear in the *build* tree,
autom4te.cache is created in the top *source* directory; you might get
away with omitting config.status, config.log, Makefile, and other build
time generated files, if you habitually build out of source, (although
it's still a good idea to include them); omission of autom4te.cache,
from the ignored set, *will* (eventually) bite someone.

>>> missing
>>> depcomp
>>> install-sh
>>
>> Aren't these build-aux candidates?  We can either import each of them
>> individually, and explicitly, or we can import all of build-aux as a
>> submodule.  Either way, it seems wrong to ignore them.
>
> Yes, but they are generated again by Automake

Strictly not generated, but rather copied from automake/autoconf
supplied masters, if automake is run with --add-missing, and they are
deemed necessary.  Once again, that's mostly a pedantic distinction;
more importantly, you still want them to become formal components of
your source distribution, even if they were added by automake, so you
really shouldn't include them in the ignored set.

> (I started to use it and chose later not to).

I'm pleased you made that choice.  I don't want to go over old ground
again.  You already know my opinion of automake; (I think it creates
more problems than it solves).

> I'll remove it.

Thanks.

> I am using the build-aux as a sub-module.

That's okay.  We may need to add .hgsub (and maybe also .hgsubstate) for
hg users; (I'll do that eventually, if no other hg user does so first).
  These need to be tracked, so definitely *shouldn't* appear
in .gitignore

>>> What about hg, what should be added?
>>
>> .hgignore: should be tracked.  Same content, but slightly different
>> syntax.  I'll formulate it when I need it, if no one else gets there
>> first.  (You can find an example in the mingw-get repository).
>
> I'll take a look, I'll definitely add .hgignore to .gitignore.

You *shouldn't* do that!  If it isn't tracked, its omission from some
future clone will eventually bite someone, (probably me).  Let *both*
git and hg track *both* of .gitignore and .hgignore

> The .hgignore file can be added later.

Sure; no problem.

--
Regards,
Keith.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Keith Marshall-3
In reply to this post by Charles Wilson-8
On 10/10/12 11:01, Charles Wilson wrote:
> On 10/9/2012 4:01 PM, Keith Marshall wrote:
>>> aclocal.m4
>>
>> Uhmm, no.  This is a fundamental, maintainer written component of the
>> build system; it should be tracked.
>
> Not if automake/aclocal is used. In that case, aclocal.m4 is generated
> and acinclude.m4 is handwritten. Dunno if that applies in this case.

It doesn't.  See my earlier reply to Earnie, which crossed with this in
the "post".

>>> missing
>>> depcomp
>>> install-sh
>>
>> Aren't these build-aux candidates?  We can either import each of them
>> individually, and explicitly, or we can import all of build-aux as a
>> submodule.  Either way, it seems wrong to ignore them.
>
> They are build-aux candidates. The files are maintained by the automake
> project, and will get copied into AC_CONFIG_AUX_DIR by automake/autoreconf.
>
> I repeat my original statement that IF automake is used, then build-aux/
> ought contain neither tracked files nor a submodule, but instead should
> be an empty dir populated by running automake --add-missing --copy (or
> autoreconf -i)

With respect, I *strongly* disagree with this, on a conceptual basis.
See, this is one of those problems that automake *creates*, (rather than
solves); if you are going to allow automake to populate your build-aux
directory, (using --add-missing), that's a step which should be
performed only once, by the lead maintainer of the package.  Thereafter,
the imported files *must* be tracked within the project, independently
of any external changes made by the automake folks.

If we follow your recommendation, then we create potential for you and I
to have subtly different versions of the imported files within our
supposedly current working trees, and who's to say which of us has the
definitively correct representation of the project state?  Please don't
go there; this is the stuff of which nightmares are made.

> Now, if automake is not in use, well...I prefer explicitly tracked files
> to submodules, because the former gives greater control over OUR build
> system, and the latter...submodules suck. :-)

In your opinion, maybe.  With the exception of the disappearing gitlink
issue, (which actually hasn't created any real problem for me anyway),
having build-aux as a *mercurial* submodule is working just fine for me.
  However, if we're talking *git* submodules, then I tend to agree: it
appears to me that git's submodule implementation *does* suck.

--
Regards,
Keith.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Earnie Boyd
In reply to this post by Keith Marshall-3
On Wed, Oct 10, 2012 at 7:08 AM, Keith Marshall wrote:

>>>> ChangeEntry*
>>>> ChangeItem*
>>>
>>> I'll need to research your earlier posts, to fully understand your
>>> intent for these; if you don't want them tracked, then okay.
>>
>> See the "RFC: Repository workflow ..." subject.
>
> Thanks.  I'd seen the reference on a cursory initial read, but felt I
> needed more time to digest it.  Personally, I don't see the need for
> these latter two[*], but if you find them useful, that's okay.
>

With the new workflow I've given, I don't either.

> [*] I normally just accumulate branch specific ChangeLog entries in
> place, on their respective branches.  Sure, that normally creates merge
> conflicts, but, perhaps because hg is more helpful[**] than git during
> merges, I've never found that to be a significant problem.
>
> [**] hg offers to resolve conflicts interactively, during the merge
> operation itself; with vim configured as my editor, I see a three-way
> vimdiff of the two parent heads vs. the merged result, and it doesn't
> usually entail too much effort to refine this.
>

Yea, git has an interactive option as well.  I was just trying to
avoid the need to deal with it.  Honestly the amount of people working
on it at the moment probably will never present a conflict.  I hope
that changes in the future.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Earnie Boyd
In reply to this post by Keith Marshall-3
On Fri, Oct 12, 2012 at 4:56 AM, Keith Marshall wrote:
>   However, if we're talking *git* submodules, then I tend to agree: it
> appears to me that git's submodule implementation *does* suck.

Maybe but it does work as documented.  It also gives a common
repository for such commonly used files so that the whole of MinGW.org
can make use of a more current version.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: mingw.org-wsl .gitignore

Charles Wilson-8
On 10/12/2012 4:09 PM, Earnie Boyd wrote:
> On Fri, Oct 12, 2012 at 4:56 AM, Keith Marshall wrote:
>>   However, if we're talking *git* submodules, then I tend to agree: it
>> appears to me that git's submodule implementation *does* suck.
>
> Maybe but it does work as documented.  It also gives a common
> repository for such commonly used files so that the whole of MinGW.org
> can make use of a more current version.
>

FYI, I haven't been saying a whole lot in these various threads b/c I've
been (and will likely continue to be) pretty swamped @ $realjob. I'm
going to have to take a back seat and let you guys determine how we go
forward with git/hg and the various workflow discussions; whatever you
decide I promise not to complain...too much.

Honestly I just want to get the next version of msys-m4 out the door so
that people can use the latest auto* if they want to...

--
Chuck


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr