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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Jonathan Nieder <jrnieder@gmail.com> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Feb 7, 2010 at 12:18 AM, Henrique de Moraes Holschuh
<hmh@debian.org> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

OoO En ce début d'après-midi ensoleillé du samedi 06 février 2010, vers
15:15, Goswin von Brederlow <goswin-v-b@web.de> 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)

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henrique de Moraes Holschuh <hmh@debian.org> 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).

<URL: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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney <ben+debian@benfinney.id.au> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, 07 Feb 2010, David Bremner wrote:
> On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney <ben+debian@benfinney.id.au> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org