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

541–546 of 546 posts

Re: Git commands I run before reading any code

#541

Post by fmbb »

mrunkel wrote: post #538
fmbb wrote: post #353

> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions. Well isn't it typical that the person who wrote is also the person that merged? I have never worked in a place where that is not the norm for application code. Even if you are one of those insane…

Code merges are made by reviewers in my org, not by the author. Spend time educating your team about `git commit --amend` and `git push --force` on their own branches and you don't have to see any of that ugliness.

Squash merges have two upsides:

1. I don’t have to see that ugliness. 2. Nobody has to force push and micro manage commits.

If I recall correctly most code forges will add co-author trailers if someone other than the author squash merges.

Re: Git commands I run before reading any code

#542

Post by hulitu »

PUSH_AX wrote: post #164
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 think it's a stretch to measure leadership quality on something so minor, a lot of teams find them pretty useless no matter how good they are.

> a lot of teams find them pretty useless

They are useless: Google Messages bothers me to upgrade to a new version. I read the changelog: "Bug fixes and performance improvements". Last time they did it it was full of bugs. Really Google: come back when you actually fixed something.

Re: Git commands I run before reading any code

#543

Post by alwillis »

irishcoffee wrote: post #410
crispyambulance wrote: post #380

Earlier quoted context omitted.

Tools, done right, are a joy to use and allow you to be expressive and precise while also saving you labor. Good tools promote mastery and creative inquiry. Git is NOT that. Git is something you use to get stuff done, until it becomes an irritating obstacle course of incidental complexity.

Hg is a joy to use compared to git. Sure wish hg had won.

> Sure wish hg had won.

To me, it's more like GitHub won; Git came along for the ride.

Back in the day when companies evaluated Git and Mercurial (Facebook, Google, Microsoft), they decided Mercurial was better. Mozilla used Mercurial for a long time until switching to Git fairly recently.

But once GitHub took off and became the center of gravity for developers, it became the de facto standard.

It also explains why there have been several attempts (Sapling, JJ) to use Mercurial's semantics as a front-end for Git.

Re: Git commands I run before reading any code

#544

Post by alwillis »

TeMPOraL wrote: post #338
alwillis wrote: post #283

Earlier quoted context omitted.

> 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. Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.

Unless you're aware that such powerful commands are something you need once in a blue moon, and then you're grateful that the tool is flexible enough to allow them in the first place. Git may be sharp and unwieldy, but it's also one of the decreasing amount of tools we still use - the trend of turning tools into toys consumed the regular user market and is eating into tech software as well.

[dead]

Re: Git commands I run before reading any code

#545

Post by compiler-guy »

palata wrote: post #441
sunnyps wrote: post #394

Earlier quoted context omitted.

JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/

But what does that bring? Your code won't compile as long as you don't fix the conflicts, so anyway you have to fix them when you rebase, right?

You have to fix them at some point, but not in the middle of doing other things. Right now. With no possible way to make progress elsewhere while deferring this decision.
Post reply on HN