Hi Dmitry! While I disagree on what is an optimal workflow, I appreciate that you have documented at https://salsa.debian.org/onlyjob/notes/-/wikis/home your workflow, and what your experience was with the other tools and the issues you ran into. A lot of people just state their opinions without detailing what problem they exactly ran into, nor presenting what their alternative solution is.
Perhaps one day I will do a writeup that explains how to efficiently use `git reset --hard` in the gbp context, how to use `git difftool` to view differences between upstream/Debian or various Debian releases in Meld, and in general how to use gbp now in 2025. I think that one of the biggest shortcomings in git-buildpackage has been that the documentation historically has only listed options on what is possible, without actually listing the exact commands Debian maintainers should be repeatedly using in dally work to review package history, prepare new upstream imports, submit Merge Requests, efficiently git amend and rebase, force push new versions for re-review, how to efficiently prepare stable and oldstable updates in parallel without duplicating work etc. We have ventured quite clearly outside a regular bug report discussion, so I will end here. Just to clarify: I am not doing any changes to the gocryptfs package or repository, and nobody is planning to remove the origtargz fallback in Salsa CI. I am just saying that this repo layout is not ideal in my view, and I would feel severely limited if I had to maintain a package without access to upstream source in-place or upstream git history.
