@kugel- I'm not familiar with subtrees, yet they look tempting. However, here we only use a subset of upstream, so how would we only get what we want? If deleting/renaming is messy, I would expect this to be a huge pain if we have the whole of upstream. And if we only copy a subset of upstream anyway, I start to wonder if it's any better to use a subtree.
For the moment I see subtrees tempting if we can use the upstream repository unmodified, kind of like a submodule but easier for users. If we need to manually import anyway, or if we lose history, I'm really not sure how it's better than plain copying. We don't actually need any of the power of Git to import changes, we have a very minimal patch that would hopefully disappear one day, and that IMO should stay very visible -- not buried in a years old merge.
I might give this a look to get a feel for it as again I'm not familiar with using those so I might miss some of its advantages though.
I any case though, I don't think that's something that should be done in this PR, or before merging this PR. I'm totally OK with the current state, and if we decide to use a subtree we can do that later, and I really don't want an additional barrier to get that one merged.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.