From: Jeff King <peff@peff.net>
To: Nicolas Pitre <nico@cam.org>
Cc: Junio C Hamano <junkio@cox.net>, cworth@cworth.org, git@vger.kernel.org
Subject: Re: Difficulties in advertising a new branch to git newbies
Date: Wed, 31 Jan 2007 17:53:52 -0500 [thread overview]
Message-ID: <20070131225352.GA31145@coredump.intra.peff.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0701311335150.3021@xanadu.home>
On Wed, Jan 31, 2007 at 01:59:37PM -0500, Nicolas Pitre wrote:
> > I would also be happy with warning (and
> > probably blocking without -f) moving from 3 to 1, which is the actual
> > dangerous thing.
> And that is already what is happening.
Doh! I'm a complete moron. Sorry, but I thought we were _not_ warning
there in favor of the warning at time of detachment. I even did a test,
but I botched it.
So please, accept my apology and assume I have hit myself over the head
with the clue stick several times. Warning at commit time _is_ stupid,
since we can complain at the correct time.
> Let's fix the warning then. But it must stay just because it is
> important that the user know _why_ and _when_ the head became detached.
> Realizing that head is detached later is far more confusing if the user
> just don't know how that happened.
OK, I completely see your point now; it doesn't have to be a _warning_
per se, but rather to let the user know this is when the state changed
(so that later if they do get a warning, it makes more sense).
> > > But making a warning at commit time is wrong. It is completely
> > > disconnected from the actual issue and I think it'd create more
> > > confusion because there is in fact nothing to worry about at the moment
> > > the commit is made. The very fact that you think yourself that a
> > > warning should be displayed at commit time indicates to me that you
> > > might be a bit confused yourself and such warning if present at commit
> > > time wouldn't help clearing that confusion at all.
> >
> > I think you are proving my point here. If you think warning at commit
> > time is too early, then how is warning _before_ that (when we detach)
> > not too early?
>
> Did I say anything about it being too early?
>
> I say that it is unnecessary and redundent, and that it would create
> more confusion than it clears.
You said "...there is in fact nothing to worry about at the moment the
commit is made." My point is that there is in fact nothing to worry
about at the moment that you detach, thus why should one get a warning
and not the other. But I agree that if you want the later warning to
make sense, it might be helpful to note that point (and I think it's
getting too fancy to tuck away that information and have the actual
warning say "When you moved your HEAD to foo~32, you were no longer on a
branch, therefore...")
So IOW, I think I agree with you now. :)
Again, sorry for the (my) confusion.
-Peff
next prev parent reply other threads:[~2007-01-31 22:54 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 [this message]
2007-01-31 20:20 ` Junio C Hamano
2007-01-31 22:51 ` Theodore Tso
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=20070131225352.GA31145@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=cworth@cworth.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=nico@cam.org \
/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).