git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Junio C Hamano <junkio@cox.net>
Cc: Jeff King <peff@peff.net>, Nicolas Pitre <nico@cam.org>,
	cworth@cworth.org, git@vger.kernel.org
Subject: Re: Difficulties in advertising a new branch to git newbies
Date: Wed, 31 Jan 2007 17:51:21 -0500	[thread overview]
Message-ID: <20070131225121.GC20514@thunk.org> (raw)
In-Reply-To: <7vhcu7uewe.fsf@assigned-by-dhcp.cox.net>

On Wed, Jan 31, 2007 at 12:20:33PM -0800, Junio C Hamano wrote:
> I think you (and others in the thread) are forgetting that
> moving to a particular state by resetting can create a state
> that you may want to keep a pointer to, but you do not have any
> existing ref.  That's one of the reasons why we do not merely
> check if the detached HEAD is not reachable from any of the
> existing refs when coming back.  Instead, we check and warn if
> the detached HEAD does not exactly match one of the existing
> refs.

Is that an important distinction?  The way the user got there was by
manually specifying the SHA-1 shash of the commit to git-checkout.  So
if the user could get there once, the user could get there again a
second time.  Just because we don't have a name to that precise commit
inside the git system doesn't necessary mean the user can't get back
there.   In fact, the user probably could via "history | grep 'git checkout'".

> So "until you make commits" is not sufficient, which means that
> covering all the way you can make commits isn't, either.

My personal belief is that covering all the way you can make commits
is where you want to be putting the check.  If I say something like

git checkout f00b51b8

There's nothing dangerous about that statement.  To argue that this is
dangerous and the git needs to warn me because I might not be able to
get back to it seems silly.  Of _course_ I can get back there; the
same way I got here in the first place --- By simply saying, "git
checkout f00b51b8" again!

And if I tell a user that they should try out a particular version of
the code, issueing a scary message right then there is pointless if
they are only going to be doing a read-only browse of the tree, is
just a Bad Thing.  The best place to warn them really is when they
modify the tree.

Otherwise, we'll be educating users to use the -f flag, or telling
users to "ignore the warning, git's being silly", neither of which is
desirable.

						- Ted

  reply	other threads:[~2007-01-31 22:51 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-30 20:13 Difficulties in advertising a new branch to git newbies Carl Worth
2007-01-30 21:02 ` Jakub Narebski
2007-01-30 21:25   ` Yann Dirson
2007-01-30 21:31     ` Jakub Narebski
2007-01-30 21:32     ` Junio C Hamano
2007-01-30 21:40       ` Jakub Narebski
2007-01-30 22:33 ` Matthias Lederhofer
2007-01-30 22:36   ` Matthias Lederhofer
2007-01-30 23:10 ` Jeff King
2007-01-31  1:34   ` Junio C Hamano
2007-01-31  1:51     ` Nicolas Pitre
2007-01-31  3:22     ` Jeff King
2007-01-31 14:59       ` Nicolas Pitre
2007-01-31 17:07         ` Jeff King
2007-01-31 18:59           ` Nicolas Pitre
2007-01-31 22:53             ` Jeff King
2007-01-31 20:20           ` Junio C Hamano
2007-01-31 22:51             ` Theodore Tso [this message]
2007-01-31 23:03               ` Junio C Hamano
2007-01-31 23:18               ` Jakub Narebski
2007-01-31  1:48   ` Nicolas Pitre
2007-01-31  0:10 ` Daniel Barkalow
2007-01-31  1:55   ` Nicolas Pitre
2007-01-31  5:09     ` Daniel Barkalow
2007-01-31 14:31       ` Nicolas Pitre
2007-01-31 14:38         ` J. Bruce Fields
2007-01-31 14:53           ` Jakub Narebski
2007-01-31 15:15             ` Nicolas Pitre
2007-01-31 16:25         ` Daniel Barkalow
2007-01-31 18:25           ` Nicolas Pitre
2007-01-31 13:13 ` Guilhem Bonnefille
2007-01-31 16:06   ` Carl Worth
2007-01-31 16:15     ` Johannes Schindelin
2007-01-31 19:27 ` Santi Béjar
2007-01-31 19:50   ` Carl Worth
2007-02-01  0:20     ` Josef Weidendorfer
2007-02-01  9:02       ` Santi Béjar
2007-02-01  4:12 ` Jakub Narebski
2007-02-06  5:51 ` Carl Worth
2007-02-06  6:37   ` Junio C Hamano
2007-02-06  7:25     ` Junio C Hamano
2007-02-06  7:31       ` Jeff King
2007-02-06 18:53     ` Carl Worth
2007-02-06 19:14       ` Junio C Hamano
2007-02-06 19:39         ` Carl Worth
2007-02-06 19:58           ` Jakub Narebski
2007-02-06  7:28   ` Jeff King
2007-02-06  7:46     ` Junio C Hamano
2007-02-06  8:12       ` Jeff King
2007-02-06 15:33     ` Nicolas Pitre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070131225121.GC20514@thunk.org \
    --to=tytso@mit.edu \
    --cc=cworth@cworth.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=nico@cam.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).