Programming

17668 readers

244 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

Is there a way to hide dependabot commits in the history of a repo? (lemmy.pe1uca.dev)

submitted 1 month ago by [email protected] to c/programming

5 comments fedilink hide all child comments

I'm trying to see how active a project is, but dependabot spam makes it annoying to find actual commits and to know if those commits are relevant.

There's no need for me to know chai was updated from 5.1.1 to 5.1.2, I want to see what were the most recent actual features implemented.

top 5 comments

sorted by: hot top controversial new old

[–] [email protected] 28 points 1 month ago (1 children)

You can use git log --author=REGEX_THAT_EXCLUDES_DEPENDABOT ... .

[–] pylapp 2 points 1 month ago

Nice idea 👍

[–] pylapp 1 points 1 month ago (2 children)

BTW I hope any project won’t increase the Z version only by including Dependabot commits, it would be insane. Release must be documented, tested, with CHANGELOG updated. If some maintainers just accept Dependabot commits without checking, move away. That’s just simple crappy auto-merge.

[–] kamstrup 5 points 1 month ago

Must include CHANGELOG...

The changelog:

misc fixes
pls work
fixe a typo

[–] Kissaki 3 points 1 month ago* (last edited 1 month ago)

Release must be documented

It's not a must [unless you put it into a contract], it's a should or would be nice

Many, if not most, projects don't follow a good, obvious, transparent, documented release or change management.

I wish for it, too, but it's not the reality of projects. Most people don't seem to care about it as much as I do.

I agree blind acceptance/merging is problematic. But for some projects (small scope/size/personal-FOSS, trustworthy upstream) I see it as pragmatic rather than problematic.