Re: filter-branch: Remove original/*

Junio C Hamano [off-list ref] writes:

Johannes Schindelin [off-list ref] writes:

quoted

quoted

That merely means whoever changes the tag and wants the record of such an
update, which is uncommon, need to make sure reflog is created for that
tag (and that tag only).

The thing is: we cannot.  At least not at the moment.

$ mkdir -p .git/logs/refs/tags
$ >.git/logs/refs/tags/junker
$ git tag junker
$ wc .git/logs/refs/tags/junker
  1   8 134 .git/logs/refs/tags/junker

Ok, it's not 180 byte as I said, but only 134 bytes.

Having proven my superiour intelligence ;-) I think I can agree if your
next proposal is to toggle reflog on for the tag when "git tag -f" is used
to update an existing tag and core.logAllRefUpdates does not say "never"
(this new value needs to be treated the same as "false" for most other
purposes), and the tag does not already have a reflog.

Hi,

On Sun, 15 Feb 2009, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

That merely means whoever changes the tag and wants the record of such an
update, which is uncommon, need to make sure reflog is created for that
tag (and that tag only).

The thing is: we cannot.  At least not at the moment.

$ mkdir -p .git/logs/refs/tags
$ >.git/logs/refs/tags/junker
$ git tag junker
$ wc .git/logs/refs/tags/junker
  1   8 134 .git/logs/refs/tags/junker

Ok, it's not 180 byte as I said, but only 134 bytes.

Having proven my superiour intelligence ;-) I think I can agree if your
next proposal is to toggle reflog on for the tag when "git tag -f" is used
to update an existing tag and core.logAllRefUpdates does not say "never"
(this new value needs to be treated the same as "false" for most other
purposes), and the tag does not already have a reflog.

Actually, to prove my inferior intelligence, I suggest going for the easy 
solution: replace the update-ref in filter-branch by a call to git tag -f, 
after making sure that the reflog exists (with >>.git/logs/$tagname).

Eric?

Ciao,
Dscho

Hi,

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

On Sun, 15 Feb 2009, Junio C Hamano wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

That merely means whoever changes the tag and wants the record of such an
update, which is uncommon, need to make sure reflog is created for that
tag (and that tag only).

The thing is: we cannot.  At least not at the moment.

$ mkdir -p .git/logs/refs/tags
$ >.git/logs/refs/tags/junker
$ git tag junker
$ wc .git/logs/refs/tags/junker
  1   8 134 .git/logs/refs/tags/junker

Ok, it's not 180 byte as I said, but only 134 bytes.

Having proven my superiour intelligence ;-) I think I can agree if your
next proposal is to toggle reflog on for the tag when "git tag -f" is used
to update an existing tag and core.logAllRefUpdates does not say "never"
(this new value needs to be treated the same as "false" for most other
purposes), and the tag does not already have a reflog.

Actually, to prove my inferior intelligence, I suggest going for the easy 
solution: replace the update-ref in filter-branch by a call to git tag -f, 
after making sure that the reflog exists (with >>.git/logs/$tagname).

Indeed, this proves my inferior intelligence: the update-ref method at 
least kept as much information as possible in the tag, including the 
tagger.

So please strike my suggestion from your memory.

Ciao,
Dscho

Hi,

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

quoted

On Sun, 15 Feb 2009, Junio C Hamano wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Johannes Schindelin [off-list ref] writes:

quoted

quoted

That merely means whoever changes the tag and wants the record 
of such an update, which is uncommon, need to make sure reflog 
is created for that tag (and that tag only).

The thing is: we cannot.  At least not at the moment.

$ mkdir -p .git/logs/refs/tags
$ >.git/logs/refs/tags/junker
$ git tag junker
$ wc .git/logs/refs/tags/junker
  1   8 134 .git/logs/refs/tags/junker

Ok, it's not 180 byte as I said, but only 134 bytes.

Having proven my superiour intelligence ;-) I think I can agree if 
your next proposal is to toggle reflog on for the tag when "git tag 
-f" is used to update an existing tag and core.logAllRefUpdates does 
not say "never" (this new value needs to be treated the same as 
"false" for most other purposes), and the tag does not already have 
a reflog.

Actually, to prove my inferior intelligence, I suggest going for the 
easy solution: replace the update-ref in filter-branch by a call to 
git tag -f, after making sure that the reflog exists (with 

quoted

quoted

.git/logs/$tagname).

Indeed, this proves my inferior intelligence: the update-ref method at 
least kept as much information as possible in the tag, including the 
tagger.

Maybe I can salvage a little bit of the "sapiens" part in the name of the 
species I think I am part of:

-- snip --

 git-filter-branch.sh |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 27b57b8..d828a91 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh

@@ -459,6 +459,10 @@ if [ "$filter_tag_name" ]; then
 			then
 				warn "gpg signature stripped from tag object $sha1t"
 			fi
+			# make sure the reflogs are written
+			mkdir -p "$(dirname "$GIT_DIR/logs/$new_ref")" &&
+			>> "$GIT_DIR/logs/$new_ref" ||
+			die "Could not initialize reflogs for $new_ref"
 		fi
 
 		git update-ref "refs/tags/$new_ref" "$new_sha1" ||
-- snap --

Eric, this is not even compile tested ;-)  But maybe you can start from 
there?

Ciao,
Dscho