I cloned a SVN repository into a git repository using git svn clone. At that point in time, I did not have a username at that site and hence didn't use the --username option of clone. As I can now commit to the SVN repository with my new username, I would like to add that username. Without it, dcommit simply fails:
% LANG=C git svn dcommit
Committing to <THE URL> ...
RA layer request failed: Server sent unexpected return value (405 Method Not Allowed) in response to MKACTIVITY request for '/svn/!svn/act/0ceca4c5-f7b4-4432-94be-0485559a6040' at /usr/lib/git-core/git-svn line 945.
Is there a way to tell git about a new username? The git-svn manual doesn't seem to help: adding a username is only allowed on init and branch. I don't know how git works with SVN internally, but I guess there should be a way to add a username afterwards.
Note that I am using SVN over http.
You can specify the username in the dcommit command, e.g.
git svn dcommit --username=isapir
I think you can use this procedure (from the git svn manpage) to create a clone of your existing svn repository, but change the git svn init step so that it specifies a username. Your new git-svn repository will then have a username.
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
git init
git remote add origin server:/pub/project
git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Prevent fetch/pull from remote git server in the future,
# we only want to use git svn for future updates
git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git svn init --username my_new_name http://svn.example.com/project
# Pull the latest changes from Subversion
git svn rebase
Note that if you specify a username, you would not be able to dcommit a merge commit, not before Git 2.16.x/2.17 (Q1 2018).
That is because "git svn dcommit" did not take into account the fact that a
svn+ssh:// URL with a username# (typically used for pushing) refers
to the same SVN repository without the username# and failed when
svn.pushmergeinfo option is set.
See commit 8aaed89 (15 Sep 2017) by Jason Merrill (jwmerrill).
(Merged by Jason Merrill -- jwmerrill -- in commit 8aaed89, 17 Sep 2017)
git-svn: fix svn.pushmergeinfo handling of svn+ssh usernames.
Previously, svn dcommit of a merge with svn.pushmergeinfo set would
get error messages like
merge parent <X> for <Y> is on branch svn+ssh://gcc.gnu.org/svn/gcc/trunk,
which is not under the git-svn root svn+ssh://jason#gcc.gnu.org/svn/gcc!"
So, let's call remove_username (as we do for svn info) before comparing
rooturl to branchurl.
Related
I made a change in gerrit which was code reviewed and after 7 revisions approved. But, now it cannot be merged and trying to rebase in gerrit website is not working due to merge conflict. How can I resolve this merge conflict and merge the same approved change and not create a new one.
(Full steps from cloning the repo would be appreciated.)
1) Clone the Gerrit repository
git clone https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME
2) Go to the change page on Gerrit and copy the checkout patch command
git fetch https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME refs/changes/XX/YYYYY/Z && git checkout FETCH_HEAD
3) Rebase the change
git rebase origin/BRANCH
4) Solve the conflicts
git mergetool
5) Continue the rebase
git rebase --continue
Repeat the steps 4 and 5 until the end of conflicts
git commit --amend
Note: Keep the same Change-Id
6) Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
The accepted solution works but I personally disagree with this workflow. It is unnecessarily cumbersome.
I prefer a workflow with exactly one merge and therefore less steps.
Clone the Gerrit repository if not already available
git clone https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME]
Checkout the Gerrit patch
git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/46/12346/N && git checkout FETCH_HEAD
Soft-reset the change and stash it
git reset --soft HEAD~1 && git stash
Checkout branch or the Gerrit patch you want to rebase onto
git checkout origin/BRANCH
# or fetch other Gerrit patch:
# git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/45/12345/N && git checkout FETCH_HEAD
Unstash the previously stashed changes
git stash pop
Solve the conflicts with your favourite 3-way merge tool.
Commit the merged changes - NOT (!!) amend them - and use the same Change-Id from the merged patch in the message:
git commit -am "[COMMIT-MESSAGE]\
\
Change-Id: [FORMER-CHANGE-ID]"
Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
Done. One merge!
I additionally use the gitreview tool. That makes it extra easy. Steps 2, 3, 4 and 5 then can be chained.
git review -d 12346 && git reset --soft HEAD~1 && git stash && git review -d 12345 && git stash pop
I'm trying to do all of my branching and merging via git-svn, however I'm hung up on the branching in subversion.
Our admin tells me that I have full read/write permissions on the repo, and I CAN fetch the latest code.
For a test, I deleted my ~/.subversion/svn.simple directory and ran this.
04:13 pm [214423L] C:\Dev\MyFooApp.Bar [master]
$ git svn fetch
Authentication realm: <https://code:443> VisualSVN Server
Password for 'cflorell': {my password}
04:14 pm [214423L] C:\Dev\MyFooApp.Bar [master]
$ git svn fetch
04:14 pm [214423L] C:\Dev\MyFooApp.Bar [master]
$
Also, if I clone the repo using Tortoise, and then create a branch using svn it appears to work.
04:43 pm [214423L] C:\Dev\MyFooApp.Bar
$ svn copy https://code/svn/MyFooApp.Bar/trunk https://code/svn/MyFooApp.Bar/branches/test-branch -m "test branch"
Committing transaction...
Committed revision 93.
But upon trying to create a branch using git-svn, it still says my auth is invalid.
04:14 pm [214423L] C:\Dev\MyFooApp.Bar [master]
$ git svn branch develop
Copying https://code/svn/MyFooApp.Bar/trunk at r92 to https://code/svn/MyFooApp.Bar/branches/develop...
Authentication failed: Unable to connect to a repository at URL 'https://code/svn/MyFooApp.Bar/trunk': No more credentials or we tried too many times.
Authentication failed at C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 1196.
04:14 pm [214423L] C:\Dev\MyFooApp.Bar [master]
$
My config file is I believe correct.
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
[svn-remote "svn"]
url = https://code/svn/MyFooApp.Bar
fetch = trunk:refs/remotes/svn/trunk
branches = branches/*:refs/remotes/svn/*
tags = tags/*:refs/remotes/svn/tags/*
Where might I be going wrong with all of this?
Note that more than a year later (March 2017), Git 2.13+ (Q2 2017) should avoid that git svn authentication issue.
See commit e0688e9 (06 Mar 2017) by Hiroshi Shirosaki (shirosaki).
It recognizes that authentication fails with svn branch while svn rebase and svn dcommit work fine without authentication failures.
$ git svn branch v7_3
Copying https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at r27519
to https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v7_3...
Can't create session: Unable to connect to a repository at URL
'https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx': No more
credentials or we tried too many times.
Authentication failed at
C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 1200.
We add auth configuration to SVN::Client->new() to fix the issue.
So it looks like there is a conflict between Tortoise SVN and git-svn, I'm not sure if this exists in other versions of SVN or not but I uninstalled Tortoise SVN and was then able to branch using git svn branch branchName
C:\Files\Source\Repos\applications\core\App01>git svn branch branchName
Copying http://url/svn/company/applications/core/App01/trunk
at r7071 to http://url/svn/company/applications/core/App01/
branches/branchName...
Found possible branch point: http://url/svn/company/applications/core/App01/trunk => http://url/svn/company/applications/core/App01/branches/branchName, 7071
Found branch parent: (refs/remotes/origin/branchName) f8ba2fd450c30d4812b7549217eae1b2d5c7dd00
Following parent with do_switch
Successfully followed parent
r15037 = 52dd759833fd89c7be03f89093aba38090b3288f (refs/remotes/origin/branchName)
C:\Files\Source\Repos\applications\core\App01>
Going to try some other SVN Browser for the time being and see if that also has an issue.
According to https://gist.github.com/kasparsd/3749872/563011118e33900b3a0ca89ec37f3c99be8e9c49 , there's no way to authenticate using git svn tag (used to work, but stopped working).
Instead, use svn directly to submit a tag:
svn cp <trunk-ul> <tag-url> -m "creating tag x.x"
It will ask to store your password in plain text though.
I want to learn to use git-svn. I have an svn local repository on my disk that I've checked out a while ago using something like this:
svn co http://myserver.com/mysvnrepo/trunk/ /mysvnrepo/
ls -a /mysvnrepo/
. .. .svn foo bar
This /mysvnrepo/ is HUGE, so I want to avoid re-downloading or copying the files at all costs.
I'm wondering if there's a way to git clone this local repo without downloading / copying anything (because it's already there).
I have this which seems to be what I'm looking for, but when I do that it doesn't quite give me what I expect.
cd /mysvnrepo/
git svn clone file://mysvnrepo/
ls /mysvnrepo/
. .. .git .svn foo bar
git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .svn/
# foo/
# bar/
I would expect git to detect foo and bar as "versioned and up-to-date".
According to the docs it seems that I need to use git svn init because git svn clone runs a fetch, which I certainly don't want. So I tried
git svn init --trunk=file:///mysvnrepo/
...but no luck.
I'm completely new to git, so my confusion is off-the-charts... am I doing something utterly wrong?
Thanks in advance
You cannot take a subversion snapshot and convert it into a git repository.
It sounds like you are trying to avoid a lengthy initialization of the git repository from svn: which ordinarily will try to ready your entire history. This can be done in another way, by limiting the fetch to recent history depending on how much history is relevant to you:
git svn clone -s -r 12334:HEAD https://svn.host.org/repo
Where 12334 is the earliest svn revision you are interested in and assuming that the repo is laid out in a standard svn way with branches and tags.
How can I do a git svn reset to HEAD revision without specifying the revision number?
It sounds like what you want is not a git svn reset but a simple git checkout. I'm not sure what you mean when you say you reverted to an older revision, but it may have been something like
$ git log
# scan through the log looking for a particular commit.
# You find it and its SHA1 is abc123...
$ git checkout abc123
You are now in 'detached HEAD' state blah blah blah...
Now, HEAD (in your git repository) refers to the commit with SHA1 abc123, whereas HEAD (in the central SVN repository) refers to the newest commit on the SVN repository. If you have things set up in a fairly typical way, then you can just do git checkout master and then git svn rebase and you're back to normal working conditions.
I understand how to initialize a git-svn repo, create a branch, do some work, merge branch, then use git svn rebase and git svn dcommit to push back to the svn repo. But between these two commands, how can you get a status of what is different between the two repos? Something like a git status that tells you that you have x number of files that have been changed.
Just do a diff between your branch and upstream.
git diff --stat git-svn/master..master
Obviously, you'll have to change the branch names to whatever's applicable for your setup.
The only real way I know is to run 'git svn dcommit -n' (or git svn dcommit --dry-run) which will usually give you output like this:
$git svn dcommit --dry-run
Committing to http://yourserver.com/trunk ...
diff-tree bc923cb54847fa340d094c3da1ebd66b8fb0e63e~1 bc923cb54847fa340d094c3da1ebd66b8fb0e63e
diff-tree a05c8be4af7f82dc4de5b4778e2b58203c75eebd~1 a05c8be4af7f82dc4de5b4778e2b58203c75eebd
And then you can 'git show bc923cb54847fa340d094c3da1ebd66b8fb0e63e' to view that diff.