Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)

2008-08-10 Thread Petr Baudis
Hi, On Sat, Aug 09, 2008 at 03:08:21AM +0200, Petr Baudis wrote: On Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote: Assuming a number of interdependent topic branches, does TopGit provide a way for me to linearise/flatten/serialise these branches in a one-patch-per-branch

Re: instances of cooperation between distros

2008-12-18 Thread Petr Baudis
Hi, On Thu, Dec 18, 2008 at 09:26:17PM +0100, martin f krafft wrote: Do you know of any instances of cross-distro collaboration where the VCS is shared between packagers? Have any of you reached out to other distros' packagers? Would you share your experiences? you might want to stop

Re: rethinking patch management with GIT / topgit

2010-03-21 Thread Petr Baudis
On Sat, Mar 20, 2010 at 07:53:34PM +0100, Thomas Koch wrote: Petr Baudis: - tg recreate patchset newbase new patchset name Creates a new patchset with root newbase by creating new patch branches for each patch branch in patchset This command is useful if you need to keep the old

Re: rethinking patch management with GIT / topgit

2010-03-22 Thread Petr Baudis
Hi! On Sun, Mar 21, 2010 at 10:18:14PM +0100, Enrico Weigelt wrote: Although the above is quite a harsh judgement, I'd like to note, that tg has had its merrit to promote one right idea: Patches should be managed in the form of branches by the means of the underlying VCS and not as

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

Re: rethinking patch management with GIT / topgit

2010-03-24 Thread Petr Baudis
On Wed, Mar 24, 2010 at 01:42:18AM +0100, Enrico Weigelt wrote: Once a new upstream is out, somebody simply forks a new branch from the last one, rebases it to the new upstream and publishes it when done. We actually dont rebase _existing_ (already published) branches, but add new ones which

Re: rethinking patch management with GIT / topgit

2010-03-24 Thread Petr Baudis
On Wed, Mar 24, 2010 at 04:36:14PM +0100, Enrico Weigelt wrote: Petr Baudis wrote: But what if you need to change one of the already committed patches? Simply add a new commit ? Remember: we're not thinking in patches here (forget that term at all ! ;-), but in (distro-specific

Re: rethinking patch management with GIT / topgit

2010-03-28 Thread Petr Baudis
On Sun, Mar 28, 2010 at 08:21:48AM +0200, Enrico Weigelt wrote: You would want to still use something like the topgit model in your forked upstream, since again, you will probably want to have the two desirable properties we seek to preserve - to reiterate them, Actually, I dont want to