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

441–450 of 546 posts

Re: Git commands I run before reading any code

#441

Post by palata »

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/

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?

Re: Git commands I run before reading any code

#442

Post by rightofcourse »

PUSH_AX wrote: post #300
mgfist wrote: post #297

Earlier quoted context omitted.

Which circles back to why it's important for leadership to tackle this

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...

Yes, we are on our third ticketing system on our team with dead refs to old issues. PR without a commit documenting why you need a change does not normally get approved and helps a lot also at present and future review time. Lots of value for new devs to see how thinking went and why something exist and not something else etc.

Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.

Re: Git commands I run before reading any code

#443

Post by account42 »

rjh29 wrote: post #311
palata wrote: post #4

Earlier quoted context omitted.

To me, it makes jujutsu look like the Nix of VCSes. Not meaning to offend anyone: Nix is cool, but adds complexity. And as a disclaimer: I used jujutsu for a few months and went back to git. Mostly because git is wired in my fingers, and git is everywhere. Those examples of what jujutsu can do and not git sound nice, but in those few months I never remotely had a need for them, so it felt overkill for me.

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?

> How many redditors say 120fps is essential for gaming or absolutely require a mechanical keyboard?

Those don't fit the others - they don't really require the user to adapt or are more complex in any way but are just nicer versions of the standard.

Re: Git commands I run before reading any code

#444

Post by grepsedawk »

nozzlegear wrote: post #320
JetSetIlly wrote: post #10

Some nice ideas but the regexes should include word boundaries. For example: git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | sort -nr | head -20 I have a project with a large package named "debugger". The presence of "bug" within "debugger" causes the original command to go crazy.

This needs a small tweak to work on macOS, where git uses the POSIX version of grep (which doesn't support `\b`). You need to use the Perl Regexp option by switching -E with -P: git log -i -P --grep="\b(fix|fixed|fixes|bug|broken)\b" --name-only --format='' | sort | uniq -c | gsort -nr | head -20

Good catch. The word boundary syntax isn't portable across platforms. I reverted to the simpler version that works everywhere.

Re: Git commands I run before reading any code

#445

Post by constantius »

jlarocco wrote: post #254

I'm so used to magit, it seems kind of primitive to pipe git output around like this. Anyway, I can glean a lot of this information in a few minutes scrolling through and filtering the log in magit, and it doesn't require memorizing a bunch of command line arguments.

I understand some people only have Emacs for magit, and I think it's very much justified: probably 95% of the use cases described here are straightforward (and flexible) operations in magit.

Re: Git commands I run before reading any code

#446

Post by rightofcourse »

jillesvangurp wrote: post #374
drums8787 wrote: post #247

Earlier quoted context omitted.

I particularly love when the “CTO” is also the main offender.

I am a CTO and I actually have very little patience for people that obsess over minor formatting issues (use a linter if you care), commit messages, and other fringe issues. If that's the biggest issue you have in a team, amazing. You are doing great. But you probably have bigger issues. The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on add…

> The focus of the CTO is on the big picture stuff. Like staying on top of technical debt and correcting people when they keep on adding more of it. And making sure people learn from their mistakes, focus on the important things first, etc.

sound like something maybe good commit messages could help with

Re: Git commands I run before reading any code

#447

Post by grepsedawk »

joshstrange wrote: post #147

I ran these commands on a number of codebases I work on and I have to say they paint a very different picture than the reality I know to be true. > git shortlog -sn --no-merges Is the most egregious. In one codebase there is a developer's name at the top of the list who outpaced the number 2 by almost 3x the number of commits. That developer no longer works at the company? Crisis? Nope, the opposite. The developer wa…

[dead]

Re: Git commands I run before reading any code

#448

Post by account42 »

palata wrote: post #326
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?

Yeah I think that dvorak is a good example, too. I don't get the mechanical keyboard one, though. I am fine with any keyboard, I just like my mechanical keyboard at home. Just like I am fine with any chair, but ideally I would have a chair I like at home. 120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to…

> 120fps I have no experience with, but I would imagine it's closer to video quality. Once you're used to watching everything in 4K, probably it feels frustrating to watch a 1080p video. But when 4K did not exist, it was not a need. I actively try to not get used to 4K because I don't want to "create the need" for it :-).

I suggest not worrying too much about that - been using a big 4K TV with lots of 4K movies for a long time now and SD content is still as watchable as ever.

For framerates, especially in an interactive context, this is what happens though in my experience. But it also really depends what happens on screen - more movement needs higher framerates to feel smooth.

Re: Git commands I run before reading any code

#450

Post by account42 »

rjh29 wrote: post #426
deno wrote: post #405

Earlier quoted context omitted.

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…

I find the resistance to be a hindrance when typing. Fastest typing speed and comfort for me is my thinkpad keyboard which uses scissor switches with a very low profile - you need less effort per keystroke!

Both noise and resistance is something where mechanical keyboards can provide all desired options with the right switch choice. Gaming-oriented mechanical keyboards tend to have particularly low activation forces.

There really isn't any reason not to choose one except for price - and that's a fair consideration if you're fine with rubber domes or other alternatives.

Post reply on HN