threads / discuss / 19364

git svn rebase problem

Subject: git svn rebase problem

## tl;dr

6 messages between May 15, 2009 and May 19, 2009.

replies: 5people: 5as markdown or json

David H. Lynch J.r· May 15, 2009, 21:21 UTC · lore

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?

Avery Pennarun· May 15, 2009, 23:53 UTC · re: David H. Lynch J.r · lore

Re: git svn rebase problem

On Fri, May 15, 2009 at 5:21 PM, David H. Lynch J.r <ml@dlasys.net> wrote:
Show 18 quoted lines
> 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
John Tapsell· May 16, 2009, 03:52 UTC · re: Avery Pennarun · lore

Re: git svn rebase problem

2009/5/16 Avery Pennarun <apenwarr@gmail.com>:
Show 6 quoted lines
> 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.

Show 35 quoted lines
>> 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
>
Matthias Andree· May 18, 2009, 08:38 UTC · re: David H. Lynch J.r · lore

Re: git svn rebase problem

Am 15.05.2009, 23:21 Uhr, schrieb David H. Lynch J.r <ml@dlasys.net>:
Show 23 quoted lines
> 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
Avery Pennarun· May 18, 2009, 17:00 UTC · re: Matthias Andree · lore

Re: git svn rebase problem

On Mon, May 18, 2009 at 4:38 AM, Matthias Andree <matthias.andree@gmx.de> wrote:
Show 5 quoted lines
> 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
Miles Bader· May 19, 2009, 00:56 UTC · re: Avery Pennarun · lore

Re: git svn rebase problem

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.

← back to recent threads