Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stacked Diffs with git rebase —onto

dineshpandiyan.com

Post reply on HN
Print view View original

111–120 of 210 posts

Re: Stacked Diffs with git rebase —onto

#111

Post by 1718627440 »

WorldMaker wrote: post #96
ndr wrote: post #8

Earlier quoted context omitted.

The main issue I kept having when trying to do this with just git is then managing all the branch names to be attached to the right moved commits, so that my stack could be reviewable on github's open PRs. Does jj help with that at all? I've experimented a bit with git-town.com (OSS) and now everyone at $DAYJOB uses graphite.com (SaaS) which does that part very well.

`--update-refs` flag helps a lot in vanilla git. That and `--autosquash` should probably be default flags to `git rebase`. I also don't entirely trust rebase without `-i` (`--interactive`), personally. I hear there is talk about shaking up the out-of-the-box default flags in git 3, and I think rebase should especially get new defaults.

I also use these flag when I have the need to, but I very much don't want them to become the default.

Re: Stacked Diffs with git rebase —onto

#112

Post by 1718627440 »

nopurpose wrote: post #62
onionisafruit wrote: post #60

Earlier quoted context omitted.

Thanks. This is going to be so useful, but it pains me to know I could have been using —update-refs for the last three years. I used to dutifully read release notes for every git release, but stopped at some point. Apparently that point was more than three years ago.

discoverability is a big problem, especially for CLI tools which can't afford to show small hints or "what's new" popups. I myself learned it from someone else, not docs.

Except they do. You can type , search the man page or read the release notes. They just don't force the user to.

Re: Stacked Diffs with git rebase —onto

#113

Post by 1718627440 »

ptx wrote: post #76

What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar". Mercurial's "histedit" command offers two operations to combine the commits: "fo…

You could use "git reset --soft oldest-commit" and then "git commit -C newest-commit".

Re: Stacked Diffs with git rebase —onto

#114

Post by 1718627440 »

WorldMaker wrote: post #109
ptx wrote: post #107

Earlier quoted context omitted.

Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main": $ git checkout feature-1 $ git reset main $ git commit -a -C feature-1@{1} This squashes all the changes and keeps the date and and message of the final commit on the branch. Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond…

Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution. Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.

git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.

Re: Stacked Diffs with git rebase —onto

#115

Post by tcoff91 »

1718627440 wrote: post #110
tcoff91 wrote: post #103

Earlier quoted context omitted.

https://ofcr.se/jujutsu-merge-workflow With `jjui` this strategy takes only a few keystrokes to do operations like adding/removing parents from merge commits. It's so nice to have like 4 parallel PRs in flight and then rebase all of them and all the other experimental branches you have on top onto main in 1 command. Also, I cannot even stress to you how much first-class-conflicts is a game changer. Like seriously you…

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

Re: Stacked Diffs with git rebase —onto

#116

Post by steveklabnik »

mwcz wrote: post #98
swaits wrote: post #37

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…

I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does. jj is harder to adopt for people with a thorough mental model of git, because it's…

Glad you like that I like it!

What I will say is this: there is certainly an adjustment period, and I also totally hear you about how learning internals can be time consuming.

I think you can get a lot of the way there with at least the core concept with something like this, if you'll indulge me:

With git, you build up stuff on your filesystem. You then select which bits go into a diff in your index, and then when you're done, you stamp out a commit.

With jj, you instead start by creating a commit. In this case, it's empty. Then, every time you run a jj command, it does a snapshot, and this produces a new commit. However, because we want to have a stable identifier for a commit, we introduce a new one: the change id. This is basically an alias for the latest commit snapshot that was made. Your git history is just made up of each of these latest commits for each change.

... does that make any sense? Obviously there's more to all of the features than this, but that's sort of the core way that the histories map to each other.

Re: Stacked Diffs with git rebase —onto

#117

Post by stouset »

mwcz wrote: post #98
swaits wrote: post #37

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…

I'm one of the git users you describe who are resistant to jj. jj sounds great, Steve Klabnik's endorsement is very convincing, and I would probably love it, but here's the issue: I've used git for 17 years and have internalized its idiosyncracies sufficiently to practically never run into problems, and help anyone on my team who does. jj is harder to adopt for people with a thorough mental model of git, because it's…

> jj is harder to adopt for people with a thorough mental model of git

No, it really isn’t. I have used git since shortly after it was first released and I’ve written a git implementation.

I switched to jj in one day. And the amount of git arcana I have to keep in working memory is now basically nil. My VCS now works in almost a 1:1 mapping with how my brain wants to interact with my repo rather than having to go through a translation layer.

If you understand what git commands are doing, what jj does is essentially trivial to add to your mental model.

I also get the benefit of being able to use workflows that I always want to use in git but which are an enormous pain in practice. And I get access to wildly powerful new workflows I didn’t even consider because they would be outlandish in git.

Re: Stacked Diffs with git rebase —onto

#118

Post by steveklabnik »

hansvm wrote: post #70
swaits wrote: post #37

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…

> introduces some mental friction in walking away??? I don't think it's just mental friction. Suppose you've learned git well enough that everything you do in it is automatic and fast, and the things which aren't fast by default you've built aliases and tooling for over the years. Yes, starting from ground zero you might want something like jj, but at the current point in your life you're not starting from ground zer…

It really just depends. I was very comfortable with the git cli. It didn't take long to learn jj's, and I'm faster with it now than I ever was with git, simply because a lot of things are easier to do and take less commands.

Re: Stacked Diffs with git rebase —onto

#119

Post by steveklabnik »

yegle wrote: post #92
swaits wrote: post #37

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…

jj does not support git submodules, this precludes even a casual use on my own personal repo.

It just means that you use git commands to update your submodules, jj still works for the rest of the repo just fine.

Re: Stacked Diffs with git rebase —onto

#120

Post by steveklabnik »

IshKebab wrote: post #79
swaits wrote: post #37

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 1. It's very new; I haven't had time to learn it properly yet. 2. It's very new and tooling doesn't support it well, e.g. VSCode. There aren't many GUIs yet. 3. I tried it once co-locating with Git and you definitely can't use both at the same time, even if it can use a `.git` directory. It ended up in a huge mess. I'm definitely in favour of better-than-Git alternatives but I don't think it's r…

Colocating is the default now, and you should be able to use both at the same time, though running git commands that mutate can confuse jj. Ideally you only use read-only git commands.

Both submodules and LFS are things that jj wants to address, but they take time.

Post reply on HN