Comment by KerrAvon

4 years ago

I don't understand the use case. Very large file support aside, are you saying you've observed people looking at git and say "I wish I could use this like I use a chat server?"

7 comments

KerrAvon

Reply
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.

  • specialist  4 years ago

    > ...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.

  • zdgeier  4 years ago

    More details about the problems I'm trying to solve are on the homepage if you're curious.

  • kccqzy  4 years ago

    How is that different from running `git pull` or the equivalent faster, maybe on a timer?

    • zdgeier  4 years ago

      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.

      1 reply →