Russ Allbery [24/Feb 8:56am -08] wrote: > 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.
No, it's done that for a long time. >>> 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. I tend to prefer to see the dgit view locally if I can. But someone else said to me that they prefer not to see the generated stuff. So I don't know. -- Sean Whitton
signature.asc
Description: PGP signature
