Am 03.01.2013 00:19, schrieb Junio C Hamano:
Grégory Pakosz gpak...@visionobjects.com 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
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 equally
On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt j...@kdbg.org 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 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.
However,
the ref being deleted pointed at
a tree or a blob, the original would have correctly removed it, but
will the updated one?
Yes.
Now that you made me think about it even more, the title of that
thread isn't git filter-branch doesn't dereference annotated tags.
It in fact does as per sha1=$(git rev
Grégory Pakosz gpak...@visionobjects.com 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
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
Grégory Pakosz gpak...@visionobjects.com 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) ||
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 filter-branch: delete -d $(git rev-parse
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
Grégory Pakosz gpak...@visionobjects.com 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 old value to git
update-ref
Please find
11 matches
Mail list logo
