On Mon, Nov 18, 2024 at 08:16:59PM +0200, Kari Pahula 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.
You are talking about the upstream git history while Peter is talking about simply importing orig tarballs. Maybe what is causing warts in gbp *for you* is some *specific* gbp workflow, one of the many it supports? -- WBR, wRAR
signature.asc
Description: PGP signature
