Hi Sean! > This is not expected to work. Could you explain what you were trying to > achieve, please?
So git-debrebase works well when one has been able to enable it for a repo. However, my experience is that it is sometimes very hard to "enable" it. I have been successful a few times with "git debrebase convert-from-gbp", but not every time. However, for the dgit+git-debrebase duo to be really powerful, I would expect this workflow to work: 1. dgit clone <any-package-in-debian-not-yet-in-dgit> 2. cd <any-package-in-debian-not-yet-in-dgit> 3. (modify debian/* files + source files in one commit) 4. git debrebase (neatly splits the commits) 5. dgit sbuild 6. (test package) 7. dgit push-source Now, I just get a "stacktrace" if doing this (step 4). At least, git-debrebase should come back with a sensible error message suggesting what to do. As far as I see, git-debrebase has all the information it needs to make this possible since the log contains a message such as "[dgit import orig osmo-bts_0.7.0.orig.tar.xz]" - where the version should match the version in the last changelog entry. Actually, I struggled so much with enabling git-debrebase for a few packages, that I ultimately gave up. I tried many variants such as: - deleting patches/* . and committing this manually - Creating a upstream/<version> tag from the clean import of orig manually - Putting in "git rebase stitch" here and there. Every time it failed with a not-understandable error message. Can you please provide instructions for how git-debrebase is supposed to be enabled for a package which is not already maintained with gbp? It might be that I have misunderstood the tool in a fundamental way, but at least it should not dump a stacktrace in this case. :) Best regards Ruben
