Programming

17482 readers

259 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 1 year ago

MODERATORS

snowe

Ategon

[email protected]

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

submitted 3 weeks 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 3 weeks ago (1 children)

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

[–] pylapp 2 points 3 weeks ago

Nice idea 👍

[–] pylapp 1 points 3 weeks 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 3 weeks ago

Must include CHANGELOG...

The changelog:

misc fixes
pls work
fixe a typo

[–] Kissaki 3 points 3 weeks ago* (last edited 3 weeks 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.