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

The git history command

lalitm.com

Post reply on HN
Print view View original

301–310 of 330 posts

Re: The git history command

#301

Post by skydhash »

WorldMaker wrote: post #298
skydhash wrote: post #297

Earlier quoted context omitted.

> you have an opportunity to drill down into the even smaller specific change inside that PR that introduced the issue. But what would be the point? Let’s say you found an issue in the first commit of the PR (assuming it’s curated and every commit can compile). But the PR is atomic, and later commits rely on the assumption made in the first one. You would need to replay the later changes as well to figure out the imp…

The point is your ability to find needles in a haystack increases . A PR often is bigger than a 10-line change, but is often made up of smaller 10-line changes. The ability to drill down with a second `git bisect` run (now with a known base and end commit, and even the ability to again use `--first-parent` to ignore merges inside the PR commit range) into the original contents of the PR is the ability to automate fin…

> Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack

But the PR is one single atomic changes. even if it 100 or 1000 lines. This very measure makes it easy to review because there’s only one assumption change PR A (the good one) and PR B (the bad one and and also the current one).

Don’t forget that the codebase will also have several modules. With just one single patch, I can see which modules are affected and then reason where the bug may be. Using merge may not have helped as the 10 line changes in an individual commit may have been because that’s where I integrated stuff that was unused in the previous commits before the merge. That’s why an holistic view matters.

> Spotting them after a rebase/squash happened is sometimes impossible because there's no unique record of the conflict resolutions unlike with a merge commit

That’s something I never needed because the only thing that matters is codebase at state A, and codebase at state B, and the diff between those two states. Ideally, a single reason for the transition between the two.

Re: The git history command

#302

Post by WorldMaker »

skydhash wrote: post #301
WorldMaker wrote: post #298

Earlier quoted context omitted.

The point is your ability to find needles in a haystack increases . A PR often is bigger than a 10-line change, but is often made up of smaller 10-line changes. The ability to drill down with a second `git bisect` run (now with a known base and end commit, and even the ability to again use `--first-parent` to ignore merges inside the PR commit range) into the original contents of the PR is the ability to automate fin…

> Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack But the PR is one single atomic changes. even if it 100 or 1000 lines. This very measure makes it easy to review because there’s only one assumption change PR A (the good one) and PR B (the bad one and and also the current one). Don’t forget…

I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that maybe read the wrong advice and got too eager in using a rerere cache only for it to cache bad regressions. Another engineer that missed a memo somewhere and regularly mismerges a feature thinking that work in progress is actually legacy code. A third engineer that accidentally committed temporary code used for testing that was more obvious looking at the exact commit where it was made than the PR it was made in.

There are so many such scenarios where more information is better. If you've got a good PR tool it might save caches of those branches pre-squash some amount of time and you can do some of that sort of archeology in your PR tool, but even GitHub will sometimes garbage collect PR commits from deleted branches eventually.

The git DAG being a two-dimensional data structure is a useful tool. I find that I want to preserve as much information as possible, including using `git merge --no-ff` in additional scenarios that many use `git rebase` for because I don't know when I will need that (integration or testing or process change) information, but if I find that I need that information it is good to have it.

It's related to the same reason we don't throw out commit messages on ancient commits. In my experience, no matter how outdated that information gets, you are going to find surprising reasons to need it. Source control isn't just about recent history, even if that is most of your day-to-day needs. Sometimes you do need to revisit the past and you don't always know exactly what you will need from that past until you do need that information search.

Re: The git history command

#303

Post by kazinator »

inigyou wrote: post #282
kazinator wrote: post #125

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!

Don't change old commits. Change commits you haven't pushed yet.

That's not for you to dictate to someone about some project you have no idea about.

Git is not a religion or cult.

Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed upstream; they will refer to garbage objects that exist in your repo only, and which will eventually disappear for you too.

Re: The git history command

#304

Post by kazinator »

kazinator wrote: post #125

The thing is, when you are rewriting history to change an old commit, you have to solve the little problem that git commit messages refer to hashes such as: This regression was caused in on December 19, 2017. The fixup and rewrite of history has to ferret out these has references and fix them to the new hash of the same commit. I have scripted this before!

By the way, the proper job of doing this recognizes abbreviated hashes also and fixes them up to equally abbreviated hashes.

Re: The git history command

#305

Post by skydhash »

WorldMaker wrote: post #302
skydhash wrote: post #301

Earlier quoted context omitted.

> Sure, you can probably comb the complete 100 or 1000 or 10,000 line PR to find the exact lines that caused that regression, you've narrowed down already to one useful haystack But the PR is one single atomic changes. even if it 100 or 1000 lines. This very measure makes it easy to review because there’s only one assumption change PR A (the good one) and PR B (the bad one and and also the current one). Don’t forget…

I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that maybe read the wrong advice and got too eager in using a rerere cache only for it to cache bad regressions. Another engineer that missed a memo somewhere and regularly mismerges a feature thinking that work in progress is actually legacy code. A third en…

