On Tue, Apr 26, 2022 at 11:03:24AM +0100, Julian Gilbey wrote:

Hi Timo (and Geert),

;-)

On Sun, Apr 24, 2022 at 10:42:51PM +0200, Timo Röhling wrote:

Hi Julian,

* Julian Gilbey <julian@d-and-j.net> [2022-04-24 21:01]:

Somehow I managed to really mess up a commit to python-qtconsole: the upstream and pristine-tar branches do not have the upstream/5.3.0
sources (the current ones). However, there's already an
upstream/5.3.0 tag in the repository, pointing to a commit to the
master branch.

I think the simplest thing to do is to "rewrite history": delete the
head commits to the master branch and the 5.3.0 tags, and then
recommit correctly and force-push to salsa.

Would people be OK with me doing this, or do you have an alternative suggestion?

I looked at the Salsa repository, and it is not so bad. It seems like you forgot to pull the latest changes in upstream and pristine-tar from
the 5.2.2 import first, so your import of 5.3.0 forked the those branches unintentionally.
[...]

Thanks for all the advice! I managed to sort it moderately cleanly in
the end, and this email records what happened and what I did, in case
anyone might benefit from this in the future.

It turns out that I'd also messed up more than I'd realised: even when
I pulled in the updated master branch, I didn't pull the upstream
branch, so managed to introduce even more conflicts. Oh well.

But the key things that allowed for a moderately clean fix were:

* I'd correctly used gbp import-orig to pull in the original 5.3.0
distribution to the master branch

* I had an upstream/5.3.0 tag in my local repository (which for some
reason I hadn't pushed, yeesh)

Ah

So the state of the salsa repository was (in an ideal world where I'd
pulled upstream):
- master included the upstream/5.3.0 commit, tagged as upstream/5.3.0,
along with further commits
- upstream was at upstream/5.2.2
- pristine-tar contained data up to upstream/5.2.2

To fix the problem, I did:

$ git checkout upstream
$ git reset --hard upstream/5.3.0

FWIW Here I miss a `git commit -a`

$ git checkout master
$ gbp pristine-tar commit

and that fixed everything. I finished with

$ git push --all

and

$ git push --tags.

Thanks for reporting, thanks for sharing what was learnt.

I hope I don't make this mistake again!

No worries, there will be other mistakes and that is good.
Know that the only way to avoid mistakes is doing nothing.

Best wishes,
Julian

Groeten
Geert Stappers
DD
--
Silence is hard to parse

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAmJn1tsACgkQITXRI9jB m+xFlA/+LVlu/3LLiPDmpWRF3Is/tPEz6oxo6fgnzYs8CamGDsrHCOBhM3/dgbo9 GbEqkMaERV3jfYoCTT1F0VANgHbdsanV47oofpPNbTlAxVxmi00DdLQlceKFDGEp P50gC74hvn5mrS1wP+83pN/gDKOT3Cxp1zzgxqXvW+HFaZfKnMa9CRwsK7b76ivH ZYY/5mGnhhvDE7sGi9HFS7ZqW2IUC5mKMjkS/xjqTZV5ffijTiYn4xkAGY0U9l/5 BBh/SR7UJbQ7LXDSP70Od3E8zgrJi95Yc/c4+uXmE7Ki323Vn2V8Di48o703dxEd +nTEQX9BdXorO3/neShQ7vlDKs8ar+9JnwlKGFAsMyq3plTtY0KYA5mt3I3mN9qD Gr8bsQGNWW4AF0yTbnOXhY4Vi7eWsaZ/kTJdZRZmfws68BLeg9nPLcaGznN9wcww fM7k/eV00RCjSO7aHSAj+e5eRGgi2Jgij7cDoWxPYNCdqi7PV7fBwHgvc7gX53UF B5AA4FyyrZsbaAS6EutLtyvjHadPfzmTB3uU2l68qpxlkh9Sw1FJGyD0ZickxI/P PeN0ATgSSKk1G3NRWeFVVUMl83kmBBr4EQBlLpC4dXpqc8HQMAJCHRpMQ6Sxccrt Zp6Nua95ZyNEu3vnbKZrWbUrTAxrVHCnRgvzk/qA17aPnK4jN9w=
=wAmc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 26, 2022 at 01:26:26PM +0200, Geert Stappers wrote:

[...]

So the state of the salsa repository was (in an ideal world where I'd pulled upstream):
- master included the upstream/5.3.0 commit, tagged as upstream/5.3.0,
along with further commits
- upstream was at upstream/5.2.2
- pristine-tar contained data up to upstream/5.2.2

To fix the problem, I did:

$ git checkout upstream
$ git reset --hard upstream/5.3.0

FWIW Here I miss a `git commit -a`

Actually there is no git commit here, surprisingly. When running
`gbp import-orig`, if I understand correctly, it checks out the
previous upstream in the master branch, then unpacks the new upstream
and commits it, tagging it as "upstream/..." - this commit has a
single parent: the previous upstream commit. Then it merges the
debian/ directory of the previous commit in the master branch with the
new upstream. The "upstream" branch contains just the upstream
commits; "upstream" is just a pointer to the most recent upstream
commit, so the `git reset` command here moves the pointer to the
correct place. There are no uncommitted files.

Thanks for reporting, thanks for sharing what was learnt.

:-)

I hope I don't make this mistake again!

No worries, there will be other mistakes and that is good.
Know that the only way to avoid mistakes is doing nothing.

That is indeed true!

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)