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

501–510 of 546 posts

Re: Git commands I run before reading any code

#501

Post by alt_422568 »

PUSH_AX wrote: post #483
alt_422568 wrote: post #368

Earlier quoted context omitted.

> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.

That sounds clever until you remember tools exist to solve actual problems. Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?

Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4]

If enough of the following apply strongly enough to your project:

* Very small codebase

* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review

* Not doing anything technically challenging

* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature

then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.

I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]

> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop

I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.

[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log

[3] https://github.com/openjdk/jdk/commits/master/src/hotspot

[4] https://github.com/openssl/openssl/commits/master/

[5] https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code

[6] https://tigerstyle.dev/

Re: Git commands I run before reading any code

#502

Post by ric2b »

psalaun wrote: post #214
theshrike79 wrote: post #11

Earlier quoted context omitted.

Can you explain to me (an avid squash-merger) what extra information do you gain by having commits that say "argh, let's see if this works", "crap, the CI is failing again, small fix to see if it works", "pushing before leaving for vacation" in the main git history? With a squash merge one PR is one commit, simple, clean and easy to roll back or cherry-pick to another branch.

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

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

Re: Git commands I run before reading any code

#503

Post by irishcoffee »

freedomben wrote: post #485
irishcoffee wrote: post #408

Earlier quoted context omitted.

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

it's a tradeoff for sure. With dig especially I can't ever remember the normal syntax because I have aliases and scripts for things. I feel the aliases are wroth it since I'm on my own machine(s) 99.5% of the time, but it does suck to be handicapped

Absolutely, and I think aliases are great and should be used. I, personally, worked in a handful of environments that made me realize it was infeasible to lean on aliases and helper scripts. Like bluGill said, if I need it in a real way, I'll try and upstream it.

What I resent is someone telling me how to use a computer. I've got that bit mostly down at this point.

Re: Git commands I run before reading any code

#505

Post by dcre »

AlexeyBelov wrote: post #479
dcre wrote: post #336

Earlier quoted context omitted.

Saw all the replies crying over how verbose these are, clicked through to TFA expecting to see simpler commands. Nope, they're basically the same thing, just slightly shorter. I would never memorize either the jj or git versions if I planned to use them regularly; I'd make aliases.

crying over? Let's not be confrontational. I could say you're "crying" with this comment, but is that a good thing to say?

Come on.

Re: Git commands I run before reading any code

#506

Post by mememememememo »

dewey wrote: post #7
ramon156 wrote: post #5

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.” The most changed file is the one people are afraid of touching?

I've just tried this, and the most touched files are also the most irrelevant or boring files (auto generated, entry-point of the service etc.) in my tests.

I'd only look at human/AI edited files (i.e. that require some kind of reasoning) not generated ones (where the reasoning is in the generator).

Generation is precompilation.

Entry point is interesting. Lots of scope to become a scary file.

Re: Git commands I run before reading any code

#507

Post by mememememememo »

zikani_03 wrote: post #293
ramon156 wrote: post #5

> The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.” The most changed file is the one people are afraid of touching?

pom.xml and package.json came up on couple of separate projects I ran the commands on. Which makes sense because the versions get bumped rather frequently. I guess context matters, as usual.

I hate that rn looks like m

Re: Git commands I run before reading any code

#508

Post by shiroiuma »

palata wrote: post #440
shiroiuma wrote: post #434

Earlier quoted context omitted.

>I think the "incompatible" was more in the dvorak sense, which I believe is that whenever you are on another computer, it most likely won't have dvorak. That's not a problem, just switch to Qwerty when you use a different computer. For me at least, it's not hard at all to switch between Dvorak and Qwerty.

> For me at least, it's not hard at all to switch between Dvorak and Qwerty. Sure, but you had to learn both. And what benefit did you get from learning Dvorak? I feel the same with jujutsu: I have to learn it on top of git , and I don't see a lot of benefits from knowing it.

>And what benefit did you get from learning Dvorak?

More comfortable typing, less wrist strain, etc. It's just a better layout.

Re: Git commands I run before reading any code

#509

Post by PUSH_AX »

alt_422568 wrote: post #501
PUSH_AX wrote: post #483

Earlier quoted context omitted.

That sounds clever until you remember tools exist to solve actual problems. Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?

Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4] If enough of the following apply strongly enough to your project: * Very small codebase * A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review * Not doing anything technically challengin…

> I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work.

This is classic dogmatics over pragmatics.

The carpenter understands how to use every tool, they are just pragmatic about its use.

Re: Git commands I run before reading any code

#510

Post by FergusArgyll »

weedhopper wrote: post #157
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’ve recently been looking into some tools that provide quick or painless help like pop up snippets with descriptions and cheat sheets, got any recommendations?

Just handroll one, I wrote one in python, use an sqlite db, call out to fzf and voila you have the perfect tool. Codex can prob one shot it
Post reply on HN