mq: addressing the broken version history (qpush/qpop/qpush cycle)

[Chris Mason]

On Wednesday 14 December 2005 04:28, Samuel Masham wrote:
> On 13/12/05, Chris Mason <mason at suse.com> wrote:
> > I'm not against the qtag command,
>
> me nether *grin*
>
> > but I do want the flexibility of merging hg qpush -m -n foo
>
> Now  I have to confess even looking at this again I still don't like this.
>
> Here you are taking changes from one queue ( .hg/foo) and then putting
> the changes into a completely separate queue (the default
> .hg/patches).
>
> If you save the queue I don't mind working on that
>
> hg -Q .hg/foo qpush -m
>   (made up syntax to match the hg -R)
>
> but when doing this I want the results to end up in the .hg/foo queue
> (repos) not jump into another one.

Compare the syntax with hg pull http://foo.com

You're pulling into the current repo.  hg qpush -m -n foo merges into the 
current queue.  In the implementation, the only file used in .hg/foo is the 
status file, we're just using it for the parent information.

> None of this discussion has any thing directly to do with the status
> file format, so including the second parent in this file is OK ?

My main concern with the second parent in the status file is this information 
is also stored in the changeset.  It seems much more flexible to me to get 
the info from the changeset instead of storing it in the status file.

But, I need to read the code more carefully to see if this is really a good 
idea.

>
> The issue is that when I added this I also removed the qpush -m -n to
> make the code simpler.
>
> So in principle if I respin and preserve this (somehow *grin*) the
> patch would be ok?

Let me review it more carefully, I don't want to make you do extra work yet ;)
>
> Samuel
>
> ps I am not going to be able to do this untill next year (gulp)
> however as for me at least xmas hits tonight...  and that means no
> access to hg etc
>
That's fine, I'm in a similar situation.

-chris