Re: filter-branch: Remove original/*

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, 16 Feb 2009, Johannes Schindelin wrote:

> On Sun, 15 Feb 2009, Junio C Hamano wrote:
> 
> > Junio C Hamano <gitster@xxxxxxxxx> writes:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux