On Sat, Feb 19, 2011 at 1:31 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html