51–60 of 233 posts
That's really interesting. Having to manage stashes is annoying.
1) What are the advantages of using native backend as compared to git? 2) Are there any potential issues one has to be aware of when using jj contributing to git repository? I remember when I was the only team member using git-svn plugin my coworkers were confused when I svn-committed many commits at once with some of them breaking the time order of the svn history (as git-svn commits in svn were recorded with git ti…
Very few. The disadvantages are generally much larger. The main advantage is that you won't run into a (harmless) race that happens once in a while with the git backend (https://github.com/martinvonz/jj/issues/27). Disadvantages include not being able to interact with git repo and performance problems (both size and speed).
I should add a note about this to the README.
The backend exists mostly to prove that it's possible and to make sure that the backend API doesn't become tied to Git.
> 2) Are there any potential issues one has to be aware of when using jj contributing to git repository?
The main one is that you should avoid pushing commits with conflicts. It won't corrupt the remote repo, but git clients won't know what to do with the conflicted files. The fix is to fix the conflict and force push the conflict-free commit.
I'll file a bug to prevent pushing commits with conflicts.
This seems really nice. git got the data model really right, and the user space really wrong. The data model is more important than the user space. This is the first project I've seen which appears to understand and respect /how/ and /why/ the git data model is so elegant.
For those interested in the different perspectives on how to weigh those priorities, I recommend starting here:
I’m curious to know if this has any similarities with fossil ( https://fossil-scm.org/ ). If it does, it would be nice to see that in the documentation.
" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.
Right now
error[E0554]: `#![feature]` may not be used on the stable release channel
--> lib/src/lib.rs:15:12
|" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
Earlier quoted context omitted.
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
What is the advantage of using worktrees over another checkout in another folder?