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

341–350 of 366 posts

Re: Extremely Linear Git History

#341

Post by simiones »

couchand wrote: post #295
jacobsenscott wrote: post #288

Earlier quoted context omitted.

A rebase and a merge result in the same code. A rebase is more error prone though. Just because someone "feels" a merge isn't as safe doesn't make it so.

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

Re: Extremely Linear Git History

#342

Post by Beltalowda »

couchand wrote: post #322
Beltalowda wrote: post #320

Earlier quoted context omitted.

> Merge commits are prone to introduce unexpected and uncaught bugs: rebases just don't. How so? If I make an error with a rebase then I risk losing my changes. You can fetch it from the local reflog, but that's not so easy. With a merge I have a merge commit which records what was merged.

We're talking past each other. You're describing issues that come up during the git workflow. I'm talking about production bugs.

You're being quite cryptic in this entire thread and I to be honest I have no idea what you're talking about any more.

Re: Extremely Linear Git History

#343

Post by Beltalowda »

ycombobreaker wrote: post #310
Beltalowda wrote: post #200

Earlier quoted context omitted.

> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…

> arguably I shouldn't have all these long-lived branches in the first place (but it works well for me, so...) Given that this scenario is common for you but sounds contrived to others, I would argue that this doesn't work well for you. It's just familiar enough that you're willing to deal with some pain. Short-lived feature branches sidestep this hell. Longer-lived projects can almost always be partitioned into a se…

It's not a organisational/manager problem; it's just how I like to work. I often work on something and then I either get bored with it or aren't quite sure what the best way is to proceed, so I work on something else and come back to it later (sometimes hours later, sometimes days, weeks, sometimes I keep working on it until I get it right). I do this with my personal projects as well where I can do whatever I want.

I know some people think this is crazy, but it works well for me and I'm fairly productive like this, usually producing fairly good code (although I'm not an unbiased source for that claim).

In the end I don't want to radically change my workflow to git or other tooling; I want the tooling to adjust to the workflow that works well for me.

Re: Extremely Linear Git History

#344

Post by Beltalowda »

frant-hartm wrote: post #264
Beltalowda wrote: post #200

Earlier quoted context omitted.

> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…

Doesn't git's rerere help here?

I looked at it before and decided it was too "magic" and it frightened me.

So probably? But I want to avoid https://i.redd.it/jdqjhi8qv3x71.jpg

Re: Extremely Linear Git History

#345

Post by latexr »

smcameron wrote: post #308
infogulch wrote: post #245

Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash. If you want more detail about the development of the PR…

Did you even read the article? This article is about perversely forcing the commit hashes to come out a certain way for lulz.

From the guidelines[1]:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".

[1]: https://news.ycombinator.com/newsguidelines.html

Re: Extremely Linear Git History

#346

Post by broeng »

michaelt wrote: post #128
broeng wrote: post #91

Earlier quoted context omitted.

In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.

Sounds like you've never worked on a project with a file everyone wants to append to :) If every error in your system needs a separate entry in the error enum, or every change needs an entry in the changelog - loads of changes will try to modify the last line of the file.

Oh, I have. :-)

I'm not saying these situations are impossible. But you can work towards reducing when they arise. If everyone needs to change the same file, then it sounds like something should be refactored (it's probably a quite big file as well?).

If every error needs to go to the same error enum, that sounds like an error enum that might benefit from being split up.

And if every change needs to write to a common changelog file, I would personally find a new way to produce that changelog.

If it's that big a painpoint, then I would look into different ways to get around it.

Re: Extremely Linear Git History

#347

Post by broeng »

collinvandyck76 wrote: post #184
broeng wrote: post #91

Earlier quoted context omitted.

In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.

It's not as contrived as you may think. I, along with what I imagine are many others, do a lot of frequent micro-commits as time goes on and the feature becomes more complete, with a lot of commits in the same area of any given file. Rebasing a development branch in this state is pretty gnarly when a conflict arises. Sadly, my current approach is to just reset my development branch to the merge base and make one huge…

I do a lot of micro-commits as well, though I rarely find that other members of my team are doing the same, to the same files, at the same time.

When that happens, we look into if it's possible to do more frequent merges (fast-forward rebases through Gerrit, to be specific) of our smaller commits to master, so we don't accumulate too much in isolation.

I find it helps reducing bugs as well, if two or more members are doing active work in the same area in that way, it's not good to be working in complete isolation as it just opens up for bugs because of incompatibility with the work going on in parallel.

Re: Extremely Linear Git History

#348

Post by broeng »

simiones wrote: post #172
broeng wrote: post #91

Earlier quoted context omitted.

In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.

It happens pretty often when two different people are adding a new function in the same area of a file. It's likely that as you're working on that function, you'll be modifying the surrounding lines a few times (say, you have a first pass for the happy path, then start adding error handling in various passes; or, handling one case of an algorithm in each commit). Rebase is still by far the most common case in our rep…

It definitely can, and it also sometimes happens to us.

But we try to reduce the chance this happens quite a bit, by avoiding letting files grow too big, for example.

Other things we do, is use codeformatting with rules that reduce the chance of merge conflicts. For instance, instead of having imports like:

  import SomePackage.{A, B, C}
we format it to:

  import SomePackage.A
  import SomePackage.B
  import SomePackage.C
That alone helps a lot. Other formatting rules that avoid dense lines, and instead splits over multiple lines also have a huge impact on merge-conflicts.

Re: Extremely Linear Git History

#349

Post by eru »

chrismorgan wrote: post #56
eru wrote: post #46

Earlier quoted context omitted.

You realise that this is a joke project?

I would not call this a joke project. It’s a fun and optional sort of a thing, but there’s no reason why you shouldn’t take it seriously, provided your approach to work makes it compatible.

Why would you want to take it serious?

Re: Extremely Linear Git History

#350

Post by kevincox »

kinduff wrote: post #17

See also Lucky Commit [0], which uses various types of whitespace characters instead of a hash inside the commit, which makes it look more magical. I wonder about performance, though. Why is the author's method slower than the package I linked? [0]: https://github.com/not-an-aardvark/lucky-commit

I figured that a good option would be to slightly change the date. I don't know what the date resultion us but shuffling it around by a bit shouldn't be an issue.

Of course if the date only has seconds resolution it may be to big of a shift to be reasonable.

Post reply on HN