[ANNOUNCE] TopGit - A different patch queue manager

  Hi,

  I'd like to announce TopGit v0.1, the first (while also the youngest)
project from my Rhine pipeline (sitting at the river shore, hacking
free of all online distractions; the only catch is that the offline
distractions can be plentiful as well - too many pretty girls tend
to cluster around the water in the hot summer days for some strange
reason.)

  TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
and others, of course in an attempt to Get It Right this time around.
TopGit is absolutely minimal porcelain layer that will manage your
patch queue for you using topic branches, one patch per branch.
And do _ONLY_ that. Unlike with StGIT, you can actually use the index.

  TopGit aims to scratch three of my long-term patch management itches:

	(i) Let you freely specify patch dependencies, instead of
	forcing you to linearize your patches into a series

	(ii) Keep your development history rigorously - it is to be
	cleaned up only once, and that is when submitted upstream

	(iii) Actually _WORK_ in the distributed environment;
	you can have several repositories and develop your patches
	in all of them

  You can get TopGit at

	http://repo.or.cz/w/topgit.git

and read up on its design, usage and implementation at:

	http://repo.or.cz/w/topgit.git?a=blob;f=README

  This is v0.1. I started working on it last evening (by spending over
two hours writing the README from scratch up to pretty much its current
state), got it feature complete few hours ago and testing it out the
rest of the evening. So yes, it probably still has some bugs, but it
should be ready for general practical usage, so please give it a try.
I just recreated

	http://repo.or.cz/w/git/gitweb.git

with it and plan to use it pretty much exclusively for all my Git patches from now on (and it turns out there is quite a few, I just had no good way to organize and submit them so far).

  Besides that, some utility commands are still missing, some of them
are TODO'd in the README. Most notably, the distributed workflow still
has no explicit support within TopGit which makes it a little awkward,
and there is actually no way to mail your patches yet ;-) - tg patch
will only dump a single one on stdout and you need to do the rest.

  TopGit is not very well optimized so far; I made little to no
benchmarks and I'm focused on getting things work right first. Still,
I believe that most operations should not take noticeably long until
you get into many tens of densely dependent patches. One exception
is 'tg summary', which is unfortunately dog-slow and I couldn't
figure out how to speed it up further so far.

  P.S.: git/gitweb.git is mentioned here just as an example of
real-world TopGit usage; ignore the contents. I actually do intend
to revive this repository, but there's still a lot of work to do.

  P.P.S.: Can I get trademark on the (ironically) /[^p]g/ porcelains
now? ;-)

  Have fun,

On Sun, Aug 03, 2008 at 05:14:24AM +0200, Petr Baudis <pasky@suse.cz> wrote:

As we discussed on IRC, this means that unlike git rebase -i and others, the history of such rebases is not stored in reflogs (which are not transfered) but stored with this "one branch, one patch" logic.

Heh, no please. I have a porcelain called 'dg'[0] after 'darcs-git', which imitates some of the darcs UI, but operating on a git repo. ;-)

[0] http://tinyurl.com/5lfs5g, http://tinyurl.com/6pb772

On Sun, Aug 03, 2008 at 09:27:26AM +0200, Miklos Vajna wrote:

Oh, good to know. I was considering naming this 'dg' as a pun on 'cg' (though only half-seriously ;).

				Petr "Pasky" Baudis

Running tg in a repo without an active pre-commit hook fails saying

  grep: .git/hooks/pre-commit: No such file or directory
  cat: .git/hooks/pre-commit: No such file or directory

Even "tg help" does this! So add extra checks for existence of the pre-commit hook.

---
 tg.sh |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

On Sun, Aug 03, 2008 at 10:14:01PM +0800, Russell Steicke wrote:

Thanks, applied.

				Petr "Pasky" Baudis

On 8/2/08, Petr Baudis <pasky@suse.cz> wrote:

It is very helpful to block git commands that will mess up the state of topgit. For example 'git rebase' is a good way to mess up stgit. Instead you need to do 'stg rebase'. It is quite easy to type the wrong command when switching between trees and some are under stgit and others aren't.

I believe there is a stgit rewrite due any day now that completely changes how it deals with the index.

On 2008-08-03 10:45:06 -0400, Jon Smirl wrote:

Indeed. This is mitigated somewhat by the new "stg undo" command, but it's still perhaps StGit's largest UI wart.

The master branch contains an infrastructure rewrite that makes it easy to make the various commands handle the index nicely. A lot of commands have been fixed to take advantage of it, but a bunch still remain.

Hi Petr and everyone else,

as some of you may know, I am working on http://vcs-pkg.org, and Pierre kindly alerted me to your announcement, which looks very interesting for what we are trying to do.

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 fashion, so that I could turn any TopGit repository into a quilt series? I am only interested in a one-way conversion from TopGit to quilt for now.

The reason for this is quite simply that while it's fabulous to use e.g. Git for managing the source repository from which to build distro packages, the resulting packages will have all distro-specific changes applied or collated into a single diff. This makes it hard for other distributions to grab patches, for upstream to keep on top of what is being distributed, and for bug fixers to separate patches and test only specific ones.

If we could turn a TopGit-managed forest into a quilt series, we could distribute the series with the package and allow those who inspect the source package to use quilt to navigate the patches.

If anyone has any input on the matter, I'd love to hear it.

Thank you,

Hi,

On Thu, Aug 7, 2008 at 19:56, martin f krafft <madduck@debian.org> wrote:

Should be doable, I think. At least you can get a topological sorted list of the TopGit branches (with git show-branch --topo-order <list of TopGit-branches>). But than it get complicated, because you don't need the diff from branch-base to branch-head, this would only work for a single dependent list of topic branches.

At least this is my current point of thinking for this problem.

Regards Bert

also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.08.07.1658 -0300]:

Hm, I am not entirely following. I understand that I can get a topological list of branches, but why don't I need the diff from branch-base to branch-head?

Also, what happens if branches cross-merge?

On Fri, Aug 8, 2008 at 19:06, martin f krafft <madduck@debian.org> wrote:

branch-base is a merge of all dependent branches, and if there are more than one you need probably other diffs to get to this merged branch, than the simple base..head of these branches.

Hi!

On Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote:

Not _yet_. But it very well could, and it should be really simple.

There are two parts:

(i) First, getting a "tidied up" commit structure from TopGit, having one commit per patch (branch). This is something covered currently in the README by:

	TODO: tg collapse for creating a one-commit-per-patch tidied up
		history (for pulling by upstream)

So it's not implemented yet, but it should be *very* easy to do.

(ii) Second, linearizing this commit structures to a series. This should be as simple as running

	git log --pretty=email -p --topo-order

on the collapsed history.

This is exactly what TopGit seeks to alleviate.

On Fri, Aug 08, 2008 at 02:06:58PM -0300, martin f krafft wrote:

This would mean there is circular dependence between the branches, which is invalid setup for TopGit - you could not get a linear ordering out of the branches anyway; in result, each branch has to turn out to a single final Git commit - with circular dependencies, you cannot do that.

  Hi,

On Sat, Aug 09, 2008 at 03:08:21AM +0200, Petr Baudis wrote:

  to prove the point, I just pushed out tg-export implementation (seems
like better name than collapse, for various reasons). It ended up not to
be as trivial as I thought, but still no more than a two-hour job. ;-)

On Fri, 2008-08-08 at 14:06 -0300, martin f krafft wrote:

Well, if the patches can be assembled into it, why would you?

Not really a problem, just need to provide a diff against one (or even both) of the merge bases to the merge commit, and have it labeled as being a relatively disinteresting patch that merges X with Y.

Sam.