Knowing the "history as it was in repo X"

[Jesse Glick]

Alexis S. L. Carvalho wrote:
>> 16:34 <@bsmedberg> Mozilla-central is A-B-C
>> 16:34 <@bsmedberg> somebody branches A, does
>> 16:35 <@bsmedberg> A-D-E
>> 16:35 <@bsmedberg> then merges C+E=F
>> 16:35 <@bsmedberg> and pushes to mozilla-central
>> 16:35 <@bsmedberg> people want to be able to walk backwards through F-C-B-A
>> 16:35 <@bsmedberg> while ignoring D-E
> 
> I'm not sure this is exactly what you want, but have you looked at 
> hg log --follow-first ?

I guess this would show F-E-D-A ignoring B & C. What was requested 
sounds like a hypothetical --follow-second. But even that is not going 
to be reliable in more complicated situations where people merged 
between themselves or using multiple local repositories, etc.

You could set up a post-push hook on the server which simply appends the 
tip node ID to a text file somewhere. This would give a record of which 
revisions were ever 'tip' in the server. I'm not sure how useful this 
would be either, because these revisions do not necessarily form a 
direct ancestry chain: you could certainly diff between them 
meaningfully but some such diffs would group together multiple unrelated 
changesets. For example, say you start with

central: A

Two users start to do work:

central: A
alice: A-B-C
bob: A-D-E

Alice pushes:

central: A-B-C
alice: A-B-C
bob: A-D-E

Then Bob (after fetching):

central: A-D-E-F
          +-B-C-+
alice: A-B-C
bob: A-D-E-F
      +-B-C-+

Now your hypothetical text file would list:

A
C
F

where the diff from A-C would include B's changes as well as C's, and 
the diff from C-F would show D & E's changes. This shows what "happened 
on the server", whatever good that does you.