Re: Feedback on 3.0 source format problems
On Tue, Jan 10, 2017 at 10:14:09AM -0800, Nikolaus Rath wrote:
> On Jan 10 2017, Guido Günther <agx@sigxcpu.org> wrote:
> > On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote:
> >> On Jan 05 2017, Brian May <bam@debian.org> wrote:
> >> > Vincent Bernat <bernat@debian.org> writes:
> >> >
> >> >> There have been a lot of complaints about it. For me, it is a pain to
> >> >> use. Its integration with gbp is poor, it produces a messy history when
> >> >> you are working on your patches and I often run into problems with
> >> >> .debian/.git-dpm file it maintains (import a new upstream, make some
> >> >> changes, notice that somebody else also pushed a change, pull --rebase,
> >> >> everything is broken). Since we started using it, we opened a lot of bug
> >> >> reports and not a single one of them has been fixed. I think that nobody
> >> >> wants to work on it because it is an extremely fragile tool and the
> >> >> first one to try to fix it will inherit of all the problems to solve.
> >> >
> >> > It also has a number of bugs that are not getting fixed.
> >>
> >> Yeah, I think we heard before that git-dpm is not being maintained. I
> >> said it, Vincent said it in his reply, and now you are saying it
> >> again. No one is disputing the point.
> >>
> >> > Plus if conflicts occur because multiple people unexpectedly make
> >> > changes at the same time it (i.e. you can't push because somebody else
> >> > already pushed changes) can be a world of confusion trying to sort out
> >> > the mess.
> >>
> >> Yes, it is a mess. But I don't think it's any worse than having to
> >> resolve conflicts in debian/patches/, which is the equivalent problem
> >> when multiple people use gbp at the same time.
> >
> > When this happens you do a "gbp pq import" and have the full power of
> > git rebas at your hands.
>
> Are you sure? The problem we're talking about is when two conflicting
> changes to debian/patches have been committed. I think in that case you
> first have to solve the git conflict before you can call gbp pq - or can
> gbp pq import really deal with conflict markers *inside the patch*?
You abort the merge instead of resolving the conflict then do a gbp pq
on your packaging branch and on the (know known to be) conflicting one
(say master and origin/master). Then you can use rebase and
whatnot. Not ideal but much batter than wading through merge conflicts
in diffs.
Cheers,
-- Guido
Reply to: