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

Reply via email to