On Fri, Jun 17, 2016 at 11:51 AM, Eliot Miranda <[email protected]> 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.
Hi Eliot, Seems enough others must have felt the same that this was added to help... https://git-scm.com/docs/git-stage Perhaps it would be preferred to use "stage" over "add" in documenting the usual workflows for this project? cheers -ben
