git svn rebase problem

git svn rebase problem

[David H. Lynch J.r]

For some time I am using git svn to manage a local copy of a remote svn
repository.

The svn repository has no branches.

A few days ago I did an
git svn rebase

The rebase took a while and after it completed reported
fatal: bad object HEAD

git status reports
root@hp-dhlii:/usr/src/pico/git# git status
# Not currently on any branch.
fatal: bad object HEAD

and git fsck reports
root@hp-dhlii:/usr/src/pico/git# git fsck
dangling blob eb3afb4aa3aaf0003bac601a5db4fd76aafa2a87
dangling commit 5c496db25007c17c325f294bb8324097c9bc407d

How can I recover without downloading the entire repository again which
could take days?

Re: git svn rebase problem

[Avery Pennarun]

On Fri, May 15, 2009 at 5:21 PM, David H. Lynch J.r <ml@dlasys.net> wrote:
> A few days ago I did an
> git svn rebase
>
> The rebase took a while and after it completed reported
> fatal: bad object HEAD
>
> git status reports
> root@hp-dhlii:/usr/src/pico/git# git status
> # Not currently on any branch.
> fatal: bad object HEAD
>
> and git fsck reports
> root@hp-dhlii:/usr/src/pico/git# git fsck
> dangling blob eb3afb4aa3aaf0003bac601a5db4fd76aafa2a87
> dangling commit 5c496db25007c17c325f294bb8324097c9bc407d
>
> How can I recover without downloading the entire repository again which
> could take days?

I don't know how this would happen; it would be great if you could
find reproduction steps and send them in, or if you had the complete
git rebase log, some of which probably explains the problem.

You can probably recover your pre-rebased repository using 'git
reflog'.  Look through the reflog to find the commit you want, then do
something like

    git checkout whatever-the-commit-id-was-that-you-got-from-git-reflog

and then optionally

    git checkout -b master

Good luck.

Avery

Re: git svn rebase problem

[John Tapsell]

2009/5/16 Avery Pennarun <apenwarr@gmail.com>:
> On Fri, May 15, 2009 at 5:21 PM, David H. Lynch J.r <ml@dlasys.net> wrote:
>> A few days ago I did an
>> git svn rebase
>>
>> The rebase took a while and after it completed reported
>> fatal: bad object HEAD

We had this come up about once a week when using http as the
transport.  After switching most people over to ssh the problems
disappeared.  We never managed to find out why.

>> git status reports
>> root@hp-dhlii:/usr/src/pico/git# git status
>> # Not currently on any branch.
>> fatal: bad object HEAD
>>
>> and git fsck reports
>> root@hp-dhlii:/usr/src/pico/git# git fsck
>> dangling blob eb3afb4aa3aaf0003bac601a5db4fd76aafa2a87
>> dangling commit 5c496db25007c17c325f294bb8324097c9bc407d
>>
>> How can I recover without downloading the entire repository again which
>> could take days?
>
> I don't know how this would happen; it would be great if you could
> find reproduction steps and send them in, or if you had the complete
> git rebase log, some of which probably explains the problem.
>
> You can probably recover your pre-rebased repository using 'git
> reflog'.  Look through the reflog to find the commit you want, then do
> something like
>
>    git checkout whatever-the-commit-id-was-that-you-got-from-git-reflog
>
> and then optionally
>
>    git checkout -b master
>
> Good luck.
>
> Avery
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: git svn rebase problem

[Matthias Andree]

Am 15.05.2009, 23:21 Uhr, schrieb David H. Lynch J.r <ml@dlasys.net>:

> For some time I am using git svn to manage a local copy of a remote svn
> repository.
>
> The svn repository has no branches.
>
> A few days ago I did an
> git svn rebase
>
> The rebase took a while and after it completed reported
> fatal: bad object HEAD
>
> git status reports
> root@hp-dhlii:/usr/src/pico/git# git status
> # Not currently on any branch.
> fatal: bad object HEAD
>
> and git fsck reports
> root@hp-dhlii:/usr/src/pico/git# git fsck
> dangling blob eb3afb4aa3aaf0003bac601a5db4fd76aafa2a87
> dangling commit 5c496db25007c17c325f294bb8324097c9bc407d
>
> How can I recover without downloading the entire repository again which
> could take days?

Have you been working on a branch other than the one that git-svn created  
for you? If so, you may have to "git checkout" the original branch before  
being able to "git svn rebase".

