[git repos]

[Arne Babenhauserheide]

Uwe Brauer writes:

>    > Uwe Brauer writes:
>
> Thanks very much for this!
>    > This sounds like a typical case for rebasing — or more elegantly using
>    > the evolve extension.
>
>    > Upstream requires a single commit (one patch). So you’d ideally have
>    > just that.
>
>    > With the evolve extension you’d simply issue
>
>    >   $ hg fold -r master -r feature
>
>    > That gives you a new commit with the folded commits and hides the old
>    > ones as obsolete (with the information that they were superseeded by the
>    > new commit).
>
>    > You could also simply send `hg diff -r master -r bookfeature`.
>
> Interesting I tried
>
> hg export  -r "only(feature,master)" -o mypatch2.patch
>
> Which did not produce a folded patch, while your command did.
> Thanks very much, that is very useful.

Diff simply compares the two revisions: The one upstream as and the one
after all your changes.

> Still I don't like the resulting graph.
>
> So the fold solution is really interesting!
>
> Suppose the patch I sent is partially refused so I have to continue with
> the feature (branch)
>
> Now
>
>  hg update feature gives me 
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> (activating bookmark feature)
> working directory parent is obsolete!
> (use 'hg evolve' to update to its successor)
>
> What I am supposed to do now precisely?

Did you try to commit? (I’m not sure whether it would work)

What I would do is continuing the work on master (hg bookmark -f
feature) and then folding that. Accept the new state and continuously
approaching the patch you need with multiple foldings.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20161219/07ca44e6/attachment.asc>