4 ms·

Autosaved: A Go utility for autosaving progress in Git projects

44 points by nikochiko 5y ago

gouggoug 5y ago
I have nothing against this tool in particular; I am however quite worried that this kind of tool will just enable this already terrible habit that a lot of developers have; which is to mindlessly commit changes and then make PRs full of "asdf", "typo", "fixing comma", "blaaaaa". With this tool, these developers won't even have to waste time typing `git commit` and will happily submit PRs as a bunch of "autosaved" commits. This further reduces git to being just a means to an end: the end being able to just mindlessly push code over a fence and see it magically deployed.
- kazinator 5y ago
  It doesn't, because these backups go to a parallel branch. What it's doing though is polluting your git repo with these commits. A daemon which backs up projects that you're working on, so you have fine-grained snapshots to go back to if you screw up is a good idea. Backing up only files known to git, and backing them up into git, is not such a hot idea.
- deleted 5y ago
  [deleted]
- herval 5y ago
  > This further reduces git to being just a means to an end: the end being able to just mindlessly push code over a fence and see it magically deployed. I fail to see how that would be a bad thing?
  - gouggoug 5y ago
    git's purpose is to track change and provide meaningful insights into code written by many different people. The fact that you can use it to deploy is just a side effect and using git solely because it makes it easier to deploy changes is thoroughly missing the point.
    - ferdowsi 5y ago
      Every large organization I've been in performs a squash merge with the PR description as merge commit summary, because intermediary commits are always noise like "fix tests" and "didn't actually fix, do it now". That's a story not worth reading.
    - notdemo88 5y ago
    - gjs278 5y ago
Narretz 5y ago
I swear a similar tool was discussed here a just a few days ago, but I can't find it.
- caseyohara 5y ago
  I immediately thought of that post last week too. Found it: Dura is a background process that watches your Git repositories | https://news.ycombinator.com/item?id=29784238 https://news.ycombinator.com/item?id=29784238
cerved 5y ago
how does this compare to using stash?
- 0xdeadb00f 5y ago
  I'm also confused, since you can roll back to a certain commit if you wanted. Although, that depends on you actually having committed changes.
  - cerved 5y ago
    not so much confused as curious stashing involves unstaging and restaging, which isn't free but it also keeps track of the index, which I imagine this doesn't?
rjmill 5y ago
I've been in the market for a tool like this. If this or dura used inotify events instead of polling, I'd use it in a heartbeat. [long story about a weird real-world use case for this kind of tool] For "reasons" I work in a cloud-based container that has persistent storage mounted via NFS. That's where we're supposed to keep our git repos, since that's the only place where we get persistence. The codebase is huge though, and "git status" takes upwards of 10 seconds on the NFS. I started keeping my .git directory in the NFS and having the actual files on the "local" container filesystem. That makes git fast again. But it means I lose any untracked changes when my container dies. I'm currently using an insane solution that I want to get rid. I'm using lsyncd to rsync my files back to the NFS as I work. But recovery is still slow as death, so I pointed lsyncd to an "rsync" script that runs rsync and then does a git diff (with hacky nonsense to include untracked files in the diff.) When I lose my container, I can then apply that diff after rebuilding the repo files. It's insane but it works really well. At any rate, this is a cool project. I wish I could go back in time and tell myself to use this instead of rolling my own ungodly hackfest of a solution.
- maartenh 5y ago
  I have a few questions about this! 1. Why? To control where the source code is stored? Restricted access to API's or data? Special compute (e.g. GPU/FPGA's) needs? 2. You have managed to make this workable for yourself. How do your colleagues deal with this? 3. Could you share what kind of industry your employer is in?
  - rjmill 5y ago
    Sure thing! I didn't want to make my already-long story even longer, but I'm happy to elaborate. 1. Special compute needs (GPU) 2. Many have the specific GPU in their work-issued laptop. I transferred to the team recently, so I haven't gotten mine yet. A few others use the same setup though. They use "git status -uno" which drops the check for untracked files to speed things up. From there, they just deal with the slowness. It's not terrible as long as you aren't obsessive about committing frequently (which I am.) That's why I'm interested in this kind of tool though. I can't recommend my current workflow because of how messy the hack is. If I can use a real tool, the recommendation becomes easier. 3. Semiconductors.

