hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Do not commit to HttpCore SVN!
Date Wed, 10 May 2017 19:45:41 GMT
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


Mime
View raw message