Jump to page: 1 2
Thread overview
From the cycle "Topic of the day" - .gitignore: how big is too big?
Mar 22, 2015
Jakob Ovrum
Mar 22, 2015
Daniel Murphy
Mar 22, 2015
Vladimir Panteleev
Mar 22, 2015
Vladimir Panteleev
Mar 22, 2015
Mengu
Mar 22, 2015
Mathias Lang
Mar 22, 2015
Mengu
Mar 23, 2015
Mengu
Mar 23, 2015
Jonathan M Davis
Mar 23, 2015
Jacob Carlborg
Mar 23, 2015
H. S. Teoh
March 22, 2015
I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087.

So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it?


Andrei
March 22, 2015
On Sunday, 22 March 2015 at 01:15:07 UTC, Andrei Alexandrescu wrote:
> I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087.
>
> So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it?
>
>
> Andrei

Aye, our tools should be configured to put temporary files and output files in uniform directories that can be .gitignore'd wholesale. The problem is not in .gitignore but our makefiles.
March 22, 2015
"Andrei Alexandrescu"  wrote in message news:mel52r$252b$1@digitalmars.com...

> I've left a comment recently at https://github.com/D-Programming-Language/phobos/pull/3087.
>
> So what's the deal with that? Whenever a new tool leaves some trash, do we chalk a circle on the pavement around it?

We add it to the .gitignore, then forget about it forever.  Having a long gitignore doesn't cost us anything. 

March 22, 2015
On 3/21/15 8:54 PM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:mel52r$252b$1@digitalmars.com...
>
>> I've left a comment recently at
>> https://github.com/D-Programming-Language/phobos/pull/3087.
>>
>> So what's the deal with that? Whenever a new tool leaves some trash,
>> do we chalk a circle on the pavement around it?
>
> We add it to the .gitignore, then forget about it forever.  Having a
> long gitignore doesn't cost us anything.

... but complicated/wrong clean rules in makefiles and clutter in ls. We should clean our shit. -- Andrei

March 22, 2015
On Sunday, 22 March 2015 at 05:56:56 UTC, Andrei Alexandrescu wrote:
> On 3/21/15 8:54 PM, Daniel Murphy wrote:
>> We add it to the .gitignore, then forget about it forever.  Having a
>> long gitignore doesn't cost us anything.
>
> ... but complicated/wrong clean rules in makefiles and clutter in ls. We should clean our shit. -- Andrei

I thought moving things around was also one of your pet peeves :)

I know for a fact that changing where win32.mak creates phobos.lib is going to break at least Digger and my own D build scripts which predate Digger. It will probably break others' workflow too. Adding lines to .gitignore seems more reasonable from that perspective.

posix.mak is already sensible in that it puts everything under generated/.
March 22, 2015
On 3/22/15 3:17 AM, Vladimir Panteleev wrote:
> On Sunday, 22 March 2015 at 05:56:56 UTC, Andrei Alexandrescu wrote:
>> On 3/21/15 8:54 PM, Daniel Murphy wrote:
>>> We add it to the .gitignore, then forget about it forever. Having a
>>> long gitignore doesn't cost us anything.
>>
>> ... but complicated/wrong clean rules in makefiles and clutter in ls.
>> We should clean our shit. -- Andrei
>
> I thought moving things around was also one of your pet peeves :)

Yah but I'm seeing pull requests "yeah there's some more junk out there, let's just add it to .gitignore". It seems to me like the wrong way to address the matter at hand.

> I know for a fact that changing where win32.mak creates phobos.lib is
> going to break at least Digger and my own D build scripts which predate
> Digger. It will probably break others' workflow too. Adding lines to
> .gitignore seems more reasonable from that perspective.

On Windows I'd speculate junk is even more of a problem - all of it appears right there in Explorer and other GUI tools. Doesn't that bother people?

> posix.mak is already sensible in that it puts everything under generated/.

Yah guess who did that :o).

Ionno at a higher level this is what bothers me: at work this wouldn't be debated - as soon as someone noticed, there'd be agreement and the matter would be looked at. I wish we had a better culture on the D team as well. It looks that as soon as anything remotely debatable comes around, belligerent mode is on.


Andrei

March 22, 2015
On Sunday, 22 March 2015 at 16:08:38 UTC, Andrei Alexandrescu wrote:
> On 3/22/15 3:17 AM, Vladimir Panteleev wrote:
>> I thought moving things around was also one of your pet peeves :)
>
> Yah but I'm seeing pull requests "yeah there's some more junk out there, let's just add it to .gitignore". It seems to me like the wrong way to address the matter at hand.

It is much easier to add a few lines to .gitignore than to fix the Makefile, then fix Digger, then fix my build scripts, then explain why the change was necessary to anyone who then complains that this broke their build. It is not a matter of which fix is better, but a matter of which is within my threshold of the effort I am ready to exert at the moment. If someone with a higher threshold and who is also bothered by the .gitignore mess comes along, all the better for everyone if they decide to fix the problem in a better way. Or do you adhere to the philosophy of "good enough is the enemy of better, so let's not fix anything unless we can fix it perfectly"?

Furthermore, I'm not sure if a "proper" fix along the lines of posix.mak is even possible, given the limitations of DM make.

> On Windows I'd speculate junk is even more of a problem - all of it appears right there in Explorer and other GUI tools. Doesn't that bother people?

My subjective answer is "yes, it is a minor nuisance, but in general, that's what .gitignore is for".

>> posix.mak is already sensible in that it puts everything under generated/.
>
> Yah guess who did that :o).
>
> Ionno at a higher level this is what bothers me: at work this wouldn't be debated - as soon as someone noticed, there'd be agreement and the matter would be looked at. I wish we had a better culture on the D team as well.

One is a controlled environment. Another is an open-source project. I had the impression that "move fast and break things" does not apply to D any more.

> It looks that as soon as anything remotely debatable comes around, belligerent mode is on.

I was not the one who created this thread. I was the one who created a pull request which improved the situation.
March 22, 2015
On 3/22/15 12:27 PM, Vladimir Panteleev wrote:
> On Sunday, 22 March 2015 at 16:08:38 UTC, Andrei Alexandrescu wrote:
>> On 3/22/15 3:17 AM, Vladimir Panteleev wrote:
>>> I thought moving things around was also one of your pet peeves :)
>>
>> Yah but I'm seeing pull requests "yeah there's some more junk out
>> there, let's just add it to .gitignore". It seems to me like the wrong
>> way to address the matter at hand.
>
> It is much easier to add a few lines to .gitignore than to fix the
> Makefile, then fix Digger, then fix my build scripts, then explain why
> the change was necessary to anyone who then complains that this broke
> their build. It is not a matter of which fix is better, but a matter of
> which is within my threshold of the effort I am ready to exert at the
> moment. If someone with a higher threshold and who is also bothered by
> the .gitignore mess comes along, all the better for everyone if they
> decide to fix the problem in a better way.

Fair enough. I'll drop this. -- Andrei


March 22, 2015
On Sunday, 22 March 2015 at 19:32:51 UTC, Andrei Alexandrescu wrote:
> On 3/22/15 12:27 PM, Vladimir Panteleev wrote:
>> On Sunday, 22 March 2015 at 16:08:38 UTC, Andrei Alexandrescu wrote:
>>> On 3/22/15 3:17 AM, Vladimir Panteleev wrote:
>>>> I thought moving things around was also one of your pet peeves :)
>>>
>>> Yah but I'm seeing pull requests "yeah there's some more junk out
>>> there, let's just add it to .gitignore". It seems to me like the wrong
>>> way to address the matter at hand.
>>
>> It is much easier to add a few lines to .gitignore than to fix the
>> Makefile, then fix Digger, then fix my build scripts, then explain why
>> the change was necessary to anyone who then complains that this broke
>> their build. It is not a matter of which fix is better, but a matter of
>> which is within my threshold of the effort I am ready to exert at the
>> moment. If someone with a higher threshold and who is also bothered by
>> the .gitignore mess comes along, all the better for everyone if they
>> decide to fix the problem in a better way.
>
> Fair enough. I'll drop this. -- Andrei

while we're at it, let's add D to this list: https://github.com/github/gitignore
March 22, 2015
On 3/22/15 1:37 PM, Mengu wrote:
> while we're at it, let's add D to this list:
> https://github.com/github/gitignore

That's be cool, any takers? -- Andrei
« First   ‹ Prev
1 2