From mboxrd@z Thu Jan  1 00:00:00 1970
From: john at keeping.me.uk (John Keeping)
Date: Fri, 19 Apr 2013 08:54:37 +0100
Subject: [PATCH] log: allow users to follow a file
In-Reply-To: <51702E0B.7030107@necoro.eu>
References: <516BE9CF.3060809@necoro.eu> <20130415123845.GF2278@serenity.lan>
 <516C3923.3060700@necoro.eu> <20130416084834.GL2278@serenity.lan>
 <7acf47c185acc0aa326be65d69320bc566e18cc2.1366227978.git.john@keeping.me.uk>
 <51702E0B.7030107@necoro.eu>
Message-ID: <20130419075437.GD2278@serenity.lan>

On Thu, Apr 18, 2013 at 07:31:55PM +0200, Ren? Neumann wrote:
> Thanks a lot for your patch, it is a huge step in the right direction
> (it is way more involved than I could imagine). One issue remains: It
> still displays empty diffstats (example: see [1]) for the commits
> _before_ the rename, as they are limited to the _new_ name. This might
> even lead to wrong commits if you have a commit "A -> B, C -> A" and are
> looking at the history of the new file A.

Thanks for trying this out.  I need to think about how to do this for a
bit because we'll need to change the links in the log to point to the
correct (pre-rename) file path, but then the "Log" link at the top of
the page will link to the log with that file name and we will only show
the pre-rename commits.

The answer to that should help with the corner case of the rename commit
itself, where we want to show both file paths, but I think it becomes
complicated when there are multiple renames in the history.

I don't really want to introduce two new query parameters, one of them
just so that clicking "Log" does the same as navigating back in the
browser.  Perhaps we should accept that once you click on a pre-rename
commit you are now examining that file path, so clicking "Log" doesn't
show any changes after it has been renamed.

That way we only need a bit of extra state to show the rename commit
itself, and the "follow" flag I'm already introducing should be
sufficient for that.