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

Git commands I run before reading any code

piechowski.io

Post reply on HN
Print view View original

461–470 of 546 posts

Re: Git commands I run before reading any code

#461

Post by PUSH_AX »

account42 wrote: post #460
PUSH_AX wrote: post #300

Earlier quoted context omitted.

Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc. It feels like we're trying really hard to stretch the utility of commit messages here...

So rather than commit messages that stay in the repo you want the information in a place where its lost by the next buck tracker migration?

Look, I'll make this easy to understand. The parent comment that this stems from said:

> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.

Re: Git commands I run before reading any code

#462

Post by HeinrichAQS »

bsuvc wrote: post #90

I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if de…

One big problem about commit messages is, that you write them from your perspective. If you write them while activly engaged with the topic and changes you are very heavily biased and might miss things which are obvious to you but not to future readers with less knowledge. I think abstracting your personal opinion is quite hard - I agree that LLMs are perfectly fitting for writing this since they just dont have a "personal opinion". Atleast I made the mistake in the past many times focusing on the things which were not obvious to me but then leaving out the non obvious things for others.

Re: Git commands I run before reading any code

#463

Post by fishbacon »

Excellent set of commands.

Of course the two most useful ones would never be useful in the code base I am currently working on.

"fix" might be the single most common commit message, and after that comes "."

Trying for two years, to get people to include at least some information in their commit messages, has exhausted me.

Re: Git commands I run before reading any code

#464

Post by seba_dos1 »

Noumenon72 wrote: post #197
seba_dos1 wrote: post #94

Earlier quoted context omitted.

Nothing is destroyed by a force push. It just overwrites a single pointer, and even keeps its old value in reflog. Things that aren't referenced by anything anymore will eventually get garbage collected and actually destroyed, but you can just keep a reference somewhere to prevent that from happening if you need. Or even disable garbage collection completely. Looks like people's fears about git come just from not kno…

You can't use the remote reflog to revert what you force pushed, can you? But I agree that having your local reflog means you're never totally lost. I still just make a branch before major edits so I can go back.

No, but you have local reflogs of remote branches, and if you --force-with-lease you are guaranteed to have the old state stored there.

You can often also access equivalent functionality by platform APIs. For example, GitHub has event API which you can use to check what a ref has pointed to previously.

Re: Git commands I run before reading any code

#465

Post by seba_dos1 »

orsorna wrote: post #224
seba_dos1 wrote: post #97

Earlier quoted context omitted.

Commits don't show "how an engineer approaches a problem". Commits are the unit of change that are supposed to go into the final repository, purposefully prepared by the engineer and presented for review. The only thing you do by squashing on merge is to artificially limit the review unit to a single commit to optimize the workflow towards people who don't know how to use git. Personally I don't think it's a good thi…

Preserving commit history pre-merge only seems useful if I had to revert or rebase onto an interstitial commit. This is at odds with treating PRs as atomic changes to the code base. I might have not stated my position correctly. When I mean "squash on merge", I mean the commit history is fully present in the PR for full scrutiny. Sometimes commits may introduce multiple changes and I can view commit ranges for each s…

"Tell me you don't have to debug foreign codebases often without telling me" ;)

The primary value of commit history comes from blame, bisect and corresponding commit messages. There's no reason to "treat PRs as atomic changes to the code base", commits are already supposed to be that and PRs are groups of commits (sometimes groups of size 1, but often not).

> When I mean "squash on merge", I mean the commit history is fully present in the PR for full scrutiny.

And when you merge the set of commits prepared by the author for review in, you get both "summations" and individual commits stored in the commit graph (where their place is) and you get to choose which way you want to view them at retrieval time without having to dig up things outside of the repository. Sometimes it's useful to see the summations only ("--first-parent"), sometimes you only want the individual atomic changes ("--no-merges"), sometimes you want to see them all but visually grouped together for clarity ("--graph"). When you squash on merge, you just give all that flexibility away for no good reason.

It's a commit graph, not a commit linked list, so treat is as such.

Re: Git commands I run before reading any code

#466

Post by zimpenfish »

bsuvc wrote: post #90

I love how the author thinks developers write commit messages. All joking aside, it really is a chronic problem in the corporate world. Most codebases I encounter just have "changed stuff" or "hope this works now". It's a small minority of developers (myself included) who consider the git commit log to be important enough to spend time writing something meaningful. AI generated commit messages helps this a lot, if de…

