Or, you could have a build system that does a 100% out-of-tree build into ./build, and then if the build is broken you delete that one directory. You hardly need git to help you with that.
Get a new job? You can't be that "in charge of" a repo if you can't enforce rules this basic. In fact, I don't understand how you can enforce something as (being polite) unusual as banning .gitignore and yet can't enforce build system hygiene.
> Or, you could have a build system that does a 100% out-of-tree build
I'm not sure what effect you think properly functioning build scripts in my project(s) are going to have on the broken build systems encountered in other projects. Those broken build systems continue to be broken, despite my projects' build scripts continuing to work as expected. Please advise.
> So all your fellow devs do `ln -s contrib/gitignore ./git/info/exclude`?
I don't know you think that will do or how symlinks work, but it won't lead to anything relevant to this discussion. (To answer your question: no.)
The symlink creates what is effectively a version-controlled gitignore. It would be the obvious way of getting around your arbitrary restriction (and how do you know they are not doing this, the symlink is not checked in).
My comment and the other replies show you how to use git to check and clean the files of the much maligned horked build script. These will work regardless of the gitignore contents.
But then again, pretty sure you are just having a laugh at our expense by taking this ridiculous position.
> The symlink creates what is effectively a version-controlled gitignore
No, it doesn't—like I already said. The ln(1) invocation you wrote is not going to work. As written, it contains two glaring errors obvious on sight to anyone who actually has enough experience with the particulars of /bin/ln and Git and how repos get populated with a default .git/info/exclude.
> My comment and the other replies show you how to use git
Yeah I guess there are things to nitpick about the ln. And ofc the comments are more for onlookers, to contextualize the poor decision making shown in banning .gitignore suggested by the original post. Obviously this is some emotional topic for you, seeing all the snarky and defensive responses (this particular one was edited and originally had ... more than just Gee, thanks!), so I will leave it at that.
Boy, those pesky emotions! Surely that's the culprit here, and not self-assured HN commenters showing up to hand out /r/confidentlyincorrect-tier advice that still wouldn't address anyone's problem even if it did work.
This is one of the strangest opinions I've seen in awhile. Your complaint seems like it should be pointed at projects not having a working "clean" make target.
Also:
git status --ignored
git clean -ndX # preview what would be removed
git clean -fdX # actually delete the files (warning: destructive)
Yeah, I don't know why you'd think, having taken care to add stuff to .git/info/exclude that doesn't belong in any commit that will make its way upstream (but nonetheless might be—and probably is—important work, maybe even the product of some non-trivial effort), that what I'd want is for it to be wiped out.
And `rm ./.gitignore` will, predictably, leave the tree without a ./.gitignore (i.e., the desired state) whereas `git status --ignore`, uh, won't.
cxr · · focus · HN ↗
[dead]
quietbritishjim · · focus · HN ↗
cxr · · focus · HN ↗
[dead]
quietbritishjim · · focus · HN ↗
cxr · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
cxr · · focus · HN ↗
I'm not sure what effect you think properly functioning build scripts in my project(s) are going to have on the broken build systems encountered in other projects. Those broken build systems continue to be broken, despite my projects' build scripts continuing to work as expected. Please advise.
Phemist · · focus · HN ↗
Also you can do `git status --ignored` and it will list all files changed, even if ignored. If that is really your main issue.
cxr · · focus · HN ↗
I don't know you think that will do or how symlinks work, but it won't lead to anything relevant to this discussion. (To answer your question: no.)
Phemist · · focus · HN ↗
My comment and the other replies show you how to use git to check and clean the files of the much maligned horked build script. These will work regardless of the gitignore contents.
But then again, pretty sure you are just having a laugh at our expense by taking this ridiculous position.
cxr · · focus · HN ↗
> The symlink creates what is effectively a version-controlled gitignore
No, it doesn't—like I already said. The ln(1) invocation you wrote is not going to work. As written, it contains two glaring errors obvious on sight to anyone who actually has enough experience with the particulars of /bin/ln and Git and how repos get populated with a default .git/info/exclude.
> My comment and the other replies show you how to use git
Oh, gee, thanks!
Phemist · · focus · HN ↗
cxr · · focus · HN ↗
athorax · · focus · HN ↗
Also:
[deleted] · · focus · HN ↗
[deleted]
cxr · · focus · HN ↗
And `rm ./.gitignore` will, predictably, leave the tree without a ./.gitignore (i.e., the desired state) whereas `git status --ignore`, uh, won't.
Supermancho · · focus · HN ↗