On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Alistair,
On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: Hi All,
so after fixing "git remote get-url origin" to fail over to "git remote show origin | filter and munge" the culture shock of "git commit -a" (git commit does nothing ?!?!?)
"git commit" will commit anything that has been "git add"ed to the index. -a is a convenience to automatically stage files that have been modified.
What I don't understand is how, or indeed why, one stages modified files. I get that adding files requires informing git. But why doesn't "git commit" commit modified files by default? Why do I have to use git commit -a to include modified files?
Because you can choose what files will be part of the commit (cherry-picking changes).
Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Add ferchrissakes. It's absurd. At least I'll get used to it now ;-)
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/