git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Anders Kaseorg <andersk@mit.edu>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Andreas Heiduk <andreas.heiduk@mathema.de>
Subject: Re: [PATCH v2] fetch: Protect branches checked out in all worktrees
Date: Fri, 5 Nov 2021 03:01:39 -0700	[thread overview]
Message-ID: <991240f7-2a3e-8ae7-ae25-a1d9d96d55d4@mit.edu> (raw)
In-Reply-To: <YYTtdZblnHYgDgBq@coredump.intra.peff.net>

On 11/5/21 01:38, Jeff King wrote:
> If we get the non-default worktree here, it might be nice to tell the
> user which worktree has it checked out. Otherwise it may lead to
> head-scratching as they peek at their current HEAD.

I’d agree if this case were reachable, but as per below, it seems not to 
be. So I didn’t bother figuring out how to shoehorn such a message into 
the arguments expected by format_display().

> I also notice that find_shared_symref() will catch cases where we're on
> a detached HEAD, but it's because we're rebasing or bisecting on a given
> branch. Arguably that's a sensible thing to do for this check, but it is
> a change from the current behavior (even if you are not using worktrees
> at all).

That’s a good observation. I agree it seems sensible, but should be 
noted in the commit message.

> So if the earlier hunk covered this case, then what is this hunk for? :)

Yeah, that duplication confused me too. The relevant call paths seem to be:

1. do_fetch calls check_not_current_branch (later hunk);
2. do_fetch calls fetch_and_consume_refs → store_updated_refs → 
update_local_ref (earlier hunk);
3. do_fetch calls backfill_tags → fetch_and_consume_refs → 
store_updated_refs → update_local_ref (earlier hunk);

in that order. That suggests there should be no way to trip the earlier 
hunk’s check without first tripping the latter hunk’s check.

>    $ git fetch . main:main
>    fatal: Refusing to fetch into branch 'refs/heads/main' checked out at '/home/peff/tmp'
> 
> It's technically correct, but perhaps it would be nicer to keep the old
> message if the worktree we found is the current one.

I note that this new message is more consistent with

$ git branch -d main
error: Cannot delete branch 'main' checked out at '/home/anders/tmp'


While looking for other related messages, I noticed another bug: 
receive-pack doesn’t stop you from updating or deleting a branch checked 
out in a worktree for a bare repository.

$ git init
$ git commit --allow-empty -qm foo
$ git clone --bare . bare.git
$ git -C bare.git worktree add wt
$ git -C bare.git/wt push .. :wt

To ..

  - [deleted]         wt


This is_bare_repository() check in update() in builtin/receive-pack.c 
seems wrong:

const struct worktree *worktree = is_bare_repository() ? NULL : 
find_shared_symref("HEAD", name);


Anders

  reply	other threads:[~2021-11-05 10:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 21:05 [PATCH] fetch: Protect branches checked out in all worktrees Anders Kaseorg
2021-11-04 21:10 ` [PATCH v2] " Anders Kaseorg
2021-11-05  8:38   ` Jeff King
2021-11-05 10:01     ` Anders Kaseorg [this message]
2021-11-05 11:53       ` Jeff King
2021-11-05 18:39         ` Junio C Hamano
2021-11-08 20:12         ` Anders Kaseorg

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=991240f7-2a3e-8ae7-ae25-a1d9d96d55d4@mit.edu \
    --to=andersk@mit.edu \
    --cc=andreas.heiduk@mathema.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).