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

[Robie Basak]

On Mon, Jun 12, 2017 at 05:17:15PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]"):

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

What do you propose?

> 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.

I think we agree. I wouldn't expect a developer on an operational task
to preserve it[1]. But I think that any discard should be explicit.
Tooling can help: by refusing to proceed by default, and requiring the
developer to be explicit about whether to preserve or discard before
continuing.

> > 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.

I'm partially contradicting myself by making an exception to the
default. If the default is "fail", as I suggest, then batch processing
archeology will become painful. A developer of such a script is unlikely
to know about the edge case until a batch job fails, and the same
principle applies to any other edge cases, of which there is a generally
increasing set. So there should be a "try not to fail" mode which such
an archeologist could enable that sets all relevant defaults
differently.

Robie


[1] Though perhaps there's some value in preserving it in a low touch
stability scenario, such as an unrelated update to a package in a stable
release. But I don't think that case affects any design decision today.
-------------- 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/20170612/a52d1223/attachment.sig>