Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update submodules and do recursive clone #123

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

stv0g
Copy link

@stv0g stv0g commented Jun 3, 2020

This will not cover all edge cases like changes in the submodules.
But we have it in production for over a year now and are happy with it.

@manics
Copy link
Member

manics commented Oct 3, 2020

Have you thought about adding git submodule sync, or is that going to cause problems? (Edit: Maybe it'll confuse things... if someone changes the submodule locally we probably shouldn't change it back. Could be worth adding to https://jupyterhub.github.io/nbgitpuller/topic/automatic-merging.html#topic-automatic-merging ?)

Also any chance of adding a test? I've got a love-hate relationship with submodules, they're great when they work, incredibly frustrating when there's a change, so I think a test would be useful to ensure we don't modify a git option somewhere in future and inadvertently break it.

@manics manics linked an issue Oct 3, 2020 that may be closed by this pull request
@jacobtomlinson
Copy link

I would support this being merged. Anything I can do to help unblock?

@yuvipanda
Copy link
Contributor

yuvipanda commented Mar 21, 2021

@jacobtomlinson mostly I'm not sure how the merging functionality would work for files inside the submodules. Will it preserve current automerge behavior? Probably not, so we should very clearly document that. A test is also needed, along with resolving the merge conflict.

@jacobtomlinson
Copy link

Naively I assumed the same merging behaviour would still apply. What makes you think it should behave differently?

@yuvipanda
Copy link
Contributor

git submodules just contain a pointer to a repo + ref to check out. So any merging behavior will only refer to those two pieces of information, and nothing more. So if the ref had changed because the user committed something inside the submodule, and the upstream has too, the merging behavior will work out to simply preserving the user's commit - no merging will happen.

To do proper merging, we'll have to recursively dive into each submodule and do our merging there too.

@jacobtomlinson
Copy link

To do proper merging, we'll have to recursively dive into each submodule and do our merging there too.

Ah right I see what you mean. Yeah that's kinda what I meant, the merging logic would be the same but it would need to be performed recursively on submodules.

Perhaps the pointer itself makes this trickier.

@yuvipanda
Copy link
Contributor

Yeah, you'd have to do

def update(self):
recursively. The ref pointer will make things difficult, since you'll probably always diverge from the upstream ref. How to make sure you still get changes from upstream ref moving while keeping the merge behavior? Doable, just tricky

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support updating git submodules
4 participants