Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Manphiz writes: > Nicholas D Steeves writes: > >> Hi manphiz, >> >> Manphiz writes: >> >>> Xiyue Deng writes: >>> >>> Hi sten, >>> >>> When trying to pick a new upstream to rebase, I found that pulling >>> either upstream repo will result in an incompatible git history versus >>> the current debian/master branch on salsa. >> >> This is expected, but please merge from upstream. >> >>> I wonder how I should handle this? >> >> The commit of the upstream source you import should be tagged. If >> upstream hasn't made a tagged release, then you'll need to: >> >> 1. With a the upstream of your choice set in the watch file, "gbp >> import-orig --uscan" will do the right thing in this repository. This >> is one reason why a functioning watch file that defines the correct >> upstream is useful. It should also save time to do this once, and >> then switch to a tag merging workflow for the next upstream import. >> >> OR >> >> I. Ask upstream to tag a stable release (probably NA to GNU ELPA's >> monorepo) >> II. Merge that tag to either the upstream branch, or directly to the >> Debian packaging branch. See the merge note at §i. >> III. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> OR >> >> i. Merge new upstream commit to the upstream branch (which will also >> merge its history), because tags of detached HEADS behave unreliably >> through remotes; ie the tag needs to be of a commit on a branch. See >> git merge man page about what to about unrelated histories. >> ii. Create an annotated tag in the format you defined in debian/watch >> (note substitutions for special characters). I've always done this >> manually with a "Tag upstream snapshot for Debian use" annotation, but >> NOTE: There is probably a better way to create these tags by now. >> iii. Merge your annotated tag to the Debian packaging branch. >> iv. Do fixup work to make "git diff tag -- !(debian)" clean. >> >> In every case, you'll need to insure that the upstream tag is pushed to >> Salsa. >> >>> Is it OK to force push to master? >> >> No. >> >> Best, >> Nicholas >> > > Thanks Nicholas, David! I found that "git merge upstream/externals/muse > --allow-unrelated-histories" did what I wanted. However, as this merged > pulled in the whole history of upstream repo it now has 1000+ commits > since the current debian/master. To be cautious, I have created a merge > request[1] which also has the packaging updates to the latest head. > PTAL. > > [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/4 Friendly ping for comments. Or should I prepare a package and upload to mentors directly for review? -- Manphiz signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Nicholas D Steeves writes: > Hi manphiz, > > Manphiz writes: > >> Xiyue Deng writes: >> >> Hi sten, >> >> When trying to pick a new upstream to rebase, I found that pulling >> either upstream repo will result in an incompatible git history versus >> the current debian/master branch on salsa. > > This is expected, but please merge from upstream. > >> I wonder how I should handle this? > > The commit of the upstream source you import should be tagged. If > upstream hasn't made a tagged release, then you'll need to: > > 1. With a the upstream of your choice set in the watch file, "gbp > import-orig --uscan" will do the right thing in this repository. This > is one reason why a functioning watch file that defines the correct > upstream is useful. It should also save time to do this once, and > then switch to a tag merging workflow for the next upstream import. > > OR > > I. Ask upstream to tag a stable release (probably NA to GNU ELPA's > monorepo) > II. Merge that tag to either the upstream branch, or directly to the > Debian packaging branch. See the merge note at §i. > III. Do fixup work to make "git diff tag -- !(debian)" clean. > > OR > > i. Merge new upstream commit to the upstream branch (which will also > merge its history), because tags of detached HEADS behave unreliably > through remotes; ie the tag needs to be of a commit on a branch. See > git merge man page about what to about unrelated histories. > ii. Create an annotated tag in the format you defined in debian/watch > (note substitutions for special characters). I've always done this > manually with a "Tag upstream snapshot for Debian use" annotation, but > NOTE: There is probably a better way to create these tags by now. > iii. Merge your annotated tag to the Debian packaging branch. > iv. Do fixup work to make "git diff tag -- !(debian)" clean. > > In every case, you'll need to insure that the upstream tag is pushed to > Salsa. > >> Is it OK to force push to master? > > No. > > Best, > Nicholas > Thanks Nicholas, David! I found that "git merge upstream/externals/muse --allow-unrelated-histories" did what I wanted. However, as this merged pulled in the whole history of upstream repo it now has 1000+ commits since the current debian/master. To be cautious, I have created a merge request[1] which also has the packaging updates to the latest head. PTAL. [1] https://salsa.debian.org/emacsen-team/muse-el/-/merge_requests/4 -- Manphiz signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Hi manphiz, Manphiz writes: > Xiyue Deng writes: > > Hi sten, > > When trying to pick a new upstream to rebase, I found that pulling > either upstream repo will result in an incompatible git history versus > the current debian/master branch on salsa. This is expected, but please merge from upstream. > I wonder how I should handle this? The commit of the upstream source you import should be tagged. If upstream hasn't made a tagged release, then you'll need to: 1. With a the upstream of your choice set in the watch file, "gbp import-orig --uscan" will do the right thing in this repository. This is one reason why a functioning watch file that defines the correct upstream is useful. It should also save time to do this once, and then switch to a tag merging workflow for the next upstream import. OR I. Ask upstream to tag a stable release (probably NA to GNU ELPA's monorepo) II. Merge that tag to either the upstream branch, or directly to the Debian packaging branch. See the merge note at §i. III. Do fixup work to make "git diff tag -- !(debian)" clean. OR i. Merge new upstream commit to the upstream branch (which will also merge its history), because tags of detached HEADS behave unreliably through remotes; ie the tag needs to be of a commit on a branch. See git merge man page about what to about unrelated histories. ii. Create an annotated tag in the format you defined in debian/watch (note substitutions for special characters). I've always done this manually with a "Tag upstream snapshot for Debian use" annotation, but NOTE: There is probably a better way to create these tags by now. iii. Merge your annotated tag to the Debian packaging branch. iv. Do fixup work to make "git diff tag -- !(debian)" clean. In every case, you'll need to insure that the upstream tag is pushed to Salsa. > Is it OK to force push to master? No. Best, Nicholas signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
David Bremner writes: > Manphiz writes: > >> >> Hi sten, >> >> When trying to pick a new upstream to rebase, I found that pulling >> either upstream repo will result in an incompatible git history versus >> the current debian/master branch on salsa. I wonder how I should handle >> this? Is it OK to force push to master? Will it affect existing >> annotated tags? > > Please don't force push the public history. There are various ways to > "fake merge" that are preferable. Hi David, Any pointers to the "fake merge" approaches? Would like to take a look. -- Manphiz signature.asc Description: PGP signature
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Manphiz writes: > > Hi sten, > > When trying to pick a new upstream to rebase, I found that pulling > either upstream repo will result in an incompatible git history versus > the current debian/master branch on salsa. I wonder how I should handle > this? Is it OK to force push to master? Will it affect existing > annotated tags? Please don't force push the public history. There are various ways to "fake merge" that are preferable.
Bug#1051247: muse-el: Choose living upstream for muse-el and merge updates
Xiyue Deng writes: > Package: elpa-muse > Severity: minor > X-Debbugs-Cc: none, Xiyue Deng > > Currently muse-el has two main upstream repositories: one from Elpa > external branch[1], one from github[2], and the two has diverged > somehow. We should decide on which repo to track in d/watch. > > [1] http://git.savannah.gnu.org/cgit/emacs/elpa.git/log/?h=externals/muse > [2] https://github.com/alexott/muse > > -- System Information: > Debian Release: 12.1 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > Hi sten, When trying to pick a new upstream to rebase, I found that pulling either upstream repo will result in an incompatible git history versus the current debian/master branch on salsa. I wonder how I should handle this? Is it OK to force push to master? Will it affect existing annotated tags? -- Manphiz signature.asc Description: PGP signature
