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.
> 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.
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.
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.
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.
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.
16 comments
[ 2.9 ms ] story [ 42.4 ms ] threadI 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.
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.
I fail to see how that would be a bad thing?
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.
Dura is a background process that watches your Git repositories | https://news.ycombinator.com/item?id=29784238
stashing involves unstaging and restaging, which isn't free
but it also keeps track of the index, which I imagine this doesn't?
[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.
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?
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.