#How to call `RepoRootForImportPath`
sand fossil
Aha, sorry I missed replying to this.
My personal preference would be if we could upstream this - sadly, since this package is now deprecated, and they recommend using go list (not an option, we don't want that).
Out of the above, I'd rather not pull this into the dagger monorepo if possible:
- it's not actually dagger-specific, and tracking and managing changes from upstream is more of a pain (it would be good to keep the filtered git history, I like that)
- it's potentially a useful utility that other projects might be interested in using
I think we should move this to the dagger org, just so it's all in one place. Not sure who has permissions to do this, cc @lucid lance?
One note - can we add a README explaining what this repo is for, and how it differs from the original? (brings in certain fixes, removes deprecations, and only supports git)
Just glancing through the commits - looks like this involved a fair amount of code archivist work, really cool, really impressive 😄 😄
lucid lance
totally fine to move it to dagger org
flat inlet
Aha, sorry I missed replying to this.
My *personal* preference would be if we c...
my main argument to include it in the engine is because the mindset while forking this library was mostly to serve Dagger. Maybe it's not worth the effort to move it outside since it'll require some overhead to setup the CI for that and "potentially" having to support it from outside contributors.
seems to me that embedding it in the engine is the leanest approach and we can always extract it if we see the value on opening it for other people to use.
sand fossil
this is true, but there are two options for vendoring it - either we keep the entire git history of go-vcs (filtered), which clogs up our git history, or we squash it all down into one, and therefore lose it all, which makes it harder to track our changes we make on top
flat inlet
this is true, but there are two options for vendoring it - either we keep the en...
what about squashing the history of the git-vcs repo into a single commit and then add our changes on top of that? This should be straightforward to do and it'll keep our history clean while allowing us to see what changes we made on top
sand fossil
Yeah fair enough - I guess it's personal preference at this point
Regardless, definitely definitely not worth blocking on, as long as the original origins and licensing are clear 🎉 I guess we just need to pick any option