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

Splitting a Git Commit

blog.gnoack.org

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Splitting a Git Commit

#51

Post by skydhash »

schacon wrote: post #50
skydhash wrote: post #47

Earlier quoted context omitted.

> The point is, interactive rebasing is a horrible solution to this problem, `git history` clearly better, at least for splitting, but really we need non-interactive solutions to problems like this so agents can do them well If it’s for scripting why not use the lower level ‘git update-index’. Start from the original file and a patch filed, edit the patch, apply it, and then add it the modified file to the index. The…

Well, there are a couple of problems here, if you are interested in an actual answer. The first is that update-index only works on worktree files, so you need to be actually modifying file contents on disk and then essentially running `hash-object` on them, then `commit-tree`, etc. For an agent, each of these are tool calls and ones that they're not very good at (because nobody really does this manually). Quick examp…

I'm saying this because, git store whole files for each commit, not hunks or patches. Scripting it out without doing any interactions would be to have discrete steps which can be rollback. So it's better to have the changes (the patch) separate from what needs to be changed (the file). So the agents need only to edit the patch in three separate version (c1, c2, c3), then loop with the apply->update-index->commit action, each easily verifiable and revertable.

Re: Splitting a Git Commit

#52

Post by gnoack »

schacon wrote: post #46

In case you're curious if _you_ can run `git history split`, the answer is almost certainly no, unless you manually installed the newest release of Git within the last 3 months. `git history` was introduced as an experimental command less than 4 months ago, which means that there are essentially zero OS releases that packages a version that contains it by default. Also, if you're on OSX and run `brew install git`, it…

Point taken, that's true. I'm admittedly developing on distributions where the updates are faster, so I missed that. But then again, I also didn't expect that this short weblog article would have such a large audience when I wrote it. :)

Re: Splitting a Git Commit

#53

Post by nemetroid »

schacon wrote: post #46

In case you're curious if _you_ can run `git history split`, the answer is almost certainly no, unless you manually installed the newest release of Git within the last 3 months. `git history` was introduced as an experimental command less than 4 months ago, which means that there are essentially zero OS releases that packages a version that contains it by default. Also, if you're on OSX and run `brew install git`, it…

It's in Fedora, Arch, and many other popular operating systems.

Re: Splitting a Git Commit

#55

Post by ericfrederich »

qsera wrote: post #17
diath wrote: post #9

That's good to know, I'd usually go about it in a roundabout way: soft reset the commit then git add --patch to stage the hunks to split it into multiple commits.

I do the same, but use `git gui` to select the changes.

Yeah, I've been using git for nearly 20 years. I still rely on `git gui`. It's my crutch. I know you can do all of that in a terminal, but staging different hunks (or individual lines) is super easy.

Re: Splitting a Git Commit

#56

Post by jgtrosh »

BeetleB wrote: post #13

Is this yet another case of git improving its UI due to jujutsu? (This is exactly how jj does it.) If you like this kind of convenient CLI command, I would seriously recommend giving jj a try. To give you an idea, I never bothered splitting a commit in my git days. I do it almost daily with jj. Lots of other niceties that I didn't bother with in git, but routinely do in jj. jj has fewer commands than git, yet does ev…

Also, `jj split` can use alternative tooling to the built-in TUI, whereas I don't think `git history split` can.

Re: Splitting a Git Commit

#58

Post by nomel »

pixl97 wrote: post #28
mateusz834 wrote: post #24

or use jj and stop worrying about git jj split --interactive {ref}

Ah yes, I'll just pass that over to the compliance team and wait a few months for a denial.

jj uses git as a backend, even though it's not a git frontend. You can use it in a "colocated" mode, with an existing git clone, alongside your normal git tools. Either way, nobody will know that you're using jj except you.

Re: Splitting a Git Commit

#59

Post by nulltrace »

meling wrote: post #44

I’m doing rebasing a lot these days, especially since I started using gh stack. The main struggle I have with rebasing is for git to recognize that a branch has actually been merged when its commits have changed (e.g., if I forgot to delete the local branch with old commits and come back months later and trying to figure out if it was actually merged or not). My understanding is that this is nicer with jj when you wo…

[dead]

Re: Splitting a Git Commit

#60

Post by Zopieux »

nemetroid wrote: post #53
schacon wrote: post #46

In case you're curious if _you_ can run `git history split`, the answer is almost certainly no, unless you manually installed the newest release of Git within the last 3 months. `git history` was introduced as an experimental command less than 4 months ago, which means that there are essentially zero OS releases that packages a version that contains it by default. Also, if you're on OSX and run `brew install git`, it…

It's in Fedora, Arch, and many other popular operating systems.

It's funny how people assume Dehian/Ubuntu's ice cold release schedule is the norm, when the rest of us have been enjoying rolling releases and timely, stress-free (easy rollback) updates with NixOS and Arch back in the days. It's been at 10+ years now.
Post reply on HN