On Tue, Jun 13, 2017 at 01:37:16PM +0100, Ian Jackson wrote: > Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git > directories in source package uploads?]"): > What about "leave ..git lying about and trust it not to break the > build" ?
I disagree. Reasons below. > > 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. I think the misunderstanding here is that I thought that by "preserve it" you meant "no change visible" and so "unescape". If you mean to build the .dsc with a ..git, then I'd call that "transform"ing it. I think this would be wrong, as it surprising to a developer that it didn't "round trip". The transformation is an artifact of the fact that the round trip happened through git. The git-ness of the tooling is "leaking", and I don't think it should (by default). > 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. I see "round-tripping" as equivalent to a no-op, which is what users expect to happen, rather than being something that is "done" on a user's behalf. If round-tripping works, then as far as the user is concerned the tooling did the right things to ensure correctness. This is what tools should by default before they do anything else. > 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). I disagree here. We don't need to "hope". I don't expect the build to see the importer's git history. It should be invisible to the build process, and I intend to make our "git ubuntu build" wrapper make it invisible. If a user tries to rebuild a previously uploaded package, then the .git originally (probably erroneously) inside the .dsc _should_ appear to the build process, because that's what happened in the original build. This is why I think the importer should round-trip it by escaping it during import, and tooling should unescaping when building a .dsc from the git tree again. If you choose not to use tooling (eg. our wrapper), then what you do is down to you, this probably won't hit you in practice, but if it does then it's your foot and your gun (IMHO unfortunate but unavoidable). If you do use our tooling, then the build will see a single .git, the same as if we weren't doing this effort at all. So this tooling won't have added any additional need to "hope". Perhaps building with a .git is is equally surprising, so I'd accept a compromise of failing by default in the normal interactive case when a ".git inside the original .dsc" (== "a ..git in the imported tree") is detected. A summary of what I want is: 1. The imported git trees are defined to escape /^\.git.*/ by prepending a '.'. Collorary: if you are working inside git and you want the final .dsc to have something starting with '.git', you must escape the name by also prepending a '.'. 2. If you use our tooling, the unescaping will happen for you automatically. If you don't use our tooling, then you can choose between: a) unescaping manually; b) building without unescaping, in which case you'll probably be fine but you're on your own if you do hit a corner case. I argue that this is the cleanest way forward because I'm defining state, rather than defining the transformations. > Archive software should reject .dscs containing ..git (except perhaps > in exceptional cases eg security branches of existing releases). Agreed in principle, though I'm not sure it's necessary to make this happen. If we do what I suggest above, then our tooling will never create a .dsc with a ..git, since it will unescape it. But sure, we can have a sanity check for that, for example if a user takes our importer's tree and runs "dpkg-buildpackage" on a commit that has a ..git. > 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'. It's much easier for me to put a check for this in my wrapper rather than get it into archive tooling (which I think would need a wider change to policy to reject "..git" on the basis that it is not permitted?). But I'm fine with doing it in both, and I assume you don't object to doing it in tooling to avoid a future failed upload. Robie
Description: PGP signature
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss