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

101–110 of 330 posts

Re: The git history command

#101

Post by knodi123 »

quacked wrote: post #96
nativeit wrote: post #31

I don’t consider myself a coder or programmer, but learning git was like an organizational superpower for my particular brain wiring. I use it for websites, design projects, electronics engineering, music composition, personal knowledge bases, remote administration scripts, config management, snippets, so many applications and so many features for one system. It’s not always perfect, but I tell everyone I work with t…

How do you use it for music composition?

there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.

Re: The git history command

#102

Post by seba_dos1 »

knodi123 wrote: post #101
quacked wrote: post #96

Earlier quoted context omitted.

How do you use it for music composition?

there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.

Also, files don't have to be text-based at all to version them with Git. When you're versioning things for your own sake, there's often not much difference between keeping text and binary files there, as it's not like you'll have to resolve an unexpected conflict.

Re: The git history command

#103

Post by nextlevelwizard »

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.

How do I know you don’t work in a big team from this?

First thing I do every time I come back from vacation is to read through our git history to see what has happened.

It is also very useful when CI breaks. In fact I probably use some form of git history reading every day at work.

Also if your code base is so tiny and the features you work on are so small that you can just squash everything then maybe that is fine for you. I definitely love being able to actually see what is going on and selectively cherry picking or reverting commits

Re: The git history command

#104

Post by seba_dos1 »

bulatb wrote: post #86
seba_dos1 wrote: post #75

Earlier quoted context omitted.

Had you actually read what I wrote, you would rather summarize it as "Git is showing exactly what's going to happen when you attempt to do it, all you have to do to make is pleasant is to not ignore it". Reading things requires unpleasant effort though, I get it.

I'm sorry (like actually sorry) if I'm getting into counter-condescension here, but, like... > all you have to do to make is pleasant This is an assumption about what I find unpleasant and why. I take it you think "reading information" and "understanding instructions" are some of those things I don't like. Your conclusion that I must not understand is based on that assumption. The assumption is wrong. If you can gran…

If the assumption was wrong, then your first comment was pretty much useless, and the second one didn't help either as it just describes doing things carelessly and without proper understanding. So if that reading of it is wrong, then it was just complaining for complaining's sake and not about Git at all, but rather about what you happen to find scary for some undisclosed reason?

People do have genuine troubles with these behaviors when they don't grasp what's going on well enough. These troubles go away pretty much entirely once they do. I think explaining them is the only thing one could write in such thread that will be useful to anyone, as the Git's UX already does make a pretty good effort to help the user orient themselves in these cases and has been visibly improving in this regard over time.

Re: The git history command

#105

Post by plorkyeran »

what wrote: post #20
hahahaa wrote: post #12

I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

You probably shouldn’t be committing things that are broken…

You should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.

Re: The git history command

#106

Post by jmholla »

jolmg wrote: post #15
catlifeonmars wrote: post #9

Earlier quoted context omitted.

Do you use git reflog?

One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.

Fun fact: you don't even need the `-n`. `git log -1` does the same thing, for any number.

    -, -n , --max-count=
        Limit the output to  commits.

Re: The git history command

#107

Post by rmunn »

seba_dos1 wrote: post #102
knodi123 wrote: post #101

Earlier quoted context omitted.

there are plenty of text-based digital music notation systems. Then, you commit periodically as your composition evolves, and you can have all the history/fork/undo whatever that you might want.

Also, files don't have to be text-based at all to version them with Git. When you're versioning things for your own sake, there's often not much difference between keeping text and binary files there, as it's not like you'll have to resolve an unexpected conflict.

I find it really useful to be able to diff two commits, which if you're using a binary format is only possible if you have a meaningful-diff tool for that format. Some formats have one already created, more formats don't. (Though these days, an LLM might be able to produce something suitable).

Re: The git history command

#108

Post by jmholla »

chandlerswift wrote: post #77

I've been theoretically a big fan of these commands; I use the `jj` equivalents all the time. The roadblock I've run into is that I as far as I can tell (from the man pages and the git source code) there's no way to get `git history` commands to sign commits they modify: $ git log --oneline --show-signature # look ma, I signed my commits! 3a1dd8f gpg: Signature made Mon 13 Jul 2026 10:45:50 PM CDT gpg: using RSA key…

Woah! That feels like a huge oversight and like it bypasses standard commit logic. The man pages do say `git history` is experimental. Sounds worth a bug report.

Re: The git history command

#109

Post by fragmede »

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.

Hell yes we are! Just because you aren't going to doesn't mean nobody else is going to.

Re: The git history command

#110

Post by bonzini »

fcarraldo wrote: post #70
jxf wrote: post #61

Earlier quoted context omitted.

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

Mine aren’t full of “oops” and “fix” messages, because I squashed them.

So you're "spending effort in perfectly curating git history" and agreeing with your parent comment.
Post reply on HN