From: Piotr Krukowiecki Date: Sat, 19 Feb 2011 09:24:53 GMT Subject: Re: [RFC/PATCH 0/3] Thinning the git toplevel directory Message-ID: In-Reply-To: <7v39nkooem.fsf@alter.siamese.dyndns.org> On Sat, Feb 19, 2011 at 1:31 AM, Junio C Hamano wrote: > Piotr Krukowiecki writes: > >> My suggestions - put each category in their own dir/name space: >> >> - sources - developer related files you can hack >> >> - technical/developer documentation like format descriptions, >>   coding guidelines etc. >> >> - end user documentation like command documentation, howtos, faqs etc > > Mild nak.  We are talking about a source tree; there is no end-user > documentation.  Only the sources to it. That's what I was talking about. Examples of what I consider "end user docs": - git-add.txt, git-bisect.txt etc - probably for all commands in command-list.txt. Not sure about porcelain vs plumbing, but since division is not clear I'd put them all together. Note that not everyone compiles docs into man pages - for example I don't have needed tools on my laptop and it's not that fast too. I just have to use raw .txt files instead. - config.txt, probably some of howto/* Examples of "devel docs": howto/maintain-git.txt, technical/*, CodingGuidelines >> - build result - objects, final binaries, generated documentation etc >>   The advantage besides unclutterting is possibility to have sources on >>   read-only medium. > > This is somewhere between a meh to mild nak.  "git grep" knows to ignore > untracked cruft, so this does not help nor hinder "finding" at all. Even It requires me to use git-grep. I might be used to plain "grep". I might not have git installed yet. I might use some other tool for browsing/searching the source. Having "cruft" mixed with sources gives you restrictions without giving any advantages (at least I don't see any - if you do please tell me) . -- Piotrek