> I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that […] looking at the exact commit where it was made than the PR it was made in.

That mostly a staple of the merge workflows where people are crisscrossing merges all over the place. At the end you have those horrendous diffs.

A rebase (and squash) only considers the tip of the main branch (which is a working state) and add changes that bring it to the next working state. You’re always aware of the latest working model of the code because that’s the starting point of your work (not something from $days ago). There’s no bad merges in the history of the PR branch.

Re: The git history command

#306

Post by jcon321 »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

yea i agree, the people who defend perfect git history are most likely not enforcing pull/merge requests. why would I care to look at git history when a pull/merge request is way more informative? they then back it up by saying how rebase is so much better than merge, but yet when you git blame a line of code that was merged and not rebased it's going to indicate the pull/merge request which is going to link back to a requirement. sorry for the harsh comments from these people about you, because imo perfected git history is actually the lazy approach instead of proper change/requirement management

Re: The git history command

#307

Post by WorldMaker »

skydhash wrote: post #305
WorldMaker wrote: post #302

Earlier quoted context omitted.

I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that maybe read the wrong advice and got too eager in using a rerere cache only for it to cache bad regressions. Another engineer that missed a memo somewhere and regularly mismerges a feature thinking that work in progress is actually legacy code. A third en…

> I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that […] looking at the exact commit where it was made than the PR it was made in. That mostly a staple of the merge workflows where people are crisscrossing merges all over the place. At the end you have those horrendous diffs. A rebase (and squash) only c…

I've seen some really bad trainwreck merges in rebase heavy workflows, too. (Unwinding them is awful.) Rebases create just as many merge conflicts as merge commits do [0], but rebases don't save the evidence for them. Just because the evidence was lost of them doesn't mean the merge conflict markers were never there.

Any time you integrate two branches, no matter how long running or short running, you have possible merge conflicts. Like I said, I prefer keeping that integration log as a tangible source control artifact. I understand how many people don't care for it. But don't mistake it for solely an aesthetic choice. Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way.

[0] ETA: Merge conflicts are not just a technical issue, but a communications and coordination issue. Software development is a social activity and as long as it is a social activity it creates merge conflicts.

Re: The git history command

#308

Post by jolmg »

ellefire wrote: post #137
jolmg wrote: post #46

Earlier quoted context omitted.

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the chan…

It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive

I mean, that's a positive feedback loop. It takes longer to review, because they're expecting them to be big. Big PRs/MRs are left there until there's a big enough free time block to tackle and discuss. If the PRs are small, obvious things, they can be merged in minutes.

(Depending on what the PR's about and how the team organizes. Ideally, there's consensus on the goals or who's responsible for what. Reviews can be limited to finding bugs and e.g. organizational problems)

Re: The git history command

#309

Post by skydhash »

WorldMaker wrote: post #307
skydhash wrote: post #305

Earlier quoted context omitted.

> I've had to deep regression analysis and archeology to make sure that regressions aren't recurring or stop recurring, because regressions can recur. An engineer that […] looking at the exact commit where it was made than the PR it was made in. That mostly a staple of the merge workflows where people are crisscrossing merges all over the place. At the end you have those horrendous diffs. A rebase (and squash) only c…

I've seen some really bad trainwreck merges in rebase heavy workflows, too. (Unwinding them is awful.) Rebases create just as many merge conflicts as merge commits do [0], but rebases don't save the evidence for them. Just because the evidence was lost of them doesn't mean the merge conflict markers were never there. Any time you integrate two branches, no matter how long running or short running, you have possible m…

I do agree that merge conflicts are a signal of a deeper collaboration issue.

> Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way.

I don’t agree that retaining them is necessary. Merge workflows encourage long running branches. Sometimes divergence in understanding does not create conflicts and that’s how regression happens.

With most rebase workflow, the commit list is often kept short (which is why squashing them is often correct). Most of mine have been below five. Such patch is easy to review and reason according to the latest knowledge of the code. Also easier to cherrypick and apply to an old version of the code.

Re: The git history command

#310

Post by LtWorf »

skydhash wrote: post #250
LtWorf wrote: post #240

Earlier quoted context omitted.

Good for you that we don't work together, because for sure I'd reject all of your pull requests until you learn :D This could probably be helpful https://mtlynch.io/code-review-love/

The only point not addressed by reviewing changes at a PR level instead of a commit level is 7. Break up large changelists First a PR shouldn’t introduce scope screep, where you are actually introducing more than one change. And second. Instead of changing everything at once, can you change the dependencies first and add the new feature in a subsequent changelist? Can you keep the codebase in a sane state if you add…

Great! Now your bisect won't tell you if the issue is caused by the dependency or the use of the dependency and you will have to do more manual investigation!

Certainly a way to do things. Not the most useful or productive… but it's a way for sure.

Post reply on HN