All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuki Kokubun <orga.chem.job@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] filter-branch: consider refs can refer to an object other than commit or tag
Date: Wed, 21 Mar 2018 20:00:00 +0000	[thread overview]
Message-ID: <5ab2b606.86f5620a.c0c10.41b3@mx.google.com> (raw)
In-Reply-To: <xmqqwoy5pcno.fsf@gitster-ct.c.googlers.com>

> Yuki Kokubun <orga.chem.job@gmail.com> writes:
> 
> > "git filter-branch -- --all" can be confused when refs that refer to objects
> > other than commits or tags exists.
> > Because "git rev-parse --all" that is internally used can return refs that
> > refer to an object other than commit or tag. But it is not considered in the
> > phase of updating refs.
> 
> Could you describe what the consequence of that is?  We have a ref
> that points directly at a blob object, or a ref that points at a tag
> object that points at a blob object.  The current code leaves both of
> these refs in "$tempdir/heads".  Then...?

Sorry, this is my wrong.
I wrongly thought only refs/replace can point at a blob or tree object.

> 
> 	... goes and looks ...
> 
> There is a loop that looks like this:
> 
> 	while read ref
> 	do
> 		sha1=$(git rev-parse "$ref^0")
> 		...
> 	done <"$tempdir/heads"
> 
> which would break on anything but a commit-ish.
> 
> >  # The refs should be updated if their heads were rewritten
> >  git rev-parse --no-flags --revs-only --symbolic-full-name \
> > -	--default HEAD "$@" > "$tempdir"/raw-heads || exit
> > +	--default HEAD "$@" > "$tempdir"/raw-objects || exit
> > +# refs/replace can refer to an object other than commit or tag
> 
> Mention of replace refs in the proposed log message gives an easy to
> understand example and is a good idea, but this in code comment does
> not have to single out the replace refs.  A tag can also point at an
> object with any type, e.g. "git tag v2.6.11-tree v2.6.11^{tree}"
> would make "refs/tags/v2.6.11-tree" point at the tree at the top
> level of the tree-ish "v2.6.11".  It probably is OK to drop this
> comment altogether.

OK, I'm gonna drop the incorrect comment.

> 
> > +while read ref
> > +do
> > +	type=$(git cat-file -t "$ref")
> > +	if test $type = commit || test $type = tag
> > +	then
> > +		echo "$ref"
> > +	fi
> > +done >"$tempdir"/raw-heads <"$tempdir"/raw-objects
> >  sed -e '/^^/d' "$tempdir"/raw-heads >"$tempdir"/heads
> 
> So... is the idea to limit the set of refs to be rewritten to those
> that point at commits and tags?  As I already alluded to, I do not
> think you want to accept a ref that points at any tag object---only
> the ones that point at a tag that points at a commit-ish, so that
> the code will not barf when doing "$ref^0".
> 
> So perhaps
> 
> 	git rev-parse --no-flags ... >"$tempdir/raw-heads" || exit
> 
> 	while read ref
> 	do
> 		case "$ref" in ^?*) continue ;; esac
> 		if git rev-parse --verify "$ref^0" 2>/dev/null
>                 then
> 			echo "$ref"
> 		fi
> 	done >"$tempdir/heads" <"$tempdir/raw-heads"
> 
> or something?  Note that you do not need the "sed" as the loop
> already excludes the negative revs.

I feel using "git rev-parse --verify" is a good way as you said.
I'm gonna modify the patch to use it.

> 
> >  test -s "$tempdir"/heads ||
> > diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> > index 7cb60799b..efeaf5887 100755
> > --- a/t/t7003-filter-branch.sh
> > +++ b/t/t7003-filter-branch.sh
> > @@ -470,4 +470,17 @@ test_expect_success 'tree-filter deals with object name vs pathname ambiguity' '
> >  	git show HEAD:$ambiguous
> >  '
> >  
> > +test_expect_success 'rewrite repository including refs/replace that point to non commit object' '
> > +	test_when_finished "git reset --hard original" &&
> > +	tree=$(git rev-parse HEAD^{tree}) &&
> > +	test_when_finished "git replace -d $tree" &&
> > +	echo A >new &&
> > +	git add new &&
> > +	new_tree=$(git write-tree) &&
> > +	git replace $tree $new_tree &&
> 
> Perhaps something like this here:
> 
> 	git tag -a "tag to a tree" treetag $new_tree &&
> 
> can tell su how well it works with a tag that points at a tree?

Sounds good. I'm gonna add such tags to the test case.

> 
> > +	git reset --hard HEAD &&
> > +	git filter-branch -f -- --all >filter-output 2>&1 &&
> > +	! fgrep fatal filter-output
> > +'
> > +
> >  test_done

  reply	other threads:[~2018-03-21 19:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 10:35 [PATCH] filter-branch: consider refs/replace can refer to an object other than commit Yuki Kokubun
2018-03-21 15:31 ` [PATCH] filter-branch: consider refs can refer to an object other than commit or tag Yuki Kokubun
2018-03-21 17:21   ` Junio C Hamano
2018-03-21 20:00     ` Yuki Kokubun [this message]
2018-03-21 20:00       ` Junio C Hamano
2018-03-22 14:26         ` Yuki Kokubun
2018-03-22 17:01           ` Junio C Hamano
2018-03-23  2:15             ` Yuki Kokubun
2018-03-23  5:09               ` [PATCH v2] filter-branch: fix errors caused by refs that cannot be used with ^0 Yuki Kokubun
2018-03-23 20:20                 ` Junio C Hamano
2018-03-24 19:29                   ` [PATCH] filter-branch: consider refs can refer to an object other than commit or tag Yuki Kokubun
2018-03-24 19:41                   ` [PATCH v3] filter-branch: fix errors caused by refs that point at non-committish Yuki Kokubun
2018-03-25 16:25                     ` Junio C Hamano
2018-03-25 16:39                       ` Yuki Kokubun
2018-03-25 20:24                         ` Junio C Hamano
2018-03-25 16:54                       ` [PATCH v4] " Yuki Kokubun
2018-03-25 16:45                         ` Yuki Kokubun
2018-04-08 23:10                           ` Junio C Hamano
2018-03-25 17:01                         ` [PATCH v5] " Yuki Kokubun
2018-03-25 17:13                         ` [PATCH v4] " Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ab2b606.86f5620a.c0c10.41b3@mx.google.com \
    --to=orga.chem.job@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.