[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Converting to dgit

On Thu, 2017-01-12 at 21:46 +0100, Raphael Hertzog wrote:
> Hi,
> On Fri, 06 Jan 2017, Ghislain Vaillant wrote:
> > > I don't use it often enough to remember all the details either.  I don't 
> > > recall the last time I had to do more than copy/paste a command from the man 
> > > page (OK, git-dpm tag I can remember).
> > 
> > Besides, git-dpm usually tells you what command to run next, like:
> > 
> > git-dpm import-new-upstream -> git-dpm rebase-patched -> git-dpm update-patches
> > 
> > It did not take me much time to adapt to the git-dpm workflow as a
> > result. I should say that I have been a happy git-dpm user so far.
> And I have been a very unhappy user with python-django. If by mistake, you
> use "gbp import-orig" instead of "git-dpm import-new-upstream" then you're
> completely screwed because git-dpm relies on metadata it manually stores
> in debian/.git-dpm, it does not rely on git's history to figure out the
> appropriate data. Same if you change any patch outside with a third party
> tool...

Well, remember that `git-dpm import-new-upstream` only records the new
upstream commit in the .git-dpm metadata and delays the actual import
of the new upstream data until you have a properly rebased patch queue.

This is to be contrasted with `gbp` where you may import the new
upstream and leave the packaging repository in an inconsistent state
(as far as the patch queue is concerned) until someone runs `gbp pq` or
`quilt` to refresh.

Then, no wonder that mixing `gbp import-orig` with git-dpm does not
work. I admire your courage for trying to fixup the git-dpm metadata
manually nonetheless. Same problem if you try to mix `git-dpm cherry-
pick` with `gbp pq import` -> `git cherry-pick` -> `gbp pq export`.

> So I have opened the manual page many times to read about the format of
> that file and tried to fix up the inconsistent meta-data.
> Also it's really painful to use with multiple branches as you can't really
> merge branches together:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801667

This is indeed a limitation. Based on the design of the tool, git-dpm
works on a rather flat git history. Considering the workflow you
described for django, git-dpm is unlikely to ever become suitable.

> It produces a very verbose git history as soon as you have a significant
> number of patches, even if most of them do not change at all across a
> minor upstream release.

Is that such a bad thing though, I wonder? Given that the price for it
is a guaranteed consistent patch queue.

> Also it's effectively orphaned, nobody is taking care of bugs.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801666
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801548
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795694

So was pristine-tar for a long time and people kept using it

I also commented in #801666, so I am aware of your issues with git-dpm. 
I agree that integration with existing gbp configuration would be a
plus and help support arbitrary repository layouts, such as those
recommended in DEP-14.

I don't necessarily disagree with you, as I keep using both gbp and
git-dpm in a complementary way. I just wanted to contrast the perceived
hate towards git-dpm in this thread with some positive feedback.


Reply to: