Re: master^ is not a local branch -- huh?!?
- From
- Ron Garret <ron1@flownet.com>
- Date
- Jan 29, 2010, 21:43 UTC
- Message-ID
- <ron1-A90E72.13434029012010@news.gmane.org>
- In-Reply-To
- <8c9a061001291325i4b8898b9m46054040c69f8fc6@mail.gmail.com>
In article <8c9a061001291325i4b8898b9m46054040c69f8fc6@mail.gmail.com>, Jacob Helwig <jacob.helwig@gmail.com> wrote:
Show 22 quoted lines
> On Fri, Jan 29, 2010 at 13:16, Ron1 <ron1@flownet.com> wrote: > > I know that master^ is a commit and not a branch. I thought I was > > invoking the third variant of git-checkout (as given on the git-checkout > > man page) and checking out a commit (which the man page calls a > > tree-ish). > > > > In any case, since my question seems to have sparked some discussion, > > I'd like to offer two observations: > > > > 1. Saying "isn't a local branch" is mightily confusing, because it is > > ambiguous whether the problem is that it isn't a branch or if it isn't > > local. > > > > 2. If I pass something to git checkout (or any other command for that > > matter) that it expects to be a branch but isn't a branch it would be > > much better if it just gave an error and did nothing rather than give a > > (confusing) warning and try to extrapolate the user's intentions. > > Whatever a user could possibly mean by 'git checkout master^' it is > > almost certainly not what that command actually does at the moment. > > > > I don't think that #2 would be possible.
Of course it's possible. It git can complain and do something (which is what it does now) then it can just as easily complain and do nothing.
Show 5 quoted lines
> My understanding is that > branches are basically just there as convenient "names" for arbitrary > commits. In other words (in my understanding): There is no place that > expects a "branch" where a commit (SHA-1) would not work (and be a > perfectly valid use).
No, that's not true. Branches have names that are recorded separately from non-branch commits. It's not a big difference, but it is a difference.
rg