Taggit

Upgrade to git 2.5.0 on Ubuntu

Git-Logo

Git, kickass distributed VCS

Running an Ubuntu 12.04 on a 2008 laptop (which I should change, but didn’t find a decent replacement yet) means that sometimes I’m not getting the latest software available by default.
For example, I just figure out that my git version was 1.9.1, while the latest available, ATOW, is 2.5.0, so I have decided to upgrade.

Conveniently there is a ppa that provides the latest and the greatest version of git for Ubuntu. Enable it and you will have the latest git running on your system:

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git

Check you have the latest

$ git --version
git version 2.5.0

Now the big question: Is upgrading really necessary? I do not really know. However being a person that creates software, I can tell you that running the most up-to-date system and software is, in most cases, a good idea.

What do I do when my Pull Request does not merge automatically in master?

Github makes very easy to collaborate with people, however sometime it’s a bit complicated to understand how to use Pull Request, and in particular how to make sure that the feature branch can be merged in master in a Fast Forward way

So let’s se how we can go from this(Or the famous “can’t be merged automatically”)

Pull Request cannot be merged

 

to this: (Or yeah, this looks good)

PullRequestCanbeMerged

 

Why this happens

The problem is that both in master and in your branch some files have been changed, and their going in different directions. The content of the file in master is different from the one in your feature_branch, and git does not know which one to pick, or how to integrate them.

To solve this, you need to

  1. Get the latest upstream/master
  2. Switch to your master
  3. merge the latest master in your master (Never develop in master, always develop in a feature branch)
  4. switch to your feature branch
  5. merge master in your feature branch
  6. solve all the conflicts: this is where you decide how to integrate the conflicting files, and this can be done only by you because you know what you did, you can figure out what happened in master, and pick the best way to integrate them.
  7. commit all the changes, after all the conflicts are solved
  8. push your feature branch to your origin: the Pull Request will automatically update

Talk is cheap, show me the commands (cit. adapted)

If you didn’t already add the upstream to your repo, have a read to this

1. Fetching upstream
git fetch upstream
2. Go to your master. Never develop here.
git checkout master
3. Bringing your master up to speed with latest upstream master
git merge upstream/master
4. Go to the branch you are developing
git checkout my_feature_branch
5. It will not be fast forward
git merge master
6. Solve the conflicts. get a decent 3 views visual diff editor. I like Meld
git mergetool
7. Commit all the changes. Write an intelligible commit message
git commit -m "Decent commit message"
8. This will push the branch up on your repo.
git push origin my_feature_branch

Hope it helps.

 

How to push to two different git repositories in one go

Branching illustration

Branching it’s good:
http://git-scm.com/

