From: Eric Wong Date: Wed, 17 Aug 2011 20:37:01 GMT Subject: Re: [PATCH v2] git svn : hook before 'git svn dcommit' Message-ID: <20110817203701.GB24581@dcvr.yhbt.net> In-Reply-To: Frédéric Heitzmann wrote: > 4) Before merging back to master and commitng to SVN, it is necessary > to remove commits with reference data (git rebase -i --onto master > master topic ...) > 5) merge topic branch with master and git svn dcommit > > -- end -- > > It is very easy to forget step 4, and svn commit lots of useless data. I agree. > Proposal 1) > * commit reference data with some specific mark in the commit message > (e.g. "NO_SVN") > * use pre-svn-dcommit hook to detect such commits The problem with this is hook standardization across committers and even across different machines/directories a committer may use. > Proposal 2) (not fully feasable for what I know) > * git svn clone to a bare repo > * clone a working repo from the the bare repo. > * steps 2, 3, maybe 3bis, ... then 4 > * push commits to the bare repo, while using pre-receive or update > hook to look for wrong commits, and abort if so. > * use post-receive hook to trigger git svn dcommit > > Main drawback for proposal 2 (appart from needing 2 repo instead of > one) is that each time you want to update your working  repo, you have > to git svn rebase the bare repo, then git pull. Proposal 2 is way too complicated, I hate it. > All things begin equal, proposal 1 seems to be the easier path, but it > is highly debatable. I had Proposal 3 in my original response: > 2011/8/17 Eric Wong wrote: > > Perhaps an interactive option for dcommit would be just as useful? 1 and 3 can both implemented, but I think 3 would be easier to use/setup/standardize. I suspect it's also easier to train oneself to always use "dcommit -i". Perhaps even default to interactive mode like git-send-email does nowadays. Unfortunately interactive dcommit requires more effort to implement. -- Eric Wong