3 ms·

I'm still figuring out semantics, but currently a "commit" is made every time you make a change to a file which is synced to the remote. Every time you run `jam

I'm still figuring out semantics, but currently a "commit" is made every time you make a change to a file which is synced to the remote. Every time you run `jam`, you push a commit. Or if you leave `jam` running, commits will be made each time you save. 3-way merging will be possible in the future, but will be a little different than most VCS since there is no history stored locally.

jeremyjh 4y ago
So how do you communicate with other developers the intention of a commit or set of commits, like you would with commit messages in git? How do you rewrite/cleanup history?
- zdgeier 4y ago
  This is still in-development but my plan is to essentially have "branches" which are merged and create a single "commit" on the main branch. You'll have the option to add information to a branch and a merge message if you would like, but it won't be required. I don't have any approaches on rewriting/cleaning up history right now since I think managing code history is pretty low-value for most teams. In my experience, it's far better to add another commit than it is to try to change history. Would be curious to know your thoughts though!
  - jacobsenscott 4y ago
    This sounds great. Your VCS should fade into the background, rather than be front and center like git. Nobody should be breaking their flow, staging, committing, pushing as an ersatz backup, and then going back to coding. Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding. However I can see where a sort of "checkpoint" feature before performing a "hold my beer" change makes sense. A commit in some sense. `jam checkpoint` ... code ... `jam revert` You should just be coding, and when the thing your are coding is done just do a single "squash merge (in git speak)" to the main branch.
    - fsckboy 4y ago
      > This sounds great. Your VCS should fade into the background, rather than be front and center like git...Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding. you're being too hard on git. large teams sharing code in previous SCCS rcs's (haha) would frequently encounter locks and not be able to "just code" but would need to negotiate with teammates or complain to committees. The features of git allow you to "just code" in a group environment, but it moves conflicts to a different link in the chain. The interplay between changes sprinkled across a codebase need to be negotiated in any system, but git generally allows you to "just code" till it makes sense or is convenient to negotiate
      - jacobsenscott 4y ago
        I've been around long enough to know git is so much better than what came before, and I appreciate it. But even so, git yak shaving still consumes more developer time than it should.
        fsckboy 4y ago
        that's fair. I just didn't like seeing git sold down the river for the feature it does better than what was before :) maybe "git with wimpy locks" would be a nice feature. if you're editing files, the center node could keep track of that, and if I go to edit one of those files, I could be told that you've already edited it. I could forge ahead ("break the lock" and you would get notice) or I could ask you. It doesn't resolve all problem between prickly developers with different styles of workflow, but it would increase communication at little cost.

jeremyjh 4y ago

So how do you communicate with other developers the intention of a commit or set of commits, like you would with commit messages in git? How do you rewrite/cleanup history?

zdgeier 4y ago
This is still in-development but my plan is to essentially have "branches" which are merged and create a single "commit" on the main branch. You'll have the option to add information to a branch and a merge message if you would like, but it won't be required. I don't have any approaches on rewriting/cleaning up history right now since I think managing code history is pretty low-value for most teams. In my experience, it's far better to add another commit than it is to try to change history. Would be curious to know your thoughts though!
- jacobsenscott 4y ago
  This sounds great. Your VCS should fade into the background, rather than be front and center like git. Nobody should be breaking their flow, staging, committing, pushing as an ersatz backup, and then going back to coding. Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding. However I can see where a sort of "checkpoint" feature before performing a "hold my beer" change makes sense. A commit in some sense. `jam checkpoint` ... code ... `jam revert` You should just be coding, and when the thing your are coding is done just do a single "squash merge (in git speak)" to the main branch.
  - fsckboy 4y ago
    > This sounds great. Your VCS should fade into the background, rather than be front and center like git...Teams shouldn't be bikeshedding on merge vs rebase, many commits vs one commit, etc. They should just be coding. you're being too hard on git. large teams sharing code in previous SCCS rcs's (haha) would frequently encounter locks and not be able to "just code" but would need to negotiate with teammates or complain to committees. The features of git allow you to "just code" in a group environment, but it moves conflicts to a different link in the chain. The interplay between changes sprinkled across a codebase need to be negotiated in any system, but git generally allows you to "just code" till it makes sense or is convenient to negotiate
    - jacobsenscott 4y ago
      I've been around long enough to know git is so much better than what came before, and I appreciate it. But even so, git yak shaving still consumes more developer time than it should.
      - fsckboy 4y ago
        that's fair. I just didn't like seeing git sold down the river for the feature it does better than what was before :) maybe "git with wimpy locks" would be a nice feature. if you're editing files, the center node could keep track of that, and if I go to edit one of those files, I could be told that you've already edited it. I could forge ahead ("break the lock" and you would get notice) or I could ask you. It doesn't resolve all problem between prickly developers with different styles of workflow, but it would increase communication at little cost.