151–160 of 210 posts
Earlier quoted context omitted.
I'm guilty lol. I wrote a helper to do rebase chains like this
update-refs works only in a narrow case when every branch starts form the tip of a previous. Your helper might still be useful if it properly "replants" whole tree keeping its structure.
Every time I see one of these nifty git tricks or workarounds I find myself wondering, “why not just use jj?” You get a nicer, significantly simpler interface. You don’t need any tricks. You don’t have to google how to work yourself out of a bad state, ever. And you get near-perfect git compatibility (ie you can use jj on a shared git repo, doing all the same things, and your teammates won’t know the difference). I’v…
“why not just use jj?” The most common reason is that the git user has no idea it exists. I am in this bucket alongside 99% of git users. There are an assortment of other potential reasons: - It is a new tool that hasn't been battle tested as much as git has, which can decrease confidence. - Git has inertia. People have learned it, it takes less effort to add a new git skill to your repertoire than learn a new tool f…
jj is sort of a bag of git tricks for me that I use when needed. It's no different than some things being easier with the git CLI vs others being easier in Sublime. I'll be at a stage where my committing/branching/rearranging wants are something that jj nails perfectly, and I do those there. As far at the other tools are concerned, I just did a bunch of sophisticated git operations.
The "colocated with git" capability of jj is probably it's most amazing feature tbh, and is key to any sort of adoption.
Earlier quoted context omitted.
I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Most rebases are to get ahead of upstream work, and I can't rewrite that. The rest are to rewrite commits that I made, and I collapse all those commits down periodically anyway. In the rare case I might be able to use this…
> I don't think I would want to rewrite all branches based on rewriting one of the ancestors of those branches. This only makes sense for local branches, and I just never have such a set of branches. Yes, it's only meant for local branches. When I used Git, I had a script for rebasing dependent branches. I remember that a coworker had written a similar script. I think jj is generally more useful for people like me wh…
Earlier quoted context omitted.
>Like what? Perhaps we can improve it. I'm sure it is stuff that makes sense to a jj user. Since I have not read the manual, it is nonsense to me. I'm just drawing attention to the fact it's a different set of non-obvious terminology and features as compared to git. I'm sure anyone who read the manual for either tool could figure it out. The trouble with git is that people don't read the manual, and hardly try to do…
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q . Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler. > I don't think making another tool entirely is the right solut…
I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. That was a good talk. I would certainly expect someone like that to have a lot of interest and expertise in git. But it seem to me that there is also a potential commercial angle to making a new/alternative VCS.
I looked at the mailing list entry you linked to about `git history` commands and thought to myself, it sounds all wrong and redundant. `git history` sounds like too broad of a name for one thing. I'd want to have it be `git ` instead. All the operations listed can be done with rebase:
- `git history drop`: Instead, rebase interactively and drop one or more commits.
- `git history reorder`: Interactively rebasing makes this work already.
- `git history split`: Insert a pause in the interactive rebase. Do a soft reset or something to the previous commit, and use `git restore` to unstage the changes (there might be a more efficient way to do this in one step, but idk). Then, do `git add -p` to add what you want, commit, as many times as you want to split the patch. Then continue the rebase.
- `git history reword`: There is a reword option in interactive rebase mode, and also a fixup-like option to do it as well if you want to postpone the rebase.
- `git history squash`: Rebase can do this now in multiple ways.
Rebasing is not that hard. It is the Swiss Army knife of VCS tools. Once you realize that you can just break in the middle of a rebase and do nearly anything (except start another rebase), the world is your oyster. We don't need to spam people with many more single-purpose tools. We need people to understand why the way things are is actually pretty damn good already, if only they read the manual.
Earlier quoted context omitted.
This seems to be a common misconception, that many jj users don't understand Git. Most jj users I know were pretty good at Git as far as I can tell. Perhaps you'll find this recent video where Scott Chacon talks about Jujutsu interesting: https://www.youtube.com/watch?v=PsiXflgIC8Q . Scott is a GitHub cofounder, author of Pro Git, and now runs GitButler. > I don't think making another tool entirely is the right solut…
Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though. I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. T…
Earlier quoted context omitted.
Yeah, I do this too: The `--onto` solution feels a bit too magical at times and an interactive rebase is pretty clear about what's happening.
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged. (Plus, of course, if you have multiple branches stacked,…
Earlier quoted context omitted.
Well, if I had to guess, many current jj users are git veterans who are tired of watching git noobs struggle. The other segment is the git noobs themselves, who never really bothered to learn git and have a deep aversion to reading the manual and doing basic experiments. Just a guess, though. I think I saw Scott Chacon talk about his git config file and advanced git features. Whoever it was, it mentioned GitButler. T…
The author of `git history` is a GitLab employee and prolific Git contributor. I think he knows how `git rebase` works.
People should really try to work on trunk.
This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.
I agree it seems error prone. I'm not sure if I'm misunderstanding something, but I use `git cherry-pick` when I know I need to move commits around that might have conflicts. The problem with rebase can be that the user doesn't fully understand all the options being applied and end up with a "bad" merge. I don't usually want to rewrite history. I just want the target branch with all my commits on top (I usually squas…
> and end up with a "bad" merge.
They end up with exactly the same merge when using cherry-pick directly?
> I don't usually want to rewrite history. I just want the target branch with all my commits on top
That's ... what rewriting history is?
Earlier quoted context omitted.
> Also, anonymous branches are SOOOO much better than git stashes. You can do anonymous branches in Git as well. I use both for different use cases.
The UX around anonymous branches in git is not nearly as good as jj though. Also git has no equivalent to the operation log. `jj undo` and `jj op restore` are so sweet.
> Also git has no equivalent to the operation log.
For easy cases it's just git reset @{1}, but sure the oplog is a cool thing. I think it will be just added to git eventually, it can't be that hard.