views:

156

answers:

3

Hi

I'm looking at how to import some third part code into a git repository. The third party code is the "stm32f10x_stdperiph_lib" that is provided by ST.

The lib is actually a bunch of normal c-files (and header-files) that you just include and build with when you do a STM32 project.

The problem is that they only provide it as a zip-file and they do release new versions, so I would like to add more control.

So my plan is to write a little script that does this:

  1. unzip
  2. grab some of the files (I don't need all the files in the zip)
  3. import the selected files into a git repository

My problems start at the last step, how do I import and overwrite the old files with the new ones (and remove files that are no longer included)?

Thanks Johan

+1  A: 

A bit of devil's advocate here but do you really need it as a git repository?

Perhaps set up a script that downloads and updates all third party code in your projects instead? My thinking is that you'll eventually run into third party dependencies that are tricky to import. For example, with python I use buildout to install all my dependencies. That way I can easily combine git, mercurial, subversion, zip files, packages, etc.

However, something like the following should work:

$ cd repo
$ find . -not -path *.git* -and -not -path . -delete
$ unzip /tmp/thirdparty.zip
$ git add .
$ git commit -a 'Updated version'

That is, delete all files except the .git directory and .gitignore, etc. This in order to handle the case of deleted files in the third party project. Then unzip updated zip file into directory. Add any new files to the repository. Commit.

Hope that helps! :)

lemonad
Since they have the same name on the zip-file (even when they change the content) I feel it is dangerous to just download unpack and hope for the best.
Johan
I see. Still, you don't have to download it from the internet. You could fetch it from an internal server which only contains tested and approved versions.
lemonad
Why not use `git clean` instead of using `find` to delete old version?
Jakub Narębski
@Jakub: `git clean` removes only non-tracked files and in this case one would want to remove both tracked as well as non-tracked files.That is, one version could contain file `abc` and the next revision might not. Unless removing all files, `abc` would remain in the project. We want the deletion to be commited.
lemonad
A: 

My preference is to create a git repository, update it periodically (git commit -a -m 'Update') and simply link it in my projects (as a directory (ln -s, junction, etc) or as a shared library). For files you don't need, use .gitignore.

terminus
That sounds like exactly his plan, but he's asking for help with how to replace the old files with the new, adding and deleting as needed.Also note that some projects come with a .gitignore.
ysth
+3  A: 

What you're looking for is a "vendor branch". Assuming you want to work on this code and merge the vendor's updates with your own patches, here's how you make that easy.

git co -b vendor    # create a vendor branch and check it out

That's a one time thing. The vendor branch and its ONLY going to contain updates from the 3rd party vendor. You never do work in the vendor branch, it contains a clean history of the vendor's code. There's nothing magic about the name "vendor" its just my terminology hold over from CVS.

Now we'll put the latest version from the vendor in there.

find . -not -path *.git* -and -not -path . -delete  # delete everything but git files
dump the 3rd party code into the project directory  # I'll leave that to you
git add .                              # add all the files, changes and deletions
git commit -a -m 'Vendor update version X.YY'   # commit it
git tag 'Vendor X.YY'                  # optional, might come in handy later

We delete everything first so that git can see things the vendor deleted. git's ability to see deletions and guess moved files makes this procedure far simpler than with Subversion.

Now you switch back to your development (I'm presuming master) and merge in the vendor's changes.

git checkout master
git merge vendor

Deal with any conflicts as normal. Your patched version is now up to date with the vendor. Work on master as normal.

Next time there's a new version from the vendor, repeat the procedure. This takes advantage of git's excellent merging to keep your patches up to date with vendor changes.

Schwern