hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Git policies and practices / of tendency for good intentions to turn into s..t
Date Thu, 18 May 2017 05:56:46 GMT
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?


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. We
> 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’ll be fine. If you don’t, people will hate
>> you, and you’ll 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

E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition

Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message