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

61–70 of 74 posts

Re: Splitting a Git Commit

#61

Post by locknitpicker »

schacon wrote: post #42
locknitpicker wrote: post #35

Earlier quoted context omitted.

I agree, interactive rebasing existed for ages and git history is mainly a user experience improvement over it. This way of framing git history goes way past engagement tricks and erodes the blogger's credibility.

Not sure if this is written by an AI, but I'll engage, because it's a bit misleading. The new `git history` command can take three verbs - fixup, reword and split. While interactive rebasing can do fixup and rewording relatively easily and the `history` variant is a slight improvement, the split sub-subcommand is really _quite_ difficult to do in other Git tooling, including interactive rebase. Before reading on, I w…

> Not sure if this is written by an AI, but I'll engage, because it's a bit misleading.

What a tinfoil hat kind of remark. Just because you read something that you dislike that doesn't mean the LLM bogeyman is behind it.

> the split sub-subcommand is really _quite_ difficult to do in other Git tooling

Nonsense.

- copy a commit hash and start interactive rebase before that commit,

- run git checkout on that commit hash and pick the files you want to split

- run git commit,

- resume rebase.

Done.

You also have variants of this, such as doing git reset on a edit, recommitting, and resuming rebase.

> The point is, interactive rebasing is a horrible solution to this problem (...)

This is your personal and baseless opinion on the topic. Something like git history split saves you a step when compared with interactive rebase. The biggest complain you can throw at interactive rebase is that operations such as splitting commits, renaming or reordering commits, dropping commits, etc are not what you think when talking about rebasing. But that's it. I mean, if interactive rebase added a command to split commits, git history would be hard to justify.

Re: Splitting a Git Commit

#62

Post by locknitpicker »

brewmarche wrote: post #33
roelschroeven wrote: post #4

> P.S. The stack overflow question for splitting commits discusses the old and cumbersome approach. The 20th answer discusses the right approach but has a meagre 2 upvotes as of today, compared to 2656 for the older top answer with the cumbersome approach. It now has 5 upvotes. A long way to go to 2656 but at least it's going in the right direction.

These answers are ~15 years apart, so the vote difference is not surprising. I personally sort by ‘date modified (newest first)’ on StackExchange sites.

> I personally sort by ‘date modified (newest first)’ on StackExchange sites.

Sites such as stack overflow would improve significantly if they actively tagged questions and answers with version numbers they would be applicable to.

Re: Splitting a Git Commit

#63

Post by locknitpicker »

ivanjermakov wrote: post #3

StackOverflow is really not great at handling questions for which the right answer changes over time. I guess it doesn't matter since SO is dead anyway: https://news.ycombinator.com/item?id=46482345

> StackOverflow is really not great at handling questions for which the right answer changes over time.

The right answer doesn't change over time. It can vary with the release version you are targeting.

Re: Splitting a Git Commit

#64

Post by prattmic »

steveklabnik wrote: post #34
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…

My understanding is that `git history` was started after seeing jj, yes. I don't have a citation for you though, I could be wrong, that's just what I remember.

> “That moment when you realize that a tool simply fixes all the UI issues that you had and that you have been developing for the last 20 years was not exactly great." He had two options: despair or learn from the competition. He chose to learn from it.

https://lwn.net/Articles/1057561/ which goes on to explain that this was the motivation for git history.

Re: Splitting a Git Commit

#67

Post by insane_dreamer »

merb wrote: post #19
qsera wrote: post #17

Earlier quoted context omitted.

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

Which gui? I’m on Mac and somehow I could never really be happy with gui‘s for git. Gitkraken is the last I tried and I found it too much cluttering. Paid choices weren’t that great aswell either (yet)

try lazygit

Re: Splitting a Git Commit

#68

Post by hotelsacher »

jatora wrote: post #22
hungryhobbit wrote: post #20

Earlier quoted context omitted.

... until they decided it was a good idea to train all power users to grief new users off the site.

The rise of AI and the death of SO is a beautiful beautiful thing. That community is the worst, and this opinion seems to be shared universally by anyone who had extensive interaction with it.

AI could gorge itself once on (probably stolen) training data from SO, among others, but who will answer new questions now, and where will new training data come from?

Re: Splitting a Git Commit

#69

Post by BeetleB »

prattmic wrote: post #64
steveklabnik wrote: post #34

Earlier quoted context omitted.

My understanding is that `git history` was started after seeing jj, yes. I don't have a citation for you though, I could be wrong, that's just what I remember.

> “That moment when you realize that a tool simply fixes all the UI issues that you had and that you have been developing for the last 20 years was not exactly great." He had two options: despair or learn from the competition. He chose to learn from it. https://lwn.net/Articles/1057561/ which goes on to explain that this was the motivation for git history.

"He discussed the workflow for splitting a Git commit, which involves seven separate commands with Git's current UI. Most users do not know how to do this, he said. The goal is to add several ""opinionated subcommands"" that make more modern styles of working with merge requests, such as stacked branches, much easier."

Re: Splitting a Git Commit

#70

Post by scratcheee »

locknitpicker wrote: post #61
schacon wrote: post #42

Earlier quoted context omitted.

Not sure if this is written by an AI, but I'll engage, because it's a bit misleading. The new `git history` command can take three verbs - fixup, reword and split. While interactive rebasing can do fixup and rewording relatively easily and the `history` variant is a slight improvement, the split sub-subcommand is really _quite_ difficult to do in other Git tooling, including interactive rebase. Before reading on, I w…

> Not sure if this is written by an AI, but I'll engage, because it's a bit misleading. What a tinfoil hat kind of remark. Just because you read something that you dislike that doesn't mean the LLM bogeyman is behind it. > the split sub-subcommand is really _quite_ difficult to do in other Git tooling Nonsense. - copy a commit hash and start interactive rebase before that commit, - run git checkout on that commit has…

Describing something in less detail doesn’t in fact make it simpler.

It’s nice you’ve done this before, so have I, but until git history it remained weirdly lacking in user friendly support infrastructure compared to most “common” tasks. Git history isn’t a major improvement, but it’s an improvement on a major weak point.

Post reply on HN