Hi Jonathan, > > In theory it might be nice to follow both, but an "svn dcommit" will > > implicitly do a rebase which in turn might lead to problems with the > > git upstream repository, at least if fast-forward is required, which > > is the default. > > Got it. You're looking for a safety that would prevent rebasing > history that has already been made public in a remote git repo, at > least in the case that this rebasing happens as a side-effect of "git > svn dcommit". > > By contrast, I really want to be able to do the following: > > git checkout -b tmp my-git-remote/topic > git svn dcommit
As far as my patch was intendet, this would still work, as you didn't specify the branch as a tracking branch. I always thought of a tracking branch as something I state as the "official source", in contrast to a normal branch and then an explicit pull of cherry-pick. My first thought was to add an other option which allows me to explicitly prohibit "git svn dcommit" for certain branches, but then I had the impression that remote and svn are contradicting each other. In my opinion the cleanest thing would be, if the svn repository would be listed as something like a remote and I could the (like with the remotes) decide on the command line to push to an other remote or svn. Sadly the way git-svn works (and I do see the benefits in the current approach) doesn't allow this. > A possible conclusion is that git-svn desperately needs a pre-dcommit > hook that carries out an arbitrary site-specific policy about when a > dcommit is allowed and not allowed. Such a hook would be useful for > other purposes, too, like flagging violations of coding standards. > > Once such a hook is in place, it would be easier to talk about what > the default pre-dcommit hook should do. > > Does that sound right? I think such a pre-dcommit hook could do the trick. And we could ship a set of useful predefined hooks. Concerning the violation of coding standards we current do this in the pre-commit hook... why would you want to have such code in the git repo in the first place?! I can have a look at the hook issue, although I'm not sure how much time I find during the next few days. Cheers Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