Branches and git-svn don't mix.

-- 
Matthias Andree

Re: git svn rebase problem

[Avery Pennarun]

On Mon, May 18, 2009 at 4:38 AM, Matthias Andree <matthias.andree@gmx.de> wrote:
> Have you been working on a branch other than the one that git-svn created
> for you? If so, you may have to "git checkout" the original branch before
> being able to "git svn rebase".
>
> Branches and git-svn don't mix.

That's not exactly true: merging and git-svn don't mix.  But rebasing
works fine.

If you have a separate branch and do 'git svn rebase', then as far as
I know, the original git-svn branch(es) will get updated to the latest
version from svn, and then your current branch will be rebased on top
of it.  This is often what you want, unless you've been using 'git
merge' from that branch.  Rebasing (unless you know exactly what
you're doing) always messes up git merge.

Have fun,

Avery

Re: git svn rebase problem

[Miles Bader]

Avery Pennarun <apenwarr@gmail.com> writes:
>> Branches and git-svn don't mix.
>
> That's not exactly true: merging and git-svn don't mix.  But rebasing
> works fine.

I've given up on trying to maintain rigid consistency with svn --
git-svn's constant rebasing is just too painful -- and just cherry-pick
everything between my "svn" branch and master, and use master in
conjunction with better-behaved git-only branches.  I often end up with
the same commits in a different order on the two branches, but oh well,
not much to do about that I suppose.

This means I often end up cherry-picking long sequences of commits, and
need to deal with conflicts in these cp-sequences.  For this reason, I
often wish cherry-pick supported all the fancy features of rebase
(multiple commits, nice handling of conflicts, -i, etc) -- after all
rebasing is really just a special case of cherry-picking.

[I've tried on a shell-script implementation of such an extended
cherry-pick, but soooo many little corner cases to deal with... maybe
it'd be easier to try and generalize git-rebase...?]

-Miles

-- 
Conservative, n. A statesman enamored of existing evils, as opposed to a
Liberal, who wants to replace them with new ones.

Re: git svn rebase problem

[David H. Lynch J.r]

>2009/5/16 Avery Pennarun <apenwarr@xxxxxxxxx>:
>>/ On Fri, May 15, 2009 at 5:21 PM, David H. Lynch J.r <ml@xxxxxxxxxx> wrote:/
>>/> A few days ago I did an/
>>/> git svn rebase/
>>/>/
>>/> The rebase took a while and after it completed reported/
>>/> fatal: bad object HEAD/
>
>We had this come up about once a week when using http as the
>transport.  After switching most people over to ssh the problems
>disappeared.  We never managed to find out why.

	I am using an ssh link

>/> git status reports/
>/> root@hp-dhlii:/usr/src/pico/git# git status/
>/> # Not currently on any branch./
>/> fatal: bad object HEAD/
>/>/
>/> and git fsck reports/
>/> root@hp-dhlii:/usr/src/pico/git# git fsck/
>/> dangling blob eb3afb4aa3aaf0003bac601a5db4fd76aafa2a87/
>/> dangling commit 5c496db25007c17c325f294bb8324097c9bc407d/
>/>/
>/> How can I recover without downloading the entire repository again which/
>/> could take days?/
>
>/ I don't know how this would happen; it would be great if you could/
>/ find reproduction steps and send them in, or if you had the complete/
>/ git rebase log, some of which probably explains the problem.
Aparently I can reproduce this. I have a git repository that is about a year old.
I have made a local copy of it, and tried to run git svn update on it.
After downloading tons of commits it fails in the same way.

if there a way to do a step by step git svn rebase - somethng vaguely like git bisect - some way to zero in on the commit that is screwing things up ?

Or some way to get a log from the rebase AFTER the repository has become trashed

/>
>/ You can probably recover your pre-rebased repository using 'git/
>/ reflog'.

git reflog replies
fatal error bad HEAD
  
> Look through the reflog to find the commit you want, then do/
>/ something like/
>
>/    git checkout whatever-the-commit-id-was-that-you-got-from-git-reflog/
>
>/ and then optionally/
>
>/    git checkout -b master/
>
>/ Good luck./
>
>/ Avery/
>/ --/
>/ To unsubscribe from this list: send the line "unsubscribe git" in/
>/ the body of a message to majordomo@xxxxxxxxxxxxxxx/
>/ More majordomo info at  http://vger.kernel.org/majordomo-info.html/
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html