A SVN repo I use git-svn to track was recently corrupted and a backup was recovered. However, a week's worth of commits were lost in the recovery. Is it possible to recover those lost commits using git-svn开发者_JS百科 dcommit
on my local git repo? Is it sufficient to run git-svn dcommit
with the SHA1 of the last recovered commit in SVN? eg.
> svn info http://tracked-svn/trunk | sed -n "s/Revision: //p"
252
> git log --grep="git-svn-id:.*@252" --format=oneline | cut -f1 -d" "
55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a
> git svn dcommit 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a
Or will the git-svn-id
need to be stripped from the intended commits?
I tried this using --dry-run
but couldn't tell whether it would try to submit all commits:
> git svn dcommit --verbose --dry-run 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a
Committing to http://tracked-svn/trunk ...
dcommitted on a detached HEAD because you gave a revision argument.
The rewritten commit is: 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a
Thanks for your help.
Here is how I achieved what I wanted:
- Re-cloned
http://tracked-svn/trunk
in a fresh git-svn repo. - Added my old git-svn repo as a remote to the fresh repo. (eg.
git remote add -f up-to-date /path/to/repo
) git merge remotes/up-to-date/master
git svn dcommit
Rebasing on my old repo gives no errors, and dcommit works as expected.
This might not be the best way to recover commits, but it got me what I wanted.
Not a complete answer, but that thread may explain a bit the error message:
'
git svn dcommit
' takes an optional revision argument, but the meaning of it was rather scary.
It completely ignored the current state of theHEAD
, only looking at the revisions between SVN and$rev
.
If HEAD was attached to $branch, the branch lost all commits $rev..$branch in the process.Considering that '
git svn dcommit HEAD^
' has the intuitive meaning "dcommit
all changes on my branch except the last one", we change the meaning of the revision argument.
git-svn temporarily checks out$rev
for its work, meaning that:
- if a branch is specified, that branch (not the
HEAD
) is rebased as part of thedcommit
,- if some other revision is specified, as in the example, all work happens on a detached HEAD and no branch is affected.
I am not sure if that patch has been integrated in version Git, but if you test your dcommit, make sure to git branch -b
after the dcommit
, to reference the current HEAD with a branch.
Will it work on the SVN side? I don't know.
I found this article that shed some light on the detached_head
situation.
I've been dealing with more or less the same issue here and this is what I ended up doing:
- First, always make sure you're on a valid branch
git branch
- If you see
(no branch)
(w/asterisk indicating "current branch"), that means you have a detached head - Checkout the detached head
git co -b [BRANCH NAME] --track
. Using the--track
option, I THINK makes it track thegit-svn
HEAD and therefore reattachs this new branch to a HEAD. - Continue with
git svn rebase/dcommit
commands per usual.
This is probably bad, but this also seemed to help - I deleted the master
branch and then after doing a git svn rebase
, it seems to add back in the master
branch automatically.
Also, I viewed the logs of a file and it seems that once I did a git svn dcommit
, all the git checkins were intact from when my branch started going crazy and I was trying to do whatever I could to get it set back correctly.
I'm not 100% sure this is completely correct, but I this seemed to work for me.
精彩评论