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

31–40 of 155 posts

Re: Git rebase -i is not that scary

#31

Post by hetman »

flyingcircus3 wrote: post #9

After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walkin…

You don't need to keep their hashes because git keeps them for you. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog". (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)

Re: Git rebase -i is not that scary

#32

Post by dietr1ch »

Normal_gaussian wrote: post #17
koolba wrote: post #14

That “-I” really needs to be lowercase.

Yeah I got quite excited that there was somehow a better -i; its almost perfect clickbait

I was hoping for a rebase that recalled what your previous base commit of your branch.

I'm really not fond of having to `git rebase --interactive` just to drop all commits that are "already in master", especially when I forget this silly step and get a borked rebase.

Re: Git rebase -i is not that scary

#34

Post by whateveracct »

TazeTSchnitzel wrote: post #3

I wish there were a shorthand for x git commit --amend --reset-author --no-edit I use that one very frequently (after a fixup, of course) because I want the author date on amended commits to reflect the last time I edited them, not the first time I committed them.

i edit my commit dates constantly for various reasons

get ahead at work? split into commits and make it look like multiple days of work

work on your own IP during work hours? edit the timestamp to be outside work hours (i even have a script for this)

Re: Git rebase -i is not that scary

#35

Post by hetman »

Glyptodon wrote: post #13
nixpulvis wrote: post #7

I feel like if you're scared of rebasing, you don't actually understand git.

My fear has never been rebasing itself, but that I make some kind of mistake with a random change conflict and don't notice it because it's not tested for directly. But I'm also not sure if that's categorically a git fear. (Edit: related to this, I think this sort of minor "itchy worry" is grounded in how sometimes conceptually simple diffs look messy during conflict resolution.)

If all I'm doing with git rebase is reorganising my commits, and I have to deal with conflicts, after I'm done, I always git diff my pre-rebase head with post rebase head commit hash. I can quickly see I've messed something up if the diff isn't empty. For more complex tasks it's best to leave the rearranging until last, but where not possible, the diff is still pretty useful to double check my work.

Re: Git rebase -i is not that scary

#37

Post by teaearlgraycold »

irishcoffee wrote: post #18
nixpulvis wrote: post #7

I feel like if you're scared of rebasing, you don't actually understand git.

The part where git needs to be “understood” is the entire problem. “Do one thing and do it well” was the whole mantra, which was completely ignored with the disaster that is git. It’s objectively awful.

It could be so much better. At the same time, it’s one of the core tools for a developer. You’ll learn it eventually. You’re going to be using version control for decades. I’ve met devs many years into their careers who don’t understand rebase. It’s like going to a metal shop and they’re complaining about the learning curve on their welder and half the tradesmen are still at a novice level.

Re: Git rebase -i is not that scary

#38

Post by [deleted] »

TazeTSchnitzel wrote: post #3

I wish there were a shorthand for x git commit --amend --reset-author --no-edit I use that one very frequently (after a fixup, of course) because I want the author date on amended commits to reflect the last time I edited them, not the first time I committed them.

[deleted]

Re: Git rebase -i is not that scary

#39

Post by pajko »

Why isn't the 'edit' command mentioned? It's one of the most useful features. It can be used for splitting commits, for example. Mark the commit you want to split to be edited. The commit replay is going to stop after that commit. Now:

  git reset HEAD^1 (NO --hard!)
  git commit --patch ...
  git rebase --continue
You want to add some pending changes to the previous commit? No problem:

  git commit --patch --amend ...
You want to move the pending changes to future commits?

  git stash
  git rebase --continue
  git stash pop

Re: Git rebase -i is not that scary

#40

Post by xelxebar »

dietr1ch wrote: post #32
Normal_gaussian wrote: post #17

Earlier quoted context omitted.

Yeah I got quite excited that there was somehow a better -i; its almost perfect clickbait

I was hoping for a rebase that recalled what your previous base commit of your branch. I'm really not fond of having to `git rebase --interactive` just to drop all commits that are "already in master", especially when I forget this silly step and get a borked rebase.

Does this not do what you want?

    git rebase -i master..HEAD
The gitrevisions(7) manpage is a good reference to keep in your back pocket, I find.

https://www.man7.org/linux/man-pages/man7/gitrevisions.7.htm...

Post reply on HN