Luc,

We discussed your "git add -p" suggestion in our group meeting just now, and nobody here could explain why the command would be "git add" rather than "git commit".  So if you want to commit all of your changes at once you would use "git commit", but not "git add"?  Or is "git add" mandatory anytime you want to commit any change and it is only the "-p" flag that is optional?

The fact that we don't understand the paradigm and that we still have long discussions about syntax indicates to me that we are not ready for the switchover here at CCI.  More discussion may serve to remedy this.

Nick

Nicholas K. Sauter, Ph. D.
Computer Staff Scientist, Molecular Biophysics and Integrated Bioimaging Division
Lawrence Berkeley National Laboratory
1 Cyclotron Rd., Bldg. 33R0345
Berkeley, CA 94720
(510) 486-5713

On Tue, Jan 12, 2016 at 12:18 PM, Luc Bourhis <luc_j_bourhis@mac.com> wrote:
Another way to slice what Graeme has just written is that there are two orthogonal aspects to git: the delocalised, collaborative, multi-branching thingy on one hand and a better version control purely locally on the other hand. One can ignore completely the former and still ripe the benefits of the latter.

For example, let’s say you start to fix a bug and in the process you end up having to introduce new features and/or fix other things to make it work. After getting it all to work, you would really like to be able to split your changes in several commits, each concern with one feature/fix, even if some of these separate changes happened at different lines of the same file. With SVN, it’s so painful to do that most people will just commit it all in one commit. With ‘git add -p’, you can add chunk by chunk the changes related to each other to a first commit. Then proceed the same with a second commit. Etc. This is one of the feature which sold me on git.

Best wishes,

Luc


_______________________________________________
cctbxbb mailing list
cctbxbb@phenix-online.org
http://phenix-online.org/mailman/listinfo/cctbxbb