[PATCH 1 of 3] export: add 'Amends' hgpatchheader line

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Nov 21 17:05:57 CST 2013


On Thu, Nov 21, 2013 at 05:50:40PM -0500, Matthew Turk wrote:
> On Thu, Nov 21, 2013 at 5:48 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
> > On Thu, Nov 21, 2013 at 05:33:28PM -0500, Matthew Turk wrote:
> >> # HG changeset patch
> >> # User Matthew Turk <matthewturk at gmail.com>
> >> # Date 1385069336 18000
> >> #      Thu Nov 21 16:28:56 2013 -0500
> >> # Node ID 4c14c3925a004ef7036715ec954c9695cdb05783
> >> # Parent  986d09e696ff83def479a2e7adb237131d10dc09
> >> export: add 'Amends' hgpatchheader line
> >>
> >> If 'amend_source' is found, the patch is an amend.  This adds the amend_source
> >> key to the exported patch, which will subsequently be ignored in patch.extract.
> >
> > I can't see it working but for very narrow case. You usually do multiple amend so amend_source is not reliable to create useful obsolescence marker.
> >
> > If you want this topic to move forward, please have a look at embedding all of extra in patch so that `--exact`` stop being broken.
> >
> 
> Okay.  In the subsequent patch I created an extra dictionary that got
> fed into the new commit, but only containing 'amend_source' (and thus
> missing all the other *_source keys).  If there's no utility to this
> series, I'll scrap it and start over with a full embed of extra.

we don't know what could be in extra and how we could use it. So we need a
content agnostic plan to handle it. (this is step one, that fixes --exact)

There is some part of extra that we know and that know how to handle. As a
second step we can have an improved handling for them.

Putting (the other) Matt in CC as he had idea about it at the print.

-- 
Pierre-Yves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20131122/bdd3b52e/attachment.pgp>


More information about the Mercurial-devel mailing list