15

I'd like learn about your practices and why you commit the way you do. Whether the practice is just "good" or "better" than another one is of course debatable but this topic could be really helpful for others. One could learn a lot from it. :)

How often do commit when you use Git, SVN etc. for your own LaTeX documents? Why? Also, did you learn anything from it, or did it even influence your workflow when creating a document?

edit

As Jubobs points out, git and SVN might greatly differ. Personally, I do not have a clue about anything other than git, so... I don't know. I initially created this topic for the usage of git but cfr implied they are somewhat the same. Not sure about this.

closed as primarily opinion-based by user31729, Guido, Masroor, Claudio Fiandrino, Jesse Sep 15 '14 at 6:37

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    @cfr Oh, no, sorry, just didn't think broadly enough. Edited the op. Feel free to finetune the terms. – henry Sep 14 '14 at 20:01
  • 1
    Thanks. I just thought you must have something git-specific in mind but couldn't figure out what! – cfr Sep 14 '14 at 20:03
  • I think the question has value, but it should be restricted to one VCS in particular; otherwise, it might be too broad. For instance, an SVN workflow is likely to greatly differ from a Git workflow. Also, you should specify whether you have collaboration in mind or whether you use version control only locally. – jubobs Sep 14 '14 at 20:25
  • @Jubobs really? Personally, I do not have a clue about anything other than git, so... I don't know. I initially created this topic for the usage of git but cfr implied they are somewhat the same. Not sure about this. Also, cfr does not tell which software she uses so I think it still works. But actually I can't say because of the lack of experience. Could gladly restrict it to git! – henry Sep 14 '14 at 20:33
  • @Jubobs I now restricted it to one's own document, i.e. not multiple authors. I do not agree about mentioning whether one saves locally only or has a remote repo. I say when you need the files on another machine pushing the content comes into play, otherwise... not. So this is just about the commits. Or maybe it's my relative inexperience speaking again but that is how I figured it. :) – henry Sep 14 '14 at 20:38
15

I generally commit in the following cases:

  • I am switching to work on another document, especially one which is part of a different project.
  • I am finishing for the day, taking a break or may be changing computers.
  • I am about to run a system update on my laptop (which runs Arch and is therefore theoretically more vulnerable to unexpected breakage although that doesn't seem true in practice).
  • I am stuck.
  • I find myself worrying about changing things in case I lose them and change my mind.
  • I want to send a copy of my current work to somebody else.
  • I am about to print a copy and the document itself includes mark-up noting the revision information.
  • I want to clean up files I no longer need, including generated files or old stuff. (This is in case I accidentally rm my current work.)
  • I want to move, rename, split or copy files.
  • I'm about to try something which could go really wrong (especially with graphics) and I want a known-good point to revert to.

My commit messages leave a great deal to be desired, though, and I'd love to know how to make these more useful.

Revision control makes my code cleaner. I still tend to initially comment stuff out but every now and again I go through and delete to reduce clutter. I know the information is in the repo so I don't really need to put up with the mess.

Branching and tagging are starting to change my workflow but I have probably not yet figured out how to maximise their usefulness.

One of my projects takes a really long time to commit or update and that is quite annoying. (It is worse on my laptop for some reason.)

I have been greatly relieved to discover how easy it is to go back and reinstate earlier versions of bits of a document when I realise that I really ought not to have changed X to Y because Y is clearly more misguided than X!

I'm not sure this is a very helpful answer...

  • I think these are all good reasons, especially to commit all work before sending it to someone or e.g. submitting a paper: then you can optionally tag it and recover the exact version you sent. – Jaap Eldering Sep 14 '14 at 20:39
  • @eldering Yes. I've started tagging submissions. For sending to people as drafts, I tend to just make a note in the commit message since the version is on the PDF I send them in that case. (Obviously this only goes for people reading it as a draft/work-in-progress.) – cfr Sep 14 '14 at 22:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.