Re: gitignore vs. exclude vs assume-unchanged?

[luc . linux]

On Fri, Apr 25, 2014 at 04:09:47PM -0700, a...@bellandwhistle.net wrote:
 Andrew Ardill andrew.ard...@gmail.com writes:
 
 As a data point, I have seen people add .gitignore to their
 .gitignore file, as they don't want to share the file.
 
 Right, I've seen that too.
That something I am actually doing in my projects, because I didn't
know they were other way to exclude files like .gitignore.

 It confused the heck out of me. It only lends
 credence to my point about the docs. Those users want the functionality of a
 pattern in '$GIT_DIR/info/exclude', but haven't been able to figure it out
 easily enough. They've just heard about .gitignore, so they're using that.
 Yes, it's all there in the docs if you read it several times, and you
 already know what you're looking at, but not in a terribly accessible, best
 practices, advice from a smart friend who's been through it all already
 kind of way.
 Well documentation can be useful when you know what you're looking for,
 but I won't go read it just for discovering new features I didn't know.

 Well, yes: semantics. Since they do slightly different things, they should
 have different names. It makes reference and teaching much easier. In fact,
 if a renaming were to occur, I would actually prefer even better semantics:
 
 .gitignore - .shared-ignore
 
 $GIT_DIR/info/exclude - $GIT_DIR/info/local-ignore
 
 These suggested names could perhaps be improved on. But if anything, the
 names need to be more different, not less. Users should be able to instantly
 know what a speaker is talking about without having to doublecheck and ask
 if by git-ignore, the speaker really meant git ignore or
 dot-gitignore.
I agree with a new name for .gitignore. A name like shared-ignore would
make explicite the fact it is shared, and then the user would look for
another way to locally exclude files. This would be a good approach, but
changing it won't be easy as most people already use .gitignore.

Would it be acceptable to have git display a warning when it detects
that .gitignore is excluding itself, with eventually a link to the
documentation or the path to $GIT_DIR/info/exclude ?



pgp468gFl5uiM.pgp
Description: PGP signature

Re: What is missing from Git v2.0

[luc . linux]

On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:
 On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
 Creating a ~/.gitconfig file if one doesn't already is one I agree
 with, and at least on Unix systems, telling them that the config file
 lives in ~/.gitconfig, or where ever it might happen to be on other
 platforms, is a good one.  If it's in some really weird place on
 Windows, then sure, we can tell them about git config -e.  But the
 point is to let the user look at the default .gitconfig file, where we
 can put in comments to help explain what is going on, and perhaps have
 links to web pages for more information.

I think the idea of a commented gitconfig is a good solution. We could
include default aliases commented, so that a new user would just have to
uncomment them. That way, he will understand they are aliases and not
commands, learn how to tune them to its own needs and it won't annoy
anyone because they will be commented by default, ideally with explicit
commentaries around them.

Furthermore, this could be a good way to show a new user all the
possibilities of git, or at least its configuration. Documentation is a
good thing when you know what you are looking for, but when you are
beginning, you don't know what can be done, and reading a complete and
commented example configuration could be a good way to discover it.



pgpbPbeQEGNjc.pgp
Description: PGP signature