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

Re: Switch to git after all?

Joachim Breitner wrote:
> I’d like to explain with a bit more detail why I prefer debian/-only
> packaging. If you have read such arguing before, feel free to skip that
> part (→ End of arguing).

An interesting point of view, well elucidated.

It may somewhat fall apart when you consider what is the source of
individual lines of debian/patches. However, I don't really want to
quibble about the definition of "source".

I prefer to just think about the set of workflows that a given use
of a vcs makes easy, and those it makes hard, and prefer the larger and
more useful set of workflows.

Keeping upstream source in the debian git repository allows me to use
these workflows:

* git commit -m 'support new ghc"; git send-email HEAD^ --to $author; release [1]

  The most basic git workflow there is. With many variants involving
  eg github pull requests and BTSs of course.

* git fetch upstream; git cherry-pick $upstream_bugfix_commit; release [1]

  The other most basic git workflow for distribution packagers.

* git import-orig orig.tar.gz; release

  Where "import-orig" can be any of several debian-specific programs
  that deal with the "combine this git repo with this new upstream tarball"
  problem in different ways.

* dgit pull; dch "acking NMU"; release

  If unfamiliar with dgit, this allows pulling a NMU's changes into your 
  package's git repository. The NMUer did not need to make any git
  commits; this sythesises a git commit from the changes
  uploaded in the NMU and its changelog.

Those are most of the ones I care about (except for the all-packages
planning workflow that I clearly need to integrate into my own).

But I don't care only about my workflows, I care about maximising the
chance that others can use their own preferred workflows, while using a
VCS for collaboration. All the evidence I've seen suggests that the
best way to do that is to use git[2] and include the upstream source.

see shy jo

[1] Assume that "release" does whatever is necessary to make a
    releasable debian package, including modifications to cruft in debian/
[2] Or more accurately, the same VCS that upstream uses.
    But it's probably git.

Attachment: signature.asc
Description: Digital signature

Reply to: