Improvements to the Mercurial Client
(This is being worked on as part of the Summer of Code 2008.)
To keep history clean and avoid users having to merge in "simple" cases, implement an <tt>hg rebase</tt> command with similar semantics to <tt>git rebase</tt>. At a minimum, it should be able to do a three-way transplant of one head onto another from a common branch point:
<tt>hg rebase E --onto= C</tt>
If a conflict is found during merging, the normal 3-way merge tool is used to resolve the conflict. The user may halt operation to manually resolve conflicts and continue the process with <tt>hg rebase --continue</tt>.
After the merge is complete, new clean commits are created without any merge history:
And the old commits and merges are stripped:
Improve error messages
Throughout the client application, error messages should suggest the action to take to resolve the error, and link to web documentation for more details. In particular:
- if <tt>hg push</tt> would cause multiple heads, suggest that the user rebase or merge
- if <tt>hg qpush</tt> fails because the patch doesn't apply, suggest the steps necessary to rebase a queue (hg qsave/qpush -m)
additional rebase features
As with git-rebase, the user should have the option of reordering their local commits (in the example above, rebase so that the final sequence is E-Dmerged-Cmerged
Improve the hgweb viewer
Add HTML anchors to many elements
Provide named anchors for various elements so that users may post links to them in bug reports, etc.
line numbers in "file" and "annotate" viewAlready done in hg 1.0
files and hunks in "revision" view, e.g. link to a particular hunk of http://hg.mozilla.org/mozilla-centra...v/1b97a74034d1 (In Mercurial 1.0, each line number is a link.)
Allow marking lines of "file" and "annotate" view
In bonsai, you can use a magic &mark=line-line,line-line URL parameter to mark interesting lines, e.g.: http://bonsai.mozilla.org/cvsblame.c....2.2&mark=8-12
- Reimplement the mark parameter in hg "file" and "annotate" view
- Add marking UI so that users can create a marked-up URI without hand-editing the URI
Add basic searching
From the root view or revision view of the hg viewer, give the ability for users to type "cssframeconstructor" and find nsCSSFrameConstructor.h/cpp in the default revision (root view) or the current revision (revision view).
Add graphical history viewing
Add the ability to get a graphical changelog of a particular file, and perhaps of the entire repository, similar to the bonsai functionality.
Because complete history is so large, it may make sense for this to be a dynamically-expandable view, using SVG, instead of a generated image.
This is somewhat like a web version of <tt>hg glog</tt> or <tt>hg view</tt>.
Improvements to give better overview of changes
It's hard to get a good summary of what has happened without checking the detailed log of every commit. This is something bonsai manages pretty well. Here's a small list of some of the problems:
- Ideally the summary, or at the very least the shortlog or changelog, should also specify which files have been edited. This is how bonsai works.
- Differentiate (with colors for example, or another column?) the author of a changeset from its commit message, for readability.
- It would be nice to be able to see the diff of a changeset without going to a new page. For example, clicking "diff" could retrieve this data and show it inline AJAX-style?
- In the shortlog/changelog: "(0) -10000 -3000 -1000 -300 -100 -60 tip" -- these links are unintelligible and confusing. How about something simpler like next page, or page 1,2 - 100 instead?
- I find it unintuitive to know the difference between "summary", "shortlog" and "changelog". Even after trying all of them, they really seem to be the same view with very minor differences.
Show file-mode changes
Currently, if you change a file's mode (e.g. from executuable to non-executable),
hg diff will output a reasonable and concise summary of the change -- something like:
diff --git a/path/to/file b/path/to/file old mode 100755 new mode 100644
It'd be great if hgweb showed something like this, too. Right now, it shows no diffs, though it does still list the modified files (but with the wrong "diff" link next to each file -- this diff link shows you the last content change, rather than the file-mode change).
For example, changeset 8a99db3f8680 simply removed the executable bit for a lot of non-executable files, and hgweb doesn't have a good way of showing the change.
Feature: linear history according to a particular repository
Because mercurial history can get very branch-y, we would like the ability to navigate through history linearly as it appears in a particular repository:
Step 1: mozilla-central
Step 2: local user clones m-c and adds commits
Step 3: new revisions in m-c
Step 4: user merges
Step 5: user pushes
So, the linear history of mozilla-central (the mainline) should be recorded somehow as A -> B -> E -> F. However, we should not require this information to be known at commit-time. It should be recorded when a changeset is pushed to mozilla-central.
Doing this should not impose special requirements on users: they should not have to create a special named branch for their intermediate changes, nor should they have to follow special rules about which direction a particular merge happens.
Possible implementation may include some kind of named-branch, or a datastore recording in which direction merges should be followed.
This implementation should work for multiple ancestries: e.g. a user should be able to follow either mozilla-central or actionmonkey history if they wish.
Add the ability to diff an arbitrary revision against its last ancestor in mozilla-central. So after step 4, the user should be able to do something like:
hg diff -rF --ancestor=mozilla-central
Add the ability for <tt>annotate</tt> and <tt>log</tt> to follow the history of mozilla-central:
$ hg log --follow=mozilla-central changeset: F changeset: E changeset: B changeset: A
none in particular, though I presume this will involve a post-push hook
In the web interface, the shortlog, changelog, file revisions, and annotate views should show a specific repository's linear history by default, and only note branch histories when explicitly requested by the user.
For example, mozilla-central's shortlog should show the mozilla-central repo's linear history.
In the shortlog and changelog views, each merge changeset in the linear history should appear with extra information. For example, as of this writing actionmonkey repo's shortlog shows hundreds of changes that were actually checked into CVS, then imported to <tt>cvs-trunk-mirror</tt>, then merged to <tt>mozilla-central</tt>, then merged to <tt>actionmonkey</tt>. Instead, it should show:
at Wed Feb 20 08:16:46 2008 -0800 jorendorff Merge from mozilla-central
←Merges 1 changeset by bhearsum. expand
at Wed Jan 30 14:31:55 2008 -0800 jorendorff Merge from mozilla-central to actionmonkey branch.
←Merges 468 changesets by 160 different committers. expand
at Wed Jan 23 13:02:44 2008 -0600 jorendorff Bug 392883 - ActionMonkey: remove gcThingFlags (r=igor) at Fri Jan 18 17:18:30 2008 -0600 jorendorff Remove some JSAutoTempValueRooters inadvertently introduced during the merge (they break the build). at Fri Jan 18 16:15:16 2008 -0600 jorendorff Merge from mozilla-central to actionmonkey branch.
←Merges 373 changesets by 97 different committers. expand
at Thu Jan 17 12:11:06 2008 -0600 jorendorff Bug 392602 - ActionMonkey: implement a new heuristic for JS_MaybeGC (r=igor) at Fri Jan 11 15:55:36 2008 -0600 jorendorff Fixes to make actionmonkey compile without JS_THREADSAFE again. All tests pass. (Rearranging the order of JSGC's data members is to silence a GCC warning about initializer order.) at Fri Jan 11 10:14:34 2008 -0600 jorendorff Bug 404879 - ActionMonkey: Modify js/src to use new thread-safe MMgc APIs (r=brendan) - Changeset 4, make gcPendingContext per-GC instead of global. ...
This gives a much more accurate view of what's going on in a given repository than the current view, which treats all changesets as equals.
The expanded view should look like <tt>hg glog</tt> or <tt>hg view</tt>, illustrating the branch and merge points visually.
For bonus points, if a merge only merges one changeset, like the first change shown in the above example, expand it by default.