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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
