On Wed, 27 Nov 2013 11:04:15 +0100, Luc Maisonobe wrote:
Le 26/11/2013 14:56, Gilles a écrit :
On Tue, 26 Nov 2013 14:47:09 +0100, Emmanuel Bourg wrote:
Le 26/11/2013 14:42, Benedikt Ritter a écrit :
What's the point of using git then?
To provide a better collaboration tool for the external
contributors,
and thus increasing the external contributions?
Unless I missed some of the recent discussions, this point has been
argued against and no counter-argument was presented.
Here are some counter arguments. I think they were already given, but
I
may be mistaken.
- Git allows unconnected operation, as everyone has a local
repository,
this is *really* interesting for some developers (like me), who
may
work in remote environment
- Git separates the notion of "commit" and the notion of "push" to
the
reference repository. This is important as some work may take time
for the developer and need some iterations with small steps. With
svn, you can save your work only by also pushing to an
experimental
branch, which is discussed in next point.
- Svn branches are a real problem, and Git branches a real solution.
We already tried to use branches when preparing a major release
for
[math] while continuing maintenance for the previous release (I
don't
remember if it was 1.2/2.0 or 2.2/3.0). It ended up in a big mess
and
we lost a tremendous amount of time (I was responsible for this
bad
choice)
- Git allows to exchange changesets between people that do not have
write access: they can create their own repository, make full use
of
the tools (diffs, updating their tree from the official repo,
branches, creating patches either for intermediate changes or
globally) and they can also either give access back to the regular
developers so they import and commit these changes in the tree,
do you remember this message
<http://markmail.org/message/36x2zajx3stoqvc6> or this one
<http://markmail.org/message/q6gbalkiifvmame2>? Git solves exactly
this
kind of problems, and
instead of having to ask for a single diff, the regular developer
just imports the "full history" of the changes, and can go to
whatever level of details he wants: either looking at each
individual
change and accept/reject them one at a time, or combine them and
look at the global diff and commit in one chunk, or do any
intermediate decision
- Git branching/merging features are far superior to SVN. Some
branches
are better handled using a rebase policy, some using a merge
policy,
both are possible. When you are stuck with conflicts, it is
generally
much easier to sort out what happens and get back to a clean way
without losing lots of work, by combining creation of temporary
local branches (the kind of branches you create just for a few
minutes while you run a few commands) and by using stash features.
- Git provides a stash feature that is really great to switch from
one line of work to another without losing temporary work
For reminder, the argument was that it is quite easy to provide a
contribution with Subversion:
$ svn co "<URL>"
$ cd trunk
$ mvn test
$ svn diff > "issue<xxxx>.patch"
Using a different source management system must bring added value to
the project (IOW: the regular developers).
I really think it does. It brings a lot of value. Git is not easy to
get
used to, but people can start using it almost just like they use SVN,
and learn progressively. Once used to Git features, it is really
difficult to go back to SVN.
I have _zero_ problem accepting that Git is better than anything that
existed before: I'm a GNU/Linux user since 1995.
The list above was not necessary to convince me.
I just do not buy the argument that we'll get more contributors by
using Git. This is pure wishful thinking (for Commons Math at least).
The initial post of this thread was intended to indeed make Git useful,
for the project(s), by taking advantage of its specific features
(IIUC);
but this has been answered somewhat negatively, hence the quite valid
question on top of this page, followed by the unproven (IMHO) answer...
I'll post a follow-up in a new [Math] mail.
Gilles
Luc
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
