fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Thomas Glanzmann]

Hello,

        (s017241) [/usr/src/linux-2.6] git checkout v2.6.20
        warning: You appear to be on a branch yet to be born.
        warning: Forcing checkout of v2.6.20.
        fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions
        Cannot detach HEAD

(s017241) [/usr/src/linux-2.6] git version
git version 1.5.2.1

what is going wrong here?

        Thomas

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Junio C Hamano]

Thomas Glanzmann <thomas@glanzmann.de> writes:

> Hello,
>
>         (s017241) [/usr/src/linux-2.6] git checkout v2.6.20
>         warning: You appear to be on a branch yet to be born.
>         warning: Forcing checkout of v2.6.20.
>         fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
>         Use '--' to separate paths from revisions
>         Cannot detach HEAD
>
> (s017241) [/usr/src/linux-2.6] git version
> git version 1.5.2.1
>
> what is going wrong here?

Perhaps repository was set up in an unusual way by hand
(i.e. not by a clone), such that:

 1. you have HEAD pointing at a branch (e.g. 'refs/heads/master'),
 2. which does _not_ exist yet (i.e. no 'refs/heads/master'),
 3. yet you have a tag that you can try to detach your HEAD to (e.g. v2.6.20).

... well that was my initial guess, but even after setting up such a
funny repository by hand, I cannot seem to reproduce it.

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Thomas Glanzmann]

Hello Junio,

> ... well that was my initial guess, but even after setting up such a
> funny repository by hand, I cannot seem to reproduce it.

This was on a fresh clone. What I did was:

        (s017241) [/usr/src] git clone 131.188.30.102:/scratch/tg/linux-2.6/
        Initialized empty Git repository in /usr/src/linux-2.6/.git/
        remote: Generating pack...
        remote: Done counting 496189 objects.
        remote: Deltifying 496189 objects...
        remote:  100% (496189/496189) done
        Indexing 496189 objects...
        remote: Total 496189 (delta 401610), reused 496189 (delta 401610)
        100% (496189/496189) done
        Resolving 401610 deltas...
        100% (401610/401610) donedone
        fatal: Not a valid object name HEAD

I see it. Last line. I tried to clone from a repository which itself had a
detached HEAD. Could that be the problem?

        Thomas

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Perhaps repository was set up in an unusual way by hand
> (i.e. not by a clone), such that:
>
>  1. you have HEAD pointing at a branch (e.g. 'refs/heads/master'),
>  2. which does _not_ exist yet (i.e. no 'refs/heads/master'),
>  3. yet you have a tag that you can try to detach your HEAD to (e.g. v2.6.20).
>
> ... well that was my initial guess, but even after setting up such a
> funny repository by hand, I cannot seem to reproduce it.

Actually, that turns out to be the reason for 'maint' releases,
although it works on 'master' (hence will be in 1.5.3 later).

How did you get your repository into such a state to begin with?

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Junio C Hamano]

Thomas Glanzmann <thomas@glanzmann.de> writes:

> I see it. Last line. I tried to clone from a repository which itself had a
> detached HEAD. Could that be the problem?

Ah, our mails crossed.

There is no reason to forbid cloning of a repository whose HEAD
is detached, but detached HEAD is a relatively recent invention,
and I would not be surprised if that was indeed the breakage,
nor nobody has hit this so far.

It's sufficiently late here so I do not think I would be able to
take a look at it tonight, though.  Sorry.

Just in case you need unblocking (although I think you know how
already), you should be able to continue with:

	$ git rev-parse v2.6.20^0 >.git/HEAD
        $ git read-tree HEAD
        $ git checkout-index -f -q -u -a

That would give you a normal detached state at v2.6.20; you
should be able to come back to your branches with usual "git
checkout".

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[Thomas Glanzmann]

Hello Junio,
sleep well! And if you want to reproduce it yourself we can e-mail
tomorrow or whenever you like.

Thanks,
        Thomas

Re: fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

[carbonated beverage]

On Fri, Jun 08, 2007 at 03:27:30AM -0700, Junio C Hamano wrote:
> How did you get your repository into such a state to begin with?

It's kinda odd to see this thread, as I hit this issue today, as well.

If you need another test case, the cvsps git repo shows this too:

ramune/lycaeum:git: git clone  http://ydirson.free.fr/soft/git/cvsps.git
<snip checkout messages>
ramune/lycaeum:git: cd cvsps
ramune/lycaeum:cvsps: ls
ramune/lycaeum:cvsps: git checkout -f
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
ramune/lycaeum:cvsps: cat .git/HEAD
ref: refs/heads/master
ramune/lycaeum:cvsps: ls .git/refs/head/master
ls: .git/refs/head/master: No such file or directory

-- DN
Daniel

fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Todd Wells]

I was using GitX to prepare a commit. Something happened -- I don't 
know what --  and suddenly my branch only had a single commit 
in it that appears to contain all  the files in my tree. So I went to the 
command line and did this:

$ git reset --soft HEAD^ 
fatal: ambiguous argument 'HEAD^': unknown revision or path not 
in the working tree.

When I do 'git log' in this branch, there's only one commit. Now, I 
had many commits in this branch a few minutes ago. I really, 
really, don't want to lose this.

What steps should I take to attempt to recover?

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[SZEDER Gábor]

Hi Todd,

On Thu, Oct 28, 2010 at 01:09:08PM +0000, Todd Wells wrote:
> I was using GitX to prepare a commit. Something happened -- I don't 
> know what --  and suddenly my branch only had a single commit 
> in it that appears to contain all  the files in my tree. So I went to the 
> command line and did this:
> 
> $ git reset --soft HEAD^ 
> fatal: ambiguous argument 'HEAD^': unknown revision or path not 
> in the working tree.
> 
> When I do 'git log' in this branch, there's only one commit. Now, I 
> had many commits in this branch a few minutes ago. I really, 
> really, don't want to lose this.
> 
> What steps should I take to attempt to recover?

