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

261–270 of 546 posts

Re: Git commands I run before reading any code

#261

Post by vntok »

berkes wrote: post #243
ramijames wrote: post #124

Earlier quoted context omitted.

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

I once tutored an intern. Who thought he was The Best Programmer On Earth (didn't we all at that age?). He refused to use revision control, it slowed him down. So we told him to commit at least once every day, with a relevant commit message, or else fail his internship. He worked 21 more days. There were 21 commits: "17:00, time to go home".

This reads like the intern was left to his own devices and his output not checked at all for three weeks straight. Actual tutoring would have surfaced the issue after 1 or 2 days tops.

Re: Git commands I run before reading any code

#262

Post by l72 »

skydhash wrote: post #103
seba_dos1 wrote: post #28

Earlier quoted context omitted.

I don't think there's much nuance in the "I don't know --first-parent exists" workflow. Yes, you may sometimes squash-merge a contribution coming from someone who can't use git well when you realize that it will just be simpler for everyone to do that than to demand them to clean their stuff up, but that's pretty much the only time you actually have a good reason to do that.

Do people actually share PR as in different people contributing to the same branch? Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.

We do. If we are building out a feature, none of its code is merged into main until it is complete (if this is a big feature, we milestone into mergeable and releasable units).

The feature is represented by a Story in Jira and a feature branch for that story. Subtasks in jira are created and multiple developers can pick up the different subtasks. There is a personal branch per subtasks, and PRs are put up against the feature branch. Those subtasks are code reviewed, tested, and merged into the feature branch.

In the end, it is the feature branch that is merged (as a single merge commit and complete unit) into main, and may well have had contributions from multiple people.

Re: Git commands I run before reading any code

#263

Post by ramijames »

ryandrake wrote: post #193
ramijames wrote: post #124

Earlier quoted context omitted.

This is a team lead/CTO problem. A good leader will be explicit in their expectations that developers write good commit messages. I've certainly had good leaders that expect this.

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…

Indeed. If you can't spend two minutes (MAX) writing a sentence or two explaining what the commit is for, then what are we doing as developers? Commits are for future you and your future team. They are a tool. Please, use them.

Re: Git commands I run before reading any code

#265

Post by duckmysick »

SoftTalker wrote: post #210
ziml77 wrote: post #171

Earlier quoted context omitted.

That was my question too. I have plenty of projects I've worked on where they rarely get touched anymore. They don't need new features and nothing is broken.

Is it fair to say they are being "worked on" if nothing is being done?

Sometimes you need to bump a dependency version, adjust the code to a changed API endpoint, or update a schema. Even if the core features stay the same, there's some expected maintenance. I'd still call that being worked on, in a sense that someone has to do it.

Re: Git commands I run before reading any code

#266

Post by dheera »

freedomben wrote: post #180
crispyambulance wrote: post #129

Earlier quoted context omitted.

I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice. That said, the OP's commands are…

> I am convinced that the vast majority of professionals simply don't bother to remember and, ESPECIALLY WITH GIT, just look stuff up every single time the workflow deviates from their daily usage. I wrote a cheat sheet in my notes of common commands, until they stuck in my head and I haven't needed it now for a decade or more. I also lean heavily on aliases and "self-documenting" things in my .bashrc file. Curious h…

I just use Claude Code as a terminal for git these days. It writes up better commit messages than I would write anyway. No more "git commit -m fix"

Re: Git commands I run before reading any code

#267

Post by l72 »

mcpherrinm wrote: post #64
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…

Squash merge is the only reasonable way to use GitHub: If you update a PR with review feedback, you shouldn’t change existing commits because GitHub’s tools for showing you what has changed since your last review assume you are pushing new commits. But then you don’t want those multiple commits addressing PR feedback to merge as they’re noise. So sure, there’s workflows with Git that doesn’t need squashing. But they’…

If your goal here is to have linear history, then just use a merge commit when merging the PR to main and always use `git log --first-parent`. That will only show commits directly on main, and gives you a clean, linear history.

If you want to dig down into the subcommits from a merge, then you still can. This is useful if you are going back and bisecting to find a bug, as those individual commits may hold value.

You can also cherry pick or rollback the single merge commit, as it holds everything under it as a single unit.

This avoids changing history, and importantly, allows stacked PRs to exist cleanly.

Re: Git commands I run before reading any code

#269

Post by konovalov-nk »

To me all of these are symptoms of the problem that I outlined in my recent blog post: https://news.ycombinator.com/item?id=47606192

and it touches in detail what exactly commit standards should be, and even how to automate this on CI level.

And then I also have idea/vision how to connect commits to actual product/technical/infra specs, and how to make it all granular and maintainable, and also IDE support.

I would love to see any feedback on my efforts. If you decide to go through my entire 3 posts I wrote, thank you

Re: Git commands I run before reading any code

#270

Post by limaoscarjuliet »

stingraycharles wrote: post #85
pzmarzly wrote: post #3

Jujutsu equivalents, if anyone is curious: What Changes the Most jj log --no-graph -r 'ancestors(trunk()) & committer_date(after:"1 year ago")' \ -T 'self.diff().files().map(|f| f.path() ++ "\n").join("")' \ | sort | uniq -c | sort -nr | head -20 Who Built This jj log --no-graph -r 'ancestors(trunk()) & ~merges()' \ -T 'self.author().name() ++ "\n"' \ | sort | uniq -c | sort -nr Where Do Bugs Cluster jj log --no-grap…

I don’t understand how people can remember all these custom scripting languages. I can’t even remember most git flags, I’m ecstatic when I remember how to iterate over arrays in “jq”, I can’t fathom how people remember these types of syntaxes.

Some things are idioms that one repeats so often they just stick, e.g. I use "grep.... | cut -c x-y | sort | uniq -c | sort -nr" to quickly grep frequency of some events from a log file.

Don't feel bad - no one remembers them all, we just remember a few idioms we use...

Post reply on HN