Sean Whitton <[email protected]> writes: > Russ Allbery [23/Feb 10:38am -08] wrote:
>> What git-debrebase does under the hood is quite complex, but you can >> mostly ignore it. The UI it exposes to you is that you can commit >> changes to upstream source normally, as with any other Git repository, >> and when you build the source package, all your upstream changes will >> be broken out into separate patches in debian/patches using the commit >> message as the patch header. Most of the time, the only constraint you >> have to follow is to make sure to never make a single Git commit that >> changes both Debian packaging files and the upstream source. > No, it's fine to make a change to both, git-debrebase will split them. Oh, neat! I think that's new? Or maybe I just misunderstood. >> If you do take that approach, I also recommend: >> git config --add --local dgit.default.split-view always >> which tells dgit to not commit debian/patches to your main working >> branch or expose it on Salsa. It's still present in the dgit view of >> your repository as uploaded, so that the dgit view matches the source >> package, but that way you don't have the output-only clutter of the >> broken-out patches in your working directory and don't have to remember >> to not touch those files. > Maybe we should have that in the workflow manpage? WDYT? I love it because it removes generated artifacts from my Git tree, which is how I always prefer to work, but I defer to you to decide if it's more magical than you may want to recommend to people who might be new to the workflow. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
