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

Extremely Linear Git History

westling.dev

Post reply on HN
Print view View original

351–360 of 366 posts

Re: Extremely Linear Git History

#351

Post by couchand »

cerved wrote: post #337
couchand wrote: post #278

Earlier quoted context omitted.

I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time. I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.

as always, different circumstances can generate different results. In a merge, you solve conflicts once. Whereas in a rebase, those conflicts will turn into incremental conflicts. If the branch history is "tidy", with discrete, purposeful commits, this can be easier. Especially if incrementally rebasing. The main difference is one rewrites history and the other does not. A rebase is by nature destructive and as such…

It's not really destructive, though! That's not really the main difference.

The main difference is that a merge sticks around in your repo forever, a commit that people assume has no real code changes in it but actually sometimes it does. A rebase is done once, and then your git history doesn't have to deal with it ever again.

Yes, you raise a fair point that if you've dug yourself into a deep pit already with long-lived branches and overlapping work, it might be slightly easier to extract yourself from the pit with a merge. But then you're leaving that fetid pit in your repository forever.

Re: Extremely Linear Git History

#352

Post by couchand »

simiones wrote: post #341
couchand wrote: post #295

Earlier quoted context omitted.

> A rebase and a merge result in the same code. If done correctly, that's true, but it's beside the point. The reason to prefer one over the other is the failure mode. > A rebase is more error prone though. On what metric? In my experience, a merge is far, far more likely to silently introduce a production bug. I've never seen a rebase fail that way.

Doesn't rebase use the exact same automatic merge algorithm as a merge? They are equally as likely to introduce a production bug. Especially if adding a tool like rerere into the mix to do even more auto-magic merging when you hit the differences between rebase and merge.

There are two distinct possible problems:

1) The merge auto-applies cleanly, but the merged code is wrong. This is pretty niche, usually, but happens in certain edit patterns. I've never seen this produce a syntactically-valid, semantically-invalid construct (but I suppose it's possible) so generally these are caught by the compiler.

2) The merge does not auto-apply, so you get into manual resolution. This is where things get hairy.

The merge commit really ought not have any changes of its own, but lots of people consider minor conflict resolution legal. So you end up with a bunch of code changes that logically belong to another commit, and are grouped together for purposes of expediency.

Rebase applies your changes to another branch as though they had been made there originally. If a conflict comes up, you already have all the context needed for how to resolve it, because you just wrote that code. The fix goes where it belongs.

All I can tell you is that I've been bit by merge-induced production bugs enough times that I now work to avoid that particular failure mode.

Re: Extremely Linear Git History

#353

Post by couchand »

simiones wrote: post #340
couchand wrote: post #229

Earlier quoted context omitted.

recursion

What does that mean in the context of git?

There is nothing special about the main branch! This is the recipe to collaborate in git:

- Pick a shared branch to work on.

- Work.

- If you complete within a day, push to shared branch.

- If you need to hold onto it longer, make a new branch, switch to it.

- (Possibly recurse.)

- Complete work, rebase new branch on shared branch, push.

And of course feel free to replace branch with remote/branch. It is distributed, after all, nothing special about any particular server.

A worked example, to make it more concrete:

- Pick the shared branch main.

- Work on a feature for more than a day, so:

- Create a feature branch feature/e2ee, switch to it.

- Recurse, since you'll be doing database updates and I'm adding the UI.

- Pick the shared branch feature/e2ee.

- I create a branch git.sr.ht/~couch/new-twitter/feature/e2ee

- You work and push to feature/e2ee.

- I complete my work, rebase the branch, and push to feature/e2ee.

- We are satisfied that we've completed the feature, rebase and push to main.

Re: Extremely Linear Git History

#354

Post by simiones »

couchand wrote: post #352
simiones wrote: post #341

Earlier quoted context omitted.

Doesn't rebase use the exact same automatic merge algorithm as a merge? They are equally as likely to introduce a production bug. Especially if adding a tool like rerere into the mix to do even more auto-magic merging when you hit the differences between rebase and merge.

There are two distinct possible problems: 1) The merge auto-applies cleanly, but the merged code is wrong. This is pretty niche, usually, but happens in certain edit patterns. I've never seen this produce a syntactically-valid, semantically-invalid construct (but I suppose it's possible) so generally these are caught by the compiler. 2) The merge does not auto-apply, so you get into manual resolution. This is where t…

> The merge commit really ought not have any changes of its own, but lots of people consider minor conflict resolution legal.

I'm not sure where this rule comes from. For code review, I for one normally review all of the changes that are going into master, and only look commit-by-commit if it becomes overwhelming - so, unless this is a huge merge (which should generally be avoided anyway), I wouldn't really see how this is a problem.

The only real problem I have with merging into your local branch to keep it in sync with master is the way it pollutes history when it is finally merged back into master. This is enough of a problem that I and my team always rebase unless we end up in one of these rare cases that I was highlighting.

Re: Extremely Linear Git History

#355

Post by simiones »

couchand wrote: post #353
simiones wrote: post #340

Earlier quoted context omitted.

What does that mean in the context of git?

There is nothing special about the main branch! This is the recipe to collaborate in git: - Pick a shared branch to work on. - Work. - If you complete within a day, push to shared branch. - If you need to hold onto it longer, make a new branch, switch to it. - (Possibly recurse.) - Complete work, rebase new branch on shared branch, push. And of course feel free to replace branch with remote/branch. It is distributed,…

