Earlier quoted context omitted.
I find Mercurial very difficult to use. I find Git much easier.
It's just because you've been using Git for too long. Mercurial is much easier to use if you're not exposed to Git.
I used Mercurial before I used Git.
Jujutsu – A Git-compatible DVCS that is both simple and powerful
171–180 of 233 posts
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#172Earlier quoted context omitted.
> You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.
True but there's usually a "git diff --staged" in the middle to check what I am committing.
You can do that with “git show HEAD” (and “git commit --amend -p”).
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#173Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…
Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
Have used node.js, I find this, conceptually, much more simple to trace through than search paths.
Of course there are major cons.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#174Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…
Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
This is the default behavior of npm. The most popular package manager on the planet.
It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#175Earlier quoted context omitted.
Surprise limitation: you cannot have two worktrees set to the same branch, or at least that confronted me when I tried it.
If you had two worktrees set to the same branch and made a new commit in one of them (thus changing the commit the branch ref points to), what would happen in the other worktree? Either it wouldn't have the right commit checked out anymore, or git would have to miraculously change what files are checked out in it -- which would likely come as a big surprise to whatever you were doing in that working tree. Ergo, it is…
Git could hide this for you and just make it look like you cloned the repo twice.
What happens if you make a commit in dir1 and dir2 is on the same branch. Absolutely nothing, until you fetch, and worktrees could work the same way. If there is any ambiguity left you could prefix the branch names similar to the remotes origin/master, worktree2/master.
The only sane way to use worktrees today is, like you say, with detached heads. Which well…isn’t that sane for many other reasons.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#176Interesting ideas! I especially like the automatic rebasing and associated ideas. It's a bit strange to see "jj st" will automatically add all files to the "working copy" commit. This means that when I initially create my project, run "npm install" to install 500 MB of dependencies, and then run "jj st" to figure out what to include in my first commit, the command is going to copy all of that into a commit object for…
Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
500 MB may be excessive for git, but it is a good practice to check in your compiler together with your source if you use perforce. It’s just an extreme case of monorepo.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#177jujutsu looks interesting, but one thing that i find missing from git is historical branch tracking. once two branches are merged, git does not tell me which series of commits used to belong to which branch. i can't check out main from two weeks ago if a merge happened in the meantime because that information is lost. i fear to add such a feature additional information would need to be stored in the git repo itself w…
Git has the concept and knowledge of which side a merge came from.
A commit having multiple parents (a merge commit) maintains the order of those parents within the commit. The branch names are famously lost, but by convention you can say that the first parent should always be the main branch.
As with all other git things, the ux for this feature isn’t the best and it’s use varies wildly across tools and organizations.
To view the main branch log only you have to pass arcane -—left-only flags into git log.
Some people don’t know the difference of merging from branch to main vs the other way around, end result looks the same right. One such mistake messes up the history.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#178Earlier quoted context omitted.
> I don't think it has anything to do with the fact that Git is distributed. I think it does since meta-data increases merge complexity, which is probably a headache when dealing with a distributed system. With a centralized system, you are basically creating a lock when you do a rename/copy/etc. which doesn't translate well to distributed systems. With Git as it is currently implemented, you only need to worry about…
> I think it does since meta-data increases merge complexity, which is probably a headache when dealing with a distributed system. I disagree. In Git, merging always happens locally, between two local commits; there is nothing distributed about merging itself. > With a centralized system, you are basically creating a lock when you do a rename/copy/etc. which doesn't translate well to distributed systems. I don't thin…
> Now, that commit operation takes a write lock on the branch – to prevent any other commit for that branch being processed at the same time
In fact on the whole repo, since branches are just subdirectories. (Shows how long it has been since I've actually used Subversion, I'm starting to forget it.)
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#179Earlier quoted context omitted.
Why put 500mb worth of downloadable dependencies in your source tree? This sounds like a terrible thing to do.
This is the default behavior of npm. The most popular package manager on the planet. It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios.
This kind of thing is also pretty much standard for most programming languages today.
Re: Jujutsu – A Git-compatible DVCS that is both simple and powerful
#180Earlier quoted context omitted.
This is the default behavior of npm. The most popular package manager on the planet. It might not be technically the most superior way to do things, but given the widespread use, tooling around it need to be compatible.
It puts those deps in your source tree, sure, but no one advocates committing them to your repository except in few specific scenarios. This kind of thing is also pretty much standard for most programming languages today.
Isn’t parent explicitly trying to avoid committing the node_modules?