Hi, > Does this mean that maintaining upstream Git history will be standard in > the Go team?
Yes, it means that you can git blame on upstream code (outside of debian/) and see what was introduced when, and you can run gbp switch --force and git cherry-pick -x <upstream commit> to backport fixes from newer upstreams to Debian releases etc. If does *not* mean that git history is garbled. There should be a single commit for each upstream import on the upstream/latest branch (and on pristine-tar) branch, but that upstream commit will have a parent commit that points to the upstream git release tag. > Personally, I prefer the simpler method of not pulling from upstream and > just importing from a tarball, as it results in better (IMO) commit > history[1] and it is much easier to revert or checkout previous upstream > versions (i.e. simpler navigation of packaging commit history). In > addition, pulling from upstream introduces tagging problems and results > in either: > 1. Two identical tags from upstream (e.g. "v2.2.4") and gbp (e.g. > "upstream/2.2.4") being created. > 2. The "upstream/2.2.4" tag format not being used at all. > (I have seen both of these occur when upstream history is incorporated.) Take a look at the graph view at https://salsa.debian.org/go-team/packages/golang-github-muesli-gitcha/-/network/debian%2Flatest GitLab is not brilliant in this, you might have a better view locally running `gitk --all &` and browsing it. Anyway, note that: - branch debian/latest has the actual packaging - branch debian/latest HEAD is tagged debian/0.3.0-1 which was uploaded recently, and there are no new commits after it - branch upstream/latest merged into debian/latest in commit titled "Update upstream source from tag 'upstream/0.3.0'" - branch upstream/latest is currently at commit "New upstream version 0.3.0", tagged upstream/0.3.0 - this is NOT the same as the upstream release, but it is a commit that has two parents: -- a561dce4: upstream git commit that was tagged as v0.3.0 -- a71b4793 previous upstream/latest import commit, tagged as upstream/0.2.0 If gbp.conf has the upstream tag format (which luckily in Go upstreams is always v0.0.0) and branches and pristine-tar like in https://salsa.debian.org/go-team/packages/golang-github-muesli-gitcha/-/blob/debian/latest/debian/gbp.conf, then simply running `gbp import-orig --uscan` will always do the Right Thing. I am aware that without the gbp.conf people might run git-buildpackage with various options and end up in messy repositories. I suspect the examples you listed above is from such situations. > I forgot to mention that gbp-dch also doesn't work properly with > upstream Git history, generating massive changelog entries that include > upstream's commits as well. It's very annoying when gbp-dch is supposed > to make updating the changelog more convenient. Yep, this is a shorcoming in git-buildpackage which I have raised with the maintainer and intend to keep pushing so gbp defaults to just looking at commits in debian/ subdirectory. You can now update d/changelog with this to have it automatically only include debian/ changes: gbp dch --distribution=UNRELEASED \ --commit --commit-msg="Update changelog and refresh patches after %(version)s import" \ -- debian
