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: [email protected]
For additional commands, e-mail: [email protected]
