Re: clean up commit messages?

[Jordi Gutiérrez Hermoso]

On 30 July 2013 09:36, Kai Torben Ohlhus <address@hidden> wrote:
> On 30 July 2013 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.
>
>
> Hello,
>
> what exact changes should be made according to my commit messages c.? I
> thought to be completely complying with to the guidelines, so I checked
> again:
>> I omitted the "*" in front of each changed file.
>> I'm not sure about writing a * full/path/to/file: (as sometimes done in
>> upstream) or just * file:
>> anything else?
>
> Then I will tidy up my repo accoding to Jordis histedit suggestion (I
> already installed the extension, to my old hg version).

Make sure you understand how to modify my instructions if you want to
edit the history yourself. After histediting, your bookmark will point
to the edited branch, but the bookmark in inversethought will still
point to the pre-edited branch. If you pull from inversethought after
histediting, you will get the pre-histediting bookmark as divergent.

> Besides this I read about re-basing a repository when synchronizing with
> upstream repositories. I think this link
> http://mercurial.selenic.com/wiki/RebaseExtension#Scenario_B summarizes my
> Repository situation perfectly.

As you wish. The point of rebasing here is to hide the merge commits
you've made. I don't mind the merge commits myself, but if you want to
rebase them away, go ahead. You should only do so right before you
think your branch is ready to go into Savannah.

- Jordi G. H.