Bug#979188: RFS: git-subrepo/0.4.9-3 -- Alternative to git-submodule(1) and git-subtree(1)
Hi,
On Fri, Feb 14, 2025 at 2:02 AM Samo Pogačnik <samo_pogacnik@t-2.net> wrote:
>
> Hi Bo,
>
> On Thu, 2025-02-13 at 07:24 +0800, Bo YU wrote:
> > Hi,
> >
> > On Sat, Jan 11, 2025 at 07:57:14PM +0100, Samo Pogačnik wrote:
> > > Package: sponsorship-requests
> > > Severity: normal
> > > Control: tags -1 -moreinfo
> > >
> > > Dear mentors,
> > >
> > > I am looking for a sponsor for my package "git-subrepo":
> > >
> > > * Package name : git-subrepo
> > > Version : 0.4.9-3
> > > Upstream contact : Ingy döt Net <ingy@ingy.net>
> > > * URL : https://github.com/ingydotnet/git-subrepo
> > > * License : GPL-2+ and GPL-2, MIT
> > > * Vcs : https://salsa.debian.org/debian/git-subrepo
> > > Section : vcs
> > >
> > > The source builds the following binary packages:
> > >
> > > git-subrepo - Alternative to git-submodule(1) and git-subtree(1)
> > >
> > > To access further information about this package, please visit the following
> > > URL:
> > >
> > > https://mentors.debian.net/package/git-subrepo/
> > >
> > > Alternatively, you can download the package with 'dget' using this command:
> > >
> > > dget -x
> > > https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.9-3.dsc
> > >
> > > Changes since the last upload:
> > >
> > > git-subrepo (0.4.9-3) unstable; urgency=medium
> > > .
> > > * d/control: update Standards-Version to 4.7.0
> > > * d/control: bump debhelper compat level to 13
> > > * d/control: added Multi-Arch: same
> >
> > Thanks for working on this.
> >
>
> Thank you very much for the reply and for being willing to sponsor this package.
>
> > From the tracker page[0], there is only 0.4.9-1 in Debian archive, so I
> > suppose you should merge 0.4.9-3 and 0.4.9-2 to 0.4.9-2.
> >
> > Once the ITP was addressed, the another RFS should be opened with new one
> > reportbug, is there something I am missing?
> >
>
> I've initially opened a new RFS[1] while proposing 0.4.9-2. Then i've been
> instructed to use existing RFS and to make some additional changes, so i ended
> up with 0.4.9-3 using old RFS.
>
Ah, thanks for let me know this, I thought #979188 was one ITP by
these wording[0], sorry.:)
> So, now i am a bit confused about how to proceed and what would be the correct
> way to merge 0.4.9-3 and 0.4.9-2 to 0.4.9-2 in git/salsa (may i force push or
> not, may d/changelog for the same version change in git history - i suppose
> until not tagged?), if that would be way to go?
Forcing push works, but now the git-subrepo was under debian project
already, some developers do not wish force push when one package was
adopted by a new maintainer. But I know the maintainer of the package
is you, so you can do this as long as you know what you are doing.
On the contrary, I would like to suggest you to push one new commit to
debian/sid just like this:
```
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,16 +1,11 @@
-git-subrepo (0.4.9-3) unstable; urgency=medium
-
- * d/control: update Standards-Version to 4.7.0
- * d/control: bump debhelper compat level to 13
- * d/control: added Multi-Arch: same
-
- -- Samo Pogačnik <samo_pogacnik@t-2.net> Sat, 11 Jan 2025 17:41:16 +0000
-
-git-subrepo (0.4.9-2) unstable; urgency=medium
+git-subrepo (0.4.9-2) UNRELEASED; urgency=medium
* Reordered and rewritten existing patches
* Added patches to fix upstream PR checks
* Fixing git-subrepo, when ff=only is set in git
+ * d/control: update Standards-Version to 4.7.0
+ * d/control: bump debhelper compat level to 13
+ * d/control: added Multi-Arch: same
-- Samo Pogačnik <samo_pogacnik@t-2.net> Fri, 10 Jan 2025 17:57:19 +0000
```
Some tips:
1. Personlly I will mark UNRELEASED tag when packaging or updating
with new release was in progress, in other words, this will tell me
there are some places to improve or to be finished, especially this is
common usage on team workflow. When you get ready to get review or
sponsorship, you can change it to `unstable`, but this up to your
sponsor or your team.
2. Another point is that one commit contains one change with all
involved modifications like[2][3]. You can just only modify your
change but d/changelog and `git commit` the changes first then `gbp
dch` will update your d/changelog at last use `git amend` to add the
file to the commit. This is also a personal approach but this will
prevent you from missing some entries in d/changelog I think.
For git-subrepo itself[4], I think you can close them now? If so,
please close the bug in the d/changelog.
Please don't hesitate to ask any questions.
BR,
Bo
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979188#224
[1]: https://salsa.debian.org/debian/git-subrepo
[2]: https://salsa.debian.org/debian/pypy3/-/commit/39dc07c4e2da28fd4c1609a6302ad611622d7ed6
[3]: https://salsa.debian.org/debian/strace/-/commit/3fb06cd0249df27c708cd1cf4d43e177b5a450f2
[4]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=git-subrepo
>
> best regards, Samo
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092712
Reply to: