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

91–100 of 210 posts

Re: Stacked Diffs with git rebase —onto

#91

Post by oscillonoscope »

unshavedyak wrote: post #74
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…

Wish i could remember my issues with jj. I tried it, i wanted to stick with it because i loved the fact that i could reorder commits while deferring the actual conflicts.. but something eventually prevented me from switching. Searching my slack history where i talked about this with a coworker who actually used jj: 1. I had quite a bit of trouble figuring out a workflow for branches. Since my companies unit of work i…

I more or less use the method described [here](https://steveklabnik.github.io/jujutsu-tutorial/advanced/sim...) for branches. One thing I do change is that I set the bookmark to an empty commit that serves as the head of each branch. When I am satisfied with a commit on head and want to move it to a branch I just `jj rebase -r @ -B branch`. When I want to create a new branch it's just `jj new -A main -B head` and `jj bookmark set branch_name -r @`

Re: Stacked Diffs with git rebase —onto

#92

Post by yegle »

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.

Re: Stacked Diffs with git rebase —onto

#93

Post by glenjamin »

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.

I invite you to look into feature flagging.

It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time.

That's exactly how I've worked for the past decade or so.

Re: Stacked Diffs with git rebase —onto

#94

Post by jhhh »

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…

It's not a trick or workaround. It's a very straightforward use of a command flag on one of the most used git commands. It's even conceptually very simple, you're just rebasing a subset of commits of a branch onto a different parent. Anyone who has ever rebased already has a working mental model of this operation. Framing this issue where knowing a single flag on a command every git user uses every day to perform an operation they already broadly understand as some arcane knowledge and 'nonsense' is ridiculous.

Re: Stacked Diffs with git rebase —onto

#95

Post by jhhh »

tcoff91 wrote: post #88
hansvm wrote: post #70

Earlier quoted context omitted.

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

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?

Re: Stacked Diffs with git rebase —onto

#96

Post by WorldMaker »

ndr wrote: post #8
dimitrieh wrote: post #6

Jujutsu comes in handy here for the same usecase: https://github.com/jj-vcs/jj https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... Also found https://github.com/gitbutlerapp/gitbutler

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.

Re: Stacked Diffs with git rebase —onto

#97

Post by WorldMaker »

nopurpose wrote: post #65
duskdozer wrote: post #31

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.

Though at that point it may be easier to rewrite your helper to manage rebase's interactive scripts.

Re: Stacked Diffs with git rebase —onto

#98

Post by mwcz »

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 harder to accept jj commands at face value. I know it's modifying my git tree, so I feel compelled to grok exactly what it's doing, but that's distracting and time consuming.

People like me should probably trial jj exclusively for two weeks, to shed that antijjotic resistance and form a more clear-headed opinion.

Re: Stacked Diffs with git rebase —onto

#99

Post by WorldMaker »

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 hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)

Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.

Re: Stacked Diffs with git rebase —onto

#100

Post by mytailorisrich »

happytoexplain wrote: post #89
mytailorisrich wrote: post #84

Earlier quoted context omitted.

No, I mean small chunks that are actually merged instead of having a stack of them floating around. A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.

Oh, yes - but this is more about your situation than your style. Sometimes a feature is large and varied enough to beg multiple PRs, yet singular enough that you are not developing them serially (i.e. as you work on later parts, you are changing earlier parts). Most of the time this isn't the case.

My experience is that you should always aim for frequent small commits. This is what continuous integration and trunk-based development advocate and it saves a lot of headaches and the need to come up with "exotic" solutions to problems created by big, long-lived dev branches.

This is quite orthogonal to developing parts serially or not, and it is perfectly fine to change or refactor ealier parts when you work on later parts. Development is an iterative process.

It seems to me that "stacked diffs" are an example of looking for a technical solution to process issue.

Post reply on HN