On Wed, 2017-05-10 at 21:27 +0200, Michael Osipov wrote: > Am 2017-05-10 um 21:16 schrieb Oleg Kalnichevski: > > On Wed, 2017-05-10 at 21:07 +0200, Michael Osipov wrote: > > > Am 2017-05-10 um 20:52 schrieb Oleg Kalnichevski: > > > > On Wed, 2017-05-10 at 11:15 -0700, Gary Gregory wrote: > > > > > On Wed, May 10, 2017 at 10:13 AM, Oleg Kalnichevski <olegk@ap > > > > > ache > > > > > .org > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > One personal request. Do you think you could try to > > > > > > > > make > > > > > > > > your > > > > > > > > commits > > > > > > > > less granular and combine logically related changes > > > > > > > > into > > > > > > > > larger > > > > > > > > change > > > > > > > > sets? > > > > > > > > > > > > > > > > > > > > > > Old habits die hard. Git might indeed make this better. > > > > > > > If > > > > > > > you > > > > > > > want > > > > > > > to add > > > > > > > this to the style guideline on the site, it will help all > > > > > > > contributors, > > > > > > > present and future. > > > > > > > > > > > > > > > > > > > Hi Gary > > > > > > > > > > > > I do not think it would be possible to enforce it through a > > > > > > style > > > > > > check > > > > > > or a commit hook as there are legitimate reasons for one > > > > > > line > > > > > > commits. > > > > > > > > > > > > Please do not get me wrong. I have no intentions of > > > > > > changing > > > > > > your > > > > > > way > > > > > > of working. I fully respect other people's habits. What I > > > > > > am > > > > > > asking > > > > > > is > > > > > > your consent to squash some of your commits (combining > > > > > > small > > > > > > related > > > > > > commit into a larger one). > > > > > > > > > > > > > > > > Oh sure, feel free to do what you want. I did read something > > > > > a > > > > > long > > > > > time > > > > > ago warning git users about fiddling with repo history, but > > > > > since > > > > > we > > > > > have a > > > > > master repo and we are not truly using git in a distributed > > > > > way, > > > > > that > > > > > should not hurt us. > > > > > > > > > > > > > Of course, re-writing history can break forks, but we are not > > > > Linux > > > > kernel. I am not aware of a single fork maintained externally. > > > > Besides, > > > > rewriting would be limited to the most recent commits. No one > > > > is > > > > going > > > > to rewrite history more than a few days back. > > > > > > INFRA won't allow that. Master is a propertive branch as far as I > > > know. > > > > > > > As far as I know this rule could be disabled per request. > > > > History rewriting works for ordinary (non-master) branches > > > > --- > > oleg@ok2c:~/src/apache.org/httpcomponents/httpcore$ git push origin > > --force-with-lease > > Counting objects: 11, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (6/6), done. > > Writing objects: 100% (11/11), 968 bytes | 0 bytes/s, done. > > Total 11 (delta 3), reused 0 (delta 0) > > remote: httpcomponents-core git commit: Keep examples self- > > contained > > To https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git > > + 0ad926e8...5b29a6e4 4.4.x -> 4.4.x (forced update) > > To avoid issues like that, we should have the same approach as Tomcat > or > Maven does. One repo per major version, thus > > httpcomponents-core-4 > httpcomponents-client-4 > httpcomponents-core-5 > httpcomponents-client-5 > > At the end, it will spare us a lot of issues and we can mark 4.x as > legacy some day. >
This makes cherry-picking impossible (or difficult). We are not Tomcat. Our stuff we can still be in one repo. I have multiple clones of the same repo, one per major version. Works quite well for me. I am sorry I am not in favor of this idea. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
