git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-filter-branch could be confused by similar names

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 3, 2008, 21:27 UTC
Message-ID
<7v7iiqppkw.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<1199040667-31850-1-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
Show 26 quoted lines
> 'git-filter-branch branch' could fail producing the error:
> "Which ref do you want to rewrite?" if existed another branch
> or tag, which name was 'branch-something' or 'something/branch'.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
>
> I have corrected my previous patch to allow "heads" or "tags"
> in the name of a branch or tag, i.e. to write it like this:
>    git filter-branch heads/master
>
>  git-filter-branch.sh     |    2 +-
>  t/t7003-filter-branch.sh |   10 ++++++++++
>  2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index dbab1a9..5de8b12 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -219,7 +219,7 @@ do
>  	;;
>  	*)
>  		ref="$(git for-each-ref --format='%(refname)' |
> -			grep /"$ref")"
> +			grep '^refs/\([^/]\+/\)\?'"$ref"'$')"
>  	esac

Do we assume everybody's grep groks ERE these days? I had an impression that we try to stick to a subset of BRE (namely, no \{m,n\}, [::], [==], nor [..]).

Also as a general rule when dealing with refname, we use fileglob not regex.

What's the goal here? Is it to make sure given refname is unambiguous by being a unique suffix of tags or heads, as in

	test $(git show-ref "$ref" | wc -l) = 1
or is there anything more going on?
Ah, it also wants the full name of the ref.  How about...
	ref=$(git show-ref "$ref" | sed -e 's/^.* //')

and have the "git check-ref-format" that comes later to issue an error message?

A better error message would be obtained with perhaps doing
	LF='
        '
        
at the beginning and then doing:
	candidate=$(git show-ref "$ref" | sed -e 's/^.* //')
	case "$candidate" in
        '')
        	die "should not happen -- $ref did not match?"
                ;;
        ?*"$LF"?*)
		die "$ref is ambiguous, which one of: $canidate?"
		;;
	esac
        ref=$candidate
Previous: Dmitry PotapovNext: Dmitry Potapov
Message 9 of 18 in “git-filter-branch could be confused by similar names”
  1. git-filter-branch could be confused by similar namesDmitry Potapov, Dec 25, 2007
  2. Johannes SchindelinDec 29, 2007
  3. Dmitry PotapovDec 30, 2007
  4. Johannes SchindelinDec 30, 2007
  5. Dmitry PotapovDec 30, 2007
  6. Johannes SchindelinDec 30, 2007
  7. Dmitry PotapovDec 30, 2007
  8. git-filter-branch could be confused by similar namesDmitry Potapov, Dec 30, 2007
  9. Junio C HamanoJan 3, 2008
  10. Dmitry PotapovJan 4, 2008
  11. Junio C HamanoJan 4, 2008
  12. Johannes SchindelinJan 5, 2008
  13. 1/2 git-rev-parse --symbolic-full-nameJunio C Hamano, Jan 5, 2008
  14. 2/2 filter-branch: work correctly with ambiguous refnamesJunio C Hamano, Jan 5, 2008
  15. Johannes SchindelinJan 6, 2008
  16. Junio C HamanoJan 6, 2008
  17. Johannes SchindelinJan 6, 2008
  18. Junio C HamanoJan 5, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.