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
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
On Sat, Mar 20, 2010 at 07:53:34PM +0100, Thomas Koch wrote:
- 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
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
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
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
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
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
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