Wow, that’s… wow. The description of how vendor branches are going to work to avoid using submodules makes me so very glad I don’t maintain anything in contrib. Thank you for your work keeping dtc in sync, I’m sorry to hear that the git working group has decided to make your life harder than it needs to be.
If you don’t have an allergic reaction to submodules, clone each of the upstreams and then the directories in the contrib directory submodules. Keep an upstream branch in each of the cloned repos and a contrib branch that carries any changes you’ve made. It requires users to add –recurse when they clone and pull, but given how many things use submodules now that’s a pretty common requirement. If you don’t have any changes, then the submodules just points at your mirror of the upstream. If you do, then having a self-contained git repo for that project makes merging relatively painless and preserves history. If you’re happy to burn some CPU cycles, you can use git-imerge in rebase-with-history mode every time you pull from upstream to give a clean history of your changes applied on top of upstream, while also making it possible for people who have local changes to merge your new version. In both cases, you update the shared version by just bumping the submodule version. Your main repo’s history just contains a hash and, for extra benefits, people can clone the whole history of your project but use shallow clones of the submodules to avoid having, for example, the entire history of the LLVM versions that you’ve shipped.
It requires users to add –recurse when they clone and pull, but given how many things use submodules now that’s a pretty common requirement.
I keep all my vim plugins as submodules in .vim/bundle and every single time I’ve ever cloned my .vim I’ve gone:
$ git clone $URL
$ ln -s .vim/vimrc .vimrc
$ vim
oh, no plugins, wtf? oh ffs
$ rm -rf .vim
$ git clone $URL --recurse-submodules
$ vim
:Helptags
I don’t think I’ve ever remembered it once, and I can never remember the command for submodules. Is it git submodule init --update? Or git submodule update --init? Easier to just clone again with --recurse-submodules.
Your main repo’s history just contains a hash and, for extra benefits, people can clone the whole history of your project but use shallow clones of the submodules to avoid having, for example, the entire history of the LLVM versions that you’ve shipped.
And of course they do have the full history of the LLVM versions that you’ve shipped if they want them, they just don’t have to if they don’t want them. It really is the best of both worlds.
I must say I find keeping submodules in sync with what they’re meant to be just bizarrely painful, though. Do you know of any way to just say ‘always keep the submodules at whatever commit they’re meant to be’?
I must say I find keeping submodules in sync with what they’re meant to be just bizarrely painful, though. Do you know of any way to just say ‘always keep the submodules at whatever commit they’re meant to be’?
There’s a bot on GitHub that notices if your submodules are out of date and sends a PR to update it. I’m not sure if you have to explicitly opt in to it (it seems to run on everything in the Microsoft org).
I know that several of my colleagues have just added some custom git verbs to handle them (and also do common things like stash, update, stash pop), so never have to deal with the core git UI abominations for them.
How is this related to https://github.com/freebsd/freebsd/? The commit hashes don’t match the tree on GitLab.
It’s the sync of the repo available at https://cgit-beta.freebsd.org/ See https://lists.freebsd.org/pipermail/freebsd-git/2020-May/000288.html
Wow, that’s… wow. The description of how vendor branches are going to work to avoid using submodules makes me so very glad I don’t maintain anything in contrib. Thank you for your work keeping dtc in sync, I’m sorry to hear that the git working group has decided to make your life harder than it needs to be.
What is the best way to handle vendor branches in cases like this?
If you don’t have an allergic reaction to submodules, clone each of the upstreams and then the directories in the contrib directory submodules. Keep an upstream branch in each of the cloned repos and a contrib branch that carries any changes you’ve made. It requires users to add –recurse when they clone and pull, but given how many things use submodules now that’s a pretty common requirement. If you don’t have any changes, then the submodules just points at your mirror of the upstream. If you do, then having a self-contained git repo for that project makes merging relatively painless and preserves history. If you’re happy to burn some CPU cycles, you can use git-imerge in rebase-with-history mode every time you pull from upstream to give a clean history of your changes applied on top of upstream, while also making it possible for people who have local changes to merge your new version. In both cases, you update the shared version by just bumping the submodule version. Your main repo’s history just contains a hash and, for extra benefits, people can clone the whole history of your project but use shallow clones of the submodules to avoid having, for example, the entire history of the LLVM versions that you’ve shipped.
I keep all my vim plugins as submodules in
.vim/bundleand every single time I’ve ever cloned my.vimI’ve gone:I don’t think I’ve ever remembered it once, and I can never remember the command for submodules. Is it
git submodule init --update? Orgit submodule update --init? Easier to just clone again with--recurse-submodules.And of course they do have the full history of the LLVM versions that you’ve shipped if they want them, they just don’t have to if they don’t want them. It really is the best of both worlds.
I must say I find keeping submodules in sync with what they’re meant to be just bizarrely painful, though. Do you know of any way to just say ‘always keep the submodules at whatever commit they’re meant to be’?
There’s a bot on GitHub that notices if your submodules are out of date and sends a PR to update it. I’m not sure if you have to explicitly opt in to it (it seems to run on everything in the Microsoft org).
I know that several of my colleagues have just added some custom git verbs to handle them (and also do common things like stash, update, stash pop), so never have to deal with the core git UI abominations for them.