On Tue, Jan 10, 2017 at 10:14:09AM -0800, Nikolaus Rath wrote: > On Jan 10 2017, Guido Günther <a...@sigxcpu.org> wrote: > > On Wed, Jan 04, 2017 at 04:38:11PM -0800, Nikolaus Rath wrote: > >> On Jan 05 2017, Brian May <b...@debian.org> wrote: > >> > Vincent Bernat <ber...@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
