What should we change about the Mercurial Web UI?
September 23rd, 2008
Great news! Siddharth Kalra, a student at Seneca College, is going to work on Mercurial history browsing this semester.
The (vague) goal of the project is to take the now-familiar mercurial-central shortlog page and make it awesome. In case you haven’t seen it, Dirkjan Ochtman’s graph view is already a step in the right direction. It’ll probably be a starting point for Sid’s work.
What should Sid change? I have a few ideas:
- It would be great to have the history scroll “forever” up and down, like a tumblelog.
- Sometimes when I’m looking at history, I can’t tell if the changes I’m looking at happened in the mainline or in a branch. So ideally the page would show major lines of development in different colors–for example, blue for mozilla-central, orange for tracemonkey. This is possible using information from those repos’ pushlogs.
- Pushlog information could also be used to make those special paths relatively straight, with other smaller branches and mini-merges happening to the side or hidden by default with some kind of collapse/expand widget.
- It should show more information about each changeset, if it can be done in an unobtrusive way. I would like to know which directories were touched and roughly the size of the diffs.
- Often I wish I could filter the history by file or directory.
- A vertical timeline would be nice, so the location of a changeset on screen would tell something about when it was developed or pushed.
- It would be great to be able to zoom in and out and see weeks, months, years of work.
This is a call for ideas. What would you like to see? How can hgweb do a better job mapping the multiple timelines of this sci-fi adventure?
September 23rd, 2008 at 4:17 pm
You might consider starting with the pushloghtml page, which is what the Mozilla community seems to use, rather than the shortlog page, which isn’t very useful to begin with.
September 23rd, 2008 at 4:47 pm
Search history restricted to a particular date range and directories. (when a bug is found to start on a particular build from a month ago, need to find what was changed since the previous build, in relevant directories)
September 23rd, 2008 at 4:56 pm
It would be nice if I could view more than 10 entries at a time in the changelog.
September 23rd, 2008 at 7:03 pm
The thing that I use HG web for the most is digging through logs for a given file.
Specifically, I find myself looking at some piece of code wondering “why was this code written this way” or “what is this code trying to do”.
Today it is quite painful do dig that information up. HG Blame allows you to see who last changed a given line, but often times that is generic cleanup patches that didn’t actually change the functionality. So you have to figure out the revision before that change by looking at the HG log and go to the previous revision, then find the code again, and repeat the process until you find the last patch to make a functional change.
Bonsai was somewhat better in this regard. It at least showed you the checkin comment for every given line and jump to that revision. You could then manually step one revision further back since the version numbers were numeric.
It would be great if the HG log page contained links to the previous version for every line.
September 24th, 2008 at 6:08 am
Nice point, Jesse.
Sid, Ted Mielczarek did another “better shortlog” page, which you can see here:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=sep+10+2008&enddate=now
The most important thing here is that the dates it’s showing you are the dates those changes were *pushed* to mozilla-central, not the dates they were *committed*. As Jesse mentions the commit dates aren’t very useful.
This makes the history linear (a huge relief) and to some degree makes it obvious when a merge is big and when it’s little.
September 24th, 2008 at 6:49 am
In addition to what Jonas said, bonsai had the nice feature of being able to easily see the list of files touched by a checkin. This would be really nice in hg as well; I used to actually skim the bonsai log looking for changes the files I cared about and looking through the diffs…
September 24th, 2008 at 9:08 am
One other comment. I just filed a bug on hg annotate being really slow: see http://www.selenic.com/mercurial/bts/issue1310
September 25th, 2008 at 4:40 pm
I have not played with the current hg page much, only to do date-searches for regression ranges.
I like the suggestions above about making it much easier to do date-range queries. My biggest use case here is to hunt down regression ranges, so anything to make that easier would be appreciated.
Additionally, being able to query by the person that checked in the patch and by source code directory would be super helpful, as I used those features in bonsai quite a bit.
October 2nd, 2008 at 10:11 am
It would be nice if the checkin could have links to official builds built from that changeset.
That is link to the ftp folder of the builds if the files exists. This would make it easier to test changes and find regression ranges.
October 2nd, 2008 at 10:18 am
I would like to see https://bugzilla.mozilla.org/show_bug.cgi?id=448707 fixed.
It’s really difficult now to find out which patch caused a regression. This was much, much easier with bonsai queries.
Also, I really miss the blame view that bonsai had.