3 ms·

Google docs has history of documents. Also, while I use latex and git, it is awkward for lots of reasons -- in particular git is line based, so if two people ed

Google docs has history of documents. Also, while I use latex and git, it is awkward for lots of reasons -- in particular git is line based, so if two people edit a comma in a paragraph, you get a conflict. (I know some people do a line per sentence, but I hate reading that).

YeGoblynQueenne 6y ago
I confess I haven't used google docs- as per another comment I prefer to not tie down my research and my code in proprietary formats, especially one living on someone else's computer (the "cloud")! About git's awkwardness, I recognise that people who are not trained as software developers may find the command line off-putting, but on the other hand having to keep track of changes to a couple dozen documents (scripts and article versions) by hand is, for me, the stuff of nightmares. This "awkwardness" pays for itself in spades when you realise that a change in a script you've written at the start of the project and haven't tested since is suddendly raising an error and you have no idea at which point it broke. This is a common thing that comes up in my projects. Git even has a special command to do this for you - "git bisect". I can't imagine the pain in the arse it would be to try and roll back maybe months of changes by hand, by copy-pasting backup files, I guess, or by making new untracked changes, until you have nothing to go back to that actually works. I've been in situations like this, like I say. Having a bedrock of committed code that I can go back to anytime I like is a time saver of epic proportions. A bit of "awkwardness" or even worse once in a while, is totally worth it. And conflicts happen for a reason. How do you merge work of two or three members of a team without something like version control? That sounds like an even worse nightmare.
- watwut 6y ago
  It is not just "having to use command line". It is also that git ui is unintuitive and awkward even by command line standards. Look at Git commands for merging and conflict solving. Look at those tutorials, they are typically bonkers complicated and don't even answer basic questions beginners have. Or, try to list all changes in one file only. In addition, you are way more likely to forget to add a file. In code, this shows up as error on jenkins or somewhere, but in document it wont.
  - YeGoblynQueenne 6y ago
    All I can say is that I find the complexity manageable, which is obviously because I've spent enough time using the tool that it doesn't scare me. Perhaps that is the solution? Use the tool until one is comfortable with it? It seems to me the alternative is a bunch of ad-hoc, half-baked procedures that are going to cause a lot more pain down the line. Or, of course, sitting down and writing a better tool than git (or svn, mercurial, etc). Personally, that's too much hassle given that someone has already done the work and all I have to do is learn how to use the program, which is much easier and much less time consuming. In general, that's why I use other peoples' software, even when I disagree with the logic behind them and I would do a better job if I had a go at it (which is, of course, always).
    - watwut 6y ago
      Even cvs and svn was easier to use then git. Git was created for a reason, it is good tool for some use cases. However, its user interface for simple projects is step back against what existed previously. By step back I mean much harder to use.
- CJefferson 6y ago
  Google docs handles conflicts by requiring an always-on connection, and showing each author a live view of the document. You can use overleaf, which provides a similar multi-author live editor for latex. This might not be a nice way to write code, but in my experience it is a great way to write large multi-author text documents, and requires no teaching of new tools -- git is (in my experience) far too hard to teach non-coders, when you are just doing one project together. Even with a GUI, we still have to teach them about merging/conflicts.
  - YeGoblynQueenne 6y ago
    Overleaf is certainly very convenient and so is Google docs, but I don't think they are meant to replace git, or v.v. Once you write your latex and your code, you can then commit it to git so you can benefit from git's version control. That is, unless it's acceptable for the text or code of a paper to live permanently on Overlaf or Google's servers - for me that's not acceptable at all. So I'll keep my local copies under version control and update them from Overleaf once in a while. I understand that git appears foreboding and hostile to people who aren't trained as programmers. Again all I have to say is that I don't find it that hard and I expect a researcher in a scientific field to be able to cope with it.

YeGoblynQueenne 6y ago

I confess I haven't used google docs- as per another comment I prefer to not tie down my research and my code in proprietary formats, especially one living on someone else's computer (the "cloud")! About git's awkwardness, I recognise that people who are not trained as software developers may find the command line off-putting, but on the other hand having to keep track of changes to a couple dozen documents (scripts and article versions) by hand is, for me, the stuff of nightmares. This "awkwardness" pays for itself in spades when you realise that a change in a script you've written at the start of the project and haven't tested since is suddendly raising an error and you have no idea at which point it broke. This is a common thing that comes up in my projects. Git even has a special command to do this for you - "git bisect". I can't imagine the pain in the arse it would be to try and roll back maybe months of changes by hand, by copy-pasting backup files, I guess, or by making new untracked changes, until you have nothing to go back to that actually works. I've been in situations like this, like I say. Having a bedrock of committed code that I can go back to anytime I like is a time saver of epic proportions. A bit of "awkwardness" or even worse once in a while, is totally worth it. And conflicts happen for a reason. How do you merge work of two or three members of a team without something like version control? That sounds like an even worse nightmare.

watwut 6y ago
It is not just "having to use command line". It is also that git ui is unintuitive and awkward even by command line standards. Look at Git commands for merging and conflict solving. Look at those tutorials, they are typically bonkers complicated and don't even answer basic questions beginners have. Or, try to list all changes in one file only. In addition, you are way more likely to forget to add a file. In code, this shows up as error on jenkins or somewhere, but in document it wont.
- YeGoblynQueenne 6y ago
  All I can say is that I find the complexity manageable, which is obviously because I've spent enough time using the tool that it doesn't scare me. Perhaps that is the solution? Use the tool until one is comfortable with it? It seems to me the alternative is a bunch of ad-hoc, half-baked procedures that are going to cause a lot more pain down the line. Or, of course, sitting down and writing a better tool than git (or svn, mercurial, etc). Personally, that's too much hassle given that someone has already done the work and all I have to do is learn how to use the program, which is much easier and much less time consuming. In general, that's why I use other peoples' software, even when I disagree with the logic behind them and I would do a better job if I had a go at it (which is, of course, always).
  - watwut 6y ago
    Even cvs and svn was easier to use then git. Git was created for a reason, it is good tool for some use cases. However, its user interface for simple projects is step back against what existed previously. By step back I mean much harder to use.
CJefferson 6y ago
Google docs handles conflicts by requiring an always-on connection, and showing each author a live view of the document. You can use overleaf, which provides a similar multi-author live editor for latex. This might not be a nice way to write code, but in my experience it is a great way to write large multi-author text documents, and requires no teaching of new tools -- git is (in my experience) far too hard to teach non-coders, when you are just doing one project together. Even with a GUI, we still have to teach them about merging/conflicts.
- YeGoblynQueenne 6y ago
  Overleaf is certainly very convenient and so is Google docs, but I don't think they are meant to replace git, or v.v. Once you write your latex and your code, you can then commit it to git so you can benefit from git's version control. That is, unless it's acceptable for the text or code of a paper to live permanently on Overlaf or Google's servers - for me that's not acceptable at all. So I'll keep my local copies under version control and update them from Overleaf once in a while. I understand that git appears foreboding and hostile to people who aren't trained as programmers. Again all I have to say is that I don't find it that hard and I expect a researcher in a scientific field to be able to cope with it.