I think the problem is the arcane interface and documentations. The verbiage in the documentation is unnecessarily difficult if not a computer science major.
I agree The Git Book is by far the best way I have found to learn it but the commands remain . I imagine they are some kind of balance between what operations are useful day-to-day and what is possible in respect to the program design but they fail so often because they have almost no consideration for interface design.
I just wrote a script for determining which files are ignored by .gitignore in a repository and the solution I arrived at is nothing short of painful to think about. It is ugly, anything but intuitive and impossible to build a test for. What is the excuse for this?
I'd be interested in that technique, he said, completely understanding the masochistic request.
I use git based deployments in a fair number of scenarios (where the .git directory is not web accessible). Git status is the perfect mechanism for detecting code changes, the primary of which being intrusion or developers working on production directly which should never happen.
Being able to detect the breadth of all the .gitignore files over the entire directory structure doesn't sound like a fun exercise but it would be a nice addition to be able to report on what ignored files exist. It's possible there's a command for this but I feel like you're confirming my assumption that such a thing doesn't exist.
Well, to give some perspective, the hg command to do what you want is hg status -i.
There are equivalent options to the hg status command to list only added, deleted, modified, deleted on disk but still tracked, files in the repo that are neither ignored nor tracked, and files that match the current checked-out commit. Admittedly, git status shows more information, but then again, hg usually doesn't need you to know about what you current state is to predict what will happen when you run a command.
I agree The Git Book is by far the best way I have found to learn it but the commands remain . I imagine they are some kind of balance between what operations are useful day-to-day and what is possible in respect to the program design but they fail so often because they have almost no consideration for interface design.
I just wrote a script for determining which files are ignored by .gitignore in a repository and the solution I arrived at is nothing short of painful to think about. It is ugly, anything but intuitive and impossible to build a test for. What is the excuse for this?