Finding the repository on sourceforge
Getting a copy
Your personal git info
Updating your copy
Committing a change
Reverting local changes
Looking at diffs
Examining history
Branching
Cleaning up old branches
Stashing local changes
Using git on MS Windows
Go to the gretl project page
at
http://sourceforge.net/projects/gretl/
and select the Code item on the taskbar.
Following on from the above: if you are not logged in you will see an instruction by means of which you can grab a read-only copy of the gretl-git sources, namely
git clone git://git.code.sf.net/p/gretl/git gretl-git
If you are logged in under your sourceforge USERNAME, and you have write privileges with git, you should see an instruction for getting a read-write copy, on the pattern
git clone ssh://USERNAME@git.code.sf.net/p/gretl/git gretl-git
These are shell commands. Obviously, if you need access to update translations you must use the second command.
Before doing anything substantive with git you should ensure that your basic personal information (name and email address) is known to the program. This can be done via two shell commands on the pattern:
git config --global user.name "Your Name" git config --global user.email "yourname@yourserver.ext"
As you might guess, the above commands will set username and email for any and all git repositories on your local machine, If you wish to set specific data for gretl commits, then change directory to your copy of the gretl-git repository and issue commands on the pattern above but omitting the --global option.
The git command to update your copy of the source is
git pull
So, very straightforward.
Having made a change that you wish to commit, you can do
git commit <filenames>
to register changes to a specific file or files, or
git commit -a
to commit any and all changes you have made. However, please note that in git the “commit” action does not upload your changes to the remote server (sourceforge). To do that you need add a “push”:
git push
This information is relevant only for gretl developers, who are in the business of making changes in the gretl code-base. It may happen from time to time (I speak from experience!) that you make some changes in your local copy of the gretl git sources and then decide (before committing) that some of these changes are ill advised, and you want to roll them back. One way of doing this is:
git checkout .
This will revert changes to files that are already tracked
by git
(known to be part of the code base) but not already staged
(set up
for a push via the git commit command).
To revert local changes that you have already committed/staged but not yet pushed, there are two variants:
git reset --soft HEAD~ git reset --hard HEAD~
The first of these just uncommits
the change, but does not revert the
state of your local files to HEAD. The second both uncommits the changes and
reverts your local files (or in other words, nukes
your changes altogether).
For a lot more on reverting changes, see this GitHub blog entry.
To see any updates in your working copy relative to the sourceforge repository, it's simple:
git diff
To inspect differences for a specific file, append the name of the file to this command.
To see any updates made in the sourceforge repository relative to your working copy:
git fetch origin git diff HEAD origin/master
Note that unlike pull, a fetch doesn't actually modify the files in your working copy, it just grabs information about what has changed in the repo.
Now suppose you've done a commit in your working copy but haven't yet (maybe inadvertently) done a push: how can you tell how your working copy differs from what's at sourceforge? Plain git diff won't do the job, but it's not so difficult:
git diff origin/master
To see a simple record of the commits to an individual file you can do:
git log -- filename
Or if you want to see what exactly was changed at each commit, in the form of a patch, do:
git log -p -- filename
To create a new branch, and then switch onto it:
git branch newbranch git checkout newbranch
or use this shortcut: git checkout -b newbranch.
To push a new branch upstream and set up tracking:
git push -u origin newbranch
To switch back to master locally:
git checkout master
To merge newbranch into master:
git checkout master git merge newbranch
To delete somebranch:
git branch -d somebranch
and to delete it upstream too:
git push origin --delete somebranch
When branching has been going on for some time, you may end up with references to defunct branches in your local copy: branches that were at one time active at “origin” but have since been merged and/or deleted. How to get rid of these dangling references? Fairly simple, though not totally easy to remember:
git remote prune origin
Stashing is particularly useful if you want to pull from the remote repository but have changes in your working copy that are not committed, and you don't really want to commit them yet. The command git stash will save your changes out of harm's way. If and when you're ready to revive those changes you can do:
git stash pop
to pull the last-stashed changes out of the stack and apply them to your working copy. There are lots of other possible stash actions, the most common probably being git stash list for a summary of what's in the stash and git stash show for details.
The following from beanstalk looks like a good guide: Working with Git on Windows.
John Anderson's 13 Git tips for Git's 13th birthday (April 2018): some nice refinements here!
Allin Cottrell, last revised 2021-04-25