Re: rethinking patch management with GIT / topgit

2010-03-28 Thread martin f krafft
also sprach Thomas Koch tho...@koch.ro [2010.03.24.0821 +0100]:
 While I don't agree with your prefered workflow, I think it's
 a very nice attribute of my proposal, that both workflows could be
 implemented with it. We could use the same tool and still have
 different workflows.

I would love to hear more about what you propose. Have you
considered writing this up as a paper or website with graphs to help
us get a better idea of who you'd implement this, and how users are
supposed to use this solution?

-- 
 .''`.   martin f. krafft madd...@d.o  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
 
there are more things in heaven and earth, horatio,
 than are dreamt of in your philosophy.
 -- hamlet

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: rethinking patch management with GIT / topgit

2010-03-23 Thread Thomas Koch
Petr Baudis:
 On Mon, Mar 22, 2010 at 08:59:40AM +0100, Thomas Koch wrote:
  In all three cases you're free to either keep or throw away the old
  patchset.
 
 Yes, but to the same degree e.g. with StGIT I'm free to keep the head of
 the old patch series. That does not mean the operation *preserves* the
 history, only that the history is still around somewhere in the
 repository, however it won't be around in other incarnations of the
 repository and it will not be connected in any way to the current
 version of the patchset.
 
 Yes, if you are lucky you can figure out the name of the previous
 version, but it's like starting development of each new kernel version
 by a clean import of the sources.

Hi Petr,

let me copy the list of methods from my last mail:

1) checkout new patch branches from the top of the old patch branches and 
merge upstream into each of them

2) recreate (like rebase) the full history of the patch branches on top of the 
new upstream

3) collapse the branch history and create one commit per patch branch on top 
of the new upstream

From these methods, 3) loses all history, 2) loses some history but preserves 
the individual history of one patch branch on a new base and 1) preserves all 
history. Let me give an example for method 1). 
You've got a patchset identified by the prefix debian/. Now you want to 
package a new upstream but need to retain the old patchset in case of security 
updates in Debian stable. Debian stable has version 0.1, new upstream is 0.2.
So you
- rename the old patchset from debian/ to debian-0.1/
- clone/copy/recreate (pick a name) a new patchset debian/ on top of 
upstream/0.2. This is done by merging upstream/0.2 into each debian/* branch.
- Once you don't maintain version 0.1 anymore, you can delete the debian-0.1/* 
branches

After these steps, the debian/ branch still contains pointers to all commits 
from the debian-0.1/* branches.
It's an additional question, how to deal with commits that are done in 
debian-0.1/* after the new upstream merge.

Best regards,

Thomas Koch, http://www.koch.ro

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss


Re: rethinking patch management with GIT / topgit

2010-03-22 Thread Petr Baudis
On Mon, Mar 22, 2010 at 08:59:40AM +0100, Thomas Koch wrote:
 In all three cases you're free to either keep or throw away the old patchset.

Yes, but to the same degree e.g. with StGIT I'm free to keep the head of
the old patch series. That does not mean the operation *preserves* the
history, only that the history is still around somewhere in the
repository, however it won't be around in other incarnations of the
repository and it will not be connected in any way to the current
version of the patchset.

Yes, if you are lucky you can figure out the name of the previous
version, but it's like starting development of each new kernel version
by a clean import of the sources.

-- 
Petr Pasky Baudis
http://pasky.or.cz/ | Ars longa, vita brevis. -- Hippocrates

___
vcs-pkg-discuss mailing list
vcs-pkg-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss