On Thu, Jun 16, 2016 at 08:51:16PM -0700, Eliot Miranda wrote: > > > > On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <[email protected]> > > wrote: > > > >> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <[email protected]> > >> wrote: > >> Hi Alistair, > >> > >> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <[email protected]> > >> 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
