Re: git and quilt

[Goswin von Brederlow]

Vincent Bernat  writes:

> OoO En ce début d'après-midi  ensoleillé du samedi 06 février 2010, vers
> 15:15, Goswin von Brederlow  disait :
>
>> He wants to KISS. So lets make it even simpler.
>
>> - master:   patched source
>> - upstream: upstream source
>
> Suppose the following workflow:
>  - upstream version X.Y
>  - master branch based on X.Y
>  - patch Z applied on master branch
>  - upstream branch is updated to (X+1).0
>  - upstream  is merged  into master  branch and  manual  intervention is
>needed because  there are conflicts between changes  on upstream side
>and patch Z
>
> Now, if upstream want to get patch Z, he can :
>  - get patch Z for version X.Y
>  - get  patch between  upstream  (X+1).0 and  master (X+1).0  containing
>patch Z and other stuff

No, he only has the options of:

1) get debian/patches/debian-changes from version X.Y (patch Z)
2) get debian/patches/debian-changes from version (X+1).0 (updated patch Z)

At least from the debian source package. What the maintainer can get
from the git directly depends how you organize your git and is irelevant
to the discussion of the debian source package.

> While git  allows to  keep track of  modifications, it is  difficult for
> upstream (or some other people) to review a precise patch.  Or maybe you
> rebase master  branch on the upstream  one (which would be  great to see
> watch patches  are applying  to upstream but  will lead  to difficulties
> when tracking master branch)?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Henrique de Moraes Holschuh]

On Sun, 07 Feb 2010, David Bremner wrote:
> On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney  
> wrote:
> > With Bazaar, one doesn't need to rebase to achieve this. The ???loom???
> > plugin allows for tracking changes against upstream revisions, while
> > *preserving* the history of changes, and generating tidy change sets to
> > feed back upstream (or, in our use case of interest, to use as Quilt
> > patches).
> 
> As was already mentioned, topgit is not perfect (it basically needs a
> little polishing, and the history of patch branches gets messy from many
> merges), but for people who don't want to switch to bzr, it provides
> essentially the same functionality as bzr loom or (AIUI) hg patch
> queues.

And stgit (git) patch-queue branches, for that matter.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[David Bremner]

On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney  
wrote:

> With Bazaar, one doesn't need to rebase to achieve this. The ‘loom’
> plugin allows for tracking changes against upstream revisions, while
> *preserving* the history of changes, and generating tidy change sets to
> feed back upstream (or, in our use case of interest, to use as Quilt
> patches).

As was already mentioned, topgit is not perfect (it basically needs a
little polishing, and the history of patch branches gets messy from many
merges), but for people who don't want to switch to bzr, it provides
essentially the same functionality as bzr loom or (AIUI) hg patch
queues.

d


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Ben Finney]

Henrique de Moraes Holschuh  writes:

> Downstream, you "fork" from upstream each release, either by merging
> topic branches (_rebasing_ them if any sort of conflict happens, all
> merge commits must be perfectly clean ones), or rebasing the debian
> changes on top of the new upstream and calling that the new 'master'
> branch.

With Bazaar, one doesn't need to rebase to achieve this. The ‘loom’
plugin allows for tracking changes against upstream revisions, while
*preserving* the history of changes, and generating tidy change sets to
feed back upstream (or, in our use case of interest, to use as Quilt
patches).

http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar>

