"git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]

[Robie Basak]

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'[1], 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20170613/701f24f8/attachment.sig>