So, using Subversion mirror(SubGit) with latest BitBucket (4.8.3). There are two changes made to master. One made directly and one made with a merge from a feature branch. When pushing the changes, get a SubGit error:
XC2T@B104315 MINGW64 /c/projects/repos/loct-demo (master)
$ git push
Total 0 (delta 0), reused 0 (delta 0)
remote: error: The following ref update is disallowed:
remote: error: refs/heads/master: leads to replacement of SVN branch 'trunk'
remote: error:
remote: error: You can allow branch replacements by setting svn.allowBranchReplacement = true in SubGit configuration file.
remote: Fetching revisions from SVN repository:
remote: up to date
remote: Sending commits to SVN repository:
To http://XC2T@localhost:7990/scm/loct/loct-demo.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'http://XC2T@localhost:7990/scm/loct/loct-demo.git'
I'm sure I've done this in the past and it worked just fine. I will try reverting back and doing this again, but just wondering if others have seen this error and know what it means.
Thanks,
Brad
This error message was introduced with SubGit version 3.2.1 and SVN Mirror add-on version 3.3.0.
SubGit/SVN Mirror rejects push operation that would result into branch replacement in Subversion repository. There are basically two cases when Git changes may lead to replacements on SVN side:
Force push.
When one forcefully pushes non-fast-forward update, SubGit/SVN Mirror has nothing to do but delete current version of the branch and re-create it from some older revision, because this is exactly what non-fast-forward update does: continuing branch history from a commit other than the branch tip.
Fast-forward merge from one branch into another.
When one creates a new branch foo
from master
:
$ git checkout -b foo
$ git commit -am 'fix foo'
[foo ca3caf9] fix foo
then pushes that branch to SubGit mirror:
$ git push origin foo
...
Sending commits to SVN repository:
remote: ca3caf9 => r10 branches/foo
which gets ca3caf9
mapped to branches/foo@10
.
Finally, one merges branch foo
back to master
:
$ git checkout master
$ git merge foo
Updating 0e39ad2..ca3caf9
Fast-forward
Noticed that Updating ... Fast-forward message? It means git merge
found no new commits on master
, hence there was no need to create a merge commit, i.e. git merge
just moved the master
pointer from older commit 0e39ad2
to a newer one ca3caf9
.
Now what happens when one pushes master
to SubGit mirror:
$ git push origin master
SubGit finds out that master
was updated from 0e39ad2
mapped to trunk@9
to ca3caf9
mapped to branches/foo@10
. There's nothing SubGit can do but delete trunk
and re-create it from branches/foo@10
which obviously leads to replacement of trunk
.
And so we made sure that SubGit does not replace branches in these two scenarios unless SubGit administrator explicitly sets the following configuration option:
$ edit REPO/subgit/config
...
[svn]
allowBranchReplacement = true
...
$ subgit install REPO
However, I'd recommend to keep svn.allowBranchReplacement
set to false
and follow these best practices to avoid the error message reported in the original question:
Never force push anything; prefer to merge, revert of branch out changes rather than overwrite them.
When merging one branch into another add --no-ff
option: it forces git merge
to create a merge commit when it would rather do a fast-forward update otherwise:
$ git merge --no-ff foo
UPDATE:
If you're using SVN Mirror add-on, you can specify svn.allowBranchReplacement
option at the Branches Mapping tab:
The text field should look as follows:
[svn]
trunk = ...
...
allowBranchReplacement = true
and then click on Apply changes button in order to activate this new setting.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With