Re: [Texmacs-dev] git & texmacs

[Massimiliano Gubinelli]

Dear Sebastian,
 
thanks for the pointer, I was not aware of this. I know Darcs and I'm very much 
interested in a principled theory of patches and Rust programming.

It is not clear what advantages Darcs or any other alternative version control 
system will bring to us as a whole.

I think for a project like TeXmacs which has a very small number of people 
which are able to reliably manage the program as a whole it make sense to have 
a central repository. Having a distributed system is not the main reason to 
choose git (or something else).

Let me write the KEY motivations I had for suggesting a switch to git:

1)  git has a notion of committer and author of a patch (possibly this is true 
in other systems). I find this crucial for community-building since everybody 
can contribute directly to the code via pull request to the maintaners, their 
contribution is clearly marked. I'm not aware that this is available in svn and 
to me is a serious problem because do not encourages in the correct way the 
contribution of the community.

2) git has github and gitlab which are established platforms to develop 
communities around open source software.

Personally I manage several git branches of TeXmacs, and it seems easy to me. 
Note that I'm not a git power user, essentially I know 4 commands and it rarely 
happens to me to have complicate merge or dependency graphs.  I do all the work 
in one branch and then just commit the whole to svn.

The ability to do correct merge is not fundamental to me, we rarely have 
complicated merges and we do not have a very complex tree of development 
branches.

git is used already in TeXmacs by many of the contributors like Darcy, me, 
Miguel, Philippe. It seems easy to move that way. 

Joris was somehow ok with the idea to try to manage a development branch in git 
while keeping the stable branch in svn on savannah. I think this is the good 
decision to evaluate the suitability of this technology for our project.

I would like to hear possible defects of git which are relevant to our 
situation. 

A byproduct of adopting git could be that we develop better tool to integrate 
TeXmacs & git which is important for our users. The colleagues I know which 
uses version control systems use git and not svn or others, so we should try to 
give nice way to manage TeXmacs documents in git.

More sophisticate revision systems like Darcs or Pijul could be interesting to 
manage conflicts in online collaborative editing of documents. I still have to 
study the way it is implemented this now in TeXmacs.

Best,
Max


> On 19. May 2021, at 12:18, Sebastian Miele <sebastian.miele@gmail.com> wrote:
> 
> Hi Massimiliano,
> 
> Massimiliano Gubinelli <m.gubinelli@gmail.com> writes:
>> I've just found the following blog post on OCAML development which in
>> part discuss the effect of their transition to github:
>> 
>> https://discuss.ocaml.org/t/analyzing-contributions-to-the-ocaml-compiler-and-all-opam-packages/7854
>> 
>> it adds some background to our discussion of moving some of the
>> development of TeXmacs to a git-based workflow, possibly on github.
> 
> There may be an even cooler kid in town than all other current version
> control system (including Git and Darcs): Pijul (https://pijul.com/), "a
> sound and fast distributed version control system based on a
> mathematical theory of asynchronous work."
> 
> It is still open how far the adoption of that system will be in the
> (nearer) future.  But when it does get widespread adoption, it probably
> is just superior.  Not the least, because it is based on a mathematical
> theory that may be far more rewarding and fun to learn.
> 
> Maybe Joris is hesitant to switch to Git, because he does not want to
> spend the time to learn it.  And that I would find a very good reason.
> It is just tedious and boring, and takes a considerable amount of time
> from a valuable life.  That may be completely different with Pijul.  The
> time spent learning may be more of a time spend in enlightening and
> general insights about the core problem at hand.  Contrary to (a lot of)
> time spent on many details of yet another half-baked solution.
> 
> However, it remains to be seen how far the adoption will be in the
> (nearer) future.
> 
> Best wishes
> Sebastian