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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
