MQ usability

[TK Soh]

On Sat, Aug 15, 2009 at 10:06 PM, Stuart W. Marks<smarks at smarks.org> wrote:
> Peter Williams wrote:
>> On 15/08/09 13:13, Stuart W. Marks wrote:
>>> But for MQ, the patch is mainly an internal storage format.
>>
>> No, it's not.  In a lot of cases, MQ is being used to generate patch
>> sets for distribution to users who aren't necessarily using MQ to manage
>> them at there end.
>
> As Isaac Jurado pointed out, "hg export" will generate a patch, as will "hg
> diff" and "hg qdiff". I should also add that even if MQ stores a patch file in
> git format, these commands will produce output in conventional diff format if
> their options and defaults indicate that they should. (Of course, they may also
> lose information in the process.)
>
> Anyway, the point is that even if MQ were to change its patch storage format,
> you could still share conventional patches with non-MQ users by using these
> commands instead of accessing the patch files directly.

Please correct me if I am wrong, but the need to use git format is
primarily to fix what conventional patch cannot support, namely the
binary delta and permission change, etc. So on this kind of changes,
we already can't share changes by exporting in conventional patch format.

No offence, but how anyone would think maintaining conventional patch
format outweigh the risk of losing changes is really beyond me.
Perhaps I am just one of the less significant few that have to deal
with binary files.

    $ hg qnew binaryfile
    $ hg add mypicture.png
    $ hg qrefresh
    $ hg qpop
    patch queue now empty
    $ hg qpush
    applying binaryfile
    patch binaryfile is empty      <== data lost !!!
    now at: binaryfile

>>> The current situation, where MQ silently loses information unless
>>> --git is
>>> specified, is pretty unfriendly.
>>
>> It should be remembered that anyone who wants --git to be the default
>> for their MQ patches just has to put:
>>
>> [defaults]
>> qrefresh = --git
>>
>> in their ~/hgrc (or equivalent).
>
> I still think this is pretty unfriendly. Yes, this is the workaround that
> everybody has to install after getting burned once or twice. And then they have
> to do it again when they start using hg on a new system, forget to add this
> workaround, and then get burned again.
>
> BTW this is tracked as http://mercurial.selenic.com/bts/issue1640 . This is
> currently classified as a "wish" even though I think it's a bug that MQ can
> silently lose information.
>
> s'marks
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>