[PATCH] hgweb: follow renames and copies in file log (issue1576)

[Matt Mackall]

On Thu, 2011-04-07 at 09:21 +1200, Robert O'Callahan wrote:
> Matt Mackall wrote:
> 
> > Consider this: if I ask "what did the President of the United States do
> > on Aug 21, 1959?", you can either say "he wasn't born yet" or "he was
> > admitting Hawaii into the union". Both of these answers are correct from
> > their perspective, but one is a hell of a lot more relevant. Also note
> > that one of these answers is constant, and the other changes wildly
> > based on when you ask the question.
> >
> > These two perspectives can be called 'identity' and 'position'.
> > Mercurial generally takes the 'position' perspective, because it's _the
> > only perspective available_ to tools like compilers, which see things
> > through the window of the filesystem. So if I ask "what were the
> > contents of Makefile on Dec 8, 2008?", I will not be impressed if you
> > tell me it didn't exist yet. I'm obviously interested in what make(1)
> > would have seen on that date, and any deletions and renames aren't
> > relevant.
> >
> 
> Your analogy doesn't map well onto how files are used, at least in projects
> like Mozilla.

Sure it does.

There are two ways to interpret the question "what is the history of
foo.c?". One is "what changes were made to the file that is currently
known as foo.c?" (the identity perspective) and the other is "what
changes were made to the file known as foo.c?" (the position
perspective). Which interpretation is the right one depends on context.

One answer is time-dependent, the other is not.

Let's think about the implications of that for a moment. What is 'now'
on hgweb? The tip? What if the tip doesn't even contain the file you're
interested in? What if there are multiple branches with different
identities of foo.c? The possibility of multiple heads means there is in
fact no consistent definition of 'now' on hgweb.

Similarly, it'd be highly confusing if hg log's default output were tied
to the current working directory contents, especially if the working
directory were in the 'past', thus causing future changes not to be
shown.

So while it's well-established that everyone initially -thinks- they
want the identity perspective, no one's yet been able to even articulate
a consistent story of how that works. In other words, people want us to
implement the elusive DWIM perspective.

What's been proposed here is that we switch from the position
perspective to the identity perspective when we hit the first revision
of a file. And when you consider that -that's not the only place- that
the identity perspective can diverge from the position perspective, it's
clear that this hybrid is -not consistent-. It can mislead people into
thinking that renames didn't appear elsewhere. Fails DWIM.

The other possible hybrid is 'merge both perspectives'. So if foo.c is
deleted and replaced by a rename from bar.c, then we show the history of
foo.c and bar.c. In this perspective, we hear that in 2003, the
president of the US invaded Iraq AND voted against invading Iraq. Also
fails DWIM.

> It would be great if there was at least an option in hgweb so we can enable
> the behavior we want.

Again, renames links are now shown in the paper file log view (and have
been there forever in the spartan style). This is about as close to a
consistent hybrid as I think we can get without making it modal.

-- 
Mathematics is the supreme nostalgia of our time.