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

101–110 of 155 posts

Re: Git rebase -i is not that scary

#101

Post by collabs »

please people, stop teaching newcomers short aliases. please teach them proper long terms --interactive is not much harder to type than -i. Why do we keep doing this? It isn't the 1970s anymore. even if we do this all day it will take what maybe 5 KiB more of ram or storage? if that? why teach people some Harry Potter incantations when we can teach them proper words?

Sure, if they want to they can later use `npm -g i` or whatever abomination they want but when we teach them, we should use full arguments, not aliases. please, people :(

Re: Git rebase -i is not that scary

#102

Post by Vinnl »

herywort wrote: post #76
selckin wrote: post #59

Earlier quoted context omitted.

you can just make a backup copy of .git or your entire project dir. When you get lost, just delete your .git, copy from the backup and try again

Is this a joke? git's whole purpose is to save the history of your project and return to earlier versions when needed

It's a super simple solution for which you can be certain that you have all the knowledge needed to perform the restore operation.

Re: Git rebase -i is not that scary

#103

Post by douglee650 »

Most developers just have a linear view of git, which is fine. Should I really care that origins are just named nodes on combined graphs? Like, I just want to check in my code before I have to merge someone else's.

Zero rebases since Fable 5.

Re: Git rebase -i is not that scary

#104

Post by codethief »

mikemcquaid wrote: post #50

I’ve used Git for 20 years now and wrote a book about it. The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first: - it’s easy to lose uncommitted data in Git and hard to lose committed data - given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late) If you just get in th…

> (Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware).

Oh wow. Is there a way to trigger GC manually?

Re: Git rebase -i is not that scary

#105

Post by brown9-2 »

xorcist wrote: post #85
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…

This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.

tags and branches are both just refs to the commit and can be used interchangeably for something like this. tags are not immutable, just in convention.

Re: Git rebase -i is not that scary

#106

Post by prima-facie »

I found the following config to bring a great QoL improvement:

    FILE: .gitconfig
    ----------------
    [alias]
        ci = commit
        fix = commit --fixup
    [rebase]
        autosquash = true
Now you can do quick commits as save-points, and squash all of them at the end.

    git tag last-good
    git ci -am 'WIP'
    git fix HEAD -a
    git fix HEAD -a
    …
    git rebase -i last-good

Re: Git rebase -i is not that scary

#107

Post by OJFord »

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…

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

Are you using diff3/zdiff3? I ask because you seem to be describing exactly the problem it solves, or at least the way I try to sell people on it.

Basically in addition to 'current' & 'incoming from the rebase' hunks you get 'parent commit of incoming from the rebase' – which allows you to see 'what was I trying to change', i.e. how does the intent of it apply to the different thing that's now on master (whatever I'm reading onto).

Re: Git rebase -i is not that scary

#108

Post by mikemcquaid »

codethief wrote: post #104
mikemcquaid wrote: post #50

I’ve used Git for 20 years now and wrote a book about it. The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first: - it’s easy to lose uncommitted data in Git and hard to lose committed data - given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late) If you just get in th…

> (Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware). Oh wow. Is there a way to trigger GC manually?

Unsure, no longer there. I think maybe just “contact support”.

Re: Git rebase -i is not that scary

#109

Post by harpiaharpyja »

nixpulvis wrote: post #7

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

This notion that `git rebase -i` is some scary unusual thing is totally alien to me. Doing some minor cleanup on local history with rebase is a *basic* operation that I would have thought everyone would be using regularly.

Re: Git rebase -i is not that scary

#110

Post by mike_hock »

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.)

Like all git operations that destroy history, it's a bit less scary than rm or unlink, because you can undo obvious fuckups using the reflog. Non-obvious fuckups will (by Murphy's law) only be detected long after the reflog has been GC'd, so it still risks losing work.

Git was written with Linux in mind, where curating a clean commit history is more important than the code itself and warrants the extra hassle.

An actually usable rebase would probably require something like a meta history. But then the meta history would accumulate fixup "commits" and typos in commit messages so the OCD people will want to change that and we're back to square one. In practice, the two times per decade it actually makes business sense to dig through the history to find when a bug was introduced instead of just writing the 5-line fix, you can live with a couple of imperfect commits and merges.

Post reply on HN