Re: [PATCH v2 09/12] worktree.c: test if branch being rebased in another worktree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nguyễn Thái Ngọc Duy  <pclouds@xxxxxxxxx> writes:

> Subject: Re: [PATCH v2 09/12] worktree.c: test if branch being rebased in another worktree

Lacks the verb?  Perhaps s/being/is/ is sufficient.

> This function find_shared_symref() is used in a couple places:
>
> 1) in builtin/branch.c: it's used to detect if a branch is checked out
>    elsewhere and refuse to delete the branch.
>
> 2) in builtin/notes.c: it's used to detect if a note is being merged in
>    another worktree
>
> 3) in branch.c, the function die_if_checked_out() is actually used by
>    "git checkout" and "git worktree add" to see if a branch is already
>    checked out elsewhere and refuse the operation.
>
> In cases 1 and 3, if a rebase is ongoing, "HEAD" will be in detached
> mode, find_shared_symref() fails to detect it and declares "no branch is
> checked out here", which is incorrect.

which is technically correct but is not what we want to check.

> This patch tightens the test. If the given symref is "HEAD", we try to
> detect if rebase is ongoing. If so return the branch being rebased. This
> makes checkout and branch delete operations safer because you can't
> checkout a branch being rebased in another place, or delete it.

Is rebase the only thing that tentatively detach before working on
the real branch?  It may be currently the case, but I would imagine
that we want to makefind-shared-symref to be responsible for
detecting new cases other than rebase that we may introduce in the
future, in which case we may want to leave come comment near the
function to describe that expectation.

> Special case for checkout. If the current branch is being rebased,
> git-rebase.sh may use "git checkout" to abort and return back to the
> original branch. The updated test in find_shared_symref() will prevent
> that and "git rebase --abort" will fail as a result.
> find_shared_symref() and die_if_checked_out() have to learn a new
> option ignore_current_worktree to loose the test a bit.

s/loose/&n/

> +void die_if_checked_out(const char *branch, int ignore_current_worktree)
>  {
>  	const struct worktree *wt;
>  
> -	wt = find_shared_symref("HEAD", branch);
> +	wt = find_shared_symref("HEAD", branch, ignore_current_worktree);
>  	if (wt) {
>  		skip_prefix(branch, "refs/heads/", &branch);
>  		die(_("'%s' is already checked out at '%s'"),
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index efcbd8f..6041718 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1111,7 +1111,7 @@ static int checkout_branch(struct checkout_opts *opts,
>  		char *head_ref = resolve_refdup("HEAD", 0, sha1, &flag);
>  		if (head_ref &&
>  		    (!(flag & REF_ISSYMREF) || strcmp(head_ref, new->path)))
> -			die_if_checked_out(new->path);
> +			die_if_checked_out(new->path, 1);
>  		free(head_ref);
>  	}

So the idea is "if the branch is checked out (or "being worked on"
even if technically the HEAD is detached, like with 'rebase')
anywhere, callers of die-if-checked-out in general want to die; but
for this caller, it is OK if the place the branch is checked out or
being worked on is in this repository"?

I understand die_if_checked_out() taking that "ignore this one" bit
may be sensible, but I do not understand why find_shared_symref()
needs to be told about it.  The change makes the meaning of the
find_shared_symref() function unclear.  It used to mean "This
symbolic ref cannot point at the same ref in different worktrees, so
for a given pair of a symbolic ref and a concrete ref, there can be
at most one worktree in which the symbolic ref points at that ref".
That is already a mouthful.  As the worktree structure already have
"Am I the current worktree?" bit, "ignore" logic can easily be done
inside die_if_checked_out() and that would help find_shared_symref()
stay simpler and more focused function, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]