Re: [dev] [surf] introduce .gitignore
Greetings.
On Fri, 15 Mar 2013 14:15:32 +0100 William Giokas <1007380_AT_gmail.com> wrote:
> On Thu, Mar 14, 2013 at 09:04:48PM +0100, Christoph Lohmann wrote:
> > Greetings.
> >
> > On Thu, 14 Mar 2013 21:04:48 +0100 Alexander Huemer <alexander.huemer_AT_xx.vu> wrote:
> > > Hi,
> > >
> > > 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? 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. Forcing the user to think of what’s explictly ig‐
> > nored is just adding complexity. In the current state all files are
> > shown which are not tracked, which is what git should do anyways.
> >
> > While adding complexity to the untracked file list it’s not adding any
> > advantage for anyone. That’s why .gitignore is not added.
>
> You do realize that there are .hgtags files in most, if not all, of your
> repositories? What are those doing there but adding extra complexity?
> Just thought I'd bring that up, while we're going on about the unneeded
> complexity of a +4 patch. Great argument. (Granted, it should be a +4-73
> patch.)
Thanks for not sending a patch to remove them.
Sincerely,
Christoph Lohmann
Received on Fri Mar 15 2013 - 14:15:32 CET
This archive was generated by hypermail 2.3.0
: Fri Mar 15 2013 - 14:24:10 CET