Vincent Bernat ber...@debian.org writes:
OoO En ce début d'après-midi ensoleillé du samedi 06 février 2010, vers
15:15, Goswin von Brederlow goswin-...@web.de disait :
He wants to KISS. So lets make it even simpler.
- master: patched source
- upstream: upstream source
Suppose the
On Sun, 07 Feb 2010, David Bremner wrote:
On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney ben+deb...@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
OoO En ce début d'après-midi ensoleillé du samedi 06 février 2010, vers
15:15, Goswin von Brederlow goswin-...@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
-
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
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
Henrique de Moraes Holschuh h...@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
On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney ben+deb...@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
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
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
On Sun, Feb 7, 2010 at 12:18 AM, Henrique de Moraes Holschuh
h...@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
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
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 commit | quilt import -P
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
* Matt Zagrabelny mzagr...@d.umn.edu [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
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
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)
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
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
Matt Zagrabelny mzagr...@d.umn.edu 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
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
also sprach Russ Allbery r...@debian.org [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
21 matches
Mail list logo
