Hi Michael

On Wed, May 17, 2017 at 10:57 AM, Michael Osipov <micha...@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...

Yes, I think we need to accept this and encourage contributors to
improve their skills, if necessary. We should provide some guidance,
and if that does not help, we can always pull the branch underlying a
PR into a local repo and refactor/rebase *before* it enters the
httpcomponents repo.

Arguably harder is to get committers to make clean commits. However,
IMHO git makes this easier, exactly because you can commit locally and
rebase/squash local changes. Therefore I have hope that the situation
improves after everyone transitions to git and improves their git
skills. Again, we may need to provide some guidance, which you
(Michael) have already been doing with the Git guidelines.


> Michael
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org

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

Reply via email to