[openbiblio-dev] github

[Noel O'Boyle]

On 17 November 2011 17:43, Mark MacGillivray <mark at odaesa.com> wrote:
> On Thu, Nov 17, 2011 at 4:29 PM, Peter Murray-Rust <pm286 at cam.ac.uk> wrote:
>>
>> From Jim Pitman:
>> On Thu, Nov 17, 2011 at 4:21 PM, Jim Pitman <pitman at stat.berkeley.edu>
>> wrote:
>>>
>>> > but one of the papers in the PMR symposium was communally authored in
>>> > Latex on Github.
>>>
>>> Please can you say which one?
>>
>>  I have copied in Noel who was the lead author on the Blue Obelisk Reloaded
>> paper and also Egon
>>
>> Noel
>> We are thinking of using Github as a communal tool for managing Open
>> Bibliography, with each contributing BibSoup having its own Github node.
>> IIRC the BO paper was authored on Github - we'd be very grateful for a
>> summary of the pros and cons of GH for communal authoring of resoureces. In
>> this case we would be authoring JSON. (I have noted that there is a eGit
>> editor for Eclipse - do you know of other tools?)
>
> I would appreciate input from Noel, but also just want to add that I
> think there is some confusion here over what git does. Using git
> enables us to have version distributed version control on a repository
> (a folder). It places no restriction on what sort of editor we or
> other people use. We can put any file into a git folder, and edit it
> using anything we want.
>
> Mark

Exactly. The editor is a separate issue.

One reason for choosing git over mercurial is that the github website
does allow direct editing of a file through the web. This may be
useful for non-technical users. One reason for choosing mercurial over
git is TortoiseHg (I use the command-line for git on Windows). The
difficulty in installing git (or mercurial) correctly should not be
underestimated if you are collaborating with many others. In
particular, both require some setting up of ssh keys and configuration
for handling Windows/Unix line-endings (if the collaborators don't do
this right at the start, you are opening a can of worms - see the
github web page for instructions on installing git on various
systems). If I were you, I would nominate a git guru who helps
collaborators through this somehow, or better still, installs it for
them.

Before you consider going the DVC route, you may want to think about
low tech solutions such as a Google docs, or just sshing into a
server. A VC system  in general may not be suitable for documents
which do not have short "sentences" (very difficult to sensibly diff),
and where the contents of documents will be rearranged in a major way
by participants (very difficult to merge).

My 2c,
   Noel