[v6,0/8] protect branches checked out in all worktrees

Message

Anders Kaseorg Nov. 13, 2021, 3:33 a.m. UTC

‘git fetch’ (without ‘--update-head-ok’), ‘git receive-pack’, and ‘git
branch -M’ protect the currently checked out branch from being
accidentally updated.  However, the code for these checks predates
‘git worktree’.  Improve it to protect branches checked out in all
worktrees, not just the current one.

Anders Kaseorg (8):
  fetch: lowercase error messages
  receive-pack: lowercase error messages
  branch: lowercase error messages
  worktree: simplify find_shared_symref() memory ownership model
  fetch: protect branches checked out in all worktrees
  receive-pack: clean dead code from update_worktree()
  receive-pack: protect current branch for bare repository worktree
  branch: protect branches checked out in all worktrees

 branch.c                        |  41 +++++++-----
 builtin/branch.c                |   7 +-
 builtin/fetch.c                 | 115 +++++++++++++++++---------------
 builtin/notes.c                 |   6 +-
 builtin/receive-pack.c          |  88 +++++++++++++-----------
 t/t2018-checkout-branch.sh      |   2 +-
 t/t3200-branch.sh               |   9 ++-
 t/t5504-fetch-receive-strict.sh |   2 +-
 t/t5516-fetch-push.sh           |  32 +++++++++
 worktree.c                      |   8 +--
 worktree.h                      |   5 +-
 11 files changed, 191 insertions(+), 124 deletions(-)

Comments

Johannes Schindelin Nov. 22, 2021, 1:21 p.m. UTC | #1

Hi Anders,

On Fri, 12 Nov 2021, Anders Kaseorg wrote:

> ‘git fetch’ (without ‘--update-head-ok’), ‘git receive-pack’, and ‘git
> branch -M’ protect the currently checked out branch from being
> accidentally updated.  However, the code for these checks predates
> ‘git worktree’.  Improve it to protect branches checked out in all
> worktrees, not just the current one.

I read through these patches, and in particular the last three were a real
delight to read, a highlight of my catching-up with the mailing list
today.

I am very much in favor of these patches to advance to `next` as-are.

Thank you,
Dscho