Re: adapting changesets without starting over

[c.]

Hi,

Thanks for your answer and for helping out with this.


On 27 Aug 2011, at 21:02, Jordi Gutiérrez Hermoso wrote:

> 2011/8/27 c. <address@hidden>:
>> 
>> On 27 Aug 2011, at 18:17, Jordi Gutiérrez Hermoso wrote:
>> 
>> I did
>> 
>>>    hg qimport
>>>    hg qpush
>>>    hg qrefresh -e
>> 
>> then exported the changeset, and the result is attached, does it look 
>> correct?
> 
> It looks like you concatenated the same patch twice, with different
> commit messages. You only need one of those.

that was produced by exactly the sequence of commands shown above, 
followed by

hg export -o bicg4.changeset tip

any idea what could have gone wrong?

> Also, your commit messages don't seem to actually summarise the same
> information as your ChangeLog messages. Your commit messages should be
> the same as what the ChangeLog was, together with a short summary of
> your changeset, with the difference that you don't give the path to
> the files you touched, only the filename.

OK, thanks.

> Note that you may want to rebase your patch if someone else has pushed
> a different patch while you were working on this one. If you don't
> rebase, you will get a warning that you're creating new heads when you
> attempt to push. Here is how you rebase, assuming you attempted a push
> and hg refused to create a remote head:
> 
>    hg qimport -r tip  ## Turn your cset back into mq patch, assuming
>                       ## your cset is at the tip.
> 
>    hg qpop            ## Unapply your patch.
> 
>    hg pull -u         ## Pull remote csets and update to the latest
>                       ## revision in this branch (for these csets,
>                       ## you probably want them in the default branch
>                       ## since they're new development).
> 
>    hg qpush           ## Reapply your patch.
> 
>    hg qfinish -a      ## Turn all applied patches back into csets.
> 
>    hg push            ## Show the world your masterpiece.
> 
> An alternative is to pull remote and merge if you don't want to rebase
> (we historically have avoided this because it looks a little bit more
> messy in the history, but it's no big problem), or to use the rebase
> extension if you find the above steps too labourious.

I do find it labourious but it's probably because I'm just getting started, so 
it's
good to learn to do things the proper way even if it takes a bit longer, i'll 
make 
another attempt tomorrow.

At the moment, though, the approach of just manually editing the changeset file 
looks very attractive.

> As to your patch itself, there seem to be a few stylistic things about
> having lines longer than 80 characters (we tend to avoid those) and a
> few whitespace things (e.g. "printf(" and "printf (", the latter is
> the Octave house style). I didn't attempt to actually test your patch
> to see if it produces the desired results.

I might have missed a few of those, I'll check better, thanks.

> HTH,
> - Jordi G. H.
c.