Take a look at 'gitk yourbranch@{1}' or 'git log yourbranch@{1}'.  If
it looks like your branch's lost history, then you can recover from
this situation with 'git reset --hard yourbranch@{1}'.

You can read up about the details here:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes

HtH,
Gábor

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Mathias Lafeldt]

Todd Wells wrote:
> I was using GitX to prepare a commit. Something happened -- I don't 
> know what --  and suddenly my branch only had a single commit 
> in it that appears to contain all  the files in my tree. So I went to the 
> command line and did this:
> 
> $ git reset --soft HEAD^ 
> fatal: ambiguous argument 'HEAD^': unknown revision or path not 
> in the working tree.
> 
> When I do 'git log' in this branch, there's only one commit. Now, I 
> had many commits in this branch a few minutes ago. I really, 
> really, don't want to lose this.
> 
> What steps should I take to attempt to recover?

Check if you can reset your HEAD to a previous state saved in your
(local) reflog.

See section "RefLog Shortnames" in http://progit.org/book/ch6-1.html

-Mathias

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Santi Béjar]

On Thu, Oct 28, 2010 at 3:09 PM, Todd Wells <ttopwells@gmail.com> wrote:
> I was using GitX to prepare a commit. Something happened -- I don't
> know what --  and suddenly my branch only had a single commit
> in it that appears to contain all  the files in my tree. So I went to the
> command line and did this:
>
> $ git reset --soft HEAD^
> fatal: ambiguous argument 'HEAD^': unknown revision or path not
> in the working tree.
>
> When I do 'git log' in this branch, there's only one commit. Now, I
> had many commits in this branch a few minutes ago. I really,
> really, don't want to lose this.
>
> What steps should I take to attempt to recover?

You could try:

git log -g

which will show you the reflog, a log of recent tip commits of HEAD.
You could also try to see other local branches and their reflog.

If all this fails you can:

git fsck --unreachable

that will output all the unreachable commits/objects, those not in
your branches or reflogs.

Once you have the correct commit you can reset the HEAD to this commit:

git reset HEAD

(or with --hard as necessary).

HTH,
Santi

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Santi Béjar]

Please, don't top post, it's difficult to follow a "reversed" conversation.

On Thu, Oct 28, 2010 at 3:54 PM, Todd Wells <ttopwells@gmail.com> wrote:
> Thanks all of you for your speedy responses.
> git log -g does indeed show my previous commits, for example:
>
> Reflog: HEAD@{0} (Todd Wells <ttopwells@gmail.com>)
> Reflog message: commit: convert mason template to use
> ProjectService.getAllGroups()
> Author: Todd Wells <ttopwells@gmail.com>
> Date:   Thu Oct 28 05:54:22 2010 -0700
>     convert mason template to use ProjectService.getAllGroups()
> commit b80ed79669c56669f05175db9eb9eba4a5fb296e
> // ...etc
>
>
> But I'm not quite sure now if I should do  'git reset --hard yourbranch@{1}'
> or 'git reset HEAD@{0}' or something else.

HEAD@{0} = HEAD

so for sure it is not what you want.

You should first examine the commit history with "git log" or better with gitk:

gitk HEAD@{1}

or

gitk HEAD@{2}

and when you are sure:

git reset --hard HEAD@{n}

(Note that all local changes in the worktree will be lost).

HTH,
Santi

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[davilda_]

Hi,
i'm new with git and i just want to cancel a commit. I just do git add and
git commit.
How can i canceled a commit in my case.
Best regards



--
View this message in context: http://git.661346.n2.nabble.com/fatal-ambiguous-argument-HEAD-unknown-revision-or-path-not-in-the-working-tree-tp5682535p7639207.html
Sent from the git mailing list archive at Nabble.com.

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Jeff King]

On Wed, Sep 09, 2015 at 01:34:03AM -0700, davilda_ wrote:

> i'm new with git and i just want to cancel a commit. I just do git add and
> git commit.
> How can i canceled a commit in my case.

Usually with "git reset HEAD^". But I'm guessing from your subject line
that you tried that, and it did not work because this commit is the
_only_ commit in your repository (and "HEAD^", which means "the parent
commit of HEAD", does not make any sense, as there is no parent).

Annoyingly, I don't think there is an easy way with the current tools to
handle this corner case (you want to not reset to a commit, but back to
the "unborn branch" state).

The "simplest" way to do that is:

  rm .git/refs/heads/master

but that is not guaranteed to work in future versions of git, and I
wouldn't recommend it in general.

Probably a better workflow is to create the commit state you _do_ want
(change files, "git add" them, etc), and then run "git commit --amend"
to replace the bad commit.

-Peff

Re: fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree.

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> The "simplest" way to do that is:
>
>   rm .git/refs/heads/master
>
> but that is not guaranteed to work in future versions of git, and I
> wouldn't recommend it in general.

Yeah, "git checkout -b" has a stronger sibling "git checkout -B"
(i.e. I know that the named branch already exists, so this is not a
request to create a new one, but to repoint that existing one), but
there is no analogue for "git checkout --orphan".  That could be
worked around with something like this though:

    $ git checkout --orphan hu
    $ git branch -D master
    $ git checkout --orphan master

As I agree with your "amending is better", I do not think allowing
an easier access to such a feature is urgent or important, though.

> Probably a better workflow is to create the commit state you _do_ want
> (change files, "git add" them, etc), and then run "git commit --amend"
> to replace the bad commit.