Web lists-archives.com

Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits




William Chargin <wchargin@xxxxxxxxx> writes:

> This patch broadens the set of commits matched by ":/" pathspecs to
> include commits reachable from HEAD but not any named ref. This avoids
> surprising behavior when working with a detached HEAD and trying to
> refer to a commit that was recently created and only exists within the
> detached state.
>
> Signed-off-by: William Chargin <wchargin@xxxxxxxxx>
> Based-on-patch-by: Jeff King <peff@xxxxxxxx>
> ---
>  Documentation/revisions.txt   | 10 +++++-----
>  sha1-name.c                   |  1 +
>  t/t4208-log-magic-pathspec.sh | 14 ++++++++++++++
>  3 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 7d1bd4409..aa56907fd 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -181,11 +181,11 @@ existing tag object.
>    the '<rev>' before '{caret}'.
>  
>  ':/<text>', e.g. ':/fix nasty bug'::
> -  A colon, followed by a slash, followed by a text, names
> -  a commit whose commit message matches the specified regular expression.
> -  This name returns the youngest matching commit which is
> -  reachable from any ref. The regular expression can match any part of the
> -  commit message. To match messages starting with a string, one can use
> +  A colon, followed by a slash, followed by a text, names a commit whose
> +  commit message matches the specified regular expression. This name
> +  returns the youngest matching commit which is reachable from any ref
> +  or from HEAD. The regular expression can match any part of the commit
> +  message. To match messages starting with a string, one can use

Please avoid unnecessary reflowing of earlier lines of the paragrpah
when the only change is to insert "or from HEAD" in the middle of its
fourth line.  That wastes reviewers time (and typically there are
more readers than there are writers).  If you did this instead:

  A colon, followed by a slash, followed by a text, names
  a commit whose commit message matches the specified regular expression.
  This name returns the youngest matching commit which is
  reachable from any ref or from HEAD.
  The regular expression can match any part of the
  commit message. To match messages starting with a string, one can use

the resulting patch would have been much easier to follow.

Also, I am not sure if "or from HEAD" is even needed when we say
"from ANY ref" already, as we count things like HEAD as part of the
ref namespace.  It may only feel necessary for the person who made
the change to call handle_one_ref() not only with for_each_ref() but
also with head_ref()---in other words, I am wondering if it was
merely a bug to ignore HEAD in the code when the documentation said
"from any ref" already.  If that is the case, then the above change
is not necessary.

> diff --git a/sha1-name.c b/sha1-name.c
> index 60d9ef3c7..641ca12f9 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
>  			struct commit_list *list = NULL;
>  
>  			for_each_ref(handle_one_ref, &list);
> +			head_ref(handle_one_ref, &list);

Makes sense.

>  			commit_list_sort_by_date(&list);
>  			return get_oid_oneline(name + 2, oid, list);
>  		}
> diff --git a/t/t4208-log-magic-pathspec.sh b/t/t4208-log-magic-pathspec.sh
> index 62f335b2d..41b9f3eba 100755
> --- a/t/t4208-log-magic-pathspec.sh
> +++ b/t/t4208-log-magic-pathspec.sh
> @@ -25,6 +25,20 @@ test_expect_success '"git log :/a -- " should not be ambiguous' '
>  	git log :/a --
>  '
>  
> +test_expect_success '"git log :/detached -- " should find a commit only in HEAD' '
> +	test_when_finished "git checkout master" &&
> +	git checkout --detach &&
> +	test_tick &&
> +	git commit --allow-empty -m detached &&
> +	test_tick &&
> +	git commit --allow-empty -m something-else &&
> +	git log :/detached --
> +'
> +
> +test_expect_success '"git log :/detached -- " should not find an orphaned commit' '
> +	test_must_fail git log :/detached --
> +'
> +

OK.

I found these tests (including the existing ones) misleading, by the
way. We are interested in seeing that ":/string" is understood as a
valid object name, and this is not limited to "log" at all.  Instead
of "git log", perhaps "git rev-parse --verify :/detached" may have
been more to the point of what we are actually trying to see.

But that is a fault of having test for ":/<string>" in "magic pathspec"
test script; correcting that mistake is totally outside of the scope
of this fix.

Thanks.