qrefresh -a to refresh all the applied patches (hence parent nodes ids)

[Nicolas Dumazet]

Well I think that qref -a somehow makes the command very ambiguous.

See, qref is mostly about syncing the local repo changes with the
topmost applied patch.

And then, we have a bunch of "secondary" options, -e, -U, -u, -D, -d
that allow setting meta-data related to that topmost patch.

But the first use of qref is mostly to record the local changes in
your current patch.


Regardless of what you actually want to achieve with this new option,
when I think of doing a "hg qrefresh -a" with local changes in my
repository, I get plainly confused. This somehow implies wrongly that
the local changes will be applied to the "whole serie". Of course, as
an experienced mercurial user, I think about it, find it that idea
strange (how can hg "guess" the patch to which the current changes
apply?), and quickly conclude that only the topmost patch will have
its content modified, while only the metadata will change in other
patches.
But to me "qref -a" is semantically confusing, and should not be
proposed to users. I think that so far Mercurial does a great job at
having plain understandable arguments, each command doing only a
specific job; and to me "qref -a" is just stretching too much the qref
usage scope

I understand the need for some kind of "qref -a -DU". But if we really
have this need, this might be the sign that we need another command,
just to manipulate metadata. Keep qref for updating topmost patch
_contents_, and use something else to update metadata on a specific
patch/all patches/topmost patch. For example, qproperty, or something
in this genre:

  hg qprop -a -D # updates dates on all patches
  hg qprop somepatchname -U # update author on a specific patch
  hg qprop -u "geek at foobar.net" # update author on topmost patch

Remember that mq behavior is really difficult to grasp for newcomers.
It seems that hg qref -a would increase even more the difficulty.

Thanks for reading,
Nciolas.

2010/2/12 Nicolas Chauvat <nicolas.chauvat at logilab.fr>:
> On Thu, Feb 11, 2010 at 09:01:51AM +0100, Dirkjan Ochtman wrote:
>> Well, the part I don't like is that in my mind, qrefresh is something
>> that works on files, adding, subtracting from the current patch (I
>> don't suppose you want qrefresh README to strip all the other files
>> out of all the patches?). Even if the options may work, you haven't
>> covered the arguments. If we do -a, qrefresh now not only is "wide"
>> (operations on the file tree), but also "deep" (operations on a bunch
>> of history). I guess there's not actually a problem if we disallow -a
>> with arguments, but it feels like command overload all the same.
>
> Sounds related to the discussion about the actual use of qref and its
> relation with a qadd or qsplit command, doesn't it? If qrefresh was a
> command with a narrow target usage, it would not lend itself to
> command overload I suppose.
>
> --
> Nicolas Chauvat
>
> logilab.fr - services en informatique scientifique et gestion de connaissances
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>



-- 
Nicolas Dumazet — NicDumZ