You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2017/05/16 07:22:18 UTC
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
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.
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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-18 um 09:38 schrieb Oleg Kalnichevski:
> On Wed, 2017-05-17 at 22:56 -0700, Gary Gregory wrote:
>> 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?
>>
>
> Of course, once merged a dev branch should be deleted in the remote
> repo.
Correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-17 at 22:56 -0700, Gary Gregory wrote:
> 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?
>
Of course, once merged a dev branch should be deleted in the remote
repo.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Gary Gregory <ga...@gmail.com>.
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 <mi...@apache.org> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Julian Sedding <js...@gmail.com>.
Hi Michael
On Wed, May 17, 2017 at 10:57 AM, Michael Osipov <mi...@apache.org> 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...
>
Yes, I think we need to accept this and encourage contributors to
improve their skills, if necessary. We should provide some guidance,
and if that does not help, we can always pull the branch underlying a
PR into a local repo and refactor/rebase *before* it enters the
httpcomponents repo.
Arguably harder is to get committers to make clean commits. However,
IMHO git makes this easier, exactly because you can commit locally and
rebase/squash local changes. Therefore I have hope that the situation
improves after everyone transitions to git and improves their git
skills. Again, we may need to provide some guidance, which you
(Michael) have already been doing with the Git guidelines.
Regards
Julian
> Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Michael Osipov <mi...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Julian Sedding <js...@gmail.com>.
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 <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Git policies and practices / of tendency for good intentions to
turn into s..t
Posted by Michael Osipov <mi...@apache.org>.
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!
> 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?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org