On 19/10/2012 13:29, Steve Langasek wrote: > On Thu, Oct 18, 2012 at 09:54:27PM -0700, Russ Allbery wrote: >>> AIUI, most users of pristine-tar in git don't have the second of these >>> branches, which means the pristine-tar binary delta is done against the >>> upstream branch - so each pristine-tar blob contains all the information >>> about autogenerated files in the tarball, in a format that doesn't in >>> turn compress well in the git repository. > >> Oh. No, I'm fairly certain that you're wrong, since any user of >> git-buildpackge will have the second. Rather, what's normally missing >> from most Git-based packaging is the *first* branch, since the >> git-buildpackage workflow was designed originally around importing >> upstream tarballs to create the second branch. > > Ok. Well, bear in mind that this is all second-hand. I was complaining on > IRC about having to work with the designated Vcs-Git branch on a package (I > don't remember which) that didn't use pristine-tar, and multiple developers > rallied to the defense of this practice, claiming that pristine-tar caused > git repositories to rapidly balloon in size. Perhaps one of them can speak > for themselves about what they think the issues are. :) > > On Thu, Oct 18, 2012 at 10:09:17PM -0700, Russ Allbery wrote: >> Oh, wait, no, I see what you're saying: one version in the pristine-tar >> xdelta and one version in the packaging branch. Yes, in that case, you'd >> probably store it twice, since Git isn't going to be able to figure out >> what's going on in that xdelta. But that would require using pristine-tar >> with a branch that isn't an actual upstream branch in the git-buildpackage >> sense, which pretty much requires not using git-buildpackage (or at least >> using a very strange set of options). While certainly nothing requires >> one to use git-buildpackage with a Git-based workflow, I suspect it's the >> most common approach. > > So my own experience is that almost none of the Debian packages maintained > in git that I try to touch appear to use git-buildpackage in anything > resembling a sensible manner. The XSF packages aren't set up for > git-buildpackage (which is reasonable since their git usage predates git-bp > and it's a comparatively large team with established practices), and random > other packages I've looked at have also shunned git-bp conventions. > Compared to the simple consistency of Ubuntu UDD branches, I find this > maddening. > > On Fri, Oct 19, 2012 at 01:02:59PM +0800, Chow Loong Jin wrote: >> Actually most users of pristine-tar in git don't have the *first* of these >> branches. They usually have an upstream branch which is synthesized >> solely from importing tarballs using git import-orig. In other words, the >> typical practice is to avoid sharing git history with the upstream VCS, >> which in turn works out very well for git-dch, because you don't get >> unnecessary upstream changes documented in debian/changelog. > > This seems utterly broken to me and optimized for the wrong priority. I > cannot imagine why anyone would endure git's user interface and then not > even use the DVCS functionality for collaboration with upstream. I'd rather you didn't use the word endure. I find git's user interface perfectly acceptable, and even preferable compared to other VCSes. At the very least, I don't have to keep throwing away my history due to repository pack format mismatches. But let's leave it at that and not escalate this into an unproductive VCS war here. On the other hand, I don't see why this is optimized for the wrong priority. Debian package releases have always been tarball-oriented, and patches are kept in debian/patches using quilt, especially with debsrc3.0. Keeping the packaging repository completely separate from the upstream repository allows the history to be kept much cleaner and simpler than it would be otherwise, while following the same tarball-oriented approach we've been using all the while. As far as collaboration with upstream goes, you can still clone the upstream repository separately or otherwise just add it as another remote to your local repository. -- Kind regards, Loong Jin
Attachment:
signature.asc
Description: OpenPGP digital signature