On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt wrote:
> Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>>
>>> IOW, if the command was something like
>>>
>>> git filter-branch ...filter options... -- v1.0 master ...
>>>
>>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
>>
Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>
>> IOW, if the command was something like
>>
>> git filter-branch ...filter options... -- v1.0 master ...
>>
>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
>> deleted if the commit it points to goes away. But if the comm
>
> IOW, if the command was something like
>
> git filter-branch ...filter options... -- v1.0 master ...
>
> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
> deleted if the commit it points to goes away. But if the commit did not
> go away, but was rewritten, then it is
Am 03.01.2013 00:19, schrieb Junio C Hamano:
> Grégory Pakosz writes:
>
>> So we have an annotated tag that points to a commit that is rewritten
>> to nothing as the result of the filtering. What should happen?
>
> If the user asked to filter that tag itself, it may make sense to
> remove it, ra
Grégory Pakosz writes:
> So we have an annotated tag that points to a commit that is rewritten
> to nothing as the result of the filtering. What should happen?
If the user asked to filter that tag itself, it may make sense to
remove it, rather than keeping it pointing at the original commit,
bec
> I was wondering if it should be
>
> sha1=$(git rev-parse --verify "$ref")
>
> or something that does not dereference a tag at all.
>
> The way I read what that loop seems to want to do is:
>
> Read each refname that was given originally from the file
> $tempdir/heads, find
Grégory Pakosz writes:
> Are you suggesting $sha1 should be obtained differently before
> entering case "$rewritten" ?
> That would mean changing sha1=$(git rev-parse "$ref"^0) at line 376 to
> something like $(git cat-file -t "$ref") = 'tag' && sha1=$(git
> rev-parse "$ref") || sha1=$(git rev-pa
> Yeah, but in that case it appears to me that you told the command to
> rewrite the tag itself and the history behind the commit the tag
> refers to, but the end result did not rewrite the tag itself and
> left the tag pointing at the original history.
>
The problem exhibits at the point git filte
Grégory Pakosz writes:
> in my use case, $ref is "refs/tags/4.0" which is an annotated tag
>
> $ git rev-parse "refs/tags/4.0"
> e941b106c17b59320f776d58b71fc2fcdb72
Yeah, but in that case it appears to me that you told the command to
rewrite the tag itself and the history behind the commit
ring didn't take place in between
test $(git rev-parse --verify "$ref^{commit}") = $sha1
and
git update-ref -m "filter-branch: delete" -d "$ref".
How defensive should git filter-branch really be?
> At the implementation level. When the ref being deleted po
Am 31.12.2012 17:24, schrieb Grégory Pakosz:
> Please disregard the previous email that contains an incorrect fix
> suggestion. I wish my first contribution was flawless.
>
> Here is what's happening.
> git-filter-branch let git-update-ref -d verify that the value for $ref
> matches $sha1.
> Howev
Grégory Pakosz writes:
> 1) either make git-filter-branch dereference annotated tags and do
> the verification itself then use the two arguments version of git
> update-ref
> 2) in the case of an annotated tag, pass another to git
> update-ref
>
> Please find below a patch that implements s
Please disregard the previous email that contains an incorrect fix
suggestion. I wish my first contribution was flawless.
Here is what's happening.
git-filter-branch let git-update-ref -d verify that the value for $ref
matches $sha1.
However, when $ref points to an annotated tag that is being dele
Hello,
I noticed git-filter-branch doesn't dereference annotated tags prior
to invoking git update-ref -d.
Please find a patch attached that changes the call to git update-ref:
-git update-ref -m "filter-branch: delete" -d "$ref" $sha1
+git update-ref -m "filte
14 matches
Mail list logo
