new recipe default branch main instead of master #451
Merged
decentral1se
merged 4 commits from 2024-12-21 18:11:13 +00:00
defaultBranch into main
Labels
Clear labels
bug
build
ci/cd
critical fix
design
documentation
duplicate
easy-first-issue
enhancement
help wanted
i10n
i18n
installer
invalid
question
release
release-candidate
security
tech-debt
test
wontfix
Something is not working
go build related issues
Building things with CI/CD
https://docs.coopcloud.tech/federation/resolutions/passed/010/
UI/UX
Documenting all the things
This issue or pull request already exists
Something for new people to get stuck into. We hope it's easy!
New feature
Need some help
Everything to do with localisation
Everything to do with internationalisation
Everything to do with the install script.
Something is wrong
More information is needed
Release management
Related to the new release candidate
Security related
Unit/integration testing
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
3wordchant
aadil (Aadil Ayub)
abra-bot (Abra Bot)
ammaratef45
amras (Sarma)
Apfelwurm
BornDeleuze
Brooke
carla
cas (Cassowary)
coopcloud
cyrnel
decentral1se (d1)
dede
devydave
fauno (fauno)
iexos
jade (Jade Ambrose)
jjsfunhouse
jmakdah2 (Jackie Makdah)
joe-irving (Joe Irving)
kawaiipunk (KawaiiPunk)
knoflook
kolaente
lambdabundesverband
linnealovespie (April)
moosemower
moritz
notplants
oxaliq (sorrel)
p4u1
pharaohgraphy (Andrew 🐦🔥❤️🔥✴️)
renovate-bot (Comrade Renovate Bot)
ripclap
simon
sixsmith (Sixsmith)
stevensting
trav (Trav Fryer)
val (val (he/him))
yksflip
Clear assignees
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#451
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Just saving my future self the trouble of searching "how to rename git branch" every-time I create a new recipe
tysm for dipping into this, definitely important work!
@@ -14,2 +15,4 @@if err != nil {return fmt.Errorf("git init: %s", err)}MasterToMain(repo)Since
Initreturns anerror,MasterToMainshould also do the same to bubble up the errors.Also, since the whole idea is to remove the word
master, we could doSwitchToMainas the function name?ah good idea!
@@ -43,2 +46,4 @@return nil}func MasterToMain(repo *git.Repository) {I'd really appreciate a unit / integration test for this one! To ensure it works, to avoid regressions etc.
added, I ran out of spoons during the first draft but should've made it a WIP PR and got back to it rather than submitting it without the test ig
@@ -45,0 +61,4 @@if err := repo.SetConfig(cfg); err != nil {log.Fatalf("Failed to update repository config: %v", err)}fmt.Println("Set 'main' as the default branch.")We normally use
slogto do logging? Do you want to doINFOorDEBUGhere? You'll see it used elsewhere instead offmt.Println.Also, all logging uses lowercase AFAIR, so it's good to follow this convention.
rip, copy-pasting code then forgetting to clean up is embarrassing lol
tysm @ammaratef45! LGTM.
I would say one more thing tho. It's up to you, as always.
I am mostly not in favour of keeping these sort of "description of what is happening" comments in the code. And especially on this kind of project which has few "regularly active" maintainers. Things can slip out of understanding very easily and also, things change hands when new people start hacking. That's all good but also, it has disadvantages for code documentation.
The danger is that the comment doesn't represent the code later on when things get changed and nobody feels ownership on the comment or forgets to change it. The comment then misleads future maintainers. I understand this is a bit flame war and personal taste territory but I've already seen comments from long gone maintainers mislead others in this project 🙃
In general, I think a good top-level "doc string" on the function should be enough. It describes "why" and not "what" which is more future proof because you only describe the core of what the code wants to do and this has a greater chance to endure in a more general way and not mislead.
Again, I'm open to argumentation or a decision otherwise but now you know 😌
That's a fair concern, and if logs, errors, and variable and function names are readable enough those comments become redundant anyways 🤷♀️
@ammaratef45 Nice! Cool, well, feel free to merge whenever 😌
The only other point is that
gofmtcomplains about that style of doc string on the function. If you look at the rest of the functions, you'll see we follow the$NAME ...style. But it's fine, just something to keep in mind in the future.The CI failure for
--- FAIL: TestEnsureDomainsResolveSameIPv4seems to be related to coop-cloud/abra#448 on a quick glance but I don't have time to dig into it.