On 2014-08-22 10:23-0000 Arjen Markus wrote: > Hi everyone, > I have subscribed to the git mailing list, got a clone of the repository and > so should be able to do commits and see the result. I did in fact change one > thing and committed it, but presumably that is just in my local copy. I guess > I need to "push" the changes to get them into the "central" repository - if I > understand it all correctly. I hesitate because the Kitware document is not > clear on how to go about with bug fixes. And I am still trying to understand > the git command ;). > The change I made (to solve the immediate problem regarding SVG files that > are replotted) consists of some three lines of code, so nothng major. Still, > I would like confirmation that I am going about it the right way: > > - I cloned the repository from SF > > - I made my changes and did a (local) commit > > - I did not do anything wrt tags or branches, so my changes are likely > to be in the main branch > > - If I push these changes, then they should end up in the main branch > - if my understanding is correct > So, can I simply push this?
Hi Arjen: Congratulations on trying out git almost as soon as we went live! Until Hazen can create the README.git_workflow file generalizing the results at http://kevinold.com/2013/04/17/my-git-workflow.html for our exact needs, you should be paying strict attention to that URL. In particular, all your development should be on a local topic branch rather than the default branch you used above which would be master. Working on topic branches saves a lot of trouble on those occasions when you have to adjust your local master (i.e., with "git checkout master; git reset --hard <SHA-1 id>") to make it easier to integrate your work with others while avoiding the merge commits (any merge other than a "fast-foward" one) which are not allowed by our rebase workflow (and the push logic checking for merge commits that occurs with our SF repo). Assuming you pick the correct SHA-1 id that reset command gets rid of all your changes on the current branch (in this case master), but such a draconian deletion of your development work on master is fine if your changes are also safely stored on a topic branch. So for now and just to encourage good workflow practices from the start I suggest you save your changes temporarily elsewhere and start over with "git clone". Then follow strictly the above URL in setting up a topic branch and using that for your changes and making sure everything is up-to-date with your topic branch and master before you fast-forward merge your topic branch with master and push master. Also, just to give you some immediate help with your initial git experimentation use "git branch" to list existing branches, "git checkout <branchname>" to navigate between branches, and "git help <commandname>" for all commands. Furthermore, you will find that "git status" is very informative as well as "git log -<number>" where number is the number of commits you want to see from the log, e.g., "git log -3" for the last 3 commits. In particular, if origin/master (the local tracking branch that tracks the official SF repo master branch) is up to date with the SF version, git status shows no problems (other than your local master being ahead of origin/master), and git log says nothing about merge commits for your local changes to the master branch then your push should be fine. But as the above URL says, always use the --dry-run option first on pushes just to see exactly what will be pushed without actually doing the push. By the way, I have found it very helpful to setup a bare local "server" repository that has no content initially, and then interact with that "remote" using another repository with working directory following the startup directions in <http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server>. For that setup I deliberately made a lot of mistakes in our workflow to see how our update hook worked, and also used "git reset --hard" a lot to figure out the effects of that command (with the aid of "git status" and "git log") for various situations. An hour's play or so with a throwaway git server repo and a working directory repo, gives a lot of confidence about what you can do with git. @Hazen: please correct anything I said above if I got something wrong due to my git inexperience. 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 __________________________ ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
