Comment by zdgeier
4 years ago
Haha appreciate you taking a look. One use case is to prevent merge conflicts, especially when working on a fast-moving project. Merge conflicts generally occur when you make changes on some old code. Jamsync constantly "rebases" your changes on top of new changes so that your code will always be up to date. Obviously some merge conflicts will still occur but much less so in this approach.
> ...on a fast-moving project.
Very interesting.
Multiple times I've been on teams with spray and pray type developers who commit more frequently. Begetting more chaos and rework, of course. But great for apparent "velocity".
Whereas I tend to work slow and deliberate. Doing old timey stuff like unit tests and verifying my code works before committing. Which then puts the onus of resolving merge conflicts onto me. Which then delays my commits. Which means more even more merge conflicts.
A vicious cycle.
It'd be cool if better tooling, such as jamsync, helped mitigate the penalty for doing good work.
More details about the problems I'm trying to solve are on the homepage if you're curious.
How is that different from running `git pull` or the equivalent faster, maybe on a timer?
This could work for the pulling side but really what jamsync does is both pull and push. Having changes that are always present in the remote means that merge conflicts are less likely. If you were to do this with Git, you would also have to automate the git add, commit, and push steps which would ruin the log in addition to being pretty slow.
That sounds like one developer being in the middle of an edit breaks the project immediately for everyone?