[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switch to git after all?

On Sun, Apr 06, 2014 at 01:13:16PM -0400, Joey Hess wrote:
> I advise against using git in some nonstandard way, such as only checking
> debian/ into the debian git repositories. There is a very wide range of
> tools for managing packages with git, and making this choice will close
> off using many of those tools, or require using them in nonstandard ways,
> and so eliminate many of the possible positive effects of switching to git
> in the first place.

I agree with this.  Non-full-source packages are getting increasingly
strange, from my point of view: it's a hassle to have to deal with
assembling the pieces, requiring specialised tools for that means that
e.g. I can't quickly refer to a gitweb or similar from my phone, and not
having everything in revision control means that I have to mess around a
lot in order to use "git blame" to help track down problems.  I know I'm
only a fairly minor contributor to the Haskell team but debian/-only
would certainly not be my preference.  I agree with Joey's position
expressed on his blog a while back that there's basically no convincing
reason not to use the upstream git repository, where it exists, as the
basis for the one used for packaging.

For what it's worth, I've had excellent experiences in a few months of
using git-dpm, after making a mental note to look into it when I spotted
it on the talk schedule at DebConf.  There are trade-offs to consider
for packages with lots of patches - you can end up with a fairly noisy
"git log" - but I don't think any of the Haskell packages fall into that
category.  Upgrading to new upstream versions and pulling in their git
history is actually a joy - a single command can commit any tarball
differences on top of a nominated upstream commit, stick the tarball in
pristine-tar, and drop me into a "git rebase" of my patch stack, which
ultimately ends up as a single publishable fast-forwarding branch.  If
upstream isn't in git then it still all works basically the same way
except of course without fine-grained history between upstream releases.
And I'm not hugely sad not to be trying to rebase patch stacks in quilt
any more.

In fact, git-dpm was what finally sold me on converting all my packages
to git.  For me, it's streets ahead of previous methods of managing
Debian patches in revision control in the same way that 3.0 (quilt) was
streets ahead of the various older build-time patch systems.

Colin Watson                                       [cjwatson@debian.org]

Reply to: