-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: export_orig: excludes files set in Files-Excluded #56
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Shengjing Zhu <i@zhsj.me>
Thanks for a having a look! While for the export-orig case (a) this makes sense but I think for the pkg-go use case (b) it's different: There are no tarballs involved since the "merge" from the upstream-ref will (when filtering is applied) create a commit that has all the necessary files filtered out (at least that's the plan to implement). Since this commit will be tagged it can be used for tarball creation and no filtering on export is necessary. Just to be sure are you looking at a) or b) ? |
Both. I'm first looking at the pkg-go workflow. Since last year's debconf, we have a draft for the new workflow[2]. It's still unclear how to manage the dfsg branch. And the reference packaging tool, dh-make-golang[1] still uses the old layout, importing upstream tarball as one commit to upstream branch, creating pristine-tar branch. [1] https://github.com/Debian/dh-make-golang |
For pkg-go I'd simply create the appropriate commit with the files filtered out (with the original commi as parent) and tag it correctly, the rest will then be handled by export-orig / buildpackage transparently. With your patch we'd have to import the exported tarball again (to which branch?) so i'd go with creating a new commt with the filtered out files. And just to be sure: this is not only usefule for pkg-go but for git based workflows in general. |
I'm unclear either, about how to store the dfsg branch, how the commit history should be looked like. As said in #812721, I'm currently using uscan-git-mode based workflow, which is easy to understand. |
We can focus on creating the filtered commit plus tag first. The dfsg-clean branch is than just an additional parent we add to the commit. |
Sure. Maybe we can drop this patch now? However what's your idea about #466912. I think this patch giving the idea about how to implement #466912 and can be modified slightly to implement a BTW, I'm still little uncomfortable with: one filtering commit after every upstream's tag. Maybe I'm wrong at gitish. Is there a BOF at debconf18, I'd like to see how people describe their gitish work flow. |
This is still in work, but I'd like to see comments, and don't merge yet.
To fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812721 we first need to create the orig tarball like mk-origtargz, reading the Files-Excluded filed in d/copyright, then let git-archive exlcude them.
git-archive will ignore files that has export-ignore attribute.
Manipulating .gitattributes will pollute the git tree, but we can set these attributes in $GIT_DIR/info/attributes.
TODO: