Re: Minor bug report
On Wed, Jun 03, 2015 at 05:39:14PM +0200, Dennis Kaarsemaker wrote: On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote: I am kind of surprised after reading these two threads that my take on this issue has changed over time, as my knee-jerk reaction before reading them was the opposite, something along the lines of This is only immediately after 'git init'; why bother?. Or depending on my mood, that How stupid do you have to be... sounds exactly like a message I may advocate for us to send. Perhaps I grew more bitter with age. The fatal: Failed to resolve 'HEAD' as a valid ref. message, closely related to the fatal: bad default revision 'HEAD' message that started this thread just came by in #git with the following situation: $ git init $ git add . # Oops, didn't want to add foo.xyz $ git reset foo.xyz fatal: Failed to resolve 'HEAD' as a valid ref. The solution there is simple, git rm --cached, but I think git could produce more helpful messages when a repo is empty. Yeah, I think there are a lot of places we could handle unborn branches better. We've slowly been smoothing these rough edges over the years (usually by using the empty tree when we wanted HEAD to be a tree-ish). Patches welcome. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Minor bug report
On Wed, Jun 03, 2015 at 11:24:19AM +0530, Tummala Dhanvi wrote: When we do create a new empty git repo using git init or create a orphan branch and do a git log then I am getting an error saying that fatal: bad default revision 'HEAD' Well the error should have been something like no commits to show either the branch is orphan / you didn't make any commits in the new repo I would like to fix the trival bug myself can some one point me in the right direction to fix it Here are some prior discussions: http://thread.gmane.org/gmane.comp.version-control.git/75692 http://thread.gmane.org/gmane.comp.version-control.git/200504 I just skimmed through them, but I expect the most desirable solution would involve: 1. We still die(), but just improve the error message (so we don't have any regressions for people expecting git log to fail). 2. We use the message only when pointing to an unborn branch, and not on other errors. The simplest way to do this is probably to make an extra call to resolve_ref() in the error code-path. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Minor bug report
On Tue, Jun 2, 2015 at 11:20 PM, Jeff King p...@peff.net wrote: Here are some prior discussions: http://thread.gmane.org/gmane.comp.version-control.git/75692 http://thread.gmane.org/gmane.comp.version-control.git/200504 I just skimmed through them, but I expect the most desirable solution would involve: 1. We still die(), but just improve the error message (so we don't have any regressions for people expecting git log to fail). 2. We use the message only when pointing to an unborn branch, and not on other errors. The simplest way to do this is probably to make an extra call to resolve_ref() in the error code-path. -Peff I am kind of surprised after reading these two threads that my take on this issue has changed over time, as my knee-jerk reaction before reading them was the opposite, something along the lines of This is only immediately after 'git init'; why bother?. Or depending on my mood, that How stupid do you have to be... sounds exactly like a message I may advocate for us to send. Perhaps I grew more bitter with age. Jokes aside, I wonder why we did not pursue that default to HEAD only when HEAD points at a branch that exists approach, with the definition of exists being either a file exists under the $GIT_DIR/refs/heads directory with any (including corrupt) contents, or an entry in the packed refs file exists with any (including corrupt) contents. With or without the error exit and warning, that sounds like a very sensible way to set the default, at least to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Minor bug report
On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote: I am kind of surprised after reading these two threads that my take on this issue has changed over time, as my knee-jerk reaction before reading them was the opposite, something along the lines of This is only immediately after 'git init'; why bother?. Or depending on my mood, that How stupid do you have to be... sounds exactly like a message I may advocate for us to send. Perhaps I grew more bitter with age. The fatal: Failed to resolve 'HEAD' as a valid ref. message, closely related to the fatal: bad default revision 'HEAD' message that started this thread just came by in #git with the following situation: $ git init $ git add . # Oops, didn't want to add foo.xyz $ git reset foo.xyz fatal: Failed to resolve 'HEAD' as a valid ref. The solution there is simple, git rm --cached, but I think git could produce more helpful messages when a repo is empty. I think you are growing bitter with age ;) -- Dennis Kaarsemaker www.kaarsemaker.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Minor bug report
When we do create a new empty git repo using git init or create a orphan branch and do a git log then I am getting an error saying that fatal: bad default revision 'HEAD' Well the error should have been something like no commits to show either the branch is orphan / you didn't make any commits in the new repo I would like to fix the trival bug myself can some one point me in the right direction to fix it -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
