[PATCH 2/2] filter-branch: work correctly with ambiguous refnames

Subsystems: the rest

DORMANTno replies

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

[PATCH 2/2] filter-branch: work correctly with ambiguous refnames

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:02

'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'.

[jc: original report and fix were done between Dmitry Potapov
and Dscho; I rewrote it using "rev-parse --symbolic-full-name"]

Signed-off-by: Junio C Hamano <redacted>
---

 Johannes Schindelin [off-list ref] writes:

 >> But at that point I would say that exposing the refname dwimming
 >> logic to the scripts could be a much cleaner solution.
 >
 > I considered that when ripping the script from cogito, but it seemed to me 
 > at that time that not requiring an up-to-date git for testing the script 
 > would be better.
 >
 > Now is a different situation, however, so I agree.

 It was already tied to the specific git version when
 git-filter-branch became part of git.git ;-)  

 I do not use filter-branch myself very often, but I think this
 is worth fixing.  The additional --no-flags and sed are to deal
 with something like:

	--topo-order master..next

 although I do not offhand know if filter-branch would work with
 things like --topo-order and --first-parent.

 git-filter-branch.sh |   22 +++-------------------
 1 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ae29f47..ebf05ca 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -209,25 +209,9 @@ ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
 GIT_WORK_TREE=.
 export GIT_DIR GIT_WORK_TREE
 
-# These refs should be updated if their heads were rewritten
-
-git rev-parse --revs-only --symbolic "$@" |
-while read ref
-do
-	# normalize ref
-	case "$ref" in
-	HEAD)
-		ref="$(git symbolic-ref "$ref")"
-	;;
-	refs/*)
-	;;
-	*)
-		ref="$(git for-each-ref --format='%(refname)' |
-			grep /"$ref")"
-	esac
-
-	git check-ref-format "$ref" && echo "$ref"
-done > "$tempdir"/heads
+# The refs should be updated if their heads were rewritten
+git rev-parse --no-flags --revs-only --symbolic-full-name "$@" |
+sed -e '/^^/d' >"$tempdir"/heads
 
 test -s "$tempdir"/heads ||
 	die "Which ref do you want to rewrite?"
-- 
1.5.4.rc2.38.gd6da3

Re: [PATCH 2/2] filter-branch: work correctly with ambiguous refnames

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:44:02

Hi,

On Sat, 5 Jan 2008, Junio C Hamano wrote:
 Johannes Schindelin [off-list ref] writes:

 > Junio wrote:
 >
 >> But at that point I would say that exposing the refname dwimming
 >> logic to the scripts could be a much cleaner solution.
 >
 > I considered that when ripping the script from cogito, but it seemed 
 > to me at that time that not requiring an up-to-date git for testing 
 > the script would be better.
 >
 > Now is a different situation, however, so I agree.

 It was already tied to the specific git version when
 git-filter-branch became part of git.git ;-)
Heh.  But that was not my intention (at least _before_ it was in git.git's 
"master"), so that people could test it.
 I do not use filter-branch myself very often, but I think this
 is worth fixing.  The additional --no-flags and sed are to deal
 with something like:

	--topo-order master..next

 although I do not offhand know if filter-branch would work with
 things like --topo-order and --first-parent.
Frankly, I have no idea, but --topo-order _should_ not matter, whereas 
--first-parent _should_ rewrite only commits in the first-parent chain of 
the given refs.

In any case, from a cursory look I like the 2 patches (except for the 
curly brackets around the single-line "else" clause, but I know your 
opinion about this, so I will not object).

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help