"warning: Updating the currently checked out branch may cause confusion" on bare repositories
It seems that the message "warning: Updating the currently checked out branch may cause confusion" is unnecessary when pushing to a bare "myproject.git" repository (instead of a "myproject/.git" repository).
Is this the case?
If so, perhaps the warning should be omitted when the target is a bare repository.
- a
Quoted 9 lines · Adam Megacz
It seems that the message "warning: Updating the currently checked out branch may cause confusion" is unnecessary when pushing to a bare "myproject.git" repository (instead of a "myproject/.git" repository).
Is this the case?
If so, perhaps the warning should be omitted when the target is a bare repository.
That should already be the case. Did you create the bare repository by taking a copy of a non-bare's .git directory? Check your bare repository's config file and see if core.bare = false, if so set it to true to signal it really is bare.
Signature · 1 line
Shawn.
Quoted 4 lines · Shawn O. Pearce
That should already be the case. Did you create the bare repository by taking a copy of a non-bare's .git directory? Check your bare repository's config file and see if core.bare = false, if so set it to true to signal it really is bare.
Hrm, is there a reason why this is explicitly configured rather than detected?
I was under the impression that you could create a bare repository by simply throwing away the working tree and renaming ".git" to any other name, but I guess I was wrong.
- a
Quoted 8 lines · Adam Megacz
Quoted 4 lines · Shawn O. Pearce
That should already be the case. Did you create the bare repository by taking a copy of a non-bare's .git directory? Check your bare repository's config file and see if core.bare = false, if so set it to true to signal it really is bare.
Hrm, is there a reason why this is explicitly configured rather than detected?
I don't know why we do this. I think its because the guessing logic can guess wrong sometimes.
Quoted 3 lines
I was under the impression that you could create a bare repository by simply throwing away the working tree and renaming ".git" to any other name, but I guess I was wrong.
If you delete the setting from the configuration file, Git usually almost always guesses correctly. :-)
Its rare to see it fail. But I think it can fail if you create a file called HEAD in the top level of your source code tree. (For example.)
Signature · 1 line
Shawn.
Quoted 7 lines · Shawn O. Pearce
Quoted 6 lines · Adam Megacz
Quoted 4 lines · Shawn O. Pearce
That should already be the case. Did you create the bare repository by taking a copy of a non-bare's .git directory? Check your bare repository's config file and see if core.bare = false, if so set it to true to signal it really is bare.
Quoted 5 lines
Quoted 2 lines
Hrm, is there a reason why this is explicitly configured rather than detected?
I don't know why we do this. I think its because the guessing logic can guess wrong sometimes.
Yup, although I am having trouble finding any actual discussion of when it can go wrong. There is some mention here:
http://article.gmane.org/gmane.comp.version-control.git/35993
and a little bit here in the 1.5.0 release notes:
http://article.gmane.org/gmane.comp.version-control.git/39612
But the latter talks about the heuristic being "does it end with .git", which I don't think we actually use anymore. So who knows if the heuristic failures are even trigger-able anymore. I tried looking at the setup code for an answer, but my eyes started bleeding from the horrible spaghetti code and I couldn't make out any of the text.
Quoted 3 lines
Its rare to see it fail. But I think it can fail if you create a file called HEAD in the top level of your source code tree. (For example.)
I don't think that would do it. When looking for a git dir we check for a well-formed HEAD, as well as objects and refs directories. The is_bare check seems to be more about "did we actually find a workdir" these days.
-Peff