On Sat, Jul 21, 2018 at 11:56:06PM +0200, Johannes Schindelin wrote:
> > The script that I feed a message from gmane or public-inbox when I need
> > to learn the set of commits that resulted from the message instead uses
> > "git grep $message-id notes/amlog". And that is fast enough for my
> > purpose.
>
> Awesome. You might want to make sure that Peff stops advertising the amlog
> notes, then, though.
Woah, what did I do now?
> > There is no good reason to abuse the notes mechanism to map a random
> > object-name looking string (i.e. hash result of message id), other
> > than the ease of "quick access" when somebody is making a lot of
> > inquiry, but that "database" does not have to be stored in notes.
>
> Right. And it does not have to be stored anywhere, because nobody used it
> anyway, right?
If I understand the situation correctly, Junio is saying that he will
continue to produce the amlog mapping, and that it contains sufficient
information to produce the reverse mapping (which, as an aside, I did
not even know existed -- I mostly want to go the other way, from digging
in history to a mailing list conversation).
E.g., the script below builds and queries an incremental reverse
mapping.
-- >8 --
#!/usr/bin/perl
my $REF = 'refs/notes/amlog';
my $DBFILE = '.git/amlog.rev';
use DB_File;
my %h;
my $db = tie %h, 'DB_File', $DBFILE, O_CREAT|O_RDWR, 0644
or die "unable to open/create $DBFILE: $!";
my $db_tip = $h{TIP};
chomp(my $rev_tip = `git rev-parse $REF`);
if (!defined $db_tip || $db_tip ne $rev_tip) {
print STDERR "Updating reverse mapping...\n";
# using -p here is quick and easy, since we know the
# shape of the data. Using --raw and cat-file might be less
# hacky, though.
my @cmd = (qw(git log --format= --reverse -p), $rev_tip);
push @cmd, "^$db_tip" if defined $db_tip;
open(my $fh, "-|", @cmd);
my $commit;
while (<$fh>) {
if (m{^\+\+\+ b/([0-9a-f/]+)}) {
$commit = $1;
$commit =~ s/[^0-9a-f]//g;
} elsif (/^\+Message-Id: <(.*)>/i) {
print STDERR "Imported $commit => $1\n";
$h{$1} = $commit;
}
}
$h{TIP} = $rev_tip;
}
print "$h{$_} $_\n" for @ARGV;
-- >8 --
That stores it in a local dbm. But it could also build a git-notes tree
if you really want that.
And if I understand what is being said here:
> > It certainly does not belong to cycles worth spending by me *while*
> > I work during the say with various history reshaping tools to record
> > and/or update the reverse mapping and that is why my post-applypatch
> > hook no longer has the "reverse map" hack.
> >
> > It is not like anybody (including me) needs realtime up-to-date
> > reverse mapping from amlog while I run my "commit --amend", "rebase
> > -i", etc. and the reverse map is constructable by reversing the
> > forward map, obviously, with a postprocessing. And I think that is
> > a reasonably way forward if anybody wants to have a reverse mapping.
> > The postprocessing can be done either by me before pushing out the
> > amlog ref, or done by any consumer after fetching the amlog ref from
> > me. If I did the postprocessing and refuse to use rewrite hook you
> > wouldn't even know ;-)
It is not "I refuse to push out a reverse mapping". It is "I could make
the reverse mapping before push-out, and you would not need to know or
care if I did it all at once, or using a rewrite hook".
Though personally, I do not know if there is much point in pushing it
out, given that receivers can reverse the mapping themselves.
Or is there some argument that there is information in the reverse map
that _cannot_ be generated from the forward map?
-Peff
