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

401–410 of 546 posts

Re: Git commands I run before reading any code

#401

Post by herewulf »

SatvikBeri wrote: post #315
rjh29 wrote: post #311

Earlier quoted context omitted.

It's the dvorak of git... Maybe more efficient but incompatible with everyone else and a very loud vocal minority. You can find this pattern again and again. How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?

It's totally compatible though, and that's a big selling point. I use jj and nobody else at my work uses it and that has never been an issue.

Reminds me of how I started using Git when it was up and coming: It was the best Subversion client out there and no one knew I was using it!

Re: Git commands I run before reading any code

#402

Post by hn_throwaway_99 »

lopis wrote: post #209
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…

If developers don't write commit messages, that's a culture problem. At my company we demand that of each other.

Totally agree. One thing I really like about HN is it reminds you that nobody's individual experience is indicative of the industry at large.

The parent comment stated "Most codebases I encounter just have "changed stuff" or "hope this works now"." I worked at 6 tech companies in my career and a slew of contracting gigs, and I literally never encountered the problem of commit messages being uninformative. Most of the companies developed strict rules for commit comments like always including an issue number (with occasional [NO-ISSUE] tags allowed for minor changes) or something like Conventional Commits, https://www.conventionalcommits.org/en/v1.0.0/ .

Re: Git commands I run before reading any code

#403

Post by hamburglar »

jbjbjbjb wrote: post #288
hamburglar wrote: post #228

Earlier quoted context omitted.

The post is “here’s what I do”, not “here’s what you should do and then confront the team about the results.” It’s just showing you a quick way to get some insights. It’s not even guaranteeing it’s accurate, just showing you some things you might be able to draw some quick conclusions on. I’m not sure why HN attracts this need to poke holes in interesting observations to “prove” they aren’t actually interesting.

It’s a bit reductive to call it poking holes. The author shared his valuable knowledge and I shared mine.

You said this analysis “isn’t strong enough” for an inadvisable scenario you completely invented.

Re: Git commands I run before reading any code

#405

Post by deno »

rjh29 wrote: post #347
deno wrote: post #322

Earlier quoted context omitted.

I mean let's not be hasty. Mechanical keyboards used to be just normal keyboards when computers were still computers.

That is a fair argument. I don't know why they dropped out of favour - price? Noise?

Most people and companies just use the keyboard that shipped with the computer. I don't think noise is as much of an issue as people make it out be.

Marketing made up this story about linear switches being for gamers. So now every mechanical keyboard needs to make unnecessary noise and offer extra resistance for harder bottom out or you're not a serious typist.

But that's not inherent to the keyboard. Linear switches are not any louder than cheapo office high-profile membrane.

Re: Git commands I run before reading any code

#406

Post by waisbrot »

sunnyps wrote: post #394
aidos wrote: post #373

Earlier quoted context omitted.

Can you explain how conflicts are not conflicts? If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?

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/

That sounds like https://git-scm.com/book/en/v2/Git-Tools-Rerere ?

Re: Git commands I run before reading any code

#407

Post by renegade-otter »

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…

Many organizations squash their commit messages from PR, where most commits actually happen. Unless everyone is committing to trunk all the time, which almost never happens on a real job, I highly doubt the value of this.

Showing my Git ignorance here, of course - does "ancestors(trunk)" pull in all the commit messages?

Re: Git commands I run before reading any code

#408

Post by irishcoffee »

bluGill wrote: post #299
freedomben wrote: post #180

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. 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 refuse to have alises and other custom commands. Either it is useful for everyone and so I make a change to the upstream project (I have never done this), or it won't exist next time I change my system so there is no point. I do have some custom tools that I am working on that haven't been released yet, but the long term goal is either delete them or release them to more people who will use them so I know it will b…

> I refuse to have alises and other custom commands.

I am the same way, and have caught much flack for it over the years.

But when I sit down at a foreign system (foreign in the sense that I haven't used it before) because something is broken and my help was requested, I don't have any need to lean on aliases.

I worked with someone once that had a very impressive bashrc, and it was very effective for them... on their workstation. Plop them in front of a production system, they can't even remember how to remount / rw because they've been using an alias for so long.

This is also why I learned vi, having started with emacs 30 years ago initially, as it was first taught to me. I know it'll be there, and I know how to use it.

Re: Git commands I run before reading any code

#410

Post by irishcoffee »

crispyambulance wrote: post #380
TeMPOraL wrote: post #338

Earlier quoted context omitted.

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.

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.
Post reply on HN