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. Luc > > Best regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
