Re: filter-branch: Remove original/*
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 16, 2009, 11:25 UTC
- Message-ID
- <alpine.DEB.1.00.0902161224140.10279@pacific.mpi-cbg.de>
- In-Reply-To
- <alpine.DEB.1.00.0902161218250.10279@pacific.mpi-cbg.de>
Hi,
On Mon, 16 Feb 2009, Johannes Schindelin wrote:
Show 29 quoted lines
> On Sun, 15 Feb 2009, Junio C Hamano wrote: > > > Junio C Hamano <gitster@pobox.com> writes: > > > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > > > >>> 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