MQ usability

Peter Williams pwil3058 at bigpond.net.au
Sat Aug 15 20:38:36 CDT 2009


On 16/08/09 11:05, TK Soh wrote:
> On Fri, Aug 14, 2009 at 4:55 PM, Matt Mackall<mpm at selenic.com>  wrote:
>> On Tue, 2009-08-11 at 05:48 +0000, TK Soh wrote:
>>> On Mon, Aug 10, 2009 at 4:25 PM, Dirkjan Ochtman<dirkjan at ochtman.nl>  wrote:
>>>> So people invariably complain that MQ is hard to use. On the other
>>>> hand, everyone recognizes that it's also quite powerful. I'd like to
>>>> fix the former without losing the latter. Therefore, I have a few
>>>> proposals to improve on the current situation:
>>>>
>>>> - remove qgoto, qnext, qprev, qtop: this functionality is already
>>>> covered quite well by qpop, qpush, qseries and log.
>>>>
>>>> - possibly remove qsave/qrestore as well, since no one seems to use
>>>> them (and many people get confused by them).
>>>>
>>>> - make qrefresh<file>  not exclude other files from the patch: this
>>>> trips a lot of people up, and the other behavior is often useful, too.
>>>>
>>>> - add a qsplit command to deal with the actual usage of qrefresh for
>>>> excluding hunks (interactive mode for this would rock even more).
>>>>
>>>> Other possible niceties:
>>>>
>>>> - make qnew vs. qnew -f more intuitive somehow (I'm really not sure
>>>> how, but this usage of -f doesn't really fit in).
>>>>
>>>> - make qpush try a merge instead of throwing .rej files around
>>>>
>>>> Any thoughts?
>>> Sorry to bring up the old topic. I wonder if it's possible to make
>>> --git format the default?
>> No. Ask again when standard patch(1) accepts git patches.
>
> I am confused. How does Mercurial export and import patches that
> involve changes in file permission or binary data, while maintaining
> patch(1) compatibility?

By providing more than patch(1) provides.  I.e. to be compatible with 
patch(1) all hg has to do is AT LEAST everything that patch(1) does. 
Being able to do more things doesn't make it incompatible.

Peter
PS I just did a quick browse of patch(1)'s project web pages and there's 
no indication there that they're thinking of expanding patch(1) to 
handle the git extensions.  However, as the source code is available in 
a git repository (as well as CVS), they may be amenable to the idea.
-- 
Peter Williams                                   pwil3058 at bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce


More information about the Mercurial-devel mailing list