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,
unescape).
I'm suggesting:
1. Interactive use: fail.
2. Non-interactive use ("batch mode", eg. -B like ssh): unescape.
> (I assume that Launchpad would be taught to reject new introductions
> of \.+git other than in security support or ancient branches.)
Agreed - if it doesn't do that already.
> If someone has such an importer-generated tree, containing ..git, they
> can just use it and ignore the ..git. Surely that's why this is a
> good choice of directory name.
Agreed.
> If there are any non-historical packages containing .git directories,
> we should file bugs and get them fixed.
Agreed.
Robie
signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]
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.
--
Ian Jackson These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]
On Mon, Jun 12, 2017 at 04:57:06PM +0100, Ian Jackson wrote: > `dgit clone' disables these .gitattributes; provides a separate verb > for disabling them in other trees; and `dgit fetch' warns about them > if it finds them. So...you have a wrapper? 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? 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". 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. Robie signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: "git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]
Robie Basak writes (""git ubuntu" wrappers [was: What to do with .git
directories in source package uploads?]"):
> Some examples:
>
> Upstreams that ship .gitignore confuses distribution developers (IMHO)
> who want to see *everything* that has changed. I'd like to work with git
> upstream in adding a repository level configuration option (or similar)
> to completely ignore all dotfiles in the worktree that affect git's
> behaviour. As a distribution developer, git's behaviour should come from
> me, not some random upstream whose package I happen to be working on. In
> the meantime, our wrapper warns you if these are present.
AIUI .gitignore does not affect whether git shows you diffs to files
that have changed. It simply suppresses listing of _added_ files.
> Similarly, there are upstreams that use $Id$ and similar abominations.
> The only sensible way to handle these and other corruptions is to turn
> off ident, text and eol in .git/info/attributes, which our wrapper adds
> on "git ubuntu clone".
`dgit clone' disables these .gitattributes; provides a separate verb
for disabling them in other trees; and `dgit fetch' warns about them
if it finds them.
> Having sensible default refspecs and dealing with sharing repositories
> when you can't push to the main importer repository is a pain. This is
> amplified when few developers work across many packages and don't keep
> persistent local git repositories for them. So "git ubuntu clone" and
> "git ubuntu remote add" deal with setting up reasonable default
> remotes and refspecs.
Obviously having sensible remotes is nice, but not IMO essential.
> In Ubuntu, the importer must maintain separate pristine-tar branches for
> Debian and Ubuntu because orig tarballs may not necessarily match. We
> try to make them match, but the importer must be able to represent
> everything that happened, including past mistakes. But "git clone"
> followed by "dpkg-buildpackage" won't be able to find the upstream
> tarball, and nor can gbp without adjusting the local pristine-tar
> branch. This is solved by "git ubuntu build-source", which takes care of
> getting the upstream tarball for you first.
dpkg-buildpackage -B does not need an upstream tarball.
It seemed obvious to me when writing dgit that it would be too hard to
to make a uniform data model and workflows that could be used to
generate source packages from git.
Anyway, I don't think a wrapper that does "unescaping" of .git is a
good idea.
Ian.
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
"git ubuntu" wrappers [was: What to do with .git directories in source package uploads?]
On Mon, Jun 12, 2017 at 04:31:48PM +0100, Ian Jackson wrote:
> Robie Basak writes ("Re: What to do with .git directories in source package
> uploads?"):
> > In mitigation, we have "build" and "build-source" wrappers that could
> > always do the correct unescaping here. Then you'd only fall into the
> > trap if you aren't using the wrapper.
>
> If these wrappers are what I think they are, they are IMO a bad idea.
I don't like them either, but for the moment, they are IMHO necessary. I
would like to see them go away, so I have been keen on not requiring
them for any workflow. I'd also like to make sure that all documentation
makes it clear how to _not_ use the wrappers. However, if you don't use
them, there is a growing list of caveats of which you need to be aware,
usually for edge cases.
Some examples:
Upstreams that ship .gitignore confuses distribution developers (IMHO)
who want to see *everything* that has changed. I'd like to work with git
upstream in adding a repository level configuration option (or similar)
to completely ignore all dotfiles in the worktree that affect git's
behaviour. As a distribution developer, git's behaviour should come from
me, not some random upstream whose package I happen to be working on. In
the meantime, our wrapper warns you if these are present.
Similarly, there are upstreams that use $Id$ and similar abominations.
The only sensible way to handle these and other corruptions is to turn
off ident, text and eol in .git/info/attributes, which our wrapper adds
on "git ubuntu clone".
Having sensible default refspecs and dealing with sharing repositories
when you can't push to the main importer repository is a pain. This is
amplified when few developers work across many packages and don't keep
persistent local git repositories for them. So "git ubuntu clone" and
"git ubuntu remote add" deal with setting up reasonable default
remotes and refspecs.
In Ubuntu, the importer must maintain separate pristine-tar branches for
Debian and Ubuntu because orig tarballs may not necessarily match. We
try to make them match, but the importer must be able to represent
everything that happened, including past mistakes. But "git clone"
followed by "dpkg-buildpackage" won't be able to find the upstream
tarball, and nor can gbp without adjusting the local pristine-tar
branch. This is solved by "git ubuntu build-source", which takes care of
getting the upstream tarball for you first.
None of these things *require* the wrappers, but we currently have no
way of making the things that they do unnecessary without causing
developer onboarding or edge case pain.
I believe there are other cases too; these are just off the top of my
head.
Robie
signature.asc
Description: PGP signature
___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
Re: What to do with .git directories in source package uploads?
On Wed, May 24, 2017 at 10:56:52PM +0100, Ian Jackson wrote: > But if there are packages where the .git directory is somehow actually > used in the build, your scheme won't help because a build from the > imported git tree will use your history, not the history found in the > .dsc's .git. I don't think this matters. By using our imported git tree and using git to clone it, the user is explicitly requesting our importer's history in .git, contrary to the source package's .git directory. I think it's reasonable for "our git" to "take over" .git in this case. The original uploader left a .git "trap" and we aren't in a position to remove the trap for unsuspecting developers, but I don't think we're making it worse. The badness happened in as an interaction between the bad source package and the the decision to use git tooling and have an importer in the first place, and the user is complicit in the latter decision. In mitigation, we have "build" and "build-source" wrappers that could always do the correct unescaping here. Then you'd only fall into the trap if you aren't using the wrapper. Robie signature.asc Description: PGP signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/vcs-pkg-discuss
