On Sat, 15 Feb 2020, Harald Dunkel wrote: > I am maintainer for mg, currently on salsa. Problem is, upstream > doesn't release tar balls anymore, but moved the code to github. > No tags. > > How can I tell Salsa? Should I drop the upstream and pristine-tar > branches on Salsa and integrate the repository on github? Would > you suggest to move the debian part to github instead?
intel-microcode went through this same problem, although it had nothing to do with salsa. Suddenly: 1. I had a debian-side upstream branch with full upstream history based on tarballs that I had built based on tarball-only releases over the years (make that a decade). 2. I had a new upstream-side upstream branch that would soon accumulate history, based on their brand new github repo. And they were two entirely separate trees, of course. No common origin commit. I fixed that using a carefully planned, manually adjusted merge (read the MERGE STRATEGIES part of the manpage for "git merge", especially the "ours" and "theirs" of the recursive merge). That gave me an unified tree that would allow git to do the right thing as far as future merges, diffs and cherry-picks were concerned. Obviously, I ensured everything relevant from *both* side of the merges was present on the merge commit result (and dropped whatever I didn't want). The result tree contents MUST be semanthically compatible with the history it creates, or things will go sour really fast. >From them on, I just merge from github upstream on a topic branch, adjust whatever is needed, and then merge the topic branch to master. Please look at the intel-microcode's history *graph* to undestand what I mean. It is on salsa: https://salsa.debian.org/hmh/intel-microcode As for tarballs, it really depends. I'd either generate those using git based on the upstream's upstream branch, or use the ones from a tagged github release from upstream, if one exists. -- Henrique Holschuh