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

Git rebase -i is not that scary

cachebag.sh

Post reply on HN
Print view View original

141–150 of 155 posts

Re: Git rebase -i is not that scary

#141

Post by irishcoffee »

rcxdude wrote: post #140
irishcoffee wrote: post #133

Earlier quoted context omitted.

Have you never seen a toddler touch a non-touch screen and be like “wtf?” Or watch a child holding mom’s phone swipe away a text message alert? Yes, good software is absolutely intuitive. Git is garbage.

Because they've already learned a model of how devices with screens work, albeit an imperfect one. Children are pretty good at learning. Software and systems should be easy to learn, but it's not a case of no learning.

So you agree then. People have been saying from inception that git isn’t intuitive.

Re: Git rebase -i is not that scary

#142

Post by rcxdude »

irishcoffee wrote: post #141
rcxdude wrote: post #140

Earlier quoted context omitted.

Because they've already learned a model of how devices with screens work, albeit an imperfect one. Children are pretty good at learning. Software and systems should be easy to learn, but it's not a case of no learning.

So you agree then. People have been saying from inception that git isn’t intuitive.

I agree that git's UI is not particularly easy to learn, and it could be better in that regard (which is frustrating because its underlying model is about as simple as you can come up with, and I essentially can always think of what I want in that model easily but then have to google how to tell git to do it). What I object to is the idea that needing to understand something to use it is a problem.

Re: Git rebase -i is not that scary

#143

Post by entrope »

letmeinhere wrote: post #119
baq wrote: post #115

After two decades of using git I'm either telling LLMs to do rebases for me or use jj (or both). Life's too short.

Just make sure you've committed and/or stashed first, as you don't really want to rely on the stochastic process to retain your local-only critical work product.

That's one of the nice features of jj: instead of having an index, the working tree is its own commit, and it tracks the history of that when you run most jj commands.

This works because each commit gets a "change id" assigned that only changes when you say. When you create a new commit, edit its commit message, and edit files, you end up with three git commits with the same change id, but two of the git commits will be gc'ed eventually. (The change id is what you normally use to identify what's in the git commit graph.)

So even if you issue a command that destroys overwrite some important changes, jj has a good chance of remembering your worktree state.

Re: Git rebase -i is not that scary

#144

Post by nottorp »

dionian wrote: post #23

sometimes i wish mercurial won, if nothing else for the fact that i found its ux to be more enjoyable. I respect and use git, but never got comfortable with merging. im thankful AI can automate it for me now

what does mercurial have to do with merging? a merge is a merge in both git and hg.

Re: Git rebase -i is not that scary

#145

Post by fleventynine »

nopurpose wrote: post #60
fleventynine wrote: post #33

I typically work with commit chains of at least 5 commits in various states of code review, so I spend at least 60% of my development time editing an old commit in the middle of a rebase -i.

You might find `jj` to help you there: all changesets have stable identifier and their content can be updated at any moment in-place. TLDR; `jj edit ; $EDITOR` will update a commit in the middle of the branch

Not an option for me until it supports submodules.

Re: Git rebase -i is not that scary

#146

Post by roryirvine »

selckin wrote: post #137
delusional wrote: post #71

Earlier quoted context omitted.

You never need to do that. git-reflog(1) is the most general solution if you will ever need.

if you're a beginner thats going to be very difficult, restoring the git dir a few times makes the learning process much faster, till it all clicks and you don't need too anymore

But then you have multiple copies of your repo which is inevitably going to end up with a my_project_v2_FINAL_3b/ mess, reminiscent of how people used to manage files before version control.

Not having to deal with all that is exactly what git is for.

Re: Git rebase -i is not that scary

#147

Post by nopurpose »

fleventynine wrote: post #145
nopurpose wrote: post #60

Earlier quoted context omitted.

You might find `jj` to help you there: all changesets have stable identifier and their content can be updated at any moment in-place. TLDR; `jj edit ; $EDITOR` will update a commit in the middle of the branch

Not an option for me until it supports submodules.

Prior to `jj` my happiest git discovery was https://github.com/ingydotnet/git-subrepo to replace submodules.

Re: Git rebase -i is not that scary

#148

Post by sensanaty »

xg15 wrote: post #96

I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic. I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history . So I te…

I use it often as well, but if I'm rebasing more than a handful of commits it becomes very annoying and confusing if there's a conflict. For example, I often run into the situation where I'll get a conflict, I resolve that conflict on the first rebase step, but then the same conflict keeps popping up. Where did the resolution I just did disappear to? Why do I have to keep redoing the resolution?

Re: Git rebase -i is not that scary

#149

Post by xg15 »

sensanaty wrote: post #148
xg15 wrote: post #96

I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic. I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history . So I te…

I use it often as well, but if I'm rebasing more than a handful of commits it becomes very annoying and confusing if there's a conflict. For example, I often run into the situation where I'll get a conflict, I resolve that conflict on the first rebase step, but then the same conflict keeps popping up. Where did the resolution I just did disappear to? Why do I have to keep redoing the resolution?

Yep. I think that's a "normal" feature of how conflict resolution during rebases work: To perform your rebase, git merges each of the original commits into your new history, in turn. If one if those commits has a change that causes a conflict, the subsequent commits will likely have the same change and cause that same conflict again. And because your resolution is only for one commit, it will be "forgotten" in the next merge.

I think "git rerere" was built as a sort of bandaid for this. It doesn't really fix the problem but it at least makes it less annoying. (Haven't used it yet though)

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Re: Git rebase -i is not that scary

#150

Post by Vinnl »

roryirvine wrote: post #146
selckin wrote: post #137

Earlier quoted context omitted.

if you're a beginner thats going to be very difficult, restoring the git dir a few times makes the learning process much faster, till it all clicks and you don't need too anymore

But then you have multiple copies of your repo which is inevitably going to end up with a my_project_v2_FINAL_3b/ mess, reminiscent of how people used to manage files before version control. Not having to deal with all that is exactly what git is for.

I'm pretty comfortable with Git, but I've still done this a number of times, and in my experience this situation is very evitable. After I've completed my gnarly process (whether successfully or unsuccessfully), I just delete the folder I don't want to use.
Post reply on HN