also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.11.30.1832 +]:
> Now, assuming there is a sane way of storing the information
> needed to address both targets, what about providing patches for
> both targets?
The only sane way I see is by dumping the DAG itself in a way that
would all
On Sun, Nov 23, 2008 at 02:25:14PM +0100, martin f krafft wrote:
> (b) I provide the pristine source and a quilt series in
> debian/patches, which applies, and thus gives very specific
> information about how the upstream source gets altered before
> building the Debian package.
also sprach Sam Vilain <[EMAIL PROTECTED]> [2008.11.20.2221 +0100]:
> potentially do this; I don't know that there is a normal UI way of doing
> it[1]; it's the sort of thing I normally do using my 'git-amend' script
> (http://utsl.gen.nz/git/git-amend ) which just pops open HEAD in an
> editor and
also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.22.1953 +0100]:
> It's also not an issue if you resolve conflicts between branches
> by making one branch depend on another, which in reading between
> the lines I think is the approach you're taking (although I could
> be wrong).
You got it, t
Manoj Srivastava wrote:
>> This is all very interesting; I don't think anyone should doubt that
>> conflicts arise. I think this sub-thread started with the desire to
>> have a moving merge commit that got re-written. With git you could
>>
> I have no idea what you just said; so I co
On Thu, Nov 20 2008, Sam Vilain wrote:
> On Thu, 2008-11-20 at 12:56 -0600, Manoj Srivastava wrote:
>> > Manoj, could you detail a particular scenario where you had conflicts
>> > between the topic branches ?
>> Sure. Back when I was still the sole maintainer of refpolicy, I
>> had a br
On Thu, 2008-11-20 at 12:56 -0600, Manoj Srivastava wrote:
> > Manoj, could you detail a particular scenario where you had conflicts
> > between the topic branches ?
> Sure. Back when I was still the sole maintainer of refpolicy, I
> had a branch where we had a Debian specific user role
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.19.0122 +0100]:
>> You load the new upstream into the upstream branch. Now, you merge the
>> new upstream into the A, B, and C topic branches. In each case,
>> upstream used a slightly different b
also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.19.0122 +0100]:
> You load the new upstream into the upstream branch. Now, you merge the
> new upstream into the A, B, and C topic branches. In each case, upstream
> used a slightly different bug fix than you had in their new release
> (differ
On Wed, Nov 19 2008, Nicolas Duboc wrote:
> Manoj, could you detail a particular scenario where you had conflicts
> between the topic branches ?
Sure. Back when I was still the sole maintainer of refpolicy, I
had a branch where we had a Debian specific user role called netuser --
thi
On Tue, Nov 18, 2008 at 04:22:08PM -0800, Russ Allbery wrote:
> The tmp-merge branch doesn't have this problem
> since it's branched off upstream and doesn't have your old B and C
> branches merged, and by the time you merge tmp-merge into master, you have
> all of your conflicts resolved already a
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.18.0056 +0100]:
>> Rather than using rerere, I create a temporary merge branch based off
>> upstream and merge each topic branch into it in sequence, and then
>> merge the temporary merge branch int
also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.18.0056 +0100]:
> Rather than using rerere, I create a temporary merge branch based off
> upstream and merge each topic branch into it in sequence, and then merge
> the temporary merge branch into the integration branch, which seems to
> accompl
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Tue, Nov 18 2008, Nicolas Duboc wrote:
>>> Rather than using rerere, I create a temporary merge branch based off
>>> upstream and merge each topic branch into it in sequence, and then
>>> merge the temporary merge branch into the integration branch
On Tue, Nov 18 2008, Nicolas Duboc wrote:
>> On Mon, Nov 17, 2008 at 03:56:06PM -0800, Russ Allbery wrote:
>>> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> > Well, I have seen this happen.
>> > a) update the upstream branch (merge from remote/upstream, or
>> > git_load_dirs).
>> >
On Mon, Nov 17, 2008 at 03:56:06PM -0800, Russ Allbery wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>
> > Well, I have seen this happen.
> > a) update the upstream branch (merge from remote/upstream, or
> > git_load_dirs).
> > b) Merge upstream branch into topic branches; re
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Well, I have seen this happen.
> a) update the upstream branch (merge from remote/upstream, or
> git_load_dirs).
> b) Merge upstream branch into topic branches; resolve conflicts.
> c) Merge topic branches into the integration branch (m
On Sun, Nov 16 2008, martin f krafft wrote:
>> But this script will checkout the build branch and try to merge
>> the upstream branch in. That should fail due to the same conflicts
>> which were resolved in the deb/conffile-location branch. That's
>> actually what I experience with my tests.
also sprach Nicolas Duboc <[EMAIL PROTECTED]> [2008.11.16.1700 +0100]:
> There's one point I didn't really understand and with which I have a
> problem when I tried to switch my jython package to git.
Hm, I really ought to update the article and state that it is aged.
The concepts still hold, but
Hi all,
I have read with interest Madduck's "Packaging with git" article [1].
There's one point I didn't really understand and with which I have a
problem when I tried to switch my jython package to git.
At the end of the section about new upstream releases, the article
describes the case
20 matches
Mail list logo