With the new release of Neuronvisio (0.8.3) we have improved the documentation, gave the software a new home (http://neuronvisio.org) and created a new fork under the NeuralEnsemble orgs.

I think for Python and Neuroscience it would be good to have a website similar to http://pinaxproject.com/ecosystem, to give visibility to the different projects and avoid to re-invent the wheel, however for now using the same space in NeuroEnsemble orgs it’s a good start. I didn’t want to move or transfer my repository there directly,  but I wanted to have a mirror of my repo https://github.com/mattions/neuronvisio in that space, without having to manually update it. I’ve looked how to open a mirror fork on github, but to no avail. So I came up with a possible solution, using the ability of git to push to different repositories.

My solution was to create a new remote point, called all in the local git config (.git/config in your repo) with the following format:

[remote "all"]
url = git@github.com:mattions/neuronvisio.git
url = git@github.com:NeuralEnsemble/neuronvisio.git

This way I can push to both the repos with a single command

git push all

Both the repos will be updated in one go. Neat.

Tools for a computational scientist

So, how do you keep track of your work?

If you are in a wet lab, usually you end up using a lab book, where all the experiments are recorded. You can replicate the experiment, and do something new. It’s pretty cool system, although I think it’s not great for computational scientist. In computational science there is the same problem of recording what is going on, and what happened before. On top of that there is also the problem of sharing the program with other people to address reproducibility. Therefore the problem can be broken down to two different sub problems:

  • record the changes happening in a computational project, in particular to the code used to run the project
  • record the results of different execution and link them with a certain state of the code.
A classic approach is “do nothing”. The code sits on your hard drive somewhere. Maybe it is organized in folders, and descriptive file name. However there is not history attached, you have no idea what’s going on, and which is the latest version. As you guessed this is not a cool position, ’cause you spend time thinking how to track your work instead of doing your work, and you have the feeling that you don’t know what’s going on. This is bad. 
Fortunately, this can be solved 🙂
This is one of the problem which could be solved using a Version Control System, which are exactly invented to track changes in text files (and more).
I found very useful to work with Git, which is an amazing Distributed Version Control System (DVCS). The most important benefit that you get one using a version control system, and in particular git is that you have the ability to be more brave. This is because Git makes very easy to create a branch and test something new as you go on.
Branches

Branch in Git are quick and cheap! Easy to experiment!

Did you ever find yourself in a situation where you wanted to try something new, which could break a lot of different things in your repository, however you didn’t want to mess with your current code?
Well, Git gives you the ability to create a branch very cheaply, to test your new crazy idea and see if it works, in a completely isolated environment from the code that is sitting on your master branch. This means you can try new things, which tends to be quite important in science, because we don’t usually know where we are going, and try more than one solution opens up a lot of different possibilities.
The other good thing is you have a log, with whatever happened, and you can try to go back to the version that was working and restart from there. For example, this is the commits log from neuronvisio.
I’ve ran a hands-on crash course at the EBI about Git, (the repo). The course was very well-welcomed and people started to understand the power of using fast tools to free some mental space.
Another big plus for Git is the ability to host your project on github, which makes collaboration super-easy. These are the contributors for Neuronvisio for example.
Using a version controlled system is a good idea, and integrating it with Sumatra is also a very good idea. Sumatra automatically tracks all the parameters and versions of the programs used. I’ll talk about it in a later post, for now have a look to the slides:

Git tutorial pushing branch

This is a very good and clear tutorial how to push a local branch to a remote with git.

In a nutshell:

1. Creating a the remote branch

git push origin origin:refs/heads/new_feature_name

2. Updating the branch list
git fetch origin

3. Just double check if it is really there
git branch -r

4. Track the remote branch on a new local one
git checkout --track -b new_feature_name origin/new_feature_name

5. Classic pull. All branches will be pulled now
git pull

Going back in the past with git

Sometimes you find yourself in a really big mess:

  • you made some modification that you want to disregard, but
  • you don’t want to delete everything you’ve done.
  • you messed up your master. Although you shouldn’t.

That’s why a git reset is not the way to go, however there is a really nice way to do it:

  • you choose the commit where you want to restart
  • you apply the merge with ‘theirs’ strategy, which actually copy the info from branch B (theirs) to branch A

This is the magic trick:

[code]git checkout -b fixing some_commit
git checkout master
git merge -s recursive –strategy-option theirs B[/code]

  1. Create a fixing branch from the right commit
  2. go back to master
  3. scrap everything you did and copy from the good old branch.

H/T darkhax

Mirroring mercurial repo on github

Mozilla people have created a script to help the mirroring of an mercurial (hg) repo on github.

I’ll post here so I’ll find it later…

Sumatra and git presentation

I’ve just uploaded the slides of Sumatra plus Git support on slideshire.

You can find some real use and possibly some answers. It’s very cool and it works very well for me.
Give it a go. There is also a git repo now 🙂

Github project support soon?

It seems github will be supporting project accounts soon:

This would be very cool. Right now Neuronvisio is hosted under my account name, something not personal, but project centric make a lot of sense. Especially when you have more than one developer.

On top of this there is this amazing plugin for mercurial, which will make git user very easy if they want to collaborate with those.

Maybe Sumatra is going in this direction, maybe not. Back on this soon.

Making patch with mercurial

Just mirroring the solution I found here to find it later on.

How to make patch with git and with mercurial

git log
git log HEAD^ -p
git format-patch HEAD^
git send-email 001-patchname.patch
git send-email HEAD^ # alternatively

Doing the same w/ HG:

hg log # note this isn't paginated, a feature git has over hg imo
hg log -r tip -p
hg email -r tip

© 2017 Train of Thoughts

Theme by Anders NorénUp ↑

By continuing to use the site (scrolling or clicking counts), you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close