12 ms·

Y U NO commit??

212 points by esneider 12y ago

asgard1024 12y ago
I think HN would do well with having a single sentence abstract on article submissions, because I have no idea what is this about.
- rcgs 12y ago
  It's a vim plugin that prompts you to commit your changes after saving a file `n` number of times (20 by default).
- deleted 12y ago
  [deleted]
- diggan 12y ago
  Reading the readme tells the purpose of this: > "Set the number of writes without committing before the message is shown" So after N number of writes to a file, it warns you that you haven't committed. But I agree, the title of the submission is kind of non-descriptive.
- colinramsay 12y ago
  I thought it was fairly straightforward - it displays a message to the user if they haven't created a git commit after x number of writes to disk (i.e. saves). This is to try and stop commits from becoming huge I guess.
- mtmail 12y ago
  The VIM plugin shows a funny image when too much time passed since the last git commit. The plugin got created 6 hours ago by the submitter.
  - ygra 12y ago
    From the source I'd say it only displays the message, not an image.
- spacemanmatt 12y ago
  I suspect this gets bumped up more for meme-compliance than novelty. I rather like the SublimeText plugin, gitgutters[1]. But it in any case, I'm a fan of VCS integration in my editor. 1. https://github.com/jisaacks/GitGutter https://github.com/jisaacks/GitGutter
  - ayrx 12y ago
    GitGutter is available for vim as well.
fredley 12y ago
It took me a while, but I think this is a tool to automatically remind you to commit your work after making [20] writes. It is a plugin for vim.
- cshimmin 12y ago
  I thought it was clear enough from just the first sentence after the image: "Set the number of writes without committing before the message is shown". Anyways, this is a cute idea but as someone who compulsive hits save after practically every edit (i.e. after most transitions from insert to normal mode), this wouldn't be very helpful.
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
k-mcgrady 12y ago
Wouldn't this just encourage people who don't want to commit to stop saving regularly and possibly lose work?
- Tehnix 12y ago
  Then they probably shouldn't be running this plugin in the first place. It's more for the people that can occasionally forget to commit, and their commits end up being huge.
  - k-mcgrady 12y ago
    Ah ok. I looked at it more as something you force on your co-workers :)
mmahemoff 12y ago
Nice idea but I don't think I'd want to use it for risk of too many false positives. e.g. if I lift a 20+ line function to move it somewhere else in the file, I would guess it will warn I should commit now.
- quarterto 12y ago
  It prompts every 20 writes (i.e. saves), not lines modified.
remon 12y ago
Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each commit should be an isolated unit of work. Also, this floating to the top of HN is a bit of a mystery to me.
- philjackson 12y ago
  You're right. I cringe a bit when I hear people say "I've not committed for a while, I'll do it now". Ok, and if I need to revert any of it, I'll have to do it hunk by hunk?
  - masukomi 12y ago
    committing after some random number of saves or lines seems silly yes. but i see no reason to not commit whenever you come to a stopping point. even if that stopping point is as arbitrary as the time to go home. I've never seen a case where someone would revert hunk by hunk. You can just revert to the last stopping point, if you need to, or as most people do just keep editing the file, hitting undo, editing, hitting undo... etc until you have another stopping point. commit. repeat. when you're all done you clean up the commits with rebase and voilla. life is good.
    - philjackson 12y ago
      I'm talking more about the situation a fellow team member has to revert something that Frank wrote that's dropped production at 3am. Trawling through commits that contain half of two small features because he commits based on home time and coffee breaks in an emergency sounds terrible.
      - klibertp 12y ago
        He will just revert a merge. Because you branch and merge for anything less trivial than one-line comment, right?
  - akerl_ 12y ago
    That's exactly what the idea is here. If you commit very incrementally during development cycles, you're more likely to have a singular commit to revert. Then before you push upstream, you rebase down your commits into full feature chunks.
