On Mon, Nov 18, 2024 at 06:19:58PM +0200, Peter Pentchev wrote: > However... different people are used to different workflows. > I personally really, really like the fact that I have the Git history of > all the upstream files in the same repo and I don't have to go over to > a different repo to figure out what changed when. Also, I like that > immediately after `gbp import-orig` I can run `git show upstream` to > review the diff (TBH, me being very pedantic, I usually have already > given it a quick glance using `diff -urN` on unpacked tarballs before > even importing it, if only to figure out if there are new files that > I need to exclude, but that's not always the case), and that I can > at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path` > or similar commands. I have even been known to use `git bisect` in > a Debian package directory in some weird cases. > > And yes, all of that can be handled in a separate Git repo with > a clean checkout of the upstream repository without any of > the Debian fluff; however, that would require me switching between > terminals/tmux panes/whatever, and sometimes that seems like too much > work when I can have it all in a single repository :)
Preface, just in case: I list a few git commands, don't try running them if you have uncommitted changes. Okay, I could amend what I proposed originally with this option: Do the debian work in a fork of upstream's repository, but never merge the debian branch and upstream branch. That is, the start of Debian maintenance would be by cloning upstream and then with "git checkout --orphan debian" followed by "git reset --hard". Do you think you could do all of the above with that model, with a command like "git checkout debian -- ." to insert the debian contents to an upstream branch? I'm thinking that it's the merging of debian and upstream branches and maintaining it that really causes the warts in gbp and I'm not at all sure if there are any actual workflows that require having that. "upstreamless" as I described it may be a bit too much for general use but could there be a case for doing everything with a mergeless model instead? Furthermore, I think import-orig should really be only about establishing a particular byte string as the orig.tar. Think of object storage. If there's a connection to a particular commit hash or release tag in the repository it would better be represented as a separate entry. Perhaps as a text file like debian/upstream-commits that would be a list of upstream version/commit hash or tag pairs. From where I stand, the way these disparate concerns have been merged seems to be one root cause for all sorts of unintended consequences. > So... yes, a simpler setup would work for some people, and it may be > better for beginners. However, there are some benefits to a full > repository containing both the upstream source and the Debian changes, > and some people like to use them every now and then. I don't agree with framing this as a beginner/expert issue. > Still, thanks for your desire to make working on Debian easier and > better! You don't really sound willing to discuss anything with that but I'm still going to try.
signature.asc
Description: PGP signature
