[ESS] public git mirror?

[Vitalie Spinu]

>>>> Aleksandar Blagotić <aca.blagotic at gmail.com>
>>>> on Wed, 8 Feb 2012 21:08:06 +0100 wrote:

  AB> IMO, the only reason why you wouldn't stick with Git(Hub) is familiarity
  AB> with SVN. Everything else is way better knitted-up on GitHub. Collaboration
  AB> is easier, bug tracking, you can easily add wiki pages or custom pages. I
  AB> understand that your productivity will suffer at first, but as you improve
  AB> your Git skills, it will start to pay of.

  AB> aL3xa

  AB> On Wed, Feb 8, 2012 at 20:43, Richard M. Heiberger <rmh at temple.edu> wrote:

  >> I think we should maintain ESS as at present.
  >> I see no value for adding complications that any switch would entail.
  >> 

I might be indeed too naive, but what is exactly the complication,
except that of learning git? Creating a project on github is 3 clicks.
No maintenance necessary. It also has automatic svn repository import.

  >> >> [1] https://github.com/blog/39-**say-hello-to-the-network-**> >> graph-visualizer<
  >> https://github.com/blog/39-say-hello-to-the-network-graph-visualizer>> >>
  >> [2] http://blogs.oracle.com/**smarks/entry/why_i_don_t_like<>
  >> http://blogs.oracle.com/smarks/entry/why_i_don_t_like>> >> [3]
  >> https://github.com/blog/674-**introducing-organizations<>
  >> https://github.com/blog/674-introducing-organizations>> >>
  >> >>
  >> > You might be right.  Or not.  Unfortunately, those 3 footnotes
  >> > don't add much to your argument.  The network graph for ESS
  >> > is as boring as the discussion in [3]; see it at
  >> > https://github.com/**emacsmirror/ess/network<> https://github.com/emacsmirror/ess/network>and be amazed
  >> > (if you can't stand the wait; the spinning beach ball
  >> > will usually make me click away immediately).

Of course network graph is blank for ESS, nobody forks or branches 
anything there,  so nothing to display.

Here is an example of a small elisp project network:

 https://github.com/sellout/emacs-color-theme-solarized/network

Link [1] explains the graph. The main idea is that the developer can
follow the evolution of the forked projects. It's a different level of
cooperation - the contributor need not even send a patch or feature to
the developer for the inclusion; the developer himself can monitor it
and adds to the project.

With current svn set-up a contributor has to make a diff, send to the
mailing list and wait for the developer to merge the stuff into the
trunk. Let alone if several people want to contribute to the same
feature they have to send diffs to each other. With github it's much
simpler. The contributor develops new feature as part of his repository
go to web interface and click pull-request to notify the main
developer. Even if the main developer doesn't include the contribution,
everyone else on github sees the feature and is free to include it in
his own repository.

  >> >
  >> > I have seen variants of article [2] before.  However, notice
  >> > that Stuart Marks is actually a proponent of Mercurial (hg)
  >> > rather than git.  I briefly used hg for XEmacs development. And, I can
  >> > honestly say; I don't get it.  If we were going down
  >> > this road; we need a nice tutorial.  

Git, Mercurial and Bazaar are all distributed systems once you know one
other shouldn't be difficult to learn (never tried myself though). 

Indeed I was assuming familiarity with git, sorry. Here is the way to
go:

M-x man  gittutorial
M-x man  gittutorial-2

M-x man  gitworkflows

and of course:

M-x man gitglossary

The above are official and are the best.

The book "Pro Git" by Scott Chacon is online here:
http://progit.org/book/

Each chapter is 20 minutes reading. Important part is ch.3 on branching
and ch.5 on distributed workflows. Ch.4 can be skipped entirely except
4.10 which is a very nice introduction to GitHub. 

All the above should be 3-4 hours of reading for the absolute beginner.

More if needed:
Official manual is the best:
http://schacon.github.com/git/user-manual.html

This is a short reference for everyday use:
http://schacon.github.com/git/everyday.html

This one is short intro for svn users:
http://git-scm.com/course/svn.html

  >> > I see that Stuart helpfully points to
  >> > http://www.bsdcan.org/2006/**papers/DistributedVCS-paper.**pdf<>
  >> > http://www.bsdcan.org/2006/papers/DistributedVCS-paper.pdf>> > But again,
  >> > that's mostly about hg and bazaar (of SXEmacs infamy).
  >> >
  >> > So, I'm not saying you are wrong exactly.  But, you are wrong
  >> > if you are assuming that we will just jump on board; we need
  >> > a gentle introduction.  In SVN, we have avoided branches
  >> > since it was too technical; so this is the audience you are
  >> > dealing with.  

Yes, it's too technical in SVN, and according to Stuart nobody is using
them for the workflow. I've no clue about them either, except that they
are physical copies residing in the directories. My main pain with svn
is captured by Stuart's sections 2 and 3, reverting or keeping
unfinished ideas in the code with svn is difficult. With git it's
natural. For each bugfix, feature one creates a branch and that branch
(being just a pointer to arbitrary commit) can be moved around and can
live indefinitely.

And to be repeated again, the main point is not git as such, but rather
social coding with GitHub with all it's fruits. You don't even need to
use the web interface if you don't want to, all the issues and
discussions are coming into your mailbox. Nothing would change
dramatically if you don't want to.

Vitalie.