User:Dbaron/Mercurial Issues

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)
• want qrebase (and want it robust)
  • This will be based on the rebase stuff for GSoC. DirkjanOchtman 00:58, 28 May 2008 (PDT)

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)

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)

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)

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)