> Most codebases I encounter just have "changed stuff" or "hope this works now".

I have been told off several times at different jobs for writing commit messages that are "too big". Also for writing too much commentary in my code changes. Also also for complaining that other people aren't doing these things.

(Not that it stops me, mind, but it does make working relationships fractious.)

Re: Git commands I run before reading any code

#467

Post by zimpenfish »

lossyalgo wrote: post #230
ryandrake wrote: post #193

Earlier quoted context omitted.

Yes, and a culture problem, too. I guess I've been blessed that I've mostly only worked for "grown up" companies, but I've never encountered a workplace where people didn't write useful commit messages. At least one line description of the work done, but often multiple lines of valuable context. Only the junior devs had to be told to do it, but once they got into the habit, everyone understood why we do it and it was…

Good commit messages would be nice but honestly I would be over the moon if our pull requests would be approved within a week without having to ping one or more people.

> if our pull requests would be approved within a week

A week? LUXURY. I'd be happy to get PRs approved without a week of fighting over stupid trivial nonsense[0]

[0] [flashbacks to the "which way of defining Perl constants is faster" week of hell]

Re: Git commands I run before reading any code

#468

Post by zimpenfish »

mewpmewp2 wrote: post #382
hbn wrote: post #363

Earlier quoted context omitted.

One of the best developers I work with commits everything with the message "changes" (This is not an endorsement to do that, he's a good developer in spite of his shitty commit messages)

Obviously a very unpopular opinion, but I guess for my own sake it's hard to write commit messages, because for me it's that I have never really even found use of other people commit messages, and I rarely even attempt to. Ultimately code is code and I don't care about how it got to how it is. I got same issue with documentation and comments or really anything that isn't building stuff. I don't like writing it, don't…

> Ultimately code is code and I don't care about how it got to how it is.

That's fine until you come up against something like a subscription system that's been built over 15 years by at least 20 different developers, none of whom are currently at the company, half of whom appear to have been clinically insane, each of whom had their own unique approach to code, with almost zero code commentary, zero external documentation, and abstractions layered like geological strata where you need 15 files open to understand one API endpoint.

Re: Git commands I run before reading any code

#469

Post by seba_dos1 »

LinXitoW wrote: post #137
seba_dos1 wrote: post #8

> If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Squash-merge workflows are stupid (you lose information without gaining anything in return as it was easily filterable at retrieval anyway) and only useful as a workaround for people not knowing how to use git, but git stores the author and committer names separately, so it doesn't matter who merged, but rather wheth…

How does not squash merging deal with the fact that branches disappear when merging? What I mean is that the information "this commit happened in the context of this PR or this overarching goal" goes missing. When you squash, you use the one central unit of information management in Git: the commit.

The commit graph is a full-blown DAG that you can operate on and form in any way you like that helps you achieve your goals. When merging something in you get back pointers to (at least) two parents that let you see what came from which branch, and a merge commit has its own commit message that lets you describe overarching goals. Even when doing rebase-before-merge flow you can still group things by merge commits, which are often used to have PRs referenced in the repository while keeping the history effectively linear and easy to browse. This way you keep the one central unit of information management in Git representing what it's supposed to - the atomic unit of change that you can build upon and traverse in various ways depending on context, rather than force larger things to squeeze into it for no good reason.

(and if you hadn't squashed on merge, short-lived branches wouldn't even "disappear" in the first place as you would still see them decorated in "git log" on commits that were merged in)

Re: Git commands I run before reading any code

#470

Post by rstuart4133 »

beanjuiceII wrote: post #369
tcoff91 wrote: post #354

Earlier quoted context omitted.

I rebase stacked diffs all the time so jj makes my life so much easier because its rebasing is much more ergonomic than git.

this seems very easy in git tho how much easier can it get, do you have an example of each of them?

As someone else said, jj comes into its own when a reviewer insists you split your PR into many commits, because they don't want to review 13k lines in one chunk. In that case it is easier because there is no rebase. To change a PR commit in the middle of the stack you checkout a PR commit, edit it - and done. The rebase happened automagically.

Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.

If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.

Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.

It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.

That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.

Post reply on HN