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). 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. 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." 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. Just my 2 cts. YMMV. Regards Julian [0] https://git-scm.com/docs/git-rebase.html#_recovering_from_upstream_rebase [1] https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_peril On Tue, May 16, 2017 at 10:30 AM, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2017-05-16 at 10:17 +0200, Michael Osipov wrote: >> Am 2017-05-16 um 09:22 schrieb Oleg Kalnichevski: >> > So, I woke up this morning, took a look at my mail box and found >> > two >> > wonderful commit messages on top of the 4.4.x release branch saying >> > 'oh, forgot this' and 'ah, forgot that' immediately after a dev >> > branch >> > merge. >> > >> > Shit like that will happen over and over again because people tend >> > to >> > forget things and tend to make mistakes all the time. >> >> We were talking against the wall. It is pretty much useless :( >> History >> repeats. There are even forced updates...that's so disappointing! >> > > Forced update is my atrocity. I squashed those two commits. > >> > I will be vehemently against (to a point of using my -1 as a veto >> > if >> > needed) any policy that stops RMs from squashing such commits >> > within a >> > defined period of time. >> >> When I see this history, I'd always give the RM the right/vote to >> clean >> up the crap -- but again, this is a waste of your precious time. >> Really >> sad about it. There is a huge lack of selforganization. I tend to do >> double-reviews these days -- even solving an issue takes three days >> longer. So what? >> > > I am sure it will get better. For now we just need to be pragmatic. > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