robmccoll 12y ago
Seems like a pretty useful idea. It would be great to also set thresholds on number of files changed and total number of lines (ignoring whitespace) changed.
jbert 12y ago
Slightly related, I get a lot of value out of a bash prompt which tells me: - if my git repo is dirty (uncommitted changes) - which branch it is on - if (and how many) changes I have stashed It's not originally my work but I find it massively useful, since it avoids the "committed but not pushed" failure mode, the "on wrong branch" failure more and the "stashed and forgotten about" failure mode. I know that regularly running git status would work, but this is a useful visual reminder for me.
- chris_wot 12y ago
  Link to bashism that allows this?
  - zorbo 12y ago
    http://lmgtfy.com/?q=git+bash+integration http://lmgtfy.com/?q=git+bash+integration
    - chris_wot 12y ago
      http://lmgtfy.com/?q=noone+likes+a+smartarse http://lmgtfy.com/?q=noone+likes+a+smartarse
      - deleted 12y ago
        [deleted]
  - jbert 12y ago
    I use this http://pastebin.com/HDJvD3GC http://pastebin.com/HDJvD3GC which as I say isn't my own work (although I've tweaked it a bit). It depends on some git output strings, so is theoretically fragile but in practice has been stable over a few years of git updates.
- ccozan 12y ago
  An actual solution is here : https://coderwall.com/p/fz0e0g https://coderwall.com/p/fz0e0g . Alternatively, look into the /etc/bash_completion.d/git file, you can use many funcs in there. Extend it at will.
brexis 12y ago
Y U NO write this for other editors?
- silverbax88 12y ago
  I would guess (and probably get downvoted for this) that it's because GIT is so widely used, is not well structured and overall group source control is not well understood by developers. If you are exposed to several source control systems, you would avoid GIT, at least until you know what you are doing. But so many people use it and don't understand what they are doing, there are massive numbers of conversations just like this article - often between people who have never used anything other than GIT.
  - zenciadam 12y ago
    It's still better than when everyone just used CVS because that's what everyone was used to.
- sudapl 12y ago
  I've ported it to GitHub's Atom: https://atom.io/packages/yuno-commit https://atom.io/packages/yuno-commit
atmosx 12y ago
I guess professional programmers has this sort of thing already sorted out, but it happens all to often to reach the point where my new feature is working as it should (appears to be stable), and I keep working on yet another addition on the same branch. When I commit, I feel like I should have committed at least 2 or 3 times by now. Happens too often so I setup up this plugin from 20 to 10 and see how it goes! But thanks, the idea is really handy.
- jmelloy 12y ago
  We've adopted the "every feature a branch" idea from git-flow. It feels silly to make a branch that is a 3 line typo fix, but does make it nice and clean to switch between them as your working.
- jerf 12y ago
  Heh, you'd be surprised how often even moderately experienced developers make the same mistake. I've seen months-long chains of "add feature X, it's sorta stable, start adding feature Y, whoops, gotta ship, uh-oh, X isn't stable either, work for three weeks, X is now stable but Y only seems to be, managers now calling feature Z release-critical, start working on Z, gotta ship, uh-oh, Y isn't stable yet..." and so it goes for literally months, always some feature preventing shipping, always some feature that has to be added. Beware that trap. Branches are cheap. Use them.
- zorbo 12y ago
  I have the same "problem". I guess I'm just too focuses on fixing stuff to stop and commit. Thankfully we're alive in a time where we don't have to adapt to our tools anymore, but our tools are adapting to us. git add <file> -p This lets you pick chunks of code from <file> that you'd like to stage for commit. When I feel I'm done coding for a session, I just run a `git diff` in one window, and in the other one pick chunks that contain changes that belong in one commit.
  - atmosx 12y ago
    Oh good to know! I didn't knew that was possible :-) thanks for the hint. I use a cli tool called 'tig' to view difference between commits and not committed changes.
