3

I've only just started using git (after many years using svn) so I probably lack some of the fundamentals.

I am working on a project using a Raspberry Pi. As it happens, one of the devices I am using it with seems to have a faulty driver in the Kernel, so I am trying to debug it.

I have started with the official RPi Kernel, from here. This kernel is not completely up to date, although it is not too far behind. I need to use this kernel because according to the documentation, it contains some drivers etc specific to the raspberry pi.

However since I am trying to fix something I guess I should start from the most up to date kernel possible, which is the wireless-testing repo for the driver I am looking into.

So, what I want to do is apply all of the commits that have been made to the wireless-testing repo but which are not yet already in the RPi Repo.

If possible it would be ideal if I could limit the commits that I pull from wireless testing to be only those affecting a particular directory tree, as I suspect that will reduce the chances of a conflict of some kind between the two repos I am pulling from.

Finally, I would ideally like to be able to continue to track the RPi repo, so as to be able to pull changes in from there also.

What is the best workflow to achieve this?

harmic
  • 28,606
  • 5
  • 67
  • 91

2 Answers2

0

You can add them both as remotes and git fetch from each.

If they are on the same branch you will then need to do a merge/rebase and resolve any merge conflicts.

If you need to combine information in two branches, after the two pulls go to the branch you want (with the raspberry pie driver stuff) and do git merge or git rebase (the difference is a topic for a longer conversation) and resolve any merge conflicts as necessary.

See also:

http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

and

git branch, fork, fetch, merge, rebase and clone, what are the differences?

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
  • Thanks! Predictably there were a lot of conflicts when pulling. Is there any way to pull only those commits which affect a particular directory within the working copy? – harmic Oct 27 '14 at 11:47
0

Doing a straight forward fetch and merge resulted in a lot of conflicts, none of which affected the driver I am trying to debug. As indicated in the question, I really want to limit the commits that I am merging to those that affect this particular driver.

I found a way to do this. The key is the git cherry-pick command.

First add the upstream repo as a remote, and fetch from it:

git remote add wireless-testing git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
git fetch wireless-testing

Now I have two remotes, origin (the RPi kernel repo I originally cloned) and wireless-testing, the further upstream repo that I want to pull changes from.

Next check out the origin branch that you want to start from (in my case the RPi rpi-3.17.y branch), and make a new local branch based off it:

git checkout rpi-3.17.y
git checkout -b rtlfix

Now, to get a list of the commits on the wireless-testing repo, which are ahead of my branch, but considering only commits that affect a particular directory tree:

git log wireless-testing/master ^HEAD -- drivers/net/wireless/rtlwifi

This means "Show a log of commits starting at the head of wireless-testing/master, and stopping when you reach head of the current local branch, and only considering files / dirs under directory drivers/net/wireless/rtlwifi".

Having confirmed that is indeed the list you want, you can proceed to apply it using the cherry-pick command:

git rev-list --reverse wireless-testing/master ^HEAD -- drivers/net/wireless/rtlwifi | git cherry-pick --stdin

The first command outputs the list of commits in reverse order, and they are piped into the cherry-pick command which then applies the given commits.

There are some caveats with this approach. One in particular is that if any of the commits you have taken rely on changes made in other commits that you did not take, then you will end up with software that fails to compile and/or work. You may then need to bring in other commits to resolve these issues.

harmic
  • 28,606
  • 5
  • 67
  • 91