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

Git Rebase for the Terrified

brethorsting.com

Post reply on HN
Print view View original

261–270 of 305 posts

Re: Git Rebase for the Terrified

#261

Post by Liskni_si »

unshavedyak wrote: post #197
Liskni_si wrote: post #184

Earlier quoted context omitted.

You do if you find yourself in a team where PRs are squash-merged. :-(

Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s

Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit.

If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...

Re: Git Rebase for the Terrified

#262

Post by g-b-r »

MeteorMarc wrote: post #89

Nice, git rerere would have saved me in the past.

It's so weird that it's not enabled by default, although occasionally it can lead to surprising problems (when it records wrong resolutions).

I had it enabled for years, and the time when I tried turning it off the rebasing esperience was a hundred times worst.

Re: Git Rebase for the Terrified

#263

Post by g-b-r »

codesnik wrote: post #31
embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

whoa. well, if it really works for you. The thing is, git has practically zero "destructive" commands, you almost always (unless you called garbage collector aggressively) return to the previous state of anything committed to it. `git reflog` is a good starting point. I think i've seen someone coded user-friendlier `git undo` front for it.

Except that with this article's advice (delete the repository and clone it again) the reflog and the unreachable commits get lost all the time

Re: Git Rebase for the Terrified

#264

Post by g-b-r »

globular-toast wrote: post #202

> Rebase has a reputation for destroying work, and the warnings you see online don’t help. Everyone using git needs to accept the following. Say it out aloud if you have to: no command in git can ever modify or delete a commit. After a botched rebase your old work is one simple reset away using the reflog. Then you can have another go or reach out for help.

It's dangerous to think that nothing can ever happen to your repository, corruptions or weird states you don't know how to recover from are not even rare.

So do take backups, of the whole local repository.

At the beginning of using git I used to keep dozens of copies around, if the repository is not huge it's trivial (and compressed they typically don't take up much more space than a single copy).

That saved my ass several times

Re: Git Rebase for the Terrified

#265

Post by cluckindan »

cmrdporcupine wrote: post #256
drysine wrote: post #216

Earlier quoted context omitted.

That's what --amend and --fixup are for.

Which wreaks havoc with githubs shitty code review tool. Which is an argument against GitHub, not clean commit history

Yep. Rebase rewrites history and all the PR review comments vanish.

Re: Git Rebase for the Terrified

#266

Post by cluckindan »

alemanek wrote: post #183
rendaw wrote: post #157

Earlier quoted context omitted.

You can bring in changes and address conflicts early with merge too, I believe that's GP's point.

Yes but specifically with a rebase merge the commits aren’t interleaved with the commits brought in from mainline like they are with a merge commit. EDIT: I may have read more into GPs post but on teams that I have been on that used merge commits we did this flow as well where we merged from main before a PR. Resolving conflicts in the feature branch. So that workflow isn’t unique to using rebase. But using rebase to…

So use --merges when browsing main.

Re: Git Rebase for the Terrified

#267

Post by g-b-r »

I'm surprised that no one said it, the article's advice of routinely deleting your local repository, without first making a copy, is terrible!!!

You lose your whole reflog and all the unreachable commits that way, and so some errors you might make will lead to unrecoverable losses..!

If you want do begin from a new clone from time to time, but make copies of the old local repository first, and keep them around! You're bound to lose work occasionally, otherwise.

And why even messing around with a remote repository and force pushes, to safeguard yourself from rebase problems you can simply take a local copy of the repository..!

That's of course when it's not a huge repository

An alternative to keep in mind is to use local clones, updating which will take less time than taking a full copy.

Re: Git Rebase for the Terrified

#268

Post by eeperson »

zbentley wrote: post #179
any1 wrote: post #99

Earlier quoted context omitted.

> Fundamentally, I do not debug off git history. Are you saying that you've never used git bisect? If that's the case, I think you're missing out.

Bisect is one of those things where if you're on a certain kind of project, it's really useful, and if you're not on that kind of project you never need it. If the contributor count is high enough (or you're otherwise in a role for which "contribution" is primarily adjusting others' code), or the behaviors that get reported in bugs are specific and testable, then bisect is invaluable. If you're in a project where bug…

> If you're in a project where buggy behavior wasn't introduced so much as grew (e.g. the behavior evolved A -> B -> C -> D -> E over time and a bug is reported due to undesirable interactions between released/valuable features in A, C, and E), then bisecting to find "when did this start" won't tell you that much useful.

I actually think that is the most useful time to use bisect. Since this is a situation where the cause isn't immediately obvious, looking through code can make those issues harder to find.

Re: Git Rebase for the Terrified

#269

Post by quacker »

OkayPhysicist wrote: post #249
quacker wrote: post #236

Earlier quoted context omitted.

Using git history as documentation is hacky. A majority of feature branch commit messages aren't useful ("fix test case X", "fix typo", etc), especially when you are accepting external contributions. IF I wanted to use git history as a form of documentation (I don't. I want real documentation pages), I'd want the history curated into meaningful commits with descriptive commit messages, and squash merging is a great w…

As far as I'm concerned, the git history of a project is the root source of truth of why a change was made, at that point in time. External documentation is mostly broad strokes, API references, or out of date. Code comments need to be git blamed anyway to figure out when they were added, and probably don't exist for every little change. Pull requests associated with a given commit give the broad description of "what…

Agree to disagree I guess, but IME, git history is good for low level detail, not for high level information. Git history is a poor source for understanding architecture, code organization, and other aspects of the codebase. More often, git commit messages tell me what changed - not why the change was made or who it impacted or etc.

Reading through git history should be my last resort to figure something out about the codebase. Important knowledge should be written somewhere current (comments, dev docs, etc). If there is a random value being appended to a url, at least a code comment explaining why so I don’t even have to git blame it. Yes, these sources of knowledge take some effort to maintain and sure, if I have a close-knit team on a smaller codebase, then git history could suffice. But larger, long-lived codebases with 100s of contributors over time? There’s just no possible way git history is good enough. I can’t ask new team members to read through thousands of commits to onboard and become proficient in the codebase (and certainly not 5x-10x that number of commits, if we are not squashing/rebasing feature branches into main. Although, maybe now an LLM can explain everything). So I really need good internal/dev documentation anyway, and I want useful git history but don’t care so much about preserving every tiny typo or formatting or other commit from every past feature branch.

Also iirc, with github, when I squash merge via the UI, I get a single squashed commit on main and I can rewrite the commit message with all the detail I like. The PR forever retains the commit history of the feature branch from before the squash, so I still have that feature branch history when I need it later (I rarely do) so I see no reason to clutter up history on main with the yucky feature branch history. And if I tend toward smaller PRs, which is so much nicer for dev velocity anyway, even squashed commits can be granular enough for things like bisect, blame, and so on.

Re: Git Rebase for the Terrified

#270

Post by seba_dos1 »

recursive wrote: post #148
seba_dos1 wrote: post #135

Earlier quoted context omitted.

> "What's the state of my never-rebased branch at time X" is a trivial question to answer. Yes, but only because of reflog.

git log will also do the job, even if you never checked out the branch in this workspace.

It won't. In some simplest cases it may correlate, but not necessarily.
Post reply on HN