Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
dev:howto:git [2009/08/13 21:10] – kelnosdev:howto:git [2009/08/14 04:26] – kelnos
Line 77: Line 77:
 ===== Repository Identification ===== ===== Repository Identification =====
  
-In order to display repository metadata on the [[http://git.xfce.org|CGit]] listings and other places, modules will need a file called "''module.xml''" in the root of their tree (on their master branch).  This file should be a DOAP file describing the project.  You can work off [[http://mocha.xfce.org/~kelnos/module-template.xml|this template]].+In order to display repository metadata on the [[http://git.xfce.org|CGit]] listings and other places, modules will need a file called "''module.xml''" in the root of their tree (on their master branch).  This file should be a [[http://trac.usefulinc.com/doap|DOAP]] file describing the project.  You can work off [[http://mocha.xfce.org/~kelnos/module-template.xml|this template]].
  
 Please at least provide ''<foaf:name>'', ''<foaf:mbox>'', and ''<gnome:userid>'' elements (the latter of which should be your Xfce ssh account username).  You can of course provide more information about yourself if you'd like; see [[http://xmlns.com/foaf/spec/20071002.html#term_Person|foaf:Person]] and [[http://xmlns.com/foaf/spec/20071002.html#term_Agent|foaf:Agent]]. Please at least provide ''<foaf:name>'', ''<foaf:mbox>'', and ''<gnome:userid>'' elements (the latter of which should be your Xfce ssh account username).  You can of course provide more information about yourself if you'd like; see [[http://xmlns.com/foaf/spec/20071002.html#term_Person|foaf:Person]] and [[http://xmlns.com/foaf/spec/20071002.html#term_Agent|foaf:Agent]].
Line 93: Line 93:
 ===== Tips and Tricks ===== ===== Tips and Tricks =====
  
-If you clone a lot of Xfce repositories, you can set a shortcut so you don't have to type out the full URL all the time.  Simply run:+See [[dev:howto:git-tips-and-tricks]].
  
-<code>git config --global 'url.ssh://git.xfce.org/git/.insteadOf' xfce:</code>+===== Migrating From git-svn Clones =====
  
-After this, you'll be able to do, for example:+This section is only useful for developers who were using git-svn to access our old Subversion repositories.
  
-<code>git clone xfce:xfce/xfdesktop</code>+If you have a git-svn clone and there are commits in it that you never pushed to svn, and want to merge them into a new git clone, it can be a little bit of a pain.  Because of how the repositories were converted, the git-svn clones do not have the same SHA1 sums for any old commits (that is, commits that were pushed to the svn repo).  So you can't just import a branch directly and expect it to work.
  
-and Git will automatically rewrite it to the correct URL.  You can of course do this with git: and http: URLs as well.+The following is what I (Brian) did.  It's really manual and annoying.  If anyone has a better way, feel free to edit this and describe your method. 
 + 
 +Here I'll use my ''xfdesktop'' repo as an example.  I'll refer to the new git clone simply as ''xfdesktop'', and the git-svn clone as ''xfdesktop.git-svn''.  I want to merge the branch ''new-drawing'' from ''xfdesktop.git-svn'' over to ''xfdesktop''.  Here's what I'd do: 
 + 
 +<code>$ cd xfdesktop 
 +$ git checkout master 
 +$ git checkout -b new-drawing 
 +$ git fetch ../xfdesktop.git-svn new-drawing:refs/heads/tmpbranch 
 +$ git log tmpbranch</code> 
 + 
 +At this point, I'll look at the log output and figure out which commits were never pushed to the main Subversion repository.  It's easy to tell because those commits don't have ''git-svn-id:'' lines at the end of each commit message. 
 + 
 +Now, I make a list of the SHA1 hashes of the commits I need to migrate.  I'll order them in the **reverse** order, so that the first commit to migrate will be the oldest out of my list.  In my case, I only have two commits, so my list (after reordering) looks like this: 
 + 
 +<code>d1e0179e8b6f00e4f452513c100f674f7d35dc11 
 +e3633d52774bd9a2a20ef9af37d3f72f964a2f54</code> 
 + 
 +At this point I could make a script to cherry pick them all in order, but since I only have two I'll just do it manually: 
 + 
 +<code>$ git cherry-pick d1e0179e8b6f00e4f452513c100f674f7d35dc11 
 +$ git cherry-pick e3633d52774bd9a2a20ef9af37d3f72f964a2f54</code> 
 + 
 +(Note: if there's only one commit to merge, you can skip the above and just do ''git cherry-pick tmpbranch'', which will just cherry pick the ''HEAD'' commit of ''tmpbranch''.) 
 + 
 +Now, if I got any merge errors after one of the cherry pick commands, I'd have to stop there and fix it up first: 
 + 
 +<code>$ vim src/xfdesktop-icon-view.c 
 +[fix the merge conflict and save] 
 +$ git add src/xfdesktop-icon-view.c</code> 
 + 
 +The merge conflict error message provided a useful bit of info: after fixing the conflicts, you can easily re-commit using the same log message, author, and author date as before by using the ''-c'' option to ''git commit'': 
 + 
 +<code>$ git commit -c e3633d52</code> 
 + 
 +Note that the argument to ''-c'' is just a shortened form of the SHA1 hash for the commit that caused conflicts. 
 + 
 +Now that we're done, we can delete the temporary branch: 
 + 
 +<code>$ git branch -D tmpbranch</code> 
 + 
 +You'll have to repeat this process for any other local branch you have in the old git-svn clone.  As I said, yes, it's annoying, repetitive, manual, and time-consuming (if you have a lot of branches/clones to convert).  If anyone knows a better way, feel free to detail it here. 
 + 
 +After you finish with all branches in a particular module, you may want to run: 
 + 
 +<code>$ git gc --prune=now</code> 
 + 
 +This will remove all the dangling commits, trees, and blobs left over from the probably-large number of mismatched objects discarded when you deleted tmpbranch.