From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH] checkout: indicate when a detached head is checked out for a branch
Date: Fri, 18 Jul 2014 10:36:11 -0700 [thread overview]
Message-ID: <xmqqr41imuwk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <35dbe7e3f3e4566d775bea19d816adc44db8ed5c.1405676303.git.git@drmicha.warpmail.net> (Michael J. Gruber's message of "Fri, 18 Jul 2014 11:50:42 +0200")
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I really like the new --to feature and will convert all my "new workdir"
> checkouts to that. But that detached checkout is so easy to miss - in fact
> I noticed it only when I compared "new-workdir" to "checkout --to" for a
> test repo with one branch, to see what a converter would need to do.
>
> I'm even wondering whether we should do this DWIMmery at all, given how
> "dangerous" a detached head is for those who are not aware of it
> before gc kicks in.
As long as the amount of warning about 'detached HEAD' is about the
same between this case and a "git checkout v1.2.3" in a normal
repository, I do not think there is no additional "danger" you need
to be worried about.
But I do agree that there should not be any DWIM here.
The reason to introduce this new set of rather intrusive changes is
so that working trees can be aware of branches other working trees
have checked out. And the whole point of wanting to have that
mutual awareness is to enable us to forbid users from mucking with
the same branch from two different places.
But Git is not in the position to dictate which alternative action
the user would want to take, when her "git checkout foo" is
prevented by this mechanism. In one scenario, she may say "I only
wanted to take a peek" and run "git checkout foo^0" instead. In
another, she may say "Ah, I forgot I already was doing this change
in the other one" and run "cd ../foo". There may be other classes
of alternative actions.
Don't make it easier for the first class of scenario and make it
less useful and more dangerous for the second class, especially the
second class involve forgetful users who are likely to forget seeing
the "we've warned you that we detached without being asked" message.
Please fix it to always just error out.
> (Sorry if that dupes something on the list, can't keep up these days;
> so this is coming from a "mere user" ;-)
>
> builtin/checkout.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index cfc6db7..38a5670 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -645,9 +645,9 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
> detach_advice(new->name);
> describe_detached_head(_("HEAD is now at"), new->commit);
> if (new->checkout && !*new->checkout)
> - fprintf(stderr, _("hint: the main checkout is holding this branch\n"));
> + fprintf(stderr, _("hint: the main checkout is holding this branch; detaching branch head instead.\n"));
> else if (new->checkout)
> - fprintf(stderr, _("hint: the linked checkout %s is holding this branch\n"),
> + fprintf(stderr, _("hint: the linked checkout %s is holding this branch; detaching branch head instead.\n"),
> new->checkout);
> }
> } else if (new->path) { /* Switch branches. */
next prev parent reply other threads:[~2014-07-18 17:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 9:50 [PATCH] checkout: indicate when a detached head is checked out for a branch Michael J Gruber
2014-07-18 10:58 ` Duy Nguyen
2014-07-18 13:27 ` Michael J Gruber
2014-07-18 14:13 ` Max Kirillov
2014-07-18 17:36 ` Junio C Hamano [this message]
2014-07-18 21:54 ` Dennis Kaarsemaker
2014-07-18 22:18 ` Junio C Hamano
2014-07-21 13:03 ` Michael J Gruber
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=xmqqr41imuwk.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/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).