incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick ALLAERT <patrickalla...@php.net>
Subject Re: [zeta-dev] Proposal: Commit guidelines
Date Fri, 08 Apr 2011 14:06:01 GMT
2011/4/8 Jerome Renard <jerome.renard@gmail.com>:
> Hi Thomas,
>
> On Fri, Apr 8, 2011 at 11:09 AM, Thomas Nunninger <thomas@nunninger.info> wrote:
>> Hi,
>>
>> Am Freitag, 8. April 2011 07:50:20 schrieb Jerome Renard:
>>> Hi Patrick,
>>>
>>> On Thu, Apr 7, 2011 at 4:09 PM, Patrick ALLAERT
>>>
>>> <patrick.allaert@gmail.com> wrote:
>>> > 2011/4/1 Tobias Schlitt <tobias@schlitt.info>:
>>> >> Hi,
>>> >>
>>> >> I wrote down our commit guidelines. Please review them shortly, before
I
>>> >> commit:
>>> >>
>>> >>        http://files.schlitt.info/tmp/commit_guidelines.patch
>>> >
>>> > Good work Toby!
>>> >
>>> > I have however a remark regarding:
>>> >
>>> > +However, larger features or bug fixes, should be split them into smaller
>>> > +commits. In this case, the issue number should only occur in the final
>>> > commit, +which closes the issue.
>>> >
>>> > I think having the issue number on the latest commit only might be a
>>> > problem for different reasons:
>>> > 1. While looking at a commit mentioning an issue ID, you have no clue
>>> > whether other commits are required or not to fix that specific issue.
>>> > 2. In the case a commit fixing a bug has to be reverted for whatever
>>> > the reason, the one which will definitely resolve the problem will
>>> > also mention that issue which is not consistent to the guidelines.
>>> > 3. In the case a bug issue is reopened, we might have the same problem as
>>> > in 2.
>>>
>>> I already thought about this problem but to be honnest I never found
>>> an acceptable
>>> solution. The only "solution" I came up with is to write commit log
>>> message like this:
>>>
>>> - Fixed #1234321 part 1 : bla bla bla bla
>>
>> Perhaps it's possible to come up with some other (fixed) term instead of "part
>> X" after the issue number. A term that means something like: "not
>> finished", "to be continued" or whatever. It shouldn't be to long. Perhaps an
>> abbreviation.
>>
>
> Why not, how about something like this ?
>
> - Fixed #XXX : bla bla bla START
> - Fixed #XXX : bla bla bla WIP
> [...]
> - Fixed #XXX : bla bla bla END

Should we really mention all that info?

I would propose to only use:
- Fixed #XXX: ...

Normal case is generally to fix issues in one single commit. But it
happens that a fix does not fully solve the problem and the bug to be
reopened.
I think we can simply have something like:

First commit solving ZETACOMP-XX:
"- Fixed #ZETACOMP-XX: Double conversion of HTML entities"

Second commit because of a special case not covered by initial fix:
"- Fixed #ZETACOMP-XX: Double conversion of HTML entities

Covering the case when ..."

This way it is quite easy to look (grep) at "Fixed #ZETACOMP-XX:" for
commits related to that issue, knowing that all those commits are
required to fully fix the problem.

Cheers,
Patrick

-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

Mime
View raw message