Archive for February, 2009

Best git-svn practices?

Saturday, February 21st, 2009

I wonder if there are any “best git-svn practices”? Particularly for the following scenario:

1) There is a common svn repository
2) There are several developers who track/sync this common svn repo with their own local git repos using git-svn bridge(via git svn rebase/dcommit)
3) From time to time these developers using git need to share their changes without affecting the svn repository. For this purpose they setup a shared git repo and exchange their work using pull/push commands
4) It turns out these developers may face conflict problems due to usage of “git svn rebase” for syncing with the main svn repo. This happens because rebase operation rewrites history of the local git branch and it becomes impossible to push into the shared git repo and pulling from it often leads to conflicts.

Anybody having the same problem?

Update: Here is what official git-svn man page says about this problem:

For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server, and avoid all git-clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git-format-patch and git-am, or just ‘dcommit’ing to the SVN repository.

Running git-merge or git-pull is NOT recommended on a branch you plan to dcommit from. Subversion does not represent merges in any reasonable or useful fashion; so users using Subversion cannot see any merges you’ve made. Furthermore, if you merge or pull from a git branch that is a mirror of an SVN branch, dcommit may commit to the wrong branch.

Looks like my whole svn workflow should be revised :(

Update: All my problems were resolved by migrating the whole repository to Mercurial :) Why Mercurial? That’s simple - it has almost all git features plus very smooth Windows support which is very important for many members of my team.

Processing results of vimgrep in vim

Thursday, February 19th, 2009

What I’ve been really missing in vim is a general mechanism of applying any arbitrary processing to the results of :vim[grep] command. What I usually did was to record a macro and apply it manually(using :cp) to every entry in a quickfix window - believe me, that’s very boring. Big thanks goes to Ben Schmidt who showed me a couple of vim script commands(in the official vim mailing list) which make it possible to automate this dull process. Here they are(put them into your ~/.vimrc):

:com! -nargs=1 Qfdo try | sil cfirst |
\ while 1 | exec <q-args> | sil cn | endwhile |
\ catch /^Vim\%((\a\+)\)\=:E\%(553\|42\):/ |
\ endtry
<br/>
:com! -nargs=1 Qfdofile try | sil cfirst |
\ while 1 | exec &lt;q-args&gt; | sil cnf | endwhile |
\ catch /^Vim\%((\a\+)\)\=:E\%(553\|42\):/ |
\ endtry

It’s dead simple to use them. For example, you have a macro @q which makes some changes in a single line and you want to apply it to every line found by :vim command. Here’s a possible sequence of vim commands:

"search for foo string in all .cpp sources recursively
:vim /foo/ **/*.cpp     
"apply q macro to all found lines
:Qfdo normal @q

Qfdofile command is a bit different to Qfdo - it applies your command not every line but to every file found by :vim search.