Le vendredi 06 août 2021 à 18:11 +0200, Rafael Laboissière a écrit : > * Sébastien Villemot <sebastien@debian.org> [2021-08-04 09:24]: > > > Le mardi 03 août 2021 à 12:29 +0200, Rafael Laboissière a écrit : > > > > > > […] > > > > > > I will try to automate the procedure to avoid errors due to manual > > > operations. Please tell me whether you agree with the plan above or if > > > I forgot something. > > > > Sounds good to me, thanks. > > Ok, I wrote a script that automates the whole procedure [*]. I tested it > on the octave-brain2mesh repository. Everything seems to work correctly > with the new layout, as you can check by cloing a fresh repository: > > gbp clone git@salsa.debian.org:rafael/octave-brain2mesh.git > > I did not test the whole workflow but, at least, "gbp dch", "gbp > buildpackage", and "gbp import-orig" seem to work fine. > > Unfortunately, I could not find a way to update an existing cloned > repository with the old branches "master" and "upstream". If someone know > how to do it, please let me know. If you have already commit to your > local master branch and not pushed them, I apologize for the > inconvinience. The following may work (untested): git fetch git branch --move upstream upstream/latest git branch --move master debian/latest git branch --set-upstream-to=origin/upstream/latest upstream/latest git branch --set-upstream-to=origin/debian/latest debian/latest git checkout upstream/latest git pull git checkout debian/latest git pull > Please, check the octave-brain2mesh repository and let me know if there > are any problems. If everything is okay, I will launch the script and > update all the repos. I think it all looks good. Regarding the “merge-mode=merge” thing: this is a workaround to a problem that you had identified some time ago, namely that the top- level .gitignore file is wiped out when doing a gbp import-orig¹. We had agreed privately² to add merge-mode=merge option in all gbp.conf files. I must say that I’m not 100% happy with this solution, because it may have unintended consequences if one modifies inadvertently an upstream file in the git repository (though I think the problem will be catched later by dpkg-buildpackage). This will also create conflicts if an upstream decides (for some reason) to ship the .gitginore file in the tarball. However at this point I’m not aware of another solution, though I did not investigate much. We could have a debian/.gitignore file which would note be wiped out by gbp import-orig, but we could only ignore files in the debian/ subdirectory. And even though this problem is unrelated to the DEP-14 layout, I understand that saving both problems at the same time is an economy of scale. Unless we find another solution, could you add a comment in the gbp.conf file that says that we changed this setting in order to preserve the top-level .gitignore? By the way, I realize that I have *again* inadvertently deleted the top-level .gitignore in the octave repository. I’m going to try to restore it. ¹ https://lists.debian.org/debian-octave/2018/08/msg00003.html ² In a thread starting on 2020-10-31 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ https://www.debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part