hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Git policies and practices
Date Mon, 15 May 2017 18:29:22 GMT
Am 2017-05-15 um 20:18 schrieb Gary Gregory:
> On Mon, May 15, 2017 at 11:13 AM, Michael Osipov <michaelo@apache.org>
> wrote:
>
>> Am 2017-05-15 um 19:35 schrieb Gary Gregory:
>>
>>> On Mon, May 15, 2017 at 9:34 AM, Michael Osipov <michaelo@apache.org>
>>> wrote:
>>>
>>> Folks,
>>>>
>>>> I have updated the link based on the input and put it onto the wiki:
>>>> https://wiki.apache.org/HttpComponents/GitGuidelines
>>>>
>>>> Here is verbatim copy:
>>>> = Typical Issue Workflow =
>>>>
>>>>  1. Branch off master ({{{git checkout -b <branch>/<JIRA id>
master}}})
>>>> where {{{<branch>}}} is the branch you are going to apply the fix,
e.g.,
>>>> 4.4.x or 5.0.x and {{{<JIRA id>}}} being the JIRA you have assigned
to
>>>> yourself, e.g., HTTPCORE-123 or HTTPCLIENT-689. Thus, {{{git checkout -b
>>>> 4.4.x/HTTPCORE-123 master}}}.
>>>>  1. Work on your issue and create as many commits as you want/need
>>>>  1. Polish it, squash it or fix it up into a single commit
>>>>
>>>>
>>> Which of the paths should we pick:
>>> https://makandracards.com/makandra/527-squash-several-git-
>>> commits-into-a-single-commit
>>> The second option sounds like error prone busy work :-(
>>>
>>
>> The second is the way to go. It is not errorprone. I have been doing this
>> for years. It just works. As soon as you get used to it, it'll feel very
>> natural. The only thing you need to remember to keep your branch updated
>> with your target branch.
>
>
> I just did it with the first option.
>
> How does it look to you?

As long as it does the same work, but consider that with the second 
option your make a deliberate choice to select exactly those commits 
your want to squash.

There are still a two issues:
1. For those who would like to do a review, they still need to list 
through all commits, making it harder to read. I want to review a final 
work and not an unpolished one.
2. It will not retain your commit, you will need an extra option for 
that: http://stackoverflow.com/a/25930432/696632

>>  1. Ask for a review if you are uncertain
>>>>  1. Take care of a proper commit message (good reads: [[
>>>> https://chris.beams.io/posts/git-commit/|1]] and [[
>>>> https://github.com/erlang/otp/wiki/Writing-good-commit-messages|2]]: Put
>>>> the title of the JIRA issue, e.g., [HTTPCORE-123] Memory leak in
>>>> response,
>>>> in the first line, followed by an explanation why you did take this
>>>> approach. The ticket desc contains the issue, your commit message
>>>> contains
>>>> the solution. If in doubt, ask for help and give people a couple of days
>>>> to
>>>> react.
>>>>  1. Request the release manager to merge your banch back to master and
>>>> make sure that this merge won't incur a merge commit
>>>>  1. When you close the issue, put a link to your commit to create a
>>>> direct
>>>> relation between issue and solution.
>>>>
>>>> =  Side Notes =
>>>>
>>>>  1. Never rewrite (rebase) history on master or any other long-lived
>>>> branch because you will break others
>>>>  1. If a change comes for a PR on GitHub:
>>>>    * Apply the same above rules
>>>>    * Don't steal authorship
>>>>    * Let the reporter polish his work
>>>>    * Amend the message at the end with "This closes/fixes #xy" and push.
>>>>
>>>>
>>>> Something else I forgot?
>>>> What do you think?
>>>>
>>>> Please comment!
>>>>
>>>> Michael
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: dev-help@hc.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message