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

271–280 of 305 posts

Re: Git Rebase for the Terrified

#271

Post by Groxx »

jon-wood wrote: post #124
xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…

You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.

I've seen that you can read one commit at a time, but never anything for reviewing (or diffing between them if they change) - is there a UI beyond just clicking on the list of commits?

Though I forget if you can even comment in the individual commits in that view. Complex multi-commit PRs have generally been a nightmare on GitHub in my experience.

Re: Git Rebase for the Terrified

#272

Post by vlovich123 »

dcre wrote: post #90
vlovich123 wrote: post #20

Earlier quoted context omitted.

How do you handle publishing the stack?

There’s tooling like https://github.com/LucioFranco/jj-spr for managing stacks of PRs, but for stacks of 2 or 3 it’s not too bad to do it manually.

I’ve not had any luck with that tool in terms of creating meaningfully reviewable prs. I’m hoping I can maybe leverage graphite for the stack generation while authoring everything in jj. We’ll see how that goes

Re: Git Rebase for the Terrified

#273

Post by kijin »

Jare wrote: post #239
macintux wrote: post #223

Earlier quoted context omitted.

> Personally, a clean commit history was never something that made my job easier. How do you define "clean"? I've certainly been aided by commit messages that help me identify likely places to investigate further, and hindered by commit messages that lack utility.

> How do you define "clean"? In the context of merge vs rebase, I think "clean" means linear, without visible parallel lines. Quality of commit messages is orthogonal. I agree with the poster that this particular flavor of "clean" (linear) has never ever helped me one bit.

Agreed, it just means "linear" for most people.

I think the obsession with a linear master/main is a leftover from the time when everyone used a centralized system like svn. Git wasn't designed like that; the Linux kernel project tells contributors to "embrace merges." Your commit history is supposed to look like a branching river, because that's an accurate representation of the activity within your community.

I think having a major platform like github encourages people to treat git as a centralized version control system, and care about the aesthetics of their master/main branches more than they should. The fact the github only shows the commit history as a linear timeline doesn't help, either.

Re: Git Rebase for the Terrified

#274

Post by globular-toast »

g-b-r wrote: post #264
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 s…

Of course you should keep backups. But that's a different abstraction level.

I have never in 15+ years of using git daily encountered one of these "weird states". Because, like I said, no command in git can modify or delete a commit.

The only real mistake you can make is hard reset with uncommitted changes in your working dir. Other than that it's down to git bugs, which I have never encountered.

Re: Git Rebase for the Terrified

#275

Post by lanyard-textile »

z3dd wrote: post #127
lanyard-textile wrote: post #96

Earlier quoted context omitted.

Disagree! If those commits were ready for production, they would have been merged. ;) Don't put a commit on main unless I can roll back to it.

When your PR build takes more than an hour you'll think twice before creating multiple PRs for multiple related commits (e.g. refactoring+feature) when working on a single issue.

That's fine and fair, but you'd better squash them then :)

Re: Git Rebase for the Terrified

#276

Post by zbentley »

eeperson wrote: post #268
zbentley wrote: post #179

Earlier quoted context omitted.

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…

I'm glad it works for you! I may not have described the situation super clearly: most bugs I triage are either very causally shallow (i.e. they line up exactly with a release or merge, or have an otherwise very well-known cause like "negative input in this form field causes ISE on submit"), or else they're causally well understood but not immediately solvable.

For example, take a made up messaging app. Let's call it ButtsApp. Three big ButtsApp releases releases happened in order that add the features: 1) "send messages"; 2) "oops/undo send"; and 3) "accounts can have multiple users operating on them simultaneously". All of these were deemed to be necessary features and released over successive months.

Most of the bugs that I've spent lots of time diagnosing in my career are of the interacting-known-features variety. In that example, it would be "user A logs in and sends a message, but user B logs in and can undo the sends of user A" or similar. I don't need bisect to tell me that the issue only became problematic when multi-user support was released, but that release isn't getting rolled back. The code triggering the bug is in the undo-send feature that was released months ago, and the offending/buggy action is from the original send-message feature.

Which commit is at fault? Some combination of "none of them" and "all of them". More importantly: is it useful to know commit specifics if we already know that the bug is caused by the interaction of a bunch of separately-released features? In many cases, the "ballistics" of where a bug was added to the codebase are less important.

Again, there are some projects where bisect is solid gold--projects where the bug triage/queue person is more of a traffic cop than a feature/area owner--but in a lot of other projects, bugs are usually some combination of trivially easy to root-cause and/or difficult to fix regardless of whether the causal commit is identified.

Re: Git Rebase for the Terrified

#277

Post by tsimionescu »

cluckindan wrote: post #266
alemanek wrote: post #183

Earlier quoted context omitted.

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.

You'll still get interleaved commits. If I work on a branch for a week, committing daily and merging daily from main, when I merge to main, git log will show one commit of mine, then 3 from someone else, then another of mine, etc. The real history of the main branch is that all my commits went in at the same time, after seven days, even if some of them were much older. Rebase tells the real story in this case, merge does not.

Re: Git Rebase for the Terrified

#278

Post by g-b-r »

globular-toast wrote: post #274
g-b-r wrote: post #264

Earlier quoted context omitted.

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 s…

Of course you should keep backups. But that's a different abstraction level. I have never in 15+ years of using git daily encountered one of these "weird states". Because, like I said, no command in git can modify or delete a commit. The only real mistake you can make is hard reset with uncommitted changes in your working dir. Other than that it's down to git bugs, which I have never encountered.

https://stackoverflow.com/questions/66449211/a-lock-file-alr... happens fairly easily, and at least years ago it was not easy to figure out how to solve it.

I think I did run in other bugs that did appear to have messed up the repository.

> like I said, no command in git can modify or delete a commit.

Well, you can end up losing commits by playing with the reflogs or deleting branches (if you haven't checked out the branch in the last by default 30 days, its commits might get deleted quickly)

Re: Git Rebase for the Terrified

#279

Post by xlii »

jon-wood wrote: post #124
xlii wrote: post #11

Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…

You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.

That's true, but acceptance is still all or nothing.

When chaining commits it's possible to (for example) have a function that does THING and then have another PR that have a function that uses first one.

It's somewhat PITA when team has no-dead-code hard rule, but otherwise it's quite manageable and invites rich feedback. Reviewer and feedback can focus on atomic change (in example: function that does THING) and not on a grand picture.

But I also often use method of logical PRs and even written about it: https://xlii.space/eng/pr_trick/

Re: Git Rebase for the Terrified

#280

Post by globular-toast »

g-b-r wrote: post #278
globular-toast wrote: post #274

Earlier quoted context omitted.

Of course you should keep backups. But that's a different abstraction level. I have never in 15+ years of using git daily encountered one of these "weird states". Because, like I said, no command in git can modify or delete a commit. The only real mistake you can make is hard reset with uncommitted changes in your working dir. Other than that it's down to git bugs, which I have never encountered.

https://stackoverflow.com/questions/66449211/a-lock-file-alr... happens fairly easily, and at least years ago it was not easy to figure out how to solve it. I think I did run in other bugs that did appear to have messed up the repository. > like I said, no command in git can modify or delete a commit. Well, you can end up losing commits by playing with the reflogs or deleting branches (if you haven't checked out the…

I've never run into index.lock nor had anyone else run into it after it being the "git guy" at various employments.

Garbage collection is a thing, of course, but it could be completely disabled if necessary. Most people don't bother because the defaults are sensible in virtually all cases.

Almost all git problems people have are because they don't know about the reflog and don't understand that git is fundamentally append only.

Post reply on HN