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/10 07:59:46 UTC
Do not commit to HttpCore SVN!
Folks
Please switch your local HttpCore repositories from SVN to the new Git
repo:
https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git
Please try to not commit to SVN while it is being set to read-only
mode.
The migration process has not been fully completed yet. We have a
terrible mess with Github mirrors and I do not yet know how it can all
be resolved.
Gary
I collected all your latest SVN commits and pushed them to the Git
repo. Nothing should have been lost.
One personal request. Do you think you could try to make your commits
less granular and combine logically related changes into larger change
sets?
You have committed 6 changes, all of them related, and all of them
pretty much one liners. Now that we have Git I am very, very tempted to
start squashing your commits and force pushing the changes back to the
repo.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
I've blow away my local SVN copy, checked out git trunk and it builds :-)
Gary
On Wed, May 10, 2017 at 12:59 AM, Oleg Kalnichevski <ol...@apache.org>
wrote:
> Folks
>
> Please switch your local HttpCore repositories from SVN to the new Git
> repo:
>
> https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git
>
> Please try to not commit to SVN while it is being set to read-only
> mode.
>
> The migration process has not been fully completed yet. We have a
> terrible mess with Github mirrors and I do not yet know how it can all
> be resolved.
>
>
> Gary
>
> I collected all your latest SVN commits and pushed them to the Git
> repo. Nothing should have been lost.
>
> One personal request. Do you think you could try to make your commits
> less granular and combine logically related changes into larger change
> sets?
>
> You have committed 6 changes, all of them related, and all of them
> pretty much one liners. Now that we have Git I am very, very tempted to
> start squashing your commits and force pushing the changes back to the
> repo.
>
> Oleg
>
> ---------------------------------------------------------------------
> 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: Do not commit to HttpCore SVN!
Posted by sebb <se...@gmail.com>.
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-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: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 10, 2017 at 12:27 PM, Michael Osipov <mi...@apache.org>
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@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)
>>
>
> 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
>
I like that. I've already checked out HttpCore twice for 4.4.x and 5 just
be able to look at both source trees at the same time.
Also, from Eclipse, switch branches between core4 and core5 is not smooth
because the modules are not the same; which is another reason I ended up
checking out core twice in two parallel directories.
Gary
At the end, it will spare us a lot of issues and we can mark 4.x as legacy
> some day.
>
>
> ---------------------------------------------------------------------
> 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: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 17:19 schrieb Gary Gregory:
> On Mon, May 15, 2017 at 8:04 AM, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski:
>>
>>> On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
>>>
>>>>
>>>>>
>>> ...
>>>
>>>
>>> Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski:
>>>> What benefit do you have if it is hard to follow the code paths? How
>>>> much is "good" code worth if you don't have proper documentation?
>>>> Even
>>>> if you have to constantly clean up their mess just like mom did?
>>>>
>>>> I see the log as a documentation of our work. At the end, good code
>>>> does
>>>> not help if it cannot be properly located by others. I still think
>>>> that
>>>> all committers should help the RM to do as little as possible and
>>>> not
>>>> more than necessary.
>>>>
>>>> Michael
>>>>
>>>>
>>> Michael,
>>>
>>> It is the same deal as with the decision on an logging API.
>>>
>>> Please put together a short statement what our Git commit policies
>>> should be (probably in Wiki), ask people to comment / complain, then
>>> copy the statement into an email and call a vote.
>>>
>>
>> I actually did: https://mail-archives.apache.o
>> rg/mod_mbox/hc-dev/201705.mbox/%3C010661f8-4e15-01af-6a5a-
>> 971baa1348ca%40apache.org%3E
>>
>> and some people agreed, including you and Gary.
>>
>> Anyway, here is the wiki page: https://wiki.apache.org/HttpCo
>> mponents/GitPoliciesAndPractices
>
>
> "Policies" and "Practices"? What's the difference? I do not see two
> sections on the page ;-) Can we take down the corporate-speak down a notch
> and go for "Git Guidelines"?
Makes sense, done!
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, May 15, 2017 at 8:04 AM, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski:
>
>> On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
>>
>>>
>>>>
>> ...
>>
>>
>> Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski:
>>> What benefit do you have if it is hard to follow the code paths? How
>>> much is "good" code worth if you don't have proper documentation?
>>> Even
>>> if you have to constantly clean up their mess just like mom did?
>>>
>>> I see the log as a documentation of our work. At the end, good code
>>> does
>>> not help if it cannot be properly located by others. I still think
>>> that
>>> all committers should help the RM to do as little as possible and
>>> not
>>> more than necessary.
>>>
>>> Michael
>>>
>>>
>> Michael,
>>
>> It is the same deal as with the decision on an logging API.
>>
>> Please put together a short statement what our Git commit policies
>> should be (probably in Wiki), ask people to comment / complain, then
>> copy the statement into an email and call a vote.
>>
>
> I actually did: https://mail-archives.apache.o
> rg/mod_mbox/hc-dev/201705.mbox/%3C010661f8-4e15-01af-6a5a-
> 971baa1348ca%40apache.org%3E
>
> and some people agreed, including you and Gary.
>
> Anyway, here is the wiki page: https://wiki.apache.org/HttpCo
> mponents/GitPoliciesAndPractices
"Policies" and "Practices"? What's the difference? I do not see two
sections on the page ;-) Can we take down the corporate-speak down a notch
and go for "Git Guidelines"?
Cheers,
Gary
>
>
> Shall I rerun it with a "[VOTE]" prefix in the subject?
>
> 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: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 17:19 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 17:04 +0200, Michael Osipov wrote:
>> Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski:
>>> On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
>>>>>
>>>
>>>
>
> ...
>
>> I actually did:
>> https://mail-archives.apache.org/mod_mbox/hc-dev/201705.mbox/%3C01066
>> 1f8-4e15-01af-6a5a-971baa1348ca%40apache.org%3E
>>
>> and some people agreed, including you and Gary.
>>
>
> It was not a binding vote, was it?
I don't know.
>> Anyway, here is the wiki page:
>> https://wiki.apache.org/HttpComponents/GitPoliciesAndPractices
>>
>> Shall I rerun it with a "[VOTE]" prefix in the subject?
>>
>
> Ask people for comments first.
Sorry, I did this in my thread by
> Something else I forgot?
>
> What do you think?
> For instance I see no mentioning of the idea of RM being in charge of
> merging dev branches onto release branches.
Done. Have a look.
> Give people some time to react (probably a few days) and then call a
> vote with defined rules as to whose votes count as binding. I guess a
> policy votes require PMC status to be considered binding, same as with
> release votes.
I'll repost with a new title. Consider that only a few people have
reacted on my questions.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-15 at 17:04 +0200, Michael Osipov wrote:
> Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski:
> > On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
> > > >
> >
> >
...
> I actually did:
> https://mail-archives.apache.org/mod_mbox/hc-dev/201705.mbox/%3C01066
> 1f8-4e15-01af-6a5a-971baa1348ca%40apache.org%3E
>
> and some people agreed, including you and Gary.
>
It was not a binding vote, was it?
> Anyway, here is the wiki page:
> https://wiki.apache.org/HttpComponents/GitPoliciesAndPractices
>
> Shall I rerun it with a "[VOTE]" prefix in the subject?
>
Ask people for comments first.
For instance I see no mentioning of the idea of RM being in charge of
merging dev branches onto release branches.
Give people some time to react (probably a few days) and then call a
vote with defined rules as to whose votes count as binding. I guess a
policy votes require PMC status to be considered binding, same as with
release votes.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 16:36 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
>>>
>
> ...
>
>
>> Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski:
>> What benefit do you have if it is hard to follow the code paths? How
>> much is "good" code worth if you don't have proper documentation?
>> Even
>> if you have to constantly clean up their mess just like mom did?
>>
>> I see the log as a documentation of our work. At the end, good code
>> does
>> not help if it cannot be properly located by others. I still think
>> that
>> all committers should help the RM to do as little as possible and
>> not
>> more than necessary.
>>
>> Michael
>>
>
> Michael,
>
> It is the same deal as with the decision on an logging API.
>
> Please put together a short statement what our Git commit policies
> should be (probably in Wiki), ask people to comment / complain, then
> copy the statement into an email and call a vote.
I actually did:
https://mail-archives.apache.org/mod_mbox/hc-dev/201705.mbox/%3C010661f8-4e15-01af-6a5a-971baa1348ca%40apache.org%3E
and some people agreed, including you and Gary.
Anyway, here is the wiki page:
https://wiki.apache.org/HttpComponents/GitPoliciesAndPractices
Shall I rerun it with a "[VOTE]" prefix in the subject?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-15 at 16:18 +0200, Michael Osipov wrote:
> >
...
> Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski:
> What benefit do you have if it is hard to follow the code paths? How
> much is "good" code worth if you don't have proper documentation?
> Even
> if you have to constantly clean up their mess just like mom did?
>
> I see the log as a documentation of our work. At the end, good code
> does
> not help if it cannot be properly located by others. I still think
> that
> all committers should help the RM to do as little as possible and
> not
> more than necessary.
>
> Michael
>
Michael,
It is the same deal as with the decision on an logging API.
Please put together a short statement what our Git commit policies
should be (probably in Wiki), ask people to comment / complain, then
copy the statement into an email and call a vote.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 16:00 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 15:18 +0200, Michael Osipov wrote:
>>>
>
> ...
>
>
>> Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski:
>>> I have _no_ intention of policing other committers. It is
>>> emotionally
>>> cheaper for me to take time to clean things up and than to hold all
>>> those conversations about policies.
>>
>> But why do you want to do the extra work to clean up somebody's else
>> mess? A project team needs to agree on some standards and rules
>> making
>> life easier for everyone -- the project members as well as our
>> clients
>> reading the log and using the software.
>>
>> A project won't run w/o rules. It is pretty discouring for every a
>> lot
>> of devs if someone else does not stick to the rules and produces
>> garbage
>> commits.
>>
>
> (1) You see. Those are not garbage commits. They are just chaotic. Some
> people work like that.
I wasn't referring to the work itself, but how people work with a SCM.
Trunk looks terrible. Impossible to do a bisect.
> (2) I personally rather deal with people who are interested in writing
> code than those people who are interested in setting rules.
What benefit do you have if it is hard to follow the code paths? How
much is "good" code worth if you don't have proper documentation? Even
if you have to constantly clean up their mess just like mom did?
I see the log as a documentation of our work. At the end, good code does
not help if it cannot be properly located by others. I still think that
all committers should help the RM to do as little as possible and not
more than necessary.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-15 at 15:18 +0200, Michael Osipov wrote:
> >
...
> Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski:
> > I have _no_ intention of policing other committers. It is
> > emotionally
> > cheaper for me to take time to clean things up and than to hold all
> > those conversations about policies.
>
> But why do you want to do the extra work to clean up somebody's else
> mess? A project team needs to agree on some standards and rules
> making
> life easier for everyone -- the project members as well as our
> clients
> reading the log and using the software.
>
> A project won't run w/o rules. It is pretty discouring for every a
> lot
> of devs if someone else does not stick to the rules and produces
> garbage
> commits.
>
(1) You see. Those are not garbage commits. They are just chaotic. Some
people work like that.
(2) I personally rather deal with people who are interested in writing
code than those people who are interested in setting rules.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote:
>> Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski:
>>> On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
>>>> Force pushing is considered a bad practice in Git for good
>>>> reasons,
>>>> thus rewriting history of published branches is IMHO a no-go. It
>>>> makes
>>>> everybody's life harder (and developers less experienced with Git
>>>> may
>>>> not be able to integrate the rewritten history at all).
>>>>
>>>
>>> How so exactly? So, it is not OK to have a developer spend a few
>>> minutes integrating upstream changes into the local branch but it
>>> is OK
>>> to have the release manager waste time wading through hundreds of
>>> unnecessary commits when preparing a release or chasing a
>>> regression?
>>
>> It is absolutely not OK for you as RM spending valuable time fixing
>> an
>> ugly log. Every committer is obliged to leave a clean log. If a dev
>> does
>> not stick to these rules he should be taken away his commit right.
>>
>> If you want to clean up because committers are too stupid to do so,
>> we
>> should take the command-and-leutnant approach.
>
> I have _no_ intention of policing other committers. It is emotionally
> cheaper for me to take time to clean things up and than to hold all
> those conversations about policies.
But why do you want to do the extra work to clean up somebody's else
mess? A project team needs to agree on some standards and rules making
life easier for everyone -- the project members as well as our clients
reading the log and using the software.
A project won't run w/o rules. It is pretty discouring for every a lot
of devs if someone else does not stick to the rules and produces garbage
commits.
>> Committers never push
>> directly to a live release branch, but request a PR for it. You as
>> the
>> RM will merge it. It will give you all the freedom you need. So
>> 5.0/master and 4.4/master should be protected branches writable by
>> you
>> only. I am fine with that.
>>
>> Michael
>>
>
> If folks can live with the restriction of release branches being
> writable to PMs only, I am fine with that but I think it is just a
> matter of time this rule gets broken. It is just cannot be enforced
> properly without git commit hooks.
This dev commit branch should not be rewritten of course. But will you
really go through all commits, cherry pick and squash. This is just
daunting.
If people cannot bring up the disciple, they should reconsider their work.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote:
> Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski:
> > On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
> > > Force pushing is considered a bad practice in Git for good
> > > reasons,
> > > thus rewriting history of published branches is IMHO a no-go. It
> > > makes
> > > everybody's life harder (and developers less experienced with Git
> > > may
> > > not be able to integrate the rewritten history at all).
> > >
> >
> > How so exactly? So, it is not OK to have a developer spend a few
> > minutes integrating upstream changes into the local branch but it
> > is OK
> > to have the release manager waste time wading through hundreds of
> > unnecessary commits when preparing a release or chasing a
> > regression?
>
> It is absolutely not OK for you as RM spending valuable time fixing
> an
> ugly log. Every committer is obliged to leave a clean log. If a dev
> does
> not stick to these rules he should be taken away his commit right.
>
> If you want to clean up because committers are too stupid to do so,
> we
> should take the command-and-leutnant approach.
I have _no_ intention of policing other committers. It is emotionally
cheaper for me to take time to clean things up and than to hold all
those conversations about policies.
> Committers never push
> directly to a live release branch, but request a PR for it. You as
> the
> RM will merge it. It will give you all the freedom you need. So
> 5.0/master and 4.4/master should be protected branches writable by
> you
> only. I am fine with that.
>
> Michael
>
If folks can live with the restriction of release branches being
writable to PMs only, I am fine with that but I think it is just a
matter of time this rule gets broken. It is just cannot be enforced
properly without git commit hooks.
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: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
>> Force pushing is considered a bad practice in Git for good reasons,
>> thus rewriting history of published branches is IMHO a no-go. It
>> makes
>> everybody's life harder (and developers less experienced with Git may
>> not be able to integrate the rewritten history at all).
>>
>
> How so exactly? So, it is not OK to have a developer spend a few
> minutes integrating upstream changes into the local branch but it is OK
> to have the release manager waste time wading through hundreds of
> unnecessary commits when preparing a release or chasing a regression?
It is absolutely not OK for you as RM spending valuable time fixing an
ugly log. Every committer is obliged to leave a clean log. If a dev does
not stick to these rules he should be taken away his commit right.
If you want to clean up because committers are too stupid to do so, we
should take the command-and-leutnant approach. Committers never push
directly to a live release branch, but request a PR for it. You as the
RM will merge it. It will give you all the freedom you need. So
5.0/master and 4.4/master should be protected branches writable by you
only. I am fine with that.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
> Force pushing is considered a bad practice in Git for good reasons,
> thus rewriting history of published branches is IMHO a no-go. It
> makes
> everybody's life harder (and developers less experienced with Git may
> not be able to integrate the rewritten history at all).
>
How so exactly? So, it is not OK to have a developer spend a few
minutes integrating upstream changes into the local branch but it is OK
to have the release manager waste time wading through hundreds of
unnecessary commits when preparing a release or chasing a regression?
Oleg
> Don't get me wrong. I do a lot of rebasing locally because I
> appreciate a commit history that tells a story (i.e. commits should
> be
> intentional, logical units, not accidental bits of work).
>
> Could we perhaps achieve a pretty history by enforcing a
> review-then-commit workflow? That way we can have temporary feature
> branches (which may be deleted or force pushed in my book), work out
> the history and only merge to master (or the respective release
> branch) when we're happy with the change and the history.
>
> Regards
> Julian
>
>
> On Thu, May 11, 2017 at 9:23 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> > On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
> > > Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
> > > > On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
> > > >
> > > >
> >
> > ...
> >
> > > > I am not sure I understand what you mean by git apply.
> > > >
> > > > Can we go back to what appears to be the only sticking point
> > > > here?
> > > >
> > > > It seems pretty clear that major release branches do not need
> > > > to be
> > > > in
> > > > different repos. Local clones per major release are perfectly
> > > > sufficient.
> > > >
> > > > The question is whether or not people can live with HEADs of
> > > > release
> > > > branches being volatile for a short period of time (not more
> > > > than a
> > > > few
> > > > days) until every active committer gets used to using dev
> > > > branches
> > > > for
> > > > building change sets?
> > >
> > > To be more precise: do you want to do this only once or before
> > > every
> > > release?
> > >
> >
> > I want to be able to do it on a case by case basis. Like the one we
> > just had.
> >
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-15 um 11:54 schrieb Julian Sedding:
> Force pushing is considered a bad practice in Git for good reasons,
> thus rewriting history of published branches is IMHO a no-go. It makes
> everybody's life harder (and developers less experienced with Git may
> not be able to integrate the rewritten history at all).
>
> Don't get me wrong. I do a lot of rebasing locally because I
> appreciate a commit history that tells a story (i.e. commits should be
> intentional, logical units, not accidental bits of work).
>
> Could we perhaps achieve a pretty history by enforcing a
> review-then-commit workflow? That way we can have temporary feature
> branches (which may be deleted or force pushed in my book), work out
> the history and only merge to master (or the respective release
> branch) when we're happy with the change and the history.
I made this propopal already several days ago. See thread "Git policies
and practices". I don't want either the master/release branch to be
rewritten.
> On Thu, May 11, 2017 at 9:23 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
>>> Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
>>>> On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
>>>>
>>>>
>>
>> ...
>>
>>>> I am not sure I understand what you mean by git apply.
>>>>
>>>> Can we go back to what appears to be the only sticking point here?
>>>>
>>>> It seems pretty clear that major release branches do not need to be
>>>> in
>>>> different repos. Local clones per major release are perfectly
>>>> sufficient.
>>>>
>>>> The question is whether or not people can live with HEADs of
>>>> release
>>>> branches being volatile for a short period of time (not more than a
>>>> few
>>>> days) until every active committer gets used to using dev branches
>>>> for
>>>> building change sets?
>>>
>>> To be more precise: do you want to do this only once or before every
>>> release?
>>>
>>
>> I want to be able to do it on a case by case basis. Like the one we
>> just had.
>>
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Julian Sedding <js...@gmail.com>.
Force pushing is considered a bad practice in Git for good reasons,
thus rewriting history of published branches is IMHO a no-go. It makes
everybody's life harder (and developers less experienced with Git may
not be able to integrate the rewritten history at all).
Don't get me wrong. I do a lot of rebasing locally because I
appreciate a commit history that tells a story (i.e. commits should be
intentional, logical units, not accidental bits of work).
Could we perhaps achieve a pretty history by enforcing a
review-then-commit workflow? That way we can have temporary feature
branches (which may be deleted or force pushed in my book), work out
the history and only merge to master (or the respective release
branch) when we're happy with the change and the history.
Regards
Julian
On Thu, May 11, 2017 at 9:23 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
>> Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
>> > On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
>> >
>> >
>
> ...
>
>> > I am not sure I understand what you mean by git apply.
>> >
>> > Can we go back to what appears to be the only sticking point here?
>> >
>> > It seems pretty clear that major release branches do not need to be
>> > in
>> > different repos. Local clones per major release are perfectly
>> > sufficient.
>> >
>> > The question is whether or not people can live with HEADs of
>> > release
>> > branches being volatile for a short period of time (not more than a
>> > few
>> > days) until every active committer gets used to using dev branches
>> > for
>> > building change sets?
>>
>> To be more precise: do you want to do this only once or before every
>> release?
>>
>
> I want to be able to do it on a case by case basis. Like the one we
> just had.
>
> 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: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2017-05-11 at 00:00 +0200, Michael Osipov wrote:
> Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
> > On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
> >
> >
...
> > I am not sure I understand what you mean by git apply.
> >
> > Can we go back to what appears to be the only sticking point here?
> >
> > It seems pretty clear that major release branches do not need to be
> > in
> > different repos. Local clones per major release are perfectly
> > sufficient.
> >
> > The question is whether or not people can live with HEADs of
> > release
> > branches being volatile for a short period of time (not more than a
> > few
> > days) until every active committer gets used to using dev branches
> > for
> > building change sets?
>
> To be more precise: do you want to do this only once or before every
> release?
>
I want to be able to do it on a case by case basis. Like the one we
just had.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-10 um 23:48 schrieb Oleg Kalnichevski:
> On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
>
> ...
>
>>>> But your answer is contrary to your previous statement -- cherry-
>>>> picking
>>>> shouldn't be a fuzz with two different repos. Can you explain
>>>> why?
>>>>
>>>
>>> My understanding is that cherry picking is not possible if remote
>>> branches do not share the same commit history. If they do, they
>>> might
>>> as well be branches in the same repository.
>>
>> Seems to be true. How about a patch from cherry-pick and a git apply?
>>
>>
>
> I am not sure I understand what you mean by git apply.
>
> Can we go back to what appears to be the only sticking point here?
>
> It seems pretty clear that major release branches do not need to be in
> different repos. Local clones per major release are perfectly
> sufficient.
>
> The question is whether or not people can live with HEADs of release
> branches being volatile for a short period of time (not more than a few
> days) until every active committer gets used to using dev branches for
> building change sets?
To be more precise: do you want to do this only once or before every
release?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-10 at 23:25 +0200, Michael Osipov wrote:
...
> > > But your answer is contrary to your previous statement -- cherry-
> > > picking
> > > shouldn't be a fuzz with two different repos. Can you explain
> > > why?
> > >
> >
> > My understanding is that cherry picking is not possible if remote
> > branches do not share the same commit history. If they do, they
> > might
> > as well be branches in the same repository.
>
> Seems to be true. How about a patch from cherry-pick and a git apply?
>
>
I am not sure I understand what you mean by git apply.
Can we go back to what appears to be the only sticking point here?
It seems pretty clear that major release branches do not need to be in
different repos. Local clones per major release are perfectly
sufficient.
The question is whether or not people can live with HEADs of release
branches being volatile for a short period of time (not more than a few
days) until every active committer gets used to using dev branches for
building change sets?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-10 um 23:19 schrieb Oleg Kalnichevski:
> On Wed, 2017-05-10 at 22:00 +0200, Michael Osipov wrote:
>> Am 2017-05-10 um 21:54 schrieb Oleg Kalnichevski:
>>> On Wed, 2017-05-10 at 21:45 +0200, Michael Osipov wrote:
>>>>
>>>> This will a problem anyway because all paths change (package
>>>> names,
>>>> etc.). Hopefully Git's similarity algorithm can detect this.
>>>>
>>>
>>> No, it is not. Git is that great. It always amazes me how
>>> intelligent
>>> Git when it comes to merging stuff.
>>
>> That's awesome, I had to do this once on a project and provided a
>> similarity key and voila -- it worked. Git tracks content, not files
>> like Subversion.
>>
>> But your answer is contrary to your previous statement -- cherry-
>> picking
>> shouldn't be a fuzz with two different repos. Can you explain why?
>>
>
> My understanding is that cherry picking is not possible if remote
> branches do not share the same commit history. If they do, they might
> as well be branches in the same repository.
Seems to be true. How about a patch from cherry-pick and a git apply?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-10 at 22:00 +0200, Michael Osipov wrote:
> Am 2017-05-10 um 21:54 schrieb Oleg Kalnichevski:
> > On Wed, 2017-05-10 at 21:45 +0200, Michael Osipov wrote:
> > >
> > > This will a problem anyway because all paths change (package
> > > names,
> > > etc.). Hopefully Git's similarity algorithm can detect this.
> > >
> >
> > No, it is not. Git is that great. It always amazes me how
> > intelligent
> > Git when it comes to merging stuff.
>
> That's awesome, I had to do this once on a project and provided a
> similarity key and voila -- it worked. Git tracks content, not files
> like Subversion.
>
> But your answer is contrary to your previous statement -- cherry-
> picking
> shouldn't be a fuzz with two different repos. Can you explain why?
>
My understanding is that cherry picking is not possible if remote
branches do not share the same commit history. If they do, they might
as well be branches in the same repository.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-10 um 21:54 schrieb Oleg Kalnichevski:
> On Wed, 2017-05-10 at 21:45 +0200, Michael Osipov wrote:
>>
>> This will a problem anyway because all paths change (package names,
>> etc.). Hopefully Git's similarity algorithm can detect this.
>>
>
> No, it is not. Git is that great. It always amazes me how intelligent
> Git when it comes to merging stuff.
That's awesome, I had to do this once on a project and provided a
similarity key and voila -- it worked. Git tracks content, not files
like Subversion.
But your answer is contrary to your previous statement -- cherry-picking
shouldn't be a fuzz with two different repos. Can you explain why?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-10 at 21:45 +0200, Michael Osipov wrote:
>
> This will a problem anyway because all paths change (package names,
> etc.). Hopefully Git's similarity algorithm can detect this.
>
No, it is not. Git is that great. It always amazes me how intelligent
Git when it comes to merging stuff.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-10 um 21:42 schrieb Oleg Kalnichevski:
> 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.
This will a problem anyway because all paths change (package names,
etc.). Hopefully Git's similarity algorithm can detect this.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
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@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)
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 10, 2017 at 10:13 AM, Oleg Kalnichevski <ol...@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.
Gary
>
> Oleg
>
> ---------------------------------------------------------------------
> 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: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
...
> > 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).
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, May 10, 2017 at 12:59 AM, Oleg Kalnichevski <ol...@apache.org>
wrote:
> Folks
>
> Please switch your local HttpCore repositories from SVN to the new Git
> repo:
>
> https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git
>
> Please try to not commit to SVN while it is being set to read-only
> mode.
>
> The migration process has not been fully completed yet. We have a
> terrible mess with Github mirrors and I do not yet know how it can all
> be resolved.
>
>
> Gary
>
> I collected all your latest SVN commits and pushed them to the Git
> repo. Nothing should have been lost.
>
> 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.
Gary
>
> You have committed 6 changes, all of them related, and all of them
> pretty much one liners. Now that we have Git I am very, very tempted to
> start squashing your commits and force pushing the changes back to the
> repo.
>
> Oleg
>
> ---------------------------------------------------------------------
> 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: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-10 at 09:51 -0700, Gary Gregory wrote:
> Can you rename trunk to master and then give the green light?
>
Done. SVN trunk pushed to remote as master and remote trunk deleted.
Oleg
> Gary
>
> On Wed, May 10, 2017 at 12:59 AM, Oleg Kalnichevski <olegk@apache.org
> >
> wrote:
>
> > Folks
> >
> > Please switch your local HttpCore repositories from SVN to the new
> > Git
> > repo:
> >
> > https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git
> >
> > Please try to not commit to SVN while it is being set to read-only
> > mode.
> >
> > The migration process has not been fully completed yet. We have a
> > terrible mess with Github mirrors and I do not yet know how it can
> > all
> > be resolved.
> >
> >
> > Gary
> >
> > I collected all your latest SVN commits and pushed them to the Git
> > repo. Nothing should have been lost.
> >
> > One personal request. Do you think you could try to make your
> > commits
> > less granular and combine logically related changes into larger
> > change
> > sets?
> >
> > You have committed 6 changes, all of them related, and all of them
> > pretty much one liners. Now that we have Git I am very, very
> > tempted to
> > start squashing your commits and force pushing the changes back to
> > the
> > repo.
> >
> > 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: Do not commit to HttpCore SVN!
Posted by Gary Gregory <ga...@gmail.com>.
Can you rename trunk to master and then give the green light?
Gary
On Wed, May 10, 2017 at 12:59 AM, Oleg Kalnichevski <ol...@apache.org>
wrote:
> Folks
>
> Please switch your local HttpCore repositories from SVN to the new Git
> repo:
>
> https://git-wip-us.apache.org/repos/asf/httpcomponents-core.git
>
> Please try to not commit to SVN while it is being set to read-only
> mode.
>
> The migration process has not been fully completed yet. We have a
> terrible mess with Github mirrors and I do not yet know how it can all
> be resolved.
>
>
> Gary
>
> I collected all your latest SVN commits and pushed them to the Git
> repo. Nothing should have been lost.
>
> One personal request. Do you think you could try to make your commits
> less granular and combine logically related changes into larger change
> sets?
>
> You have committed 6 changes, all of them related, and all of them
> pretty much one liners. Now that we have Git I am very, very tempted to
> start squashing your commits and force pushing the changes back to the
> repo.
>
> Oleg
>
> ---------------------------------------------------------------------
> 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
Git policies and practices; Re: Do not commit to HttpCore SVN!
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2017-05-10 at 16:18 +0200, Michael Osipov wrote:
> Am 2017-05-10 um 09:59 schrieb Oleg Kalnichevski:
> >
> > I collected all your latest SVN commits and pushed them to the Git
> > repo. Nothing should have been lost.
> >
> > One personal request. Do you think you could try to make your
> > commits
> > less granular and combine logically related changes into larger
> > change
> > sets?
> >
> > You have committed 6 changes, all of them related, and all of them
> > pretty much one liners. Now that we have Git I am very, very
> > tempted to
> > start squashing your commits and force pushing the changes back to
> > the
> > repo.
>
> We should talk about this in a separate thread. With Git comes more
> disciple but also a better way to make your own work cleaner avoiding
> 10
> cleanup commits.
>
>
Hi Michael
Yes, please do feel free to start a new thread on Git etiquette, common
practices, policies and so on.
We can discuss whether or not we want to keep trunk as an unstable dev
branch or rename it to 5.0.x or master.
I am personally interested in finding a consensus if it is OK to re-
write branches, for instance, by squashing noisy commits and style
check fixes.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Do not commit to HttpCore SVN!
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-05-10 um 09:59 schrieb Oleg Kalnichevski:
>
> I collected all your latest SVN commits and pushed them to the Git
> repo. Nothing should have been lost.
>
> One personal request. Do you think you could try to make your commits
> less granular and combine logically related changes into larger change
> sets?
>
> You have committed 6 changes, all of them related, and all of them
> pretty much one liners. Now that we have Git I am very, very tempted to
> start squashing your commits and force pushing the changes back to the
> repo.
We should talk about this in a separate thread. With Git comes more
disciple but also a better way to make your own work cleaner avoiding 10
cleanup commits.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org