44 points by nikochiko 5y ago

I have nothing against this tool in particular; I am however quite worried that this kind of tool will just enable this already terrible habit that a lot of developers have; which is to mindlessly commit changes and then make PRs full of "asdf", "typo", "fixing comma", "blaaaaa". With this tool, these developers won't even have to waste time typing `git commit` and will happily submit PRs as a bunch of "autosaved" commits. This further reduces git to being just a means to an end: the end being able to just mindlessly push code over a fence and see it magically deployed.

kazinator 5y ago
It doesn't, because these backups go to a parallel branch. What it's doing though is polluting your git repo with these commits. A daemon which backs up projects that you're working on, so you have fine-grained snapshots to go back to if you screw up is a good idea. Backing up only files known to git, and backing them up into git, is not such a hot idea.
deleted 5y ago
[deleted]
herval 5y ago
> This further reduces git to being just a means to an end: the end being able to just mindlessly push code over a fence and see it magically deployed. I fail to see how that would be a bad thing?
- gouggoug 5y ago
  git's purpose is to track change and provide meaningful insights into code written by many different people. The fact that you can use it to deploy is just a side effect and using git solely because it makes it easier to deploy changes is thoroughly missing the point.
  - ferdowsi 5y ago
    Every large organization I've been in performs a squash merge with the PR description as merge commit summary, because intermediary commits are always noise like "fix tests" and "didn't actually fix, do it now". That's a story not worth reading.
  - notdemo88 5y ago
  - gjs278 5y ago

Narretz 5y ago

I swear a similar tool was discussed here a just a few days ago, but I can't find it.

caseyohara 5y ago
I immediately thought of that post last week too. Found it: Dura is a background process that watches your Git repositories | https://news.ycombinator.com/item?id=29784238 https://news.ycombinator.com/item?id=29784238

cerved 5y ago

how does this compare to using stash?

0xdeadb00f 5y ago
I'm also confused, since you can roll back to a certain commit if you wanted. Although, that depends on you actually having committed changes.
- cerved 5y ago
  not so much confused as curious stashing involves unstaging and restaging, which isn't free but it also keeps track of the index, which I imagine this doesn't?

rjmill 5y ago

I've been in the market for a tool like this. If this or dura used inotify events instead of polling, I'd use it in a heartbeat. [long story about a weird real-world use case for this kind of tool] For "reasons" I work in a cloud-based container that has persistent storage mounted via NFS. That's where we're supposed to keep our git repos, since that's the only place where we get persistence. The codebase is huge though, and "git status" takes upwards of 10 seconds on the NFS. I started keeping my .git directory in the NFS and having the actual files on the "local" container filesystem. That makes git fast again. But it means I lose any untracked changes when my container dies. I'm currently using an insane solution that I want to get rid. I'm using lsyncd to rsync my files back to the NFS as I work. But recovery is still slow as death, so I pointed lsyncd to an "rsync" script that runs rsync and then does a git diff (with hacky nonsense to include untracked files in the diff.) When I lose my container, I can then apply that diff after rebuilding the repo files. It's insane but it works really well. At any rate, this is a cool project. I wish I could go back in time and tell myself to use this instead of rolling my own ungodly hackfest of a solution.

maartenh 5y ago
I have a few questions about this! 1. Why? To control where the source code is stored? Restricted access to API's or data? Special compute (e.g. GPU/FPGA's) needs? 2. You have managed to make this workable for yourself. How do your colleagues deal with this? 3. Could you share what kind of industry your employer is in?
- rjmill 5y ago
  Sure thing! I didn't want to make my already-long story even longer, but I'm happy to elaborate. 1. Special compute needs (GPU) 2. Many have the specific GPU in their work-issued laptop. I transferred to the team recently, so I haven't gotten mine yet. A few others use the same setup though. They use "git status -uno" which drops the check for untracked files to speed things up. From there, they just deal with the slowness. It's not terrible as long as you aren't obsessive about committing frequently (which I am.) That's why I'm interested in this kind of tool though. I can't recommend my current workflow because of how messy the hack is. If I can use a real tool, the recommendation becomes easier. 3. Semiconductors.