-- 
 \“The restriction of knowledge to an elite group destroys the |
  `\   spirit of society and leads to its intellectual |
_o__)impoverishment.” —Albert Einstein |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Henrique de Moraes Holschuh]

On Sun, 07 Feb 2010, Vincent Bernat wrote:
> While git  allows to  keep track of  modifications, it is  difficult for
> upstream (or some other people) to review a precise patch.  Or maybe you
> rebase master  branch on the upstream  one (which would be  great to see
> watch patches  are applying  to upstream but  will lead  to difficulties
> when tracking master branch)?

Well, a non-native Debian package would need to use a git workflow that is
optimized for downstream maintenance.  And that does mean rebases.  One
should never confuse the optimal *upstream* git workflow, with downstream
workflows.  Anything that goes "never rebase" is solely for pure upstream
use.

Downstream, you "fork" from upstream each release, either by merging topic
branches (_rebasing_ them if any sort of conflict happens, all merge commits
must be perfectly clean ones), or rebasing the debian changes on top of the
new upstream and calling that the new 'master' branch.

This doesn't mean a lot of branches.  You just need "master", and to tag
every release so that you can get it back (and even make it a permanent or
temporary branch) at any time.

And you shouldn't have a mess of a history, either.  All patches cleaned up.
If this doesn't suit your style of developent, you should have a work repo
somewhere, and keep the package repo separate and clean.

There are different ways of doing the above, of course.  The important
details are exactly what you pointed at: it needs to result in clean commits
that are easy to locate, and that apply cleanly to the upstream version
matching the package's (and not to some past upstream version).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[David Claughton]

Hi Vincent,

Vincent Bernat wrote:
> Now, if upstream want to get patch Z, he can :
>  - get patch Z for version X.Y
>  - get  patch between  upstream  (X+1).0 and  master (X+1).0  containing
>patch Z and other stuff
> 

Well, in this example there wouldn't be any "other stuff" - you would do
the conflict resolution and end up with modified patch Z' which can be
extracted easily.

> While git  allows to  keep track of  modifications, it is  difficult for
> upstream (or some other people) to review a precise patch.  

In the more general sense however, I agree - you could have committed 20
revisions to the master branch while fixing 3 bugs and intermittently
working on one experimental feature which isn't finished yet.  There is
no simple way of separating these looking at the master branch alone.

IMHO you still need to have someway to separate the commits into patches
or something equivalent.  You could use topic branches.  You could
cherry pick commits from master and combine them into
one-commit-per-bugfix onto a different branch.  Or, of course, you could
cherry pick commits and combine them into quilt patches ;-)

Cheers,

David.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Vincent Bernat]

OoO En ce début d'après-midi  ensoleillé du samedi 06 février 2010, vers
15:15, Goswin von Brederlow  disait :

> He wants to KISS. So lets make it even simpler.

> - master:   patched source
> - upstream: upstream source

Suppose the following workflow:
 - upstream version X.Y
 - master branch based on X.Y
 - patch Z applied on master branch
 - upstream branch is updated to (X+1).0
 - upstream  is merged  into master  branch and  manual  intervention is
   needed because  there are conflicts between changes  on upstream side
   and patch Z

Now, if upstream want to get patch Z, he can :
 - get patch Z for version X.Y
 - get  patch between  upstream  (X+1).0 and  master (X+1).0  containing
   patch Z and other stuff

While git  allows to  keep track of  modifications, it is  difficult for
upstream (or some other people) to review a precise patch.  Or maybe you
rebase master  branch on the upstream  one (which would be  great to see
watch patches  are applying  to upstream but  will lead  to difficulties
when tracking master branch)?
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


pgpk4diN0Vp0H.pgp
Description: PGP signature

Re: git and quilt

[Paul Wise]

On Sun, Feb 7, 2010 at 12:18 AM, Henrique de Moraes Holschuh
 wrote:


> Given the size of the .git dir when you're not using something like stgit
> and have all objects properly packed, one could even consider shipping .git
> inside the package if it is small enough.
>
> Is that a proper way to do this?  Or would we need a new 3.0 format variant
> to do it right (assuming we want to do that) ?

There are already 3.0 (git) and 3.0 (bzr) formats according to
dpkg-source(1), but the archive does not accept them.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Henrique de Moraes Holschuh]

On Sat, 06 Feb 2010, Goswin von Brederlow wrote:
> Convert to 3.0 (quilt) format and keep it out of git:
> 
> echo "3.0 (quilt)" >debian/source/format
> echo "debian/patches" >>.gitignore
> echo ".pc" >>.gitignore
> 
> And then to build you use (or pass it to git-buildpackage):
> 
> debuild --single-debian-patch
> 
> There is no need to manually create any patch with git format-patch.
> dpkg-source will create a fresh debian/patches/debian-changes on every
> build containing all your differences between upstream (well, the
> orig.tar.ext) and master outside the debian dir.
> 
> The advantage of this over the 1.0 format is that it supports
> orig.tar.bz2, has the debian dir as tar (so it can contain binary data
> too) and changes to upstream in debian/patches/debian-changes that can
> easily be extracted by upstream or for a patch tracker without having to
> know your git.

Given the size of the .git dir when you're not using something like stgit
and have all objects properly packed, one could even consider shipping .git
inside the package if it is small enough.

Is that a proper way to do this?  Or would we need a new 3.0 format variant
to do it right (assuming we want to do that) ?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Goswin von Brederlow]

Jonathan Nieder  writes:

> John Goerzen wrote:
>> On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
>>> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
>>> package.
>>
>> I am doing the same, for the very simple reason that every other
>> approach I've seen violates the KISS (Keep It Simple, Stupid)
>> principle.
>
>> I am not a fan of git-rebase due in part to the difficulty of working
>> with others, but also in part due to the difficulty of tracking how
>> your differences from upstream change over time.  All the
>> debian/patches systems I have seen suffer from both of these flaws.
>
> I don’t strongly disagree, but consider for a moment a method that
> tries to work around these flaws.  It uses dpkg source format
> 3.0 (quilt).
>
> There are three branches: master, upstream, and upstream+patches.
>
>  - master:patched source (including debian/ dir)
>  - upstream:  upstream source
>  - upstream+patches:  patched source (w/o debian/ dir)
>
> upstream+patches is rebuilt for each new upstream version by
> cherry-picking the relevant commits.  I haven’t scripted this, but
> it would not be hard to.
>
> This method has a few advantages:
>
>  - upstream can pull directly from you if they like all your patches
>  - you can work on and test the patched source by building off of the
>upstream+patches branch
>  - it is easy for others to find your patches, in a form that does not
>require any forward porting.
>  - if you generate your debian/patches directory with git format-patch,
>dpkg will check that master and upstream+patches tell the same story.
>
> If you don’t mind the occasional duplicate commit, for new fixes you
> can work against upstream+patches and then merge it into master, though
> I don’t do this.
>
> FWIW I have been using this method and it’s not so bad.
>
> Regards,
> Jonathan

He wants to KISS. So lets make it even simpler.

- master:   patched source
- upstream: upstream source

Convert to 3.0 (quilt) format and keep it out of git:

echo "3.0 (quilt)" >debian/source/format
echo "debian/patches" >>.gitignore
echo ".pc" >>.gitignore

And then to build you use (or pass it to git-buildpackage):

debuild --single-debian-patch

There is no need to manually create any patch with git format-patch.
dpkg-source will create a fresh debian/patches/debian-changes on every
build containing all your differences between upstream (well, the
orig.tar.ext) and master outside the debian dir.

The advantage of this over the 1.0 format is that it supports
orig.tar.bz2, has the debian dir as tar (so it can contain binary data
too) and changes to upstream in debian/patches/debian-changes that can
easily be extracted by upstream or for a patch tracker without having to
know your git.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Jonathan Nieder]

John Goerzen wrote:
> On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
>> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
>> package.
>
> I am doing the same, for the very simple reason that every other
> approach I've seen violates the KISS (Keep It Simple, Stupid)
> principle.

> I am not a fan of git-rebase due in part to the difficulty of working
> with others, but also in part due to the difficulty of tracking how
> your differences from upstream change over time.  All the
> debian/patches systems I have seen suffer from both of these flaws.

I don’t strongly disagree, but consider for a moment a method that
tries to work around these flaws.  It uses dpkg source format
3.0 (quilt).

There are three branches: master, upstream, and upstream+patches.

 - master:  patched source (including debian/ dir)
 - upstream:upstream source
 - upstream+patches:patched source (w/o debian/ dir)

upstream+patches is rebuilt for each new upstream version by
cherry-picking the relevant commits.  I haven’t scripted this, but
it would not be hard to.

This method has a few advantages:

 - upstream can pull directly from you if they like all your patches
 - you can work on and test the patched source by building off of the
   upstream+patches branch
 - it is easy for others to find your patches, in a form that does not
   require any forward porting.
 - if you generate your debian/patches directory with git format-patch,
   dpkg will check that master and upstream+patches tell the same story.

If you don’t mind the occasional duplicate commit, for new fixes you
can work against upstream+patches and then merge it into master, though
I don’t do this.

FWIW I have been using this method and it’s not so bad.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[John Goerzen]

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.

I am doing the same, for the very simple reason that every other
approach I've seen violates the KISS (Keep It Simple, Stupid)
principle.

My Debian patches have two branches: master and upstream (some also
have a pristine-tar branch, but that is beside the point here.)  I use
git-import-orig to load upstream, git merge to merge it into master,
and git-buildpackage to build my .debs.

It is easy, it is clean, and it works well.  And it works like Git is
supposed to work.

I am not a fan of git-rebase due in part to the difficulty of working
with others, but also in part due to the difficulty of tracking how
your differences from upstream change over time.  All the
debian/patches systems I have seen suffer from both of these flaws.

Consider, for instance, a git system in which debian/patches/* is
committed into git.  OK, that's fine as it goes.  The history of how
you "fixed upstream's frob from going all fubar" is in Git.  But how
accessible is it?  git blame frob.c is useless now, as the diff to
frob.c isn't in git.  There is, in fact, no easy way to find out just
when a given change to frob.c was introduced or why (especially if
multiple debian/patches/* modified frob.c).

A git rebase workflow is slightly better on this, but only slightly.

For some non-Debian packages where I maintain a large number of diffs
against upstream, I use feature branches.  Each feature branch can run
git merge upstream, and then the master branch merges all the FBs in.
(A couple of shell scripts automate this easily.)

Frankly I do see the utility of debian/patches for people that don't
use a VCS.  But if your VCS already has very strong history analysis
features, which Git does, I see it as an unnecessary complication.

If someone reading this isn't familiar with Git's history features, I
would suggest you read manpages about:

git log --pickaxe or -S (details in gitdiffcore(7)

git blame (one of my very favorite git commands)

git diff -M -C --find-copies-harder
  (git can be very intelligent about detecting copies and renames,
  more than a debian/patch can reflect)
  (these options also work for many other commands)

It all comes down to this: if I avoid debian/patches in my Git
packages, I get:

 * A very simple and very fast workflow for routine maintenance

 * Powerful history searching for when I need it

 * An easily-accessible history of my changes to upstream, and
   how they relate to upstream's changes.  (How my diffs change over
   time)

Looking at a diff of a diff is never easy or powerful, in my
experience.  It is more of a bang your head on the keyboard sort of
experience.


-- John


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Bernhard R. Link]

* Matt Zagrabelny  [100203 23:26]:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.
>
> I receive the following error from lintian and am looking for some
> guidance/best practices.
>
> % lintian --pedantic cdpr_2.3-3.dsc
> P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
> 1 more
>
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.

You could try http://git-dpm.alioth.debian.org/.

There are no packages for this yet, but that's no big harm as it is
only a single shell script.

Hochachtungsvoll,
Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Joachim Breitner]

Hi,

Am Mittwoch, den 03.02.2010, 16:25 -0600 schrieb Matt Zagrabelny:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I found git-dpm  very nice.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: git and quilt

[sean finney]

hi!

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

i use git+gbp+quilt in a number of my packages.  i'm not convinced it's
necessarily the *best* system out there, but it keeps the overhead pretty
simple compared to using more complicated workflows à la topgit, while
still meeting my own requirements for per-release branches etc.

i've heard that gbp has recently introduced some new tools for working
with patch queues, but i haven't had the time to look much more into them.
in the meantime i'm dropping the patches into a quilt series.  backporting
upstream fixes is a bit nicer this way as well, as you can can do stuff
like "git show  | quilt import -P upstream_.patch -"[1]


sean

[1] if there are conflicts it's a bit trickier, then i usually resolve
the cherry-pick, commit it, do the above for the resolved commit, and
rebase the resolved commit from the history.


signature.asc
Description: Digital signature

Re: git and quilt

[Stefano Zacchiroli]

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I personally do (and we do the same thoroughly in a couple of teams I'm
involved with).

The idea is to keep the status stored in debian/patches/, fully
compatible with quilt and v3 source formats. Then, to manipulate patches
you create on the fly a "patch-queue" branch, where you have one commit
per patch. On that branch you do the changes you want (possibly
including rebases) and when you're done you "save" the branch in a new
series of patches to be stored in debian/patches/, throwing away the
"patch-queue" branch.

The tools I use the most to that hand are dom-apply-patches
(debian/patches/ -> patch-queue) and dom-save-patches (patch-queue ->
debian/patches/) from the dh-ocaml package which have been the initial
implementation of the work-flow. Nowadays however, the same idea has
been implemented and generalized in "gbp-pq", from git-buildpackage
itself. Unfortunately the doc is a bit scarce ATM and the manpage of
gbp-pq simply redirects to
https://honk.sigxcpu.org/piki/development/debian_packages_in_git/

If you like it, you can help out in improving the doc :-)

Hope this helps,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: git and quilt

[martin f krafft]

also sprach Russ Allbery  [2010.02.04.1208 +1300]:
> I generally do not.  Doing so with a tool like TopGit is a little awkward
> and requires more steps, and I don't see much utility in doing so.  I
> think it's easier to just manage Git branches.

All that TopGit really does is help you in merging depending
branches into dependent ones if the former have updated. You also
don't have to always update them, as TopGit works quite well even if
branches are out-of-date. tg-summary is still useful to keep an
overview.

But yes, there are still some open issues with TopGit that prevent
me from unconditionally adovating it.

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=topgit;exclude=tags:fixed;exclude=tags:fixed-upstream;exclude=tags:pending;exclude=tags:wontfix;exclude=pending:done;dist=unstable

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"sometimes the urge to do bad is nearly overpowering"
  -- ben horne


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: git and quilt

[James Vega]

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I receive the following error from lintian and am looking for some
> guidance/best practices.
> 
> % lintian --pedantic cdpr_2.3-3.dsc
> P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
> 1 more

This isn't an error.  It's an informational message only shown in
pedantic mode.  From lintian(1):

“Pedantic tags are Lintian at its most pickiest and include checks for
particular Debian packaging styles and checks that many people disagree
with.  Expect false positives and Lintian tags that you don't consider
useful if you use this option.”

In other words, if you think the tag is useful then fix it, otherwise
ignore it.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: git and quilt

[Russ Allbery]

Matt Zagrabelny  writes:

> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I generally do not.  Doing so with a tool like TopGit is a little awkward
and requires more steps, and I don't see much utility in doing so.  I
think it's easier to just manage Git branches.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[Josselin Mouette]

Le mercredi 03 février 2010 à 16:25 -0600, Matt Zagrabelny a écrit : 
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

http://packages.debian.org/sid/topgit

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

git and quilt

[Matt Zagrabelny]

Greetings,

I read through the git-buildpackage docs and also a HOWTO by Russ
Allbery [1] regarding git and Debian packaging. I am wondering if those
who use git to manage their source package development are also using
the debian/patches mechanism for modifying the upstream tarball.

I receive the following error from lintian and am looking for some
guidance/best practices.

% lintian --pedantic cdpr_2.3-3.dsc
P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
1 more

I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
package.

Thanks for the tips,

[1] http://www.eyrie.org/~eagle/notes/debian/git.html

-- 
Matt Zagrabelny - mzagr...@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF  C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part