That doesn't really solve much: if both you and I rebase our personal feature branches onto master at different places, when we both try to push to the shared feature branch, we'll have a REALLY bad time - especially if we actually had to do conflict resolution.

Re: Extremely Linear Git History

#356

Post by daveguy »

voxl wrote: post #236
daveguy wrote: post #196

Earlier quoted context omitted.

Sounds like the definition of making it okay to fail. The only consequence is a plush toy of shame on your desk until the next person fails? Yes, please. Sounds like a great way to lighten the mood about failure.

Uh no, and please never work with me. The definition of "making it okay to fail" is a pat on the back and a retrospective to figure out what went wrong and prevent it from happening again.

Thank you for distinguishing yourself.

I'm not sure why you think a humorous plush toy precludes any of the other things you mention (retrospective, etc). I see a plush toy as something that makes failure an amusing thing to laugh at, rather than something to be hung up about.

But don't worry. At your request, I will not work with you.

Re: Extremely Linear Git History

#357

Post by pedroteosousa »

masklinn wrote: post #185
jwilk wrote: post #148

Earlier quoted context omitted.

What do you mean by "extra headers"?

Exactly what the name says. A git commit is composed of a number of headers (key: value fields) and a commit message. There is a set of "standard headers" (tree, parent*, author, committer, encoding?), but then you can add more. In fact there's a set of semi-standard headers, as in headers git itself will add under some conditions: `gpgsig` and `gpgsig-sha256` if the commit is signed, and I think `mergetag` for signe…

I was trying to make something like this post a couple of years back and used custom headers, even made this repo with a few zeroes with no salt on the commit message and no shenanigans in the files: https://gitlab.com/pedroteosousa/teste/-/commit/000000005093...

I have this ugly code that finds the salt given the target hash, and another that actually creates the commit given the salt. Is not very useable, but I'll leave it here for anyone that finds it interesting: https://gitlab.com/pedroteosousa/useless-git-tools/-/tree/ma...

Re: Extremely Linear Git History

#358

Post by flir »

wirrbel wrote: post #260
newswasboring wrote: post #183

Earlier quoted context omitted.

I am literally in the middle of trying to convince my group from moving away from all this. Would you recommend going back to this system?

In this case I reminisced about the toolset but the work flow is what brought the value so I advise of course against using subversion. Look up trunk based development and read the continuous integration book published by Addison Wesley (Is it the hez humble book or the Duvall book I always confuse the authors, both books are great though). The hard part will be to convince people of exploring a different way working…

So I'm thinking about my approach, which is "use commits as game save points, mostly WIP, then use rebase to tidy things up before publishing".

Wouldn't working on trunk still mean I'm working on a feature branch, but it all ends up squashed into a single commit? Or do I lose my opportunity to polish?

Re: Extremely Linear Git History

#359

Post by turtleyacht »

cerved wrote: post #338
turtleyacht wrote: post #312

Earlier quoted context omitted.

First time I've seen aliases using other chars other than a-z; care to share your dotfiles? It's a neat trick to explode your alias namespace, since you'll never see a tool published named `ls-` So you have reserved a huge "address block" for your personal aliases :)

I'd be happy to, this is (roughly) my git config. https://github.com/CervEdin/gut/blob/config/.gitconfig NB, that some are personal custom scripts, like git-branch-status, which I also publish in the same public repository. It's very much opinionated and geared to my use but feel free to use it, submit feedback and/or PR

Thank-you. I collected some from kristopolous recently [1] too.

I see d- there, so the one use of dash is used sparingly. There's a lot of git functionality I'm leaving on the table, looks like.

Currently, I'm using a shell script to help with a git conflict resolution flow that does something like

    read -p 'Conflict. Resolve and press [Enter]'
And fix in a separate tmux window (git add, git cherry-pick --continue).

TUIs and autocomplete popups are nice, but there's opportunity for a deeper understanding writing one's own tools. So I'm hoping to combine ZZ and `read -p` (or similar) to coax nvi (Keith Bostic) to something for Java stuff. Or at least build some primitives around that.

Encountering the equivalent of "flash of unstyled content" when switching from text editor to a--for example--Java method chooser feels like the philosophical difference between "Let's SPA" versus "Click flashes between pages is fine."

The flow would be something like

  1. In nvi, keystroke equivalent of
     Ctrl-Space brings up an Intellisense
     tool.
  2. The tool loads up a list of
     autocomplete methods as well as its
     own hotkeys.
  3. Pressing up and down manipulates a
     temporary text file that just prepends
     ">" next to the line, for example.
  4. And Enter somehow brings back nvi with
     the method added, right after the
     period (with our partial typing
     replaced).
All this to say, dotfiles and git config are no big deal, but in CLI it's an escape hatch to molding a custom environment.

[1] https://news.ycombinator.com/item?id=33628204

Re: Extremely Linear Git History

#360

Post by plonk »

GauntletWizard wrote: post #323
palata wrote: post #298

Earlier quoted context omitted.

What about commit signatures? If you rebase, you lose the original signature, don't you?

If you let Github do the rebase, yes, you do. But you can do so manually yourself, taking the commit down to a single squashed commit, that you then sign. This is a tooling issue that needs to be solved client-side (i.e. where the signing key lives). It's an important one but actually really simple.

I wonder why GitHub doesn’t apply their own signature when they rebase a commit with a valid signature from one of their users. They do that when you edit a file through their Web UI.
Post reply on HN