davedx 12y ago
I much prefer our ascii art doge when all tests pass. :)
yitchelle 12y ago
I would typically commit at the end of the day, even if it is into my private repository. So days, I think it as backup, but on other days, I use it to socialise the code. I find that this forces me to take stock of the current state of implementation and put my mind in the right mind frame for the next stage. When pushing it into the main repository, it will be a unit of work.
johncoltrane 12y ago
Commit time is a good time to step back a little and think about what I wrote and why. Organizing hunks of changes into a meaningful package. I usually commit when I'm done with a feature (once or twice a day) or right after fixing a bug (a good dozen times a day).
chris_wot 12y ago
I'm finding that I commit in units of work. Currently, I'm refactoring LibreOffice's SalGraphics class to move the mirroring from this class into an upper layer, but I'm finding it better to do it little by little. Gerrit topic is here: https://gerrit.libreoffice.org/#/q/status:open+project:core+branch:master+topic:salgraphicsmirror,n,z https://gerrit.libreoffice.org/#/q/status:open+project:core+... I'm finding it productive to commit when I have a compilable change. I find it helps me keep track of what's going on.
flowerpot 12y ago
I like the general idea, I sometimes also tend to code too much until committing, however, for me it is more a combination of running tests, amount of code and of course completeness. Plus, I often start hammering ":w" when I am stuck. (which would be miss-interpreted by this tool)
clubhi 12y ago
I have all my code in a dropbox synced in a dropbox folder. Works pretty well in combination with something like Git.
relate 12y ago
I just wanted to point out vim's persistent undo: http://stackoverflow.com/questions/5700389/using-vims-persistent-undo http://stackoverflow.com/questions/5700389/using-vims-persis... Sometimes I forget to commit, and suddenly I'm in the middle of a second feature, with the code in a non-working state. Then it's perfect to just undo back a couple of hours, save, commit, and redo back to where I am. However, It's rather risky though if you're not confident with the undo system, so it's a good idea to save the file to a temporary location first.
- godDLL 12y ago
  Or use `git stash`. Or use `git add -p`.
fmoralesc 12y ago
I tend to write to disk after every edit (a bad habit, I know, but it's pretty ingrained in my muscle memory), so as-is, this would spam me quite a bit. A better criterion for determining when to display the message would be to count the non-empty lines of the diff, and only show it if it passes a threshold. Or: only if the added/removed lines ratio is > 1, or something like that.
- gmantastic 12y ago
  I save after every logical edit too - I think it's a good habit. You never get caught out by network/file-system failures, and can confidently reload from disk to a recent good state if you mess up or change your mind mid-edit. I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction.
  - fmoralesc 12y ago
    I tried to integrate git into this with per-file repos once, but I never really used it much: https://github.com/fmoralesc/vim-autogit https://github.com/fmoralesc/vim-autogit This commits on writes. > I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction. What do you think would be a good set of criteria for what should count as a meaningful unit of work?
    - gmantastic 12y ago
      > What do you think would be a good set of criteria for what should count as a meaningful unit of work? I'd consider a meaningful unit of work to be a bug fixed, or feature implemented, at least to the extent that you have a runnable version of the code again (even if you intend to do further work to implement it better e.g. replacing hard-coding). I'd consider changes short of this as not worth commiting, as this would not be a good starting point for further work (I know it's cheap to branch with Git etc., but it just feels untidy to leave something so part-done).
    - gmantastic 12y ago
loganfsmyth 12y ago
I save pretty compulsively, so this would annoy the crap out of me...
ryanpardieck 12y ago
This thread has included some interesting discussion of how everyone handles the different tasks of a) committing individual units of work, b) saving works-in-progress, c) syncing files, d) backing up files, and e) persistent undo editor features. I thought I'd toss out what my setup is right now on my personal machine, for a bit of reflection/discussion... - I compulsively save to disk after nearly every edit, so I'm a big fan of editors that provide some kind of persistent undo functionality. Right now I'm using live-archive inside the Atom editor, and it is wonderful. I hit cmd-shift-y and it pops the current buffer open in a live-archive interface that includes VCR-like with rewind/fast-forward buttons, etc. It leaves me feeling quite free to mess with code a little more dangerously that I would otherwise. Whereas before I might briefly comment out a line while I try something out, now I'll just delete it and hack away. Anything that was there is just a cmd-shift-y away. live-archive is actually maybe the foremost reason I'm still using Atom. I'll probably switch away from it eventually, but I'm grown to like the customized little hole I've built for myself, inside that particular editor. I might try out a JetBrains IDE next, sometime ... - I don't do a lot of work-in-progress saving. Maybe I should be better about this? I'm not a fan of git histories that read like "went to lunch," "stuck, think on this--" etc. Even when I'm the only one that's going to be seeing them. I keep a gitignored text file where I tend to scribble down notes like this, but maybe I should play around with WIP commits. - For syncing I have an hourly cron job that does a rsync -av --delete-after for my important directories to several different locations. This is mostly meant as a true sync and not backup, but I do find myself using it as a way to lose no more than an hour's work at a time. I might change this to running every 30 or 20 minutes since it doesn't seem to tax the machine too much. - For backup I have crashplan backing everything up to a local external drive and then their cloud service too. I haven't put a terrible amount of thought into this. It only runs when I sleep. I want to play around with using arq and amazon glacier eventually. For git I just do small unit-of-work commits for myself, and then cleaning up when necessary.

