If the committer squashes their commits *before* pushing then history is maintained.
On 10 May 2017 at 20:16, Oleg Kalnichevski <ol...@apache.org> wrote: > 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@apache >> > > .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) > --- > > This _actually_ goes completely counter to our established release > processes. We might want to be strict with stable branches (4.4.x and > so on) but have more leniency about what is going on in master. > > Oleg > > --------------------------------------------------------------------- > 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
