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

291–300 of 546 posts

Re: Git commands I run before reading any code

#291

Post by Exoristos »

mamcx wrote: post #273
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.

No, jj is super simple in daily use, in contrast with git that is a constant chore (and any sane person use alias). This include stuff that in git is a total mess of complexity like dealing with rebases. So not judge the tool for this odd case.

One rarely needs more from git than `git add -A && git commit -m`.

Re: Git commands I run before reading any code

#293

Post by zikani_03 »

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.

Re: Git commands I run before reading any code

#294

Post by thiisguy »

Eldt wrote: post #130
jbjbjbjb wrote: post #53

Earlier quoted context omitted.

This command needs a warning. Using this command and drawing too many conclusions from it, especially if you’re new, will make you look stupid in front of your team mates. I ran this on the repo I have open and after I filtered out the non code files it really can only tell me which features we worked on in the last year. It says more about how we decided to split up the features into increments than anything to do w…

Better for people to know they're just blindly copying tools and parroting their output as if it's automatically meaningfully. Any warning against that should be built into the individual, for their own sake

Right? Some of these comments feel “you gave me commands to run and I should be able to turn my brain off to interpret the outputs”. These aren’t newbie commands so the assumption would be that you kinda know what you’re doing at least a little bit. If not, then don’t run them… similar to how you should approach all commands/things from the internet

Re: Git commands I run before reading any code

#296

Post by zikani_03 »

heresie-dabord wrote: post #201
blenderob wrote: post #141

> Is This Project Accelerating or Dying > > git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c If the commit frequency goes down, does it really mean that the project is dying? Maybe it is just becoming stable?

For this command in particular, one can add a cheap bar chart with awk: git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c | awk '{printf $2" "; for (i=1;i<=$1;i++){printf "-";} print ""; }'

This is a neat trick for a quick visual presentation, thanks!

Re: Git commands I run before reading any code

#297

Post by mgfist »

PUSH_AX wrote: post #256
macintux wrote: post #253

Earlier quoted context omitted.

The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.

Fine, but none of that is in a normal commit message, lets be real...

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

Re: Git commands I run before reading any code

#299

Post by bluGill »

freedomben wrote: post #180
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 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 be there next time I use a different system.

Re: Git commands I run before reading any code

#300

Post by PUSH_AX »

mgfist wrote: post #297
PUSH_AX wrote: post #256

Earlier quoted context omitted.

Fine, but none of that is in a normal commit message, lets be real...

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

Post reply on HN