Hi Arjen: I am changing the subject line for obvious reasons....
On 2015-01-30 09:40-0000 Arjen Markus wrote: > [.... A]t this stage I want to stick to the receipe :) Exactly. And this is a perfect example why the detailed recipe is the thing to follow. If you decided to use git checkout master git pull that is indeed exactly equivalent to git checkout master git fetch git merge origin/master But that last command is potentially dangerous and could lead to a merge commit (if the local master has been updated in any way since the last time you pushed from local master to the combination of origin/master + repository). Which is why README.developers say to never use "git pull", and whenever you use git merge always use the --ff-only option. So instead of either set of commands above you should be following the detailed recipe which is git checkout master git fetch git merge --ff-only origin/master where that --ff-only option guards against making a merge commit to your local master branch, i.e., checks there has been no changes to to master branch since the last time you pushed. Also, if "git fetch" is silent, that means your local master is already identical to the repository master branch and origin/master so that final "git merge --ff-only origin/master" command becomes superfluous. > I am beginning to understand what the steps are doing and I have no problem following the receipe as long as I understand what to expect – less chance of me getting frustrated about it. I am really pleased you are beginning to feel more comfortable with git now. Also to respond to another comment you made, git indeed takes more commands to make a commit than svn. That's because svn has just one built-in workflow (rebase only) while for git there are many workflow possibilities so to choose one of them (in our case we are continuing with rebase only) takes additional effort/commands. So the naive conclusion just based on that git issue is everyone should migrate from git to svn. However, the many extra features you get with git (such as its substantial speed compared to svn because virtually everything is done with a local repository) make that additional effort worthwhile, and because of those features the net migration is from svn to git instead. So frankly I would never want to go back to svn, and this appears to be a fairly common reaction for svn users who have used git exclusively and intensively for their development for more than a month or so. That practice makes the commands you need to follow the workflow just become automatic for you so the fact that more commands are involved than the svn case just plain doesn't register any more. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
