Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"): > On Mon, Jun 12, 2017 at 05:46:14PM +0100, Ian Jackson wrote: > > Again, I don't follow why `fail' occurs. You seem to be suggesting > > that importing a .dsc containing a .git would generate ..git. > > Correct. I'm suggesting "fail" for the round-tripping - for "git ubuntu > build-source" to "unescape" the ..git. Or if we don't agree, then I > think there are only three reasonable choices: (fail, discard, > unescape). > > I'm suggesting: > > 1. Interactive use: fail. > 2. Non-interactive use ("batch mode", eg. -B like ssh): unescape.
What about "leave ..git lying about and trust it not to break the build" ? I wrote: [If] the transformation is reversible, I think this should be for archeaological purposes, not for operational ones. Ie you should be able to inspect what's there, but any work based on the old branch should probably either preserve it or discard it. You replied: > I think we agree. But you continue to talk about `round-tripping' as if this was going to be a routine operation, which tools should occasionally do on the user's behalf. The way I see it: Some ancient .dscs contain .git. We transform these on import, and corresponding git trees might contain a `..git'. We hope that building those trees works even though the build will see both `.git' (containing importer history) and `..git' (archeaological history made by the importer from the .dsc's .git). Archive software should reject .dscs containing ..git (except perhaps in exceptional cases eg security branches of existing releases). If anyone wants to make a version of the package derived principally from such an ancient version, the archive tools will reject the upload unless the user has deleted the `..git'. This deletion should be requested manually somehow, and the need for this will be sufficiently rare that wrapper tooling for it superfluous. The user should be expected to say `git rm -r ..git'. Ian. _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss