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

101–110 of 210 posts

Re: Stacked Diffs with git rebase —onto

#101

Post by WorldMaker »

Xophmeister wrote: post #54
the_gipsy wrote: post #3

I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.

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, `--update-refs` makes it easier to update all of them if you start from the outermost branch.)

Re: Stacked Diffs with git rebase —onto

#102

Post by SideburnsOfDoom »

happytoexplain wrote: post #83
glenjamin wrote: post #72

Earlier quoted context omitted.

I’m amazed that this comment is so low down Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP Absolutely everything gets easier when you lower your work in progress.

This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.

> It's very normal to be working on a feature that depends on a not-yet-merged feature.

Oh sure, many bad ideas and poor practises such as that one are quite "normal". It's not a recommendation.

Re: Stacked Diffs with git rebase —onto

#103

Post by tcoff91 »

jhhh wrote: post #95
tcoff91 wrote: post #88

Earlier quoted context omitted.

But with jj there are better workflows that aren’t really doable with git.

Last time I saw this claimed (maybe from steve's tutorial?) it was just autosquash. Do you have another example?

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 do NOT understand how much better it is to not have to resolve conflicts immediately when rebasing and being able to come back and resolve them whenever you want. It cannot be overstated how much better this is than git.

Also, anonymous branches are SOOOO much better than git stashes.

Re: Stacked Diffs with git rebase —onto

#104

Post by ptx »

WorldMaker wrote: post #99
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…

That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started. One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too. At the very least, you can do your han…

I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.

But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".

Re: Stacked Diffs with git rebase —onto

#105

Post by taejavu »

IshKebab wrote: post #73

Eh I just use `git rebase -i` and delete the commits I don't want. Much easier to think about. But the real problem with this workflow is that neither Github nor Gitlab support it at all. Not even Forgejo does. Which blows my mind because is such an obvious way to work. As far as I know only Tangled actually supports it, but unfortunately Tangled is tangled up in its own weird federation ideas. There's no way to priv…

I’m not sure what you mean, I stack PRs all the time with GitHub - select the earlier branch as the merge target instead of the main branch.

Re: Stacked Diffs with git rebase —onto

#106

Post by WorldMaker »

ptx wrote: post #104
WorldMaker wrote: post #99

Earlier quoted context omitted.

That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started. One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too. At the very least, you can do your han…

I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit. But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningfu…

My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.

Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)

Re: Stacked Diffs with git rebase —onto

#107

Post by ptx »

WorldMaker wrote: post #106
ptx wrote: post #104

Earlier quoted context omitted.

I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit. But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningfu…

My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time. Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces onl…

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 to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.

It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".

Re: Stacked Diffs with git rebase —onto

#108

Post by Valodim »

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…

I was in the same position. Then I tried jj. I knew within the day that I wouldn't switch back.

Re: Stacked Diffs with git rebase —onto

#109

Post by WorldMaker »

ptx wrote: post #107
WorldMaker wrote: post #106

Earlier quoted context omitted.

My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time. Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces onl…

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.

Re: Stacked Diffs with git rebase —onto

#110

Post by 1718627440 »

tcoff91 wrote: post #103
jhhh wrote: post #95

Earlier quoted context omitted.

Last time I saw this claimed (maybe from steve's tutorial?) it was just autosquash. Do you have another example?

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.

Post reply on HN