On Thu, Jun 16, 2016 at 08:51:16PM -0700, Eliot Miranda wrote:
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 ;-)
The Linux Kernel development has some fairly strict rules about how patches are structured and what is included in each commit (which I can't remember now). One of the requirements is that you have a working system after each commit, and that it is fairly small in scope (they define "small" properly). git has a great "bisect" feature which makes it easy to go back and find where problems started, and structuring the commits is necessary for bisect to be easily usable. I also find it not particularly intuitive, but it is still a great tool once you understand it. Cheers, Alistair