[ANNOUNCE] TopGit - A different patch queue manager

[ANNOUNCE] TopGit - A different patch queue manager

[Petr Baudis]

  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,

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

Re: [ANNOUNCE] TopGit - A different patch queue manager

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Sun, Aug 03, 2008 at 05:14:24AM +0200, Petr Baudis <pasky@suse.cz> wrote:
> 	(iii) Actually _WORK_ in the distributed environment;
> 	you can have several repositories and develop your patches
> 	in all of them

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.

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] TopGit - A different patch queue manager

[Petr Baudis]

On Sun, Aug 03, 2008 at 09:27:26AM +0200, Miklos Vajna wrote:
> 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

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

				Petr "Pasky" Baudis

[PATCH] [TopGit] Check for pre-commit hook existence.

[Russell Steicke]

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(-)

diff --git a/tg.sh b/tg.sh
index 56c5709..15005db 100644
--- a/tg.sh
+++ b/tg.sh
@@ -21,9 +21,11 @@ die()
 setup_hook()
 {
 	hook_call="\"\$(tg --hooks-path)\"/$1 \"\$@\""
-	if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
-		# Another job well done!
-		return
+	if [ -x "$git_dir/hooks/$1" ]; then
+		if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
+			# Another job well done!
+			return
+		fi
 	fi
 	# Prepare incanation
 	if [ -x "$git_dir/hooks/$1" ]; then
@@ -35,7 +37,7 @@ setup_hook()
 	{
 		echo "#!/bin/sh"
 		echo "$hook_call"
-		cat "$git_dir/hooks/$1"
+		[ -x "$git_dir/hooks/$1" ] && cat "$git_dir/hooks/$1"
 	} >"$git_dir/hooks/$1+"
 	chmod a+x "$git_dir/hooks/$1+"
 	mv "$git_dir/hooks/$1+" "$git_dir/hooks/$1"
-- 
1.6.0.rc1


-- 
Russell Steicke

-- Fortune says:
I got the bill for my surgery.  Now I know what those doctors were
wearing masks for.
		-- James Boren

Re: [PATCH] [TopGit] Check for pre-commit hook existence.

[Petr Baudis]

On Sun, Aug 03, 2008 at 10:14:01PM +0800, Russell Steicke wrote:
> 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.

Thanks, applied.

				Petr "Pasky" Baudis

Re: [ANNOUNCE] TopGit - A different patch queue manager

[Jon Smirl]

On 8/2/08, Petr Baudis <pasky@suse.cz> wrote:
>   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.

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.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [ANNOUNCE] TopGit - A different patch queue manager

[Karl Hasselström]

On 2008-08-03 10:45:06 -0400, Jon Smirl 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.

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

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

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.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

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

[martin f krafft]

[-- Attachment #1.1: Type: text/plain, Size: 1579 bytes --]

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,

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
infinite loop: see 'loop, infinite'.
loop, infinite: see 'infinite loop'.

[-- Attachment #1.2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Bert Wesarg]

Hi,

On Thu, Aug 7, 2008 at 19:56, martin f krafft <madduck@debian.org> wrote:
> 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.
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
> Thank you,

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

[martin f krafft]

[-- Attachment #1.1: Type: text/plain, Size: 945 bytes --]

also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.08.07.1658 -0300]:
> 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.

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?

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
don't hate yourself in the morning -- sleep till noon.

[-- Attachment #1.2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Bert Wesarg]

On Fri, Aug 8, 2008 at 19:06, martin f krafft <madduck@debian.org> wrote:
> also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.08.07.1658 -0300]:
>> 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.
>
> 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?
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.

>
> Also, what happens if branches cross-merge?

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

[Petr Baudis]

Hi!

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 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.

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.

> 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.

This is exactly what TopGit seeks to alleviate.

On Fri, Aug 08, 2008 at 02:06:58PM -0300, martin f krafft wrote:
> Also, what happens if branches cross-merge?

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.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

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

[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 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.
> 
> 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.

  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. ;-)

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

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

[Sam Vilain]

On Fri, 2008-08-08 at 14:06 -0300, martin f krafft wrote:
> 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?

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

> Also, what happens if branches cross-merge?

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.