Frédéric Heitzmann <frederic.heitzmann@xxxxxxxxx> 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 <normalperson@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html