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

511–520 of 546 posts

Re: Git commands I run before reading any code

#511

Post by shiroiuma »

crispyambulance wrote: post #129
stingraycharles wrote: post #85

Earlier quoted context omitted.

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.

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

Partly that, but for me at least, I have a bunch of simple bash scripts and aliases for things I do frequently. Git makes this really easy because you can set aliases for lots of custom commands in the .gitconfig file.

Re: Git commands I run before reading any code

#512

Post by mi_lk »

rstuart4133 wrote: post #470
beanjuiceII wrote: post #369

Earlier quoted context omitted.

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

> That said, if you are starting out - I'd suggest starting with jj instead of git

That wouldn't be my advice if you're going to work with other people. You can't know jj without knowing git well enough to fall back in general

Re: Git commands I run before reading any code

#513

Post by 946789987649 »

lossyalgo wrote: post #482
rcfox wrote: post #424

Earlier quoted context omitted.

Maybe you need to make shorter PRs?

haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal). To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.

Why can code even go in with breaking tests? They shouldn't even have the power to do that.

Re: Git commands I run before reading any code

#514

Post by seba_dos1 »

ric2b wrote: post #502
psalaun wrote: post #214

Earlier quoted context omitted.

git bisect gets more useful because it will pin a smaller set of changes

But it will run into so many more broken commits...

Broken commits shouldn't be merged in the first place, you're supposed to review every commit in the MR anyway.

But even if you don't, you're just one command line parameter away from making bisect behave exactly as if you had squashed them should you need it.

Re: Git commands I run before reading any code

#515

Post by lossyalgo »

946789987649 wrote: post #513
lossyalgo wrote: post #482

Earlier quoted context omitted.

haha as if. I mostly do bugfixes, small features, and otherwise most of my PRs are just unit text fixes so that our CI jobs run again (because my colleagues don't seem to care about breaking tests, so I get to fix everyone's tests, so that QA doesn't go postal). To put it into numbers: my PRs are usually less than 5 files changed, and very little changes in those files.

Why can code even go in with breaking tests? They shouldn't even have the power to do that.

Because each job only runs once in the middle of the night when it detects any changes. Also a lot of our tests are very finicky and need to be restarted multiple times before they run successfully, so a failing test isn't necessarily an indication of bad code. On top of that, a lot of our tests are not actually testing anything useful, they are merely fulfilling the customer requirements from specifications - the only useful test for a lot of these requirements are full system tests, which are not easily automated since there are a lot of complex interconnected systems involved with expensive physical hardware that would not be easy to fake.

Re: Git commands I run before reading any code

#516

Post by seba_dos1 »

mgfist wrote: post #115
mcpherrinm wrote: post #64

Earlier quoted context omitted.

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

Yes, I think people who are anti squash merge are those who don't work in Github and use a patch based system or something different. If you're sending a patch for linux, yes it makes sense that you want to send one complete, well described patch. But Github's tooling is based around the squash merge. It works well and I don't know anyone in real life who has issues with it. And to counter some specific points: * In…

> If you had to force overwrite your whole commit chain for the PR, this becomes very annoying and not useful to reviewers.

I'd say that optimizing for reviewers who don't know "git range-diff" exists has even less merit that optimizing for contributors who don't know how to edit their commit graph.

I'm regularly using GitHub, GitLab, Gerrit, Phabricator and mailing lists and while some make it more pleasant than others, none of them really put any actual obstacles on your path when manipulating the commit graph mid-review.

Re: Git commands I run before reading any code

#517

Post by wwader »

NoSalt wrote: post #313
stingraycharles wrote: post #85

Earlier quoted context omitted.

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.

So, how does one iterate over an array in jq? Asking for a friend.

Assume input is an array you can do it several ways depending on what you want:

    # output each value in the array separately 
    .[]

    # output each value but transform it in some way
    .[] | . * 2


    # map each value into a new array
    map(. * 2) 

    # same as above but manual iterate/collect
    [.[] | . * 2]

Re: Git commands I run before reading any code

#518

Post by mystickphoenix »

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…

Likely my own personal bias, but I have never once found git log/commit messages to be useful when debugging or understanding what happened. I'm sure that others do so I try to write useful commits (conventional commits syntax is helpful here) but I'd much rather spend my time and effort understanding the current state of the codebase instead of trying to diagnose how "fixed bug related to file naming" relates to a website going down.

Re: Git commands I run before reading any code

#519

Post by berkes »

vntok wrote: post #261
berkes wrote: post #243

Earlier quoted context omitted.

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.

Oh, but I had a daily sit down and addressed this and other issues several times.

The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked.

This was my first encounter with a self-proclaimed "10x" developer before that term existed. Someone who - as seen by far off management - seemingly have a high output, but in reality just create a trail of tech-debt and work for the rest of the team.

Re: Git commands I run before reading any code

#520

Post by michaelcampbell »

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.

`jq` and `ffmpeg` were two of my very early uses of LLM's for daily ease.
Post reply on HN