Control: retitle -1 dgit: can't handle debian branch with removed files
Replying to the new bug because indeed this is a different problem.
I've found the cause. While my repo was faulty, I wonder if dgit can
be made to work better in this case.
On Wed, Jun 21, 2017 at 8:55 AM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
>
> Felipe Sateler writes ("Bug#842614: Bug#842608: dgit pull should bail out in
> splitbrain mode"):
> > But the clash between the upstream gitignore and the debian one breaks dgit.
> >
> > Or at least that's what I think it happened when I tried to use dgit. As I
> > said
> > in my earlier message, the dgit output is unparseable for me :(
>
> I'm sorry that you found the error message incomprehensible. It's
> difficult to know how to improve this without having dgit spit out an
> essay.
I think verbose error messages are a feature, not a bug. But, I have
some ideas, more below.
>
>
> Are you sure that this is caused by .gitignore ?
No, I was not sure. As mentioned, I thought it was (due to gitignore
being mentioned), but I didn't understand the error message. Further
investigation reveals it is indeed not the gitignore file.
> Let me explain these messages:
>
> | dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
>
> dgit is simply saying that because you specified --quilt=gbp, it may
> need to use split view mode. It's going to check.
>
> | dgit: base trees orig=d510ca798480f37fc567 o+d/p=5c8951c97cef58952a93
>
> dgit creates a git object corresponding to the contents of the
> .orig.tar.gz. That git object is d510ca798480f37fc567. dgit calls it
> "orig" in some of the next output.
>
> It also creates a git object corresponding to the .orig.tar.gz but
> with debian/ copied from your .debian.tar.gz. That's a "patches
> unapplied" tree. That git object is 5c8951c97cef58952a93.
> dgit calls this "o+d/p" in some of the next output. TBH maybe it
> ought to be called "o+d".
>
> These git object names are provided so you can use `git diff' etc. to
> investigate what's going on.
(FTR, this repository is csound, if you want to try out what is wrong)
OK, so now we can investigate what is wrong. Lets diff the first git commit:
% git diff --stat master..d510ca798480f37fc567
debian/patches/debian-specific/lua-link.diff | 6 +-
doc/latex/doxygen.sty | 78 +++++++++++++++++++++++
frontends/CsoundVST/ScoreGeneratorVstUi.cpp | 169
++++++++++++++++++++++++++++++++++++++++++++++++++
frontends/CsoundVST/ScoreGeneratorVstUi.h | 34 ++++++++++
4 files changed, 282 insertions(+), 5 deletions(-)
The diff in the patch is removal of `diff --git` lines generated by
gbp pq. The other files are not present in the master branch but they
are in the upstream tarball. It appears that at some point in the
history I removed them from the debian branch[1]. This breaks dgit's
expectations and thus the error we saw before. dpkg-source is fine
with this because it ignores file removals. Restoring these files
makes `dgit --clean=git sbuild` work.
So, my repository was faulty and fixing this fault makes dgit work.
Success! However, I wonder if dgit can be more forgiving of this
problem. I have done this sort of removal in the past, when upstream
includes autogenerated files in the tarball that are removed on clean.
dgit would be incompatible with those repositories.
BTW, if d510ca798480f37fc567 is supposed to be the orig tarball, why
does it have the debian dir? Or are the reported trees the
patches-unapplied and patches-applied trees?
[1] I didn't retrace the whole history but it appears that at some
point they were excluded when repacking but they no longer are, and
thus the removal from the debian branch persisted. These files are not
used for debian so this fault was never uncovered.
> | dgit: quilt differences: src: ## orig ## gitignores: == orig ==
> | dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p
>
> dgit is reporting the differences between these various trees. It
> considers only differences outside debian/, and separates out the
> comparison of .gitignores from the comparison of other files.
>
> Your HEAD, the .orig, and the .orig plus debian/, are all different.
> But the .gitignores (outside debian/) in all of these trees are
> identical.
This error message should list the offending files, similar to how
dpkg-source prints the filenames when it finds uncommitted changes.
Something as simple as printing the git diff --stat would be very
useful.
>
> | dgit: --quilt=gbp specified, implying patches-unapplied git tree
> | dgit: but git tree differs from orig in upstream files.
>
> --quilt=gbp expects to be given a gbp interchange branch, which (as
> far as upstream files goes) is patches-unapplied except that it might
> contain uncommitted .gitignore changes.
>
> However, your HEAD differs from your .orig in other ways.
>
> git-diff HEAD d510ca798480f37fc567 will show you the differences from
> the upstream tarball.
>
> git-diff HEAD 5c8951c97cef58952a93 will show you the differences from
> upstream + your debian/. That should be empty apart from .gitignore.
The error message should probably include these two lines to hint
further investigation.
>
> > But the clash between the upstream gitignore and the debian one breaks dgit.
>
> This is supposed to be handled by --quilt=gbp.
For this repository at least, this was not a problem
Thanks!
--
Saludos,
Felipe Sateler
