User:Dbaron/Mercurial Issues

This is my list of issues, and I'd like to keep it that way. Other people's could potentially go on Mercurial/Desired Features or, even better, in the Mercurial Bug Tracking System.

mq issues

• git diffs should be the default, at least for mq, since data loss (binary files dropped on the floor, moves. etc.) in the default configuration is a really bad idea
  • We're not sure about doing this because patch(1) doesn't support git diffs. I think warning on not-representable diffs for qnew/qref would be good. DirkjanOchtman 00:58, 28 May 2008 (PDT)
    • warning really isn't enough. Dataloss in the default case is simply unacceptable; I have to give people a long lecture before recommending mq to them because of this.
• want qrebase (and want it robust)
  • This will be based on the rebase stuff for GSoC. DirkjanOchtman 00:58, 28 May 2008 (PDT)
• want to be able to keep patches fresh against tip (e.g., a qpush option that rewrites the patch with the new line numbers; definitely part of qrebase) without having to qrefresh (and thus look for modifications I know I don't have) all the time

diffs

I want to be able to change the context argument to diff. But in the cases where mercurial uses patch (e.g., mq), it should call patch with a -F argument appropriate to the amount of context in the diff (amount of context minus 1), not just let patch default to 2 (assuming default context of 3).

Right now you can set a default option to diff and qdiff commands. How/why is that not good enough? DirkjanOchtman 00:58, 28 May 2008 (PDT)

As of 1.0.1, the unified option does most of what I want, although mq still doesn't pass an appropriate -F argument to patch.

mq redesign

I'd like something like mq with a significantly different design. In particular, I'd like to be able to:

• do editing of non-topmost patches
  • with a special command that launches editor in a temp file
  • by simply editing the file in the working directory and telling mq to merge those edits into a non-topmost patch
• reorder patches
• edit and reorder patches without touching my working directory, and *then* update my working directory.
• have good merging for all of the above operations

See post.

Architecturally, a bunch of this seems hard in the current hg design since the merging code wants to operate on a working directory, and doesn't accept the "common parent" part of the merge as an argument.

Stability

• it's really easy to get a corrupt repository by hitting Ctrl-C while pushing/popping/refreshing patches in mq
  • sometimes it's just .hg/patches/status being out of sync with the repo
  • sometimes it's corruption of the hg repo itself
    • We really need specific cases of this to be documented. A bunch of these have been fixed in recent releases, but we can't really fix them unless we can reproduce them (that is, I certainly can't). DirkjanOchtman 00:58, 28 May 2008 (PDT)

Documentation

• it's really not clear to me how named branches work -- a lot of commands describe things in terms of heads when you'd really want them to operate only within the current named branch; it's not clear if they actually do
  • I want to be able to use named branches so that people can have the history corresponding to releases (which are done off of stability branches) in their local repos
  • Yes, we need some fixes for this stuff. Please document specific cases you run into. DirkjanOchtman 00:58, 28 May 2008 (PDT)

• was very unclear that the default "hg serve" would respond to any path, so if you type "hg serve" in the wrong repository you'll serve the wrong changes, and somebody else can pull them despite having pulled from a URL that looks like it should pull only other changes
  • Do you mean hg help serve? Can you give an example for this? DirkjanOchtman 00:58, 28 May 2008 (PDT)
    • When I first used hg serve, I expected to have to put the path info the same way when using http: that I would have to when using ssh:. I guess this even seems like a bug to me -- hg serve should serve at a particular URL, not any URL that the client happens to connect to; serving any URL confuses users into thinking the URL might be meaningful, when it's really not.

Annotations

I'd like to be able to annotate changesets with additional metadata. This can include things like:

• crypto signatures of author, reviewer, approver, release manager
• information on when the changeset was pushed to a particular repository, and by whom (and maybe why?)

Essentially I think the underlying mechanism needed for this is changesets that:

• never modify files
• don't count towards the number of heads

I think other DVCSes have mechanisms like this, though I don't know a whole lot about them. (monotone?)

I then want to be able to use these annotations to do things like:

• follow the history of a particular repository that does push-annotation of its incoming changesets
  • This is kind of a big change. It's currently possible to store some annotations in the changeset, but that probably means you can't really annotate the changeset after committing. Is the latter what you want? DirkjanOchtman 00:58, 28 May 2008 (PDT)
    • Yes, I really do want additional annotations after committing. I realize that they'd be detachable, but I think making them hard to detach accidentally would suffice.

hgweb

• want UI for a log or shortlog of a range of changesets, probably inclusive of the end and exclusive of the beginning, because the goal is to show what's different between builds of changeset X vs builds of changeset Y
• merge changesets should show diffs against both parents
  • right now they sometimes show the file list against one and the diff against the other, e.g. this one (which has the same problem with Mercurial 1.0.1)
• web interface to diff between arbitrary changesets
• custom rules for linkification (e.g., of bug numbers) in changeset descriptions
• UI for log of a directory
• detailed description of tip changeset at the top of many pages (e.g., annotations) is confusing

Miscellaneous

• want to be able to update between two revisions that aren't ancestor/descendant without -C
  • I think this was shot down by mpm when it was discussed, though I agree with you. You should raise this issue in the mailing lists again if you dislike the current behavior. DirkjanOchtman 00:58, 28 May 2008 (PDT)