212 points by esneider 12y ago

I think HN would do well with having a single sentence abstract on article submissions, because I have no idea what is this about.

rcgs 12y ago
It's a vim plugin that prompts you to commit your changes after saving a file `n` number of times (20 by default).
deleted 12y ago
[deleted]
diggan 12y ago
Reading the readme tells the purpose of this: > "Set the number of writes without committing before the message is shown" So after N number of writes to a file, it warns you that you haven't committed. But I agree, the title of the submission is kind of non-descriptive.
colinramsay 12y ago
I thought it was fairly straightforward - it displays a message to the user if they haven't created a git commit after x number of writes to disk (i.e. saves). This is to try and stop commits from becoming huge I guess.
mtmail 12y ago
The VIM plugin shows a funny image when too much time passed since the last git commit. The plugin got created 6 hours ago by the submitter.
- ygra 12y ago
  From the source I'd say it only displays the message, not an image.
spacemanmatt 12y ago
I suspect this gets bumped up more for meme-compliance than novelty. I rather like the SublimeText plugin, gitgutters[1]. But it in any case, I'm a fan of VCS integration in my editor. 1. https://github.com/jisaacks/GitGutter https://github.com/jisaacks/GitGutter
- ayrx 12y ago
  GitGutter is available for vim as well.

fredley 12y ago

It took me a while, but I think this is a tool to automatically remind you to commit your work after making [20] writes. It is a plugin for vim.

cshimmin 12y ago
I thought it was clear enough from just the first sentence after the image: "Set the number of writes without committing before the message is shown". Anyways, this is a cute idea but as someone who compulsive hits save after practically every edit (i.e. after most transitions from insert to normal mode), this wouldn't be very helpful.
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]

k-mcgrady 12y ago

Wouldn't this just encourage people who don't want to commit to stop saving regularly and possibly lose work?

Tehnix 12y ago
Then they probably shouldn't be running this plugin in the first place. It's more for the people that can occasionally forget to commit, and their commits end up being huge.
- k-mcgrady 12y ago
  Ah ok. I looked at it more as something you force on your co-workers :)

mmahemoff 12y ago

Nice idea but I don't think I'd want to use it for risk of too many false positives. e.g. if I lift a 20+ line function to move it somewhere else in the file, I would guess it will warn I should commit now.

quarterto 12y ago
It prompts every 20 writes (i.e. saves), not lines modified.

remon 12y ago

Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each commit should be an isolated unit of work. Also, this floating to the top of HN is a bit of a mystery to me.

philjackson 12y ago
You're right. I cringe a bit when I hear people say "I've not committed for a while, I'll do it now". Ok, and if I need to revert any of it, I'll have to do it hunk by hunk?
- masukomi 12y ago
  committing after some random number of saves or lines seems silly yes. but i see no reason to not commit whenever you come to a stopping point. even if that stopping point is as arbitrary as the time to go home. I've never seen a case where someone would revert hunk by hunk. You can just revert to the last stopping point, if you need to, or as most people do just keep editing the file, hitting undo, editing, hitting undo... etc until you have another stopping point. commit. repeat. when you're all done you clean up the commits with rebase and voilla. life is good.
  - philjackson 12y ago
    I'm talking more about the situation a fellow team member has to revert something that Frank wrote that's dropped production at 3am. Trawling through commits that contain half of two small features because he commits based on home time and coffee breaks in an emergency sounds terrible.
    - klibertp 12y ago
      He will just revert a merge. Because you branch and merge for anything less trivial than one-line comment, right?
- akerl_ 12y ago
  That's exactly what the idea is here. If you commit very incrementally during development cycles, you're more likely to have a singular commit to revert. Then before you push upstream, you rebase down your commits into full feature chunks.

robmccoll 12y ago

Seems like a pretty useful idea. It would be great to also set thresholds on number of files changed and total number of lines (ignoring whitespace) changed.

jbert 12y ago

Slightly related, I get a lot of value out of a bash prompt which tells me: - if my git repo is dirty (uncommitted changes) - which branch it is on - if (and how many) changes I have stashed It's not originally my work but I find it massively useful, since it avoids the "committed but not pushed" failure mode, the "on wrong branch" failure more and the "stashed and forgotten about" failure mode. I know that regularly running git status would work, but this is a useful visual reminder for me.

