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,
> 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
[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.
> 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
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'.
vcs-pkg-discuss mailing list