top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

git rev-parse --show-toplevel doesn't work inside git-dir

–1 vote
992 views

Running "git rev-parse --show-toplevel" doesn't print anything when it is run inside .git dir (on all levels)

posted Jun 5, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

This is by design. "--show-toplevel" does not print anything when you do not have a working tree, and you do not have one if you are inside the .git directory. If you were to do:

 cd .git
 git --work-tree=.. rev-parse --show-toplevel

(or use GIT_WORK_TREE, or set core.worktree, etc), you would get back the toplevel of the working tree.

answer Jun 5, 2013 by anonymous
Similar Questions
+1 vote

When run that command immediate after "git bisect start" somebody sees the full commit range as defined in "git bisect start".

However running that command later after few git bisect steps" somebody is just presented with the remaining commit interval. Is this intended ?

+1 vote

What's the meaning of the following in git name-rev output. I know the commit went into 100.15 version, but what to makeof ^2~4^2~1, any pointer to documentation ?

tags/100.15^2~4^2~1
+1 vote

In my local clone of git.git, currently with the v1.8.4-rc2 tag checked out and built (and installed on the system), starting up gitk yields an empty window, with a dialog in front of it:

 error    
 Can't parse git log output: { }

Has anyone else seen this, and know what might have happened? I do not get the behavior in other repositories (including other clones of git.git), only this particular one.

0 votes

I don't quite manage to figure out gits argv parsing and would need some help on the way.

I want:
git format-patch -o outdir HEAD~

Work exactly the way it does now, setting output_directory to outdir. But I also want
git format-patch -o HEAD~

to set output_directory with a NULL value so that I can assign a default value to it. Is that even possible with the current argv-parsing implementation?

The currect argv parser is using OPTION_CALLBACK so I thought that that callback should be able to determine if there was an outdir supplied or not.

Or is the correct solution to also add a bolean type OPTION_BOOLEAN for -o?

+1 vote

I'm using git 1.9.1 in Ubuntu 14.04.

I have a repository on github, a clone on my desktop and bare repo on a private server, in my desktop the remotes looks like this

all git@github.com:user/repo.git (fetch)
all git@github.com:user/repo.git (push)
all user@server.com:user/repo.git (push)
server user@server.com:user/repo.git (fetch)
server user@server.com:user/repo.git (push)
origin git@github.com:user/repo.git (fetch)
origin git@github.com:user/repo.git (push)

If I commit to master in my desktop and run 'git push all master', the github and the server repos are correctly updated, but if I run 'git status' the message says:

Your branch is ahead of 'origin/master' by 1 commit.
 (use "git push" to publish your local commits)

The message won't update unless I run git fetch or git push origin master. I'd expect the git status to give me a updated status message after calling 'git push all master'.

...