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

161–170 of 330 posts

Re: The git history command

#161

Post by Cthulhu_ »

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.

I have a more nuanced view of this; in libraries and software projects that span years like Linux, curl, etc, this happens all the time. Bugs get fixed and they can point to the exact commit where it was first introduced, and that commit contains all information necessary to figure out why it was introduced in the first time.

But that's projects like Linux, which is a whole different use case than for example what I do for a living, front-end applications that have at best a lifespan of 10 years and whose individual features / screens / components have less than that, and it's much more rare that an older commit is still relevant today.

(that said, looking history up has made me dislike squash commits. I get it from a pragmatic point of view but it's not ideal)

Re: The git history command

#162

Post by Cthulhu_ »

gbalduzzi wrote: post #112
locknitpicker wrote: post #88

Earlier quoted context omitted.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches

That's one approach, sure, probably works best if your units of work (e.g. everything inside of a PR) are small and atomic though.

Other use cases exist where each individual commit adds value / changes something important / is atomic. Which one is best depends on the use case.

What should definitely be avoided (or, what should not end up in main) is "work log" commits. Many people use git commit like a save / checkpoint operation, that's the kind of thing nobody needs to read. That's the "fix" commits.

Succinct guideline:

Good commits: "When applied, this commit will "

Bad commits: "I did "

Then whether it's one commit or the result of a squash merge it doesn't really matter much anymore.

Re: The git history command

#163

Post by bjackman »

rmunn wrote: post #25
jolmg wrote: post #6

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…

After a rebase, mybranch@{1} refers to the previous location of mybranch, so you don't need to manually track these before-rebase branches etc.

(In practice I find this syntax super annoying and usually end up typing `git reflog mybranch` and then copy-pasting the commit hash from the output).

Re: The git history command

#164

Post by Cthulhu_ »

Myrmornis wrote: post #49
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.

One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

That's one approach I suppose, it leaves evidence of "I wrote a test first" and such.

However, it also feels more like a "work log" than a "commit log"; I like to make my commits atomic (test + code at the same time), so that in theory, each individual commit will pass CI. If you separate them, you can't just revert one commit, you need multiple.

Re: The git history command

#165

Post by Cthulhu_ »

Sharlin wrote: post #155

Huh, TIL about `git commit —fixup`.

Yeah I learned that one a few months ago, before that I'd use interactive rebase and shuffle the commits around manually in the editor that opens.

I appreciate that these commands are just utilities / conveniences on top of a stable base though.

Re: The git history command

#166

Post by hahahaa »

seba_dos1 wrote: post #41
hahahaa wrote: post #38

Earlier quoted context omitted.

I am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)

Remotes aren't equal either. Sometimes the remote is my other machine, sometimes it's a fork on a forge used for producing CI artifacts. It's a good rule of thumb to consider shared branches to be append-only, but not every remote branch is "shared" and, as with any proper rule of thumb, you can always find exceptions.

Ok I amend to what I think I really mean: don't edit history for anything deployed to prod (or released to public or customers) already.

Re: The git history command

#168

Post by ansgar77 »

jxf wrote: post #61
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.

> No one is ever going back and reading individual commits. I violently disagree with this. At a minimum, when I review PRs I look at the commit history to understand what's up. If the path that was taken to commit this is full of "oops" and "fix" messages, it's an immediate reject for me. The commits tell the story and it's a kindness to your human reviewers to not make them work harder to understand the point you'r…

I think that the path that was taken should include mistakes. It's natural that code at some point would contain bugs and mistakes. If anything, your approach would encourage to squash those commits into one just to make it being review-worthy, but that misses the point then.

Re: The git history command

#169

Post by quibono »

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around...

Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day.

Also: does anyone know if `magit` has history support?

Re: The git history command

#170

Post by xorcist »

gbalduzzi wrote: post #112
locknitpicker wrote: post #88

Earlier quoted context omitted.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches

> if you squash the commits when merging the PR?

You tidy up and rebase before making a PR. Anything else is really disrespectful of your reviewer's time. That is also how all the larger open source projects operate.

> you only get one commit for the whole feature

If you are doing one logical commit per PR, you are doing way too many PRs.

Alternatively you don't have a working review process.

Post reply on HN