chris_wot 12y ago
Link to bashism that allows this?
- zorbo 12y ago
  http://lmgtfy.com/?q=git+bash+integration http://lmgtfy.com/?q=git+bash+integration
  - chris_wot 12y ago
    http://lmgtfy.com/?q=noone+likes+a+smartarse http://lmgtfy.com/?q=noone+likes+a+smartarse
    - deleted 12y ago
      [deleted]
- jbert 12y ago
  I use this http://pastebin.com/HDJvD3GC http://pastebin.com/HDJvD3GC which as I say isn't my own work (although I've tweaked it a bit). It depends on some git output strings, so is theoretically fragile but in practice has been stable over a few years of git updates.
ccozan 12y ago
An actual solution is here : https://coderwall.com/p/fz0e0g https://coderwall.com/p/fz0e0g . Alternatively, look into the /etc/bash_completion.d/git file, you can use many funcs in there. Extend it at will.

brexis 12y ago

Y U NO write this for other editors?

silverbax88 12y ago
I would guess (and probably get downvoted for this) that it's because GIT is so widely used, is not well structured and overall group source control is not well understood by developers. If you are exposed to several source control systems, you would avoid GIT, at least until you know what you are doing. But so many people use it and don't understand what they are doing, there are massive numbers of conversations just like this article - often between people who have never used anything other than GIT.
- zenciadam 12y ago
  It's still better than when everyone just used CVS because that's what everyone was used to.
sudapl 12y ago
I've ported it to GitHub's Atom: https://atom.io/packages/yuno-commit https://atom.io/packages/yuno-commit

atmosx 12y ago

I guess professional programmers has this sort of thing already sorted out, but it happens all to often to reach the point where my new feature is working as it should (appears to be stable), and I keep working on yet another addition on the same branch. When I commit, I feel like I should have committed at least 2 or 3 times by now. Happens too often so I setup up this plugin from 20 to 10 and see how it goes! But thanks, the idea is really handy.

jmelloy 12y ago
We've adopted the "every feature a branch" idea from git-flow. It feels silly to make a branch that is a 3 line typo fix, but does make it nice and clean to switch between them as your working.
jerf 12y ago
Heh, you'd be surprised how often even moderately experienced developers make the same mistake. I've seen months-long chains of "add feature X, it's sorta stable, start adding feature Y, whoops, gotta ship, uh-oh, X isn't stable either, work for three weeks, X is now stable but Y only seems to be, managers now calling feature Z release-critical, start working on Z, gotta ship, uh-oh, Y isn't stable yet..." and so it goes for literally months, always some feature preventing shipping, always some feature that has to be added. Beware that trap. Branches are cheap. Use them.
zorbo 12y ago
I have the same "problem". I guess I'm just too focuses on fixing stuff to stop and commit. Thankfully we're alive in a time where we don't have to adapt to our tools anymore, but our tools are adapting to us. git add <file> -p This lets you pick chunks of code from <file> that you'd like to stage for commit. When I feel I'm done coding for a session, I just run a `git diff` in one window, and in the other one pick chunks that contain changes that belong in one commit.
- atmosx 12y ago
  Oh good to know! I didn't knew that was possible :-) thanks for the hint. I use a cli tool called 'tig' to view difference between commits and not committed changes.

davedx 12y ago

I much prefer our ascii art doge when all tests pass. :)

yitchelle 12y ago

I would typically commit at the end of the day, even if it is into my private repository. So days, I think it as backup, but on other days, I use it to socialise the code. I find that this forces me to take stock of the current state of implementation and put my mind in the right mind frame for the next stage. When pushing it into the main repository, it will be a unit of work.

johncoltrane 12y ago

Commit time is a good time to step back a little and think about what I wrote and why. Organizing hunks of changes into a meaningful package. I usually commit when I'm done with a feature (once or twice a day) or right after fixing a bug (a good dozen times a day).

chris_wot 12y ago

I'm finding that I commit in units of work. Currently, I'm refactoring LibreOffice's SalGraphics class to move the mirroring from this class into an upper layer, but I'm finding it better to do it little by little. Gerrit topic is here: https://gerrit.libreoffice.org/#/q/status:open+project:core+branch:master+topic:salgraphicsmirror,n,z https://gerrit.libreoffice.org/#/q/status:open+project:core+... I'm finding it productive to commit when I have a compilable change. I find it helps me keep track of what's going on.

flowerpot 12y ago

