Also, if this is an organization setting, I'm extremely disappointed in your PR review process. If someone is committing vendor code to the repo someone else should reject the pull.

[–] Cqrd@lemmy.dbzer0.com 106 points 6 months ago (3 children)

What if I told you a lot of companies don't have solid review requirement processes? Some barely use version control at all

[–] xmunk@sh.itjust.works 32 points 6 months ago (2 children)

Sure, I understand... but if you're at one of those companies you should introduce it.

[–] FizzyOrange@programming.dev 27 points 6 months ago (1 children)

Yeah... Usually if you join a company with bad practices it's because the people who already work there don't want to do things properly. They tend to not react well to the new guy telling them what they're doing wrong.

Only really feasible if you're the boss, or you have an unreasonable amount of patience.

[–] frezik@midwest.social 3 points 6 months ago

Usually, the boss (or people above the boss) are the one's stopping it. Engineers know what the solution is. They may still resent the new guy saying it, though, because they've been through this fight already and are tired.

[–] Ephera@lemmy.ml 9 points 6 months ago (2 children)

Eh, if everyone knows what they're doing, it can be much better to not have it and rather do more pairing.

But yes, obviously Steven does not know what they're doing.

[–] firelizzard@programming.dev 8 points 6 months ago (2 children)

Better to not have version control!? Dear god I hope I never work on anything with you.

[–] docAvid@midwest.social 16 points 6 months ago* (last edited 6 months ago) (2 children)

Pretty sure they meant to not have review. Dropping peer review in favor of pair programming is a trendy idea these days. Heh, you might call it "pairs over peers". I don't agree with it, though. Pair programming is great, but two people, heads together, can easily get on a wavelength and miss the same things. It's always valuable to have people who have never seen the new changes take a look. Also, peer review helps keep the whole team up to date on their knowledge of the code base, a seriously underrated benefit. But I will concede that trading peer review for pair programming is less wrong than giving up version control. Still wrong, but a lot less wrong.

[–] firelizzard@programming.dev 2 points 6 months ago

Agreed. Even self-reviewing a few days after I wrote the code helps me see mistakes.

load more comments (1 replies)

[–] Ephera@lemmy.ml 2 points 6 months ago (1 children)

Ah, no, I meant a review process. Version control is always a good idea.

[–] firelizzard@programming.dev 2 points 6 months ago

Ah, yeah that makes a lot more sense

load more comments (1 replies)

[–] dylanTheDeveloper@lemmy.world 12 points 6 months ago* (last edited 6 months ago) (1 children)

I've seen people trade zip archives like Yo-Ge-oh cards useing excel as a source control manager so it could be much MUCH worse

[–] littlewonder@lemmy.world 10 points 6 months ago* (last edited 6 months ago)

Dude, put content warnings on this. I have trauma from shared drives and fucking Jared leaving the Important File open on his locked computer while he takes off for a week, locking out access to anyone else.

[–] brlemworld@lemmy.world 2 points 6 months ago* (last edited 6 months ago) (1 children)

Those companies probably also pay ABSOLUTE SHITTER

load more comments (1 replies)

[–] half_built_pyramids@lemmy.world 8 points 6 months ago

Fucking stop Steven, that absolute shitter

[–] xlash123@sh.itjust.works 120 points 6 months ago (7 children)

Correct me if I'm wrong, but it's not enough to delete the files in the commit, unless you're ok with Git tracking the large amount of data that was previously committed. Your git clones will be long, my friend

[–] Backfire@lemmy.world 130 points 6 months ago (2 children)

You'd have to rewrite the history as to never having committed those files in the first place, yes.

And then politely ask all your coworkers to reset their working environments to the "new" head of the branch, same as the old head but not quite.

Chaos ensues. Sirens in the distance wailing.

[–] Potatos_are_not_friends@lemmy.world 35 points 6 months ago (1 children)

Rewrite history? Difficult.

Start a new project and nuke the old one? Finger guns.

[–] Klear@lemmy.world 24 points 6 months ago

History is written by the victors. The rest of us have to nuke the project and start over.

[–] Dultas@lemmy.world 21 points 6 months ago (1 children)

If this was committed to a branch would doing a squash merge into another branch and then nuking the old one not do the trick?

[–] Backfire@lemmy.world 15 points 6 months ago

Yes, that would do the trick

[–] Shareni@programming.dev 13 points 6 months ago (1 children)

git clone --depth=1 ?

[–] flying_sheep@lemmy.ml 43 points 6 months ago (3 children)

No, don't do that. That modifies the commit hashes, so tags no longer work.

git clone --filter=blob:none is where it's at.

[–] masterspace@lemmy.ca 18 points 6 months ago* (last edited 6 months ago) (11 children)

I don't understand how we're all using git and it's not just some backend utility that we all use a sane wrapper for instead.

Everytime you want to do anything with git it's a weird series or arcane nonsense commands and then someone cuts in saying "oh yeah but that will destroy x y and z, you have to use this other arcane nonsense command that also sounds nothing like you're trying to do" and you sit there having no idea why either of them even kind of accomplish what you want.

[–] frezik@midwest.social 21 points 6 months ago (10 children)

It's because git is a complex tool to solve complex problems. If you're one hacker working alone, RCS will do an acceptable job. As soon as you add a second hacker, things change and RCS will quickly show its limitations. FOSS version control went through CVS and SVN before finally arriving at git, and there are good reasons we made each of those transitions. For that matter, CVS and SVN had plenty of arcane stuff to fix weird scenarios, too, and in my subjective experience, git doesn't pile on appreciably more.

You think deleting an empty directory should be easy? CVS laughs at your effort, puny developer.

load more comments (10 replies)

[–] zalgotext@sh.itjust.works 9 points 6 months ago

There are tons of wrappers for git, but they all kinda suck. They either don't let you do something the cli does, so you have to resort to the arcane magicks every now and then anyways. Or they just obfuscate things to the point where you have no idea what it's doing, making it impossible to know how to fix things if (when) it fucks things up.

[–] phoenixz@lemmy.ca 6 points 6 months ago

Git is complicated, but then again, it's a tool with a lot of options. Could it be nicer and less abstract in its use? Sure!

However, if you compare what goes does, and how it does, to it's competitors, then git is quite amazing. 5-10 years ago it was all svn, the dark times. Simpler tool and an actual headache to use.

[–] alsimoneau@lemmy.ca 2 points 6 months ago

Mercurial is way better.

There, I said it.

load more comments (7 replies)

[–] Shareni@programming.dev 7 points 6 months ago

Thanks, didn't know about that one.

[–] kevincox@lemmy.ml 5 points 6 months ago* (last edited 6 months ago) (3 children)

What are you smoking? Shallow clones don't modify commit hashes.

The only thing that you lose is history, but that usually isn't a big deal.

--filter=blob:none probably also won't help too much here since the problem with node_modules is more about millions of individual files rather than large files (although both can be annoying).

load more comments (3 replies)

load more comments (5 replies)

[–] mox@lemmy.sdf.org 61 points 6 months ago* (last edited 6 months ago) (1 children)

I can't see past the word wrap implementation in that UI. Mo dules indeed.

load more comments (1 replies)

[–] Ephera@lemmy.ml 46 points 6 months ago

Wow, that's 300k lines of text that anyone, who clones the repo, has to download.

[–] lars@lemmy.sdf.org 29 points 6 months ago (4 children)

Do I really have to escape my dots in a .gitignore?

[–] Ephera@lemmy.ml 28 points 6 months ago* (last edited 6 months ago)

I really don't think so. The documentation says nothing of the like.

Maybe someone thought it's a regex pattern, where escaping dots would make sense. But yeah, it mostly works like glob patterns instead.

[–] vox@sopuli.xyz 4 points 6 months ago

nah

[–] Lobreeze@lemmy.world 3 points 6 months ago

Not usually

[–] brlemworld@lemmy.world 3 points 6 months ago

Also don't need trailing slash

[–] BeefPiano@lemmy.world 19 points 6 months ago (1 children)

Why do I get the feeling this is Steven’s commit?

[–] JoYo@lemmy.ml 5 points 6 months ago

sid-code steven is dumb-code

[–] thatirishguyyy@lemmy.today 7 points 6 months ago* (last edited 6 months ago)

Creating a mucj larger dl. What a dick.

[–] penquin@lemm.ee 3 points 6 months ago (2 children)

How long did it take Steve to git push every time?

load more comments (2 replies)

load more comments