Hi Peter,
On Mon, Apr 15, 2024 at 02:28:18PM +0200, Petter Reinholdtsen wrote:
> Dear package maintainer of git-buildpackage,
>
> Do you have an idea when you will find time to look at this patch?
Sorry, I assumed that it was meant to show the intended result not as an
actual patch proposal (as
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]
> The attached new patch, although still "quick and dirty", improves the
> handing of possible modification+deletion conflicts that may arise while
>
On Sun, 10 Jul 2022 14:34:01 +0200 Gioele Barabucci
wrote:
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.
[...]
+
On 2022-07-10 14:34 +0200, Gioele Barabucci wrote:
> 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.
>
> ---
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
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
Package: git-buildpackage
Version: 0.7.0
Severity: normal
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
7 matches
Mail list logo
