On Wed, Jan 10, 2007 at 04:34:57PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > On Tue, Jan 09, 2007 at 03:46:32PM -0800, Linus Torvalds wrote: > > > >> I would suggest a solution: > >> > >> - git checkout will refuse to switch AWAY from a detached head unless the > >> SHA1 of the detached head exactly matches some other branch. > > > > What about > > > > git checkout HEAD~20 > > > > I agree that checking out tags will be more common, but it feels like we > > are discouraging this usage by presenting spurious warning messages. > > Once the user knows what HEAD~20 means, I think it is safe to > assume that the user knows what the branches are. I'm interested of course in making life easy for project admins when they need to tell testers how to get code to test out of git. It'll be nice to able to say: "Install git, then run git clone git://ourproject.com/ourproject.git cd ourproject git checkout <version you want> " Instead of having to say "Install git, then run git clone git://ourproject.com/ourproject.git cd ourproject git checkout -b FOO <version you want> Then if you later need to check out another version, run git reset --hard <other version> " I suppose <version you want> will typically be either some tagged release or the latest head. But it's not that farfetched to imagine asking someone to test version 01997b4.... > "git checkout master" will barf and suggests the user possible > common exits; "checkout -f" if there is nothing of value, > "checkout -b <branch>" or if they want to build on the current > state. That should make it easy enough, though, I guess. --b. - 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