Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
MIME-Version: 1.0
In-Reply-To: <30059706-8cf2-5e98-65de-4023bf07bebd@apache.org>
References: <010661f8-4e15-01af-6a5a-971baa1348ca@apache.org>
 <eb42a8fc-c720-cfce-7516-4bca4ca66e24@apache.org> <1494872319.25236.1.camel@apache.org>
 <123d44fe-f1e8-83b4-d680-14eb27e43a4c@apache.org> <CACZkXPxPSMkce2y7FJdsq1zDpH8CgH=_G4O8KMBK27DKqDMnmg@mail.gmail.com>
 <803da5db-b900-d7be-5ae8-1a1794362bea@apache.org> <CACZkXPy8+iyyQsBC0ciEBFVqu1a_HYMK_1cUHt111Cb04MV0Rw@mail.gmail.com>
 <CACZkXPwnugcw4SH2yNMw6qH1DDUaBF1yFOYA8tP9nRQzN4NLSg@mail.gmail.com>
 <1494919338.27597.1.camel@apache.org> <7ef121a6-da85-451a-a1c5-fd16bf40639d@apache.org>
 <1494923452.31505.1.camel@apache.org> <CAKE+MjoH-=0z2a=F0t15eqBWy_w5C0UwMhYdWNSdMvRC-uqn_g@mail.gmail.com>
 <30059706-8cf2-5e98-65de-4023bf07bebd@apache.org>
From: Gary Gregory <garydgregory@gmail.com>
Date: Wed, 17 May 2017 22:56:46 -0700
Message-ID: <CACZkXPyGWwBMJUeJhEfq8LqOGunq4zhJPzBbNZUKvsQPfPubxw@mail.gmail.com>
Subject: Re: Git policies and practices / of tendency for good intentions to
 turn into s..t
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: multipart/alternative; boundary="94eb2c04f7ecec4075054fc6118f"
archived-at: Thu, 18 May 2017 05:56:56 -0000

--94eb2c04f7ecec4075054fc6118f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Now that I am done with the branch dev/4.4.x/HTTPCORE-468 and the code is
merged into 4.4.x, is it OK to delete the branch?

Gary

On Wed, May 17, 2017 at 1:57 AM, Michael Osipov <michaelo@apache.org> wrote=
:

> Hi Julian,
>
> Am 2017-05-17 um 09:30 schrieb Julian Sedding:
>
>> Hi Oleg and Michael
>>
>> I understand your frustration with a messy commit log.
>>
>> Personally I strive to give context so that the commit can more easily
>> be understood. Normally that includes a JIRA ID and the title. There
>> are cases where I prefer to have several commits for one JIRA, but
>> only if the separate commits help understand the changes AND the state
>> after each commit is sane (i.e. build and tests work, system is
>> functional).
>>
>
> That's perfectly fine and correct. With several commits for one issue we
> mean that followup commits say: "forgot that", or "um this too".
>
> So far I don't understand why the commit log is required to create
>> release notes. I would expect this information to be in JIRA. But
>> maybe that assumption is wrong.
>>
>
> I absolutely agree, I see no reason to maintain separate release notes. W=
e
> have JIRA. Everything has to be an issue, unless you fix a typo or so.
>
> Still, I am reluctant to make rebasing/squashing of public history the
>> de-facto default.
>>
>> The Git rebase documentation's section about recovering from upstream
>> rebase[0] starts with the words:
>>
>> "Rebasing (or any other form of rewriting) a branch that others have
>> based work on is a bad idea: anyone downstream of it is forced to
>> manually fix their history."
>>
>> Likewise the Git book talks about the perils of rebasing[1] and gives
>> the following advice before giving examples of problematic scenarios :
>>
>> "Do not rebase commits that exist outside your repository. If you
>> follow that guideline, you=E2=80=99ll be fine. If you don=E2=80=99t, peo=
ple will hate
>> you, and you=E2=80=99ll be scorned by friends and family."
>>
>
> Absolutely.
>
> Bear in mind that you are most likely more skilled in using Git than
>> the average contributor. If someone is preparing a patch to contribute
>> and the next thing their Git repo doesn't work anymore (and they don't
>> know how to fix it), that person may well turn their back to the
>> httpcomponents project before even getting in touch.
>>
>
> This is a constant problem when reviewing PRs for the Maven project.
> 1) People are using Git like Subversion and never used squash before
> 2) They are completely swamped when I ask them to rebase their PR on top
> of master. A lot of them can't do.
> I don't want to image what will happen if they encouter a rewritten
> upstream branch when pulling...
>
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>


--=20
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=3Das_li_tl?ie=3DUTF8&camp=
=3D1789&creative=3D9325&creativeASIN=3D1617290459&linkCode=3Das2&tag=3Dgary=
gregory-20&linkId=3Dcadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=3Dgarygregory-20&l=3Dam2&o=3D1&a=
=3D1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=3Das_li_tl?ie=3DUTF8&camp=
=3D1789&creative=3D9325&creativeASIN=3D1935182021&linkCode=3Das2&tag=3Dgary=
gregory-20&linkId=3D31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=3Dgarygregory-20&l=3Dam2&o=3D1&a=
=3D1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=3Das_li_tl?ie=3DUTF8&camp=
=3D1789&creative=3D9325&creativeASIN=3D1935182951&linkCode=3D%7B%7BlinkCode=
%7D%7D&tag=3Dgarygregory-20&linkId=3D%7B%7Blink_id%7D%7D%22%3ESpring+Batch+=
in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=3Dgarygregory-20&l=3Dam2&o=3D1&a=
=3D1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

--94eb2c04f7ecec4075054fc6118f--