Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git 
directories in source package uploads?]"):
> I don't really follow what you're saying. Are you saying that wrapping
> these types of things in general is bad, or that having a wrapper for
> the specific case of unescaping .git is bad?

Yes, the latter.

> For the latter, I think that safe round-tripping is an important
> property of an importer and that ditching this property shouldn't be
> taken lightly. I'm applying this principle in making design decisions
> that we can't easily change later, such as the imported "format".

There is some logic to this, indeed.  I think your model requires a
higher degree of fidelity.

So I guess it's worthwhile thinking about how to make any
transformations you do reversible, from which pov ..git is not too
bad an idea.

Before we adopt this I think we should consult more widely, though.

And: even 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.

> OTOH, I wouldn't consider it to be a high priority to actually
> implement, and a default of failing if ..git exists would be perfectly
> acceptable for this extreme edge case. We could require the user to tell
> us exactly what is required (drop or unescape) when rebuilding the
> source package.
> Though then we'd probably need a "batch mode" that would probably
> default to unescape to avoid creating a minefield of edge cases for
> script writers.

I'm not sure what you mean.  Do you mean something which contradicts
my previous paragraph.


Ian Jackson <>   These opinions are my own.

If I emailed you from an address or, that is
a private address which bypasses my fierce spamfilter.

vcs-pkg-discuss mailing list

Reply via email to