Re: [dev] [surf] introduce .gitignore

From: Alexander Huemer <alexander.huemer_AT_xx.vu>
Date: Fri, 15 Mar 2013 09:45:22 +0100

On Thu, Mar 14, 2013 at 09:04:48PM +0100, Christoph Lohmann wrote:
> On Thu, 14 Mar 2013 21:04:48 +0100 Alexander Huemer
> <alexander.huemer_AT_xx.vu> wrote:
> > On Thu, Mar 14, 2013 at 05:51:14PM +0100, Christoph Lohmann wrote:
> > > On Thu, 14 Mar 2013 17:51:14 +0100 Christian Hesse <list_AT_eworm.de>
> > > wrote:
> > > > this introduces file .gitignore and makes git ignore files generates
> > > > on build process.
> > >
> > > Why is this needed? When suckless moves to the next hip vcs on the block
> > > another file needs to be introduced. So: No, just don’t add these files
> > > to be tracked and the changes will not be committed as change.
> > >
> >
> > It's best practice to have a .gitignore file.
> > I recommend it for all suckless subprojects.
> > You want to explicitly tell the VCS which files are not of interest for
> > it, it can not know by itself.
> > The move to a different VCS occurs very seldomly, in this case the
> > infrastructure has to be adopted. Porting the file ignore list is a very
> > easy task.
> > What are the downsides of having this besides the VCS move thing?
>
> The argumentation is different: What’s the advantage of having a .gitig‐
> nore file?

Again: To tell the VCS what files it should not care about.

> If I put some spare files into that directory, like patch
> files or some debug output, then git will tell me that these files are
> untracked too.

Exactly. With a proper .gitignore you will then see _only_ the files
that just appeared. That's how it's meant to be.
There is no reason to have patch files in a git controlled directory.
Apply and commit them. If you need version control for patches, use
topgit.

> Forcing the user to think of what’s explictly ignored is
> just adding complexity.

The vast majority of users do not have to think about that at all. They
clone the repository, add a configuration and compile. And the result of
that, object files and executables will _never_ be under version
control. That's why there is a .gitignore file.

> In the current state all files are shown which are not tracked, which
> is what git should do anyways.

That's a personal opinion and not how git is intended.

> While adding complexity to the untracked file list it’s not adding
> any advantage for anyone.

Again, just a personal opinion.

Of course personal opinion are fine and project maintainers are free to
do what they want, but that does not mean that a made decision is
clever.

Your argumentation sounds like having a .gitignore file is a bad idea,
at least useless. Everybody else seems to like the idea very much. Do
you have a lot of examples handy of projects that don't maintain
.gitignore files and gain benefit of that? I can list hundreds who love
it, but maybe there are just not smart enough.

Kind regards,
-Alex^Wblackbit
Received on Fri Mar 15 2013 - 09:45:22 CET