I like the general idea, I sometimes also tend to code too much until committing, however, for me it is more a combination of running tests, amount of code and of course completeness. Plus, I often start hammering ":w" when I am stuck. (which would be miss-interpreted by this tool)

clubhi 12y ago

I have all my code in a dropbox synced in a dropbox folder. Works pretty well in combination with something like Git.

relate 12y ago

I just wanted to point out vim's persistent undo: http://stackoverflow.com/questions/5700389/using-vims-persistent-undo http://stackoverflow.com/questions/5700389/using-vims-persis... Sometimes I forget to commit, and suddenly I'm in the middle of a second feature, with the code in a non-working state. Then it's perfect to just undo back a couple of hours, save, commit, and redo back to where I am. However, It's rather risky though if you're not confident with the undo system, so it's a good idea to save the file to a temporary location first.

godDLL 12y ago
Or use `git stash`. Or use `git add -p`.

fmoralesc 12y ago

I tend to write to disk after every edit (a bad habit, I know, but it's pretty ingrained in my muscle memory), so as-is, this would spam me quite a bit. A better criterion for determining when to display the message would be to count the non-empty lines of the diff, and only show it if it passes a threshold. Or: only if the added/removed lines ratio is > 1, or something like that.

gmantastic 12y ago
I save after every logical edit too - I think it's a good habit. You never get caught out by network/file-system failures, and can confidently reload from disk to a recent good state if you mess up or change your mind mid-edit. I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction.
- fmoralesc 12y ago
  I tried to integrate git into this with per-file repos once, but I never really used it much: https://github.com/fmoralesc/vim-autogit https://github.com/fmoralesc/vim-autogit This commits on writes. > I think commiting should be done for a more meaningful unit of work than a single edit, something logically 'complete' akin to a transaction. What do you think would be a good set of criteria for what should count as a meaningful unit of work?
  - gmantastic 12y ago
    > What do you think would be a good set of criteria for what should count as a meaningful unit of work? I'd consider a meaningful unit of work to be a bug fixed, or feature implemented, at least to the extent that you have a runnable version of the code again (even if you intend to do further work to implement it better e.g. replacing hard-coding). I'd consider changes short of this as not worth commiting, as this would not be a good starting point for further work (I know it's cheap to branch with Git etc., but it just feels untidy to leave something so part-done).
  - gmantastic 12y ago

loganfsmyth 12y ago

I save pretty compulsively, so this would annoy the crap out of me...

ryanpardieck 12y ago

This thread has included some interesting discussion of how everyone handles the different tasks of a) committing individual units of work, b) saving works-in-progress, c) syncing files, d) backing up files, and e) persistent undo editor features. I thought I'd toss out what my setup is right now on my personal machine, for a bit of reflection/discussion... - I compulsively save to disk after nearly every edit, so I'm a big fan of editors that provide some kind of persistent undo functionality. Right now I'm using live-archive inside the Atom editor, and it is wonderful. I hit cmd-shift-y and it pops the current buffer open in a live-archive interface that includes VCR-like with rewind/fast-forward buttons, etc. It leaves me feeling quite free to mess with code a little more dangerously that I would otherwise. Whereas before I might briefly comment out a line while I try something out, now I'll just delete it and hack away. Anything that was there is just a cmd-shift-y away. live-archive is actually maybe the foremost reason I'm still using Atom. I'll probably switch away from it eventually, but I'm grown to like the customized little hole I've built for myself, inside that particular editor. I might try out a JetBrains IDE next, sometime ... - I don't do a lot of work-in-progress saving. Maybe I should be better about this? I'm not a fan of git histories that read like "went to lunch," "stuck, think on this--" etc. Even when I'm the only one that's going to be seeing them. I keep a gitignored text file where I tend to scribble down notes like this, but maybe I should play around with WIP commits. - For syncing I have an hourly cron job that does a rsync -av --delete-after for my important directories to several different locations. This is mostly meant as a true sync and not backup, but I do find myself using it as a way to lose no more than an hour's work at a time. I might change this to running every 30 or 20 minutes since it doesn't seem to tax the machine too much. - For backup I have crashplan backing everything up to a local external drive and then their cloud service too. I haven't put a terrible amount of thought into this. It only runs when I sleep. I want to play around with using arq and amazon glacier eventually. For git I just do small unit-of-work commits for myself, and then cleaning up when necessary.