[PATCH] [mq] addchangegroupe finalize mq patches if changeset children are added

[Gilles Moris]

On Monday 14 March 2011 09:09:43 am Martin Geisler wrote:
> Gilles Moris <gilles.moris at free.fr> writes:
> > On Saturday 12 March 2011 07:30:46 pm David Pierre-Yves wrote:
> >> On 12 mars 11, at 18:57, Pierre-Yves David wrote:
> >> > With this change, any mq patches getting standard changeset
> >> > descendant get
> >> > finalize uncondfitionnaly. Status messages are displayed for the user.
> >>
> >> There is actually Two sane possibilities to handle the situation.
> >>
> >> - Reject pull, highlight the harmful situation and suggest finish (as
> >> djc suggests)
> >> - Accept pull and finish inconsistent patches (with children) (as
> >> implemented)
> >>
> >> And two mixed solution.
> >>
> >> - Reject unless -f is provided (and finish inconsistent patches).
> >> - Prompt the user to either accept the pull (finishing inconsistent
> >> patches) or reject it.
> >>
> >> The most problematic part of automatically finishing mq patches is
> >> that finishing a patch is not easy to rollback. Patches files à
> >> remove from .hg/patches/, series files are modified and revision can
> >> only be reimported with qimport (loosing patch name information)
> >
> > I don't like tools to take decision on my behalf. I want to decide
> > what to do with it because I am the one who knows the workflow that
> > leads there. Possibly attempting a dry-run merge of my queue or my be
> > I just made a mistake.
>
> There is nothing to merge -- we are talking about the case where the
> changesets created by your patches already exists in some other
> repository. Not just similar changesets, but the exact
> bit-for-bit-identical changesets.
>

I am talking about merge because I saw one people in this situation earlier: 
merge with an MQ series. This was an user error in that case, and MQ should 
probably prevent that.

> Additionally, we are talking about the case where you pull in new things
> *on top* of your patches. In that case there is a strong argument for
> finalizing your patches: someone else has gotten hold of them and have
> based work on top of them. You can therefore no longer refresh your
> patches without messing things up for him -- having to 'hg qimport' the
> changesets again does not seem too much to ask for in that case.
>

I don't want to throw even more confusion with another concept, but why 
wouldn't there any possibility that the descendant be kind of liquid as well.
May be we just want to check the pull and rollback... OK, may be far-fetched.

> The only thing you lose is the patch names. I know some people spend
> time chosing their patch names and wont like to lose them. But are these
> the same people who carelessly publish their patches as a repository and
> subsequently pull from it?

Making a tool take decisions based on supposed workflow is hazardous. There's 
pretty good chances that somebody out there uses a workflow you did not even 
think about. Possibly an insane workflow, possibly not.

Regards.
Gilles.