Hello, Am 10.10.2018 um 01:38 schrieb Артем Семенов: > Hello. > > Git svn bug on merging svn branches: > > Svn repository (branches tag trunk). > > 1. Add a some file by svn tools. > 2. Create a new branch by svn tools (e.g. br1) . > 3. Create a new branch by svn tools on branch br1 (e.g. br2). > 4. Add some changes to file f1 in branch br1. Commit by svn tools. > 5. Clone repository by git svn. > 6. Create two local branches – br1_svn (on origin/br1) and br2_svn (on > origin/br2); > 7. Checkout to br2_svn. Add some changes (e.g add file f2). Execute git > add, git commit. > 8. Execute “git merge br1_svn”. > 9. Checkout to br1_svn. > 10. Execute “git svn info” - URL refers to br1. (URL: > https://127.0.0.1/svn/branchtest/branches/br1) > 11. Execute “git merge br2_svn”. > 12. Execute “git svn info” - URL refers to br2. (URL: > https://127.0.0.1/svn/branchtest/branches/br2) The "CAVEAT" section in the git-svn manual already contains some text about your case: If you do merge, note the following rule: git svn dcommit will attempt to commit on top of the SVN commit named in git log --grep=^git-svn-id: --first-parent -1 You must therefore ensure that the most recent commit of the branch you want to dcommit to is the first parent of the merge. Chaos will ensue otherwise, especially if the first parent is an older commit on the same SVN branch. The paragraphs before these lines give more reasons to avoid a non-linear history in SVN branches. Best regards Andreas Heiduk
