Hi! I'm about to submit a first PR for a complete ...
# genomeannotator
o
Hi! I'm about to submit a first PR for a complete renewal of the pipeline. However, I noticed that there are some big files in its git history... Is there any way to delete them from the history at some point? Once the new version of the pipeline is on dev, is it feasible to have one of the core team members perform a `git filter-repo`on it? Thanks!
🙌 1
Or isn't it easier to archive the current one and create a new one (with a different name)?
Actually, the more I look at it, the more I think we should create nf-core/genomeannotation, and archive nf-core/genomeannotator
m
🚫
So we did that some time ago for #C06PHJM0Y3D
My recommendation, since it involves some heavy duty things rewrites of history is to do it ASAP
👍 1
But you don't need an nf-core core member to do it
I think this is one of the special cases for which we can grant you admin access
👍 1
o
but do we really need to keep the existing pipeline after all?
n
I would flatten whatever is there
It has no meaningful history with what you are doing now, as I understand
👍 1
o
Yes I will, but the matter is about rights. I can perform a git filter-repo locally, but then I need to be able to force push to
nf-core
IMO, the best solution is to archive the existing one, because it's the simplest and because perhaps some people are still using it (with a very old version of nextflow though). And we could create a brand new pipeline (with a different name), without all the hassle of cleaning the history, etc.
n
Not sure if I fully get what you want to do; do you want to start fresh / flatten existing genomeannotator, or do you want to keep the dead genomeannotator repo around as an historic artifact and have a second repo that is useful? Imo having a dead repo tagging along for historic reasons is mainly confusing for everyone who is looking for a pipeline
Was genomeannotator ever actually functional?
o
I want to have something fresh, but unless I get admin rights (as Maxime said), I cannot modify the history of it
n
I think you will get admin rights
👍 1
p
Yes that's no issue
👍 1
we can also just remove the rule that blocks force-pushes temporarily
👍 1
o
I agree with the fact that having two different pipelines (the old one, archived, and the new fresh one) could be confusing for people. But what do the other people think about it? Do you think we should create a new one? It all depends on your past experience with existing pipelines that had to be revamped at some point 😉
p
Generally I think that if the old one never got a release, and was fairly unusable, then better to just wipe it and stay with the existing repo
💯 1
👍 1
If it had meaningful usage, then it's more nuanced: can do what you suggest, can also keep the old git history around in a branch for anyone who goes looking for it
👍 1
o
I agree with you, keeping everything in a separate branch is a good idea. If we do modify the git history, it may break things for some people, and given its number of stars and the Issues raised on the repo, I suspect that the pipeline was functional at some point
I'll add a comment in the README for people who want the old version
p
ok, sounds good
note that this won't help with the clone size, unless folks do shallow-clones
o
Yes it's what I was thinking about 🤔
I have to admit that I'm a bit concerned about repeatability. I'm pretty sure that some people have used this pipeline for their work, and that perhaps some annotations done with it have been published. Even if the pipeline is still in
dev
, is there a way to archive it in Zenodo?
p
I'm pretty sure that some people have used this pipeline for their work, and that perhaps some annotations done with it have been published.
If this is the case, then we should archive + new repo, as you say
<!subteam^S016E36N7TQ> - do you agree?
👍 4
m
Ok for me
👍 1