Hi, On Tue, 6 Oct 2009, Euguess@xxxxxxxxx wrote: > I'ma new user of git and I don't think i will ever have a commit in > git.git, because I'm not a programmer (I'm QA). Welcome! Let me take this opportunity to express my deep sadness that your first input to this list was brushed off so carelessly. I sincerely hope that you give us another chance, and that you let us benefit from your fresh and unbiased view of the usability issues in Git (some of us use Git for so long, they think that Git has no usability issues anymore). > I was reading this topic as carefully as i could and I think that this > makes a lot of sense to address this issue. As i understand when > somebody fetches from remote repo in order to be able to start working > on the code from this remote repo you should create tracking branch for > one of the branches from remote and only then you should do your changes > or perform merges. > > in case if you didn't do that and you try to checkout you will end up > having detached HEAD which is quite scary;) for non-experienced user and > as i see might lead to some unnecessary questions in this list or on IRC > channel... Right. We see that type of confusion in #git everyday, and blaming the user would be a violation of http://c2.com/cgi/wiki?BlameTheRightThing > As for the solution i would choose the "simplest thing that will work" - > so i think that we just have to notify user about his suicide attempt to > checkout nonlocal branch and offer him a correct syntax to go with. > > Something like below should work: > > % git clone git://git.git git > % git checkout next > You're attempting to checkout to non-local branch. This will lead to your HEAD > being detached (our team is on its way!). > Do you want to check out local branch 'next' tracking 'origin/next' instead? > y/n > > if yes, then: > Created branch "next" tracking "origin/next" > You can update it with 'git pull'. > > If no - abort or continue with checkout to nonlocal branch? ('m not sure if > detaching HEAD can provide some benefits if done on purpose) > > I hope I'm not missing anything... No, I think that is something perfectly fine to expect in a software whose UI complexity is unfortunately pretty much in disagreement with its internal complexity. One thing one might add for the technically inclined folks (i.e. those who need to implement, and to see that Git is in dear need of some user-friendliness first): "git checkout" is a porcelain (i.e. a program meant for end-user consumption), and as such should not have a problem to react to isatty(0) (i.e. "is the input coming directly from the console?"). So yes, even if I was on the verge of giving up on this thread, I have been encouraged enough to get this uphill battle going again, and to try to overturn some stubborn resistance. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html