Help trying to merge my changes to current default

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Help trying to merge my changes to current default

Juan Pablo Carbajal-2
Hi all,

I did some changes during Octconf to include test for pkg.m and start
the refactoring of that function.
Now, when I lok at hg log, I see I have done quite a messy commit
work. Is there a way to export a clean change set (I guess some flavor
of hg diff) to get only the things I have done to the sources?

I essentially do not want to had to the repo history my commits
ranting, quite rookie, to be honest. But I want to add the final form
of the local branch I have.

Is it maybe easier to just re-clone and copy the changes over and make
a new commit with that?

Thanks

Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

John W. Eaton
Administrator
On 03/20/2018 10:39 AM, Juan Pablo Carbajal wrote:

> Hi all,
>
> I did some changes during Octconf to include test for pkg.m and start
> the refactoring of that function.
> Now, when I lok at hg log, I see I have done quite a messy commit
> work. Is there a way to export a clean change set (I guess some flavor
> of hg diff) to get only the things I have done to the sources?
>
> I essentially do not want to had to the repo history my commits
> ranting, quite rookie, to be honest. But I want to add the final form
> of the local branch I have.
>
> Is it maybe easier to just re-clone and copy the changes over and make
> a new commit with that?

It's hard to say for sure without seeing exactly what you've done.

You might be able to simply rebase your changes to the head of the
branch that you are working on.  Then if you want to smash them all into
a single commit (or just a few instead of many) you can also use
histedit to do that.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Juan Pablo Carbajal-2
> It's hard to say for sure without seeing exactly what you've done.
>
> You might be able to simply rebase your changes to the head of the branch
> that you are working on.  Then if you want to smash them all into a single
> commit (or just a few instead of many) you can also use histedit to do that.
>
> jwe

Ok, attached is my messy committing: a) I mention a local bookmark
(refactor_pkg), b) I mention upstream, c) there are many local merges
(the repo was moving quite fast in octconf)
I think this adds too much noise tot he log, so I was trying to find
out the best way to do it.
Since rebase is an extension (I am not confident), I might go for the
re-cloning. Is there an objection to that?

outgoing.log (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Carnë Draug
In reply to this post by Juan Pablo Carbajal-2
On 20 March 2018 at 14:39, Juan Pablo Carbajal <[hidden email]> wrote:

> Hi all,
>
> I did some changes during Octconf to include test for pkg.m and start
> the refactoring of that function.
> Now, when I lok at hg log, I see I have done quite a messy commit
> work. Is there a way to export a clean change set (I guess some flavor
> of hg diff) to get only the things I have done to the sources?
>
> I essentially do not want to had to the repo history my commits
> ranting, quite rookie, to be honest. But I want to add the final form
> of the local branch I have.
>
> Is it maybe easier to just re-clone and copy the changes over and make
> a new commit with that?
>
> Thanks

I think you are looking for something like this

    hg rebase --collapse --base refactor_pkg --dest @

Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

John W. Eaton
Administrator
In reply to this post by Juan Pablo Carbajal-2
On 03/20/2018 11:19 AM, Juan Pablo Carbajal wrote:
>> It's hard to say for sure without seeing exactly what you've done.

> Ok, attached is my messy committing: a) I mention a local bookmark
> (refactor_pkg), b) I mention upstream, c) there are many local merges
> (the repo was moving quite fast in octconf)
> I think this adds too much noise tot he log, so I was trying to find
> out the best way to do it.
> Since rebase is an extension (I am not confident), I might go for the
> re-cloning. Is there an objection to that?

I use rebase often.  If you are really worried that it will fail, work
on a separate clone where it won't matter if you make some mistakes.

Another useful extension is "glog" for displaying a graphical
representation of parent commits so you can see more clearly the
relationship of changesets, similar to the display here:

http://hg.savannah.gnu.org/hgweb/octave/graph/4f1da669b610

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

John W. Eaton
Administrator
In reply to this post by Juan Pablo Carbajal-2
On 03/20/2018 11:19 AM, Juan Pablo Carbajal wrote:

> Since rebase is an extension (I am not confident), I might go for the
> re-cloning. Is there an objection to that?

If you don't see how to rebase, or don't want to use that extension,
then I'd recommend first exporting all your changesets to individual
files, then using import to add them back in to a clean repo, importing
them from oldest to newest.  Then you can get them all in a linear
series of commits at the head of the new repo.  If there are conflicts,
you can deal with them individually.  This is essentially what you would
be doing with rebase, but you'd be doing it manually, one changeset at a
time.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Carlo de Falco-2
In reply to this post by John W. Eaton


> On 20 Mar 2018, at 16:44, John W. Eaton <[hidden email]> wrote:
>
> On 03/20/2018 11:19 AM, Juan Pablo Carbajal wrote:
>>> It's hard to say for sure without seeing exactly what you've done.
>
>> Ok, attached is my messy committing: a) I mention a local bookmark
>> (refactor_pkg), b) I mention upstream, c) there are many local merges
>> (the repo was moving quite fast in octconf)
>> I think this adds too much noise tot he log, so I was trying to find
>> out the best way to do it.
>> Since rebase is an extension (I am not confident), I might go for the
>> re-cloning. Is there an objection to that?
>
> I use rebase often.  If you are really worried that it will fail, work on a separate clone where it won't matter if you make some mistakes.
>
> Another useful extension is "glog" for displaying a graphical representation of parent commits so you can see more clearly the relationship of changesets, similar to the display here:
>
> http://hg.savannah.gnu.org/hgweb/octave/graph/4f1da669b610

I also sometimes use "hg serve" to be able to see exactly that representation in a browser.

> jwe

c.
Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Juan Pablo Carbajal-2
Hi all,

Thank you for all the input. I tried with rebase but I wasn't sure the
results was what I wanted,so I followed jwe suggestion of doing it
manually.
I have pushed a clean sequence of changesets to the repo. I hope I
have done it the right way.

Anybody has a good link to a good tutorial for rebase (mercurial)?

I will start now the refactoring work on pkg.m
This implies a major re-writing of the function. Should keep the order
of the Copyright holders as it is now?
What about the author field?

Regards,

Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Carlo de Falco-2


> On 22 Mar 2018, at 10:41, Juan Pablo Carbajal <[hidden email]> wrote:
>
> I will start now the refactoring work on pkg.m
> This implies a major re-writing of the function.

JPi,

Great to know you are working on this, this has been needed for a VEEERY long time.

Sorry to ask a question about something that has probably already discussed at OctConf,
is the plan to maintain exact backwards compatibility with the current syntax of pkg?

The point is that I think the pkg function which consists 90% of input parsing could
be greatly simplified if it were based on the InputParser class, but I'm not sure
that 100% compatibility could be maintained.

c.



Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Carnë Draug
On 22 March 2018 at 11:06, Carlo De Falco <[hidden email]> wrote:
> [...]
> The point is that I think the pkg function which consists 90% of input parsing could
> be greatly simplified if it were based on the InputParser class, but I'm not sure
> that 100% compatibility could be maintained.
>

I don't think this is true.  See number of non-comment lines on pkg.m:

    $ grep -vP '\s*#' scripts/pkg/pkg.m | wc -l
    304

versus the number on its subfunctions:

    $ grep -vP '\s*#' scripts/pkg/private/*.m | wc -l
    1744

The options parsing happens in pkg.m only but even that is only a
portion of the file.  Much more complicated is the handling of the
multiple options, not finding which options have been set.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Help trying to merge my changes to current default

Carlo de Falco-2
Hi,


> On 22 Mar 2018, at 13:31, Carnë Draug <[hidden email]> wrote:
>
> On 22 March 2018 at 11:06, Carlo De Falco <[hidden email]> wrote:
>> [...]
>> The point is that I think the pkg function which consists 90% of input parsing could
>> be greatly simplified if it were based on the InputParser class, but I'm not sure
>> that 100% compatibility could be maintained.
>>
>
> I don't think this is true.  See number of non-comment lines on pkg.m:
>
>    $ grep -vP '\s*#' scripts/pkg/pkg.m | wc -l
>    304
>
> versus the number on its subfunctions:
>
>    $ grep -vP '\s*#' scripts/pkg/private/*.m | wc -l
>    1744

True but I was referring to pkg.m alone.

> The options parsing happens in pkg.m only but even that is only a
> portion of the file.

Can you quantify that?

>  Much more complicated is the handling of the
> multiple options, not finding which options have been set.


Indeed, and that is something that may possibly be simplified
by changing the syntax for commands / options.

I think this is worth considering as a choice, after all I don't
believe there is much user code that depends on the syntax of
the pkg command and pkg is not available in matlab so there are
not too many constrains that we need to comply with ...


> Carnë

c.