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.hue...@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 <l...@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
