octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clean up commit messages?


From: c.
Subject: Re: clean up commit messages?
Date: Tue, 30 Jul 2013 17:15:39 +0200

On 30 Jul 2013, at 14:09, Jordi Gutiérrez Hermoso <address@hidden> wrote:

> I'm sorry the following is long-winded, but I am trying to be clear in
> my explanations, and I could not be any more terse.
> 
> On 30 July 2013 06:15, Olaf Till <address@hidden> wrote:
>> On Tue, Jul 30, 2013 at 11:45:31AM +0200, c. wrote:
>>> Hi,
>>> 
>>> As usual when I have hg-related question I am CC-ing Jordi.
>>> 
>>> I was having a look at the code written by Kai for his GSoC Project
>>> and the first thing I noted is that his commit messages don't comply
>>> with the guidelines:
>>> 
>>> http://wiki.octave.org/Commit_message_guidelines
>>> 
>>> So I was wondering, is there a way to clean up those messages
>>> before merging his code in the main repo?
>>> 
>> 
>> There is e.g. a way using the mq extension. IIRR (untested, and
>> assumes you have no other patches under mq control):
> 
> I don't recommend using MQ anymore. It's a brittle system that can
> cause data loss if used carelessly. I also don't like its interface.
> There are better modern alternatives.
> 
> Nowadays, I recommend using the histedit extension. Looking at Kai's
> commits, it looks like almost all of them need to have their commit
> message edited. After pulling from his repo, I did
> 
>    hg log --user k.ohlhus
> 
> to see which commits came from him. The earliest one is 4b92af851dd1.
> Do
> 
>    hg histedit -r 4b92af851dd1
> 
> You will almost certainly be told that you can't edit immutable
> history. The problem here is that Mercurial knows that these commits
> have been shared publicly, so editing them will in effect create a
> new, edited branch, but it won't remove the one that is already
> publicly available. Because we understand these issues, we will
> forcibly tell Mercurial that these public commits are now drafts, so
> it will let us edit them:
> 
>    hg phases --draft 4b92af851dd1 --force
> 
> Try the histedit command again after this.
> 
> You should now get an editor screen where you have to define a plan
> for what needs to be edited. The commits that need to be edited should
> be labelled as "edit". Leave all the other commits alone as "pick".
> Save this file and close the editor.
> 
> Mercurial will now bring you back to first commit you'll be editing.
> Do "hg summary" and "hg status" to see that the working directory is
> now as it was when Kai made this commit. You could, if you want, make
> changes to the working directory, but since you only want to edit the
> commit message, do
> 
>    hg histedit --continue
> 
> This will bring up an editor again with Kai's original commit message,
> which you can edit to your liking as usual. Repeat "hg hist -c" as
> needed until you've edited all the necessary commit messages.
> 
> If you think they're in good shape, you can push them to Savannah.
> Now, if Kai pulls from Savannah, he's going to get your edited branch,
> but he'll also have his own original branch. I recommend that before
> he pulls from Savannah, he simply closes his own original branch as
> dead and drops his original bookmark:
> 
>    ## Go to Kai's original unedited branch
>    hg up kais-work
> 
>    ## Close the original branch
>    hg ci --close-branch -m 'Closing branch with bad commit messages'
> 
>    ## Remove original bookmark
>    hg book --delete kais-work
> 
>    ## Assuming Kai's default points to Savannah, see "hg paths",
>    ## edit octave/.hg/hgrc to add more paths.
>    ##
>    ## Carlo's post-edited branch will now have the new location of
>    ## the bookmark "kais-work"
>    hg pull default
> 
> I hope this is clear and easy to understand.
> 
> - Jordi G. H.


Jordi,

Would it be possible somehow for Kai to change the commit messages as 
they appear on his published repository? 

One option is for him to clone the repo an do the editing in his local copy
then replace the public repo. Is there any other way of doing this?

c.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]