Dear Maintainer,

import-dsc create merge commits instead of normal commits for the first
Debian patch after a new upstream release. This is very impractical.
These commits are continuous sources of conflicts and this makes doing
rebasing operations (for example for cosmetic purposes or to add
changelogs in the commit message like suggested in bug #577810) very
time consuming or practically impossible for packages with longer
histories.

import-dsc will create an history like this:

```
* 244a2a6 (HEAD -> master, tag: debian/0.9b-2) Imported Debian patch 0.9b-2
* 82a9cf5 (tag: debian/0.9b-1.1) Imported Debian patch 0.9b-1.1
*   2531e71 (tag: debian/0.9b-1) Imported Debian patch 0.9b-1
|\
| * 255de2b (tag: upstream/0.9b, upstream) Imported Upstream version 0.9b
* | a7bfdf7 (tag: debian/0.8b-1) Imported Debian patch 0.8b-1
|/
* ce22f3b (tag: upstream/0.8b) Imported Upstream version 0.8b
```

It should instead act like import-orig does in the normal case, creating
an history like the following:

```
* 244a2a6 (HEAD -> master, tag: debian/0.9b-2) Imported Debian patch 0.9b-2
* 82a9cf5 (tag: debian/0.9b-1.1) Imported Debian patch 0.9b-1.1
* 2531e71 (tag: debian/0.9b-1) Imported Debian patch 0.9b-1
*   xxxxxxx Merge tag 'upstream/0.9b'
|\
| * 255de2b (tag: upstream/0.9b, upstream) Imported Upstream version 0.9b
* | a7bfdf7 (tag: debian/0.8b-1) Imported Debian patch 0.8b-1
|/
* xxxxxxx Merge tag 'upstream/0.8b'
* ce22f3b (tag: upstream/0.8b) Imported Upstream version 0.8b
```

In this way each Debian patch is represented by a normal commit and
operations like cherry-picking and rebasing became feasible.

I've been hitting this recently and wondering whether the current
behaviour is by accident or design (I'm surprised it's at least five
years old) but I concur with the filer that a much simpler, two-step
merge (merge upstream, then apply debian diff as the next commit) would
be *far* easier to work with. Do the maintainers have a view?

All that is needed to do two-step merge (first merge the upstream branch, then
apply the debian diff) is to do a merge at the right moment in `import_dsc.py`.

The following quick-and-dirty patch adds such a merge.

--- /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py.orig       2022-07-10 13:14:48.358945384 +0200
+++ /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py        2022-07-10 14:22:25.030125614 +0200
@@ -520,20 +520,23 @@ def main(argv):
                  commit = import_upstream(repo, sources[0], dsc, options)
                  imported = True

              if not repo.has_branch(options.debian_branch):
                  if options.create_missing_branches:
                      repo.create_branch(options.debian_branch, commit)
                  else:
                      raise GbpError("Branch %s does not exist, use --create-missing-branches" %
                                     options.debian_branch)

+            tag = os.popen("git tag --list 'upstream/*' --sort=-v:refname | head -n1").read().rstrip()
+            os.system(f'git merge {tag} --strategy-option theirs -m "Merge tag \'{tag}\'"')
+
              if dsc.diff or dsc.deb_tgz:
                  apply_debian_patch(repo, sources[0], dsc, commit, options)
              else:
                  gbp.log.warn("Didn't find a diff to apply.")

              if imported and options.pristine_tar:
                  repo.create_pristine_tar_commits(commit, sources)
          if repo.get_branch() == options.debian_branch or repo.empty:
              # Update HEAD if we modified the checked out branch
              repo.force_head(options.debian_branch, hard=True)

Having just imported a large package history of 100+ .dsc's, I
definitely agree that this creates a much nicer history, at the cost of
increased verbosity.  The result was definitely worth it, thank you very
much!

Cheers,
       Sven

The attached new patch, although still "quick and dirty", improves the
handing of possible modification+deletion conflicts that may arise while
merging the the upstream branch into the Debian branch.

Dear package maintainer of git-buildpackage,

Do you have an idea when you will find time to look at this patch?

[Gioele Barabucci 2024-08-19]

Hi Peter,

Sorry, I assumed that it was meant to show the intended result not as an
actual patch proposal (as it doesn't use any of the methods provided by
gbp but shells out via popen). (It *is* helpful to demo the desired
outcome, thanks Gioele).

So is the intended flow to

- import the new upstream version
- fake merge that into the packaging branch (using the "replace" mode
  to avoid any conflicts (e.g. if the upstream source contain a debian/ dir)
- apply the new debian/ on or debian diff on top?

If so a patch that reuses the corresponding bits from import-orig (plus
adjusting the test to verify it) would be very welcome.

Cheers,
 -- Guido