25 Feb
2016
25 Feb
'16
4:29 p.m.
I would personally be on the side arguing AGAINST any sort of
migration to git as the primary repository. We have a mirror that
already exists, I see no reason why that is insufficient.
Whether contributions are provided as a single patch versus multiple
'commits' is, in my opinion, a matter of personal preference and one
is not inherently superior to the other. SVN is just as capable of
supporting branches that keep track of changes via commits, but the
times wherein I've used branches for development when I merge back to
trunk I do a single combined commit with all the changes rolled into
one, which ignores all of the previous development commits done to the
branch. I have never found reason to want all the extraneous commits,
their history is preserved in the tagged branch.
Git also remains extremely cumbersome in the one point where one would
think its developers would have gone out of their way to make the
operation as seamless and unneeding of direct intervention as
possible, the actual process of combining your changes with that of
other people. The fact that it does not automatically track changes of
files ALREADY part of the repository has never made sense to me, why
wouldn't I want any local changes I've made be merged cleanly with
whatever upstream changes are pulled down? Though I've always felt
that was more a cop out to try to minimize the burden on git's
remarkably crappy diff/merge support in the first place. How does it
mess up changes that are in two completely separate places in the same
file in this day and age is beyond me when SVN doesn't have this
problem.
Poor performance/usability on Windows is not just a matter of tooling.
Due to the size that the git history can grow to, it literally can end
up stalling out when doing operations. A place where I previously
worked resorted to trimming history. Unless the git developers are
willing to actually go into their internals and change how they do
file I/O to use dedicated Windows functions (there are hard limits to
the standard C file i/o functions on Windows) no amount of tooling
around the edges is going to fix that problem. Combined with the
constant extraneous merges generated because git 'insists' on merging
instead of automatically attempting to rebase when someone else gets
in a commit before you, we have a fundamental problem here.
I've used git, fairly extensively at that. I've generally found it to
be a much poorer user experience than SVN, especially in light of the
fact that I don't care about a lot of its 'features.' In fact the only
feature that it has that is a genuine feature and is not just a more
convoluted way of doing the same thing with SVN is local branches.
That can be useful, but that's achievable with the git mirror and
doesn't require those of us who do not want to use git to have to
suffer through its clunkiness. And when git due to its nature can
result in a lot of situations where it's faster to just nuke your
checkout and reclone instead of trying to untangle whatever snarl it
got its local history into, I would argue it's not doing a very good
job as a revision control system.
On Thu, Feb 25, 2016 at 6:55 AM, David Quintana (gigaherz)
<gigaherz(a)gmail.com> wrote:
Sorry about that. I guess I have read a lot of
technical papers ;P
On 25 February 2016 at 12:47, Ged Murphy <gedmurphy.maillists(a)gmail.com>
wrote:
Okay ignore me, we cleared it up in IRC. David means significant, I've
just never heard ........ nevermind ......
If moving to git will increase the likelihood of patches from outside the
team, then that in itself is a good enough reason to move IMO.
-----Original Message-----
From: Ged Murphy [mailto:gedmurphy.maillists@gmail.com]
Sent: 25 February 2016 11:26
To: 'ReactOS Development List' <ros-dev(a)reactos.org>
Subject: RE: [ros-dev] Consideration for migrating from Subversion to Git
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev I think the real goal with moving to a platform
such as github is
reducing the entry barriers for new contributors. As it has been
mentioned already, almost all projects who moved from SVN with "send
patches" contribution system, to Git/Hg with Pull Requests have got
non-negligible growth in contributions.
I'm confused, maybe it's your use of a double negative (non-negligible),
but that sounds contradictory?
Are you saying that projects that have moved from SVN to git have had no
growth or good growth in contributions?
Ged.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev