threads / discuss / 18020

topgit patches

Subject: topgit patches

## tl;dr

16 messages between Feb 25, 2009 and Mar 3, 2009.

replies: 15people: 3as markdown or json

Uwe Kleine-König· Feb 25, 2009, 19:58 UTC · lore

Hello,

The following changes since commit 8c77c342166ddc6ecb3840628d89ddc5bb6b043b:
  Kirill Smelkov (1):
        tg-completion: complete options for `tg remote`

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/topgit.git pu

Uwe Kleine-König (5):
      [TOPGIT] limit rev-list in branch_contains to a single rev
      [TOPGIT] allow working with annihilated branches
      [TOPGIT] make tg remote idempotent
      [TOPGIT] make creating a commit from a topgit branch a function
      [TOPGIT] implement linearize export method

 tg-export.sh  |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
 tg-remote.sh  |    6 ++--
 tg-summary.sh |   11 ++++++-
 tg.sh         |   19 ++++++++++-
 4 files changed, 113 insertions(+), 17 deletions(-)

I consider the first three as ready to pull (they form my master branch at the repo above). The fourth commit is just preparing the fifth. The fifth commit implements a new export method that I use often. The error handling isn't well tested, just because I don't usually run into merge conflicts in my series :-)

I look forward to comments, especially for the last commit.

For review purposes I send the patches as a reply to this mail.

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uwe Kleine-König· Feb 25, 2009, 20:03 UTC · re: Uwe Kleine-König · lore

[PATCH] [TOPGIT] limit rev-list in branch_contains to a single rev

This eases reading of debug output using sh -x and probably helps performance, too.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 tg.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tg.sh b/tg.sh
index 8c23d26..ccb40cd 100644
--- a/tg.sh
+++ b/tg.sh
@@ -77,7 +77,7 @@ measure_branch()
 # Whether B1 is a superset of B2.
 branch_contains()
 {
-	[ -z "$(git rev-list ^"$1" "$2" --)" ]
+	[ -z "$(git rev-list --max-count=1 ^"$1" "$2" --)" ]
 }
 
 # ref_exists REF

-- 
1.5.6.5

Uwe Kleine-König· Feb 25, 2009, 20:03 UTC · re: Uwe Kleine-König · lore

[PATCH] [TOPGIT] allow working with annihilated branches

If you decide that you want to drop a patch, you can just merge in its base with strategy "theirs". Then you have base=topic and so no .top* files any more. This patch fixes tg summary and the helper function recurse_deps() to handle these annihilated branches as if they don't exist and don't show up in .topdeps files.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 tg-summary.sh |   11 ++++++++++-
 tg.sh         |   17 ++++++++++++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/tg-summary.sh b/tg-summary.sh
index 842d95a..50ee883 100644
--- a/tg-summary.sh
+++ b/tg-summary.sh
@@ -53,13 +53,22 @@ fi
 git for-each-ref refs/top-bases |
 	while read rev type ref; do
 		name="${ref#refs/top-bases/}"
+		if branch_annihilated "$name"; then
+			continue;
+		fi;
+
 		if [ -n "$terse" ]; then
 			echo "$name"
 			continue
 		fi
 		if [ -n "$graphviz" ]; then
 			git cat-file blob "$name:.topdeps" | while read dep; do
-				echo "\"$name\" -> \"$dep\";"
+				dep_is_tgish=true
+				ref_exists "refs/top-bases/$dep"  ||
+					dep_is_tgish=false
+				if ! "$dep_is_tgish" || ! branch_annihilated $dep; then
+					echo "\"$name\" -> \"$dep\";"
+				fi
 			done
 			continue
 		fi
diff --git a/tg.sh b/tg.sh
index ccb40cd..5bb2d0c 100644
--- a/tg.sh
+++ b/tg.sh
@@ -94,6 +94,16 @@ has_remote()
 	[ -n "$base_remote" ] && ref_exists "remotes/$base_remote/$1"
 }
 
+branch_annihilated()
+{
+	_name="$1";
+
+	# use the merge base in case the base is ahead.
+	mb="$(git merge-base "refs/top-bases/$_name" "$_name")";
+
+	test "$(git rev-parse "$mb^{tree}")" = "$(git rev-parse "$_name^{tree}")";
+}
+
 # recurse_deps CMD NAME [BRANCHPATH...]
 # Recursively eval CMD on all dependencies of NAME.
 # CMD can refer to $_name for queried branch name,
@@ -116,7 +126,12 @@ recurse_deps()
 	if has_remote "top-bases/$_name"; then
 		echo "refs/remotes/$base_remote/top-bases/$_name" >>"$_depsfile"
 	fi
-	git cat-file blob "$_name:.topdeps" >>"$_depsfile"
+
+	# if the branch was annihilated, there exists no .topdeps file
+	if ! branch_annihilated "$_name"; then
+		#TODO: handle nonexisting .topdeps?
+		git cat-file blob "$_name:.topdeps" >>"$_depsfile";
+	fi;
 
 	_ret=0
 	while read _dep; do

-- 
1.5.6.5

Uwe Kleine-König· Feb 25, 2009, 20:03 UTC · re: Uwe Kleine-König · lore

[PATCH] [TOPGIT] make tg remote idempotent

Before this patch each call to tg remote added three config entries no matter if they already existed. After some time my .git/config was crowded.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 tg-remote.sh |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tg-remote.sh b/tg-remote.sh
index c3e8bd3..3a40081 100644
--- a/tg-remote.sh
+++ b/tg-remote.sh
@@ -27,9 +27,9 @@ git config "remote.$name.url" >/dev/null || die "unknown remote '$name'"
 
 ## Configure the remote
 
-git config --add "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*"
-git config --add "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*"
-git config --add "remote.$name.push" "+refs/heads/*:refs/heads/*"
+git config --replace-all "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*" "\\+refs/top-bases/\\*:refs/remotes/$name/top-bases/\\*"
+git config --replace-all "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*" "\\+refs/top-bases/\\*:refs/top-bases/\\*"
+git config --replace-all "remote.$name.push" "+refs/heads/*:refs/heads/*" "\\+refs/heads/\\*:refs/heads/\\*"
 
 info "Remote $name can now follow TopGit topic branches."
 if [ -z "$populate" ]; then

-- 
1.5.6.5

Uwe Kleine-König· Feb 25, 2009, 20:03 UTC · re: Uwe Kleine-König · lore

[PATCH] [TOPGIT] make creating a commit from a topgit branch a function

This helps avoiding code duplication for the next commit.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 tg-export.sh |   27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/tg-export.sh b/tg-export.sh
index 9e6940f..dea24d9 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -71,14 +71,11 @@ pretty_tree()
 	 git write-tree)
 }
 
-# collapsed_commit NAME
-# Produce a collapsed commit of branch NAME.
-collapsed_commit()
+create_tg_commit()
 {
 	name="$1"
-
-	rm -f "$playground/^pre" "$playground/^post"
-	>"$playground/^body"
+	tree="$2"
+	parent="$3"
 
 	# Get commit message and authorship information
 	git cat-file blob "$name:.topmsg" | git mailinfo "$playground/^msg" /dev/null > "$playground/^info"
@@ -92,6 +89,20 @@ collapsed_commit()
 	test -n "$GIT_AUTHOR_EMAIL" && export GIT_AUTHOR_EMAIL
 	test -n "$GIT_AUTHOR_DATE" && export GIT_AUTHOR_DATE
 
+	(printf '%s\n\n' "$SUBJECT"; cat "$playground/^msg") |
+	git stripspace |
+	git commit-tree "$tree" -p "$parent"
+}
+
+# collapsed_commit NAME
+# Produce a collapsed commit of branch NAME.
+collapsed_commit()
+{
+	name="$1"
+
+	rm -f "$playground/^pre" "$playground/^post"
+	>"$playground/^body"
+
 	# Determine parent
 	parent="$(cut -f 1 "$playground/$name^parents")"
 	if [ "$(cat "$playground/$name^parents" | wc -l)" -gt 1 ]; then
@@ -107,9 +118,7 @@ collapsed_commit()
 	if branch_empty "$name"; then
 		echo "$parent";
 	else
-		(printf '%s\n\n' "$SUBJECT"; cat "$playground/^msg") |
-		git stripspace |
-		git commit-tree "$(pretty_tree "$name")" -p "$parent"
+		create_tg_commit "$name" "$(pretty_tree $name)" "$parent"
 	fi;
 
 	echo "$name" >>"$playground/^ticker"

-- 
1.5.6.5

Uwe Kleine-König· Feb 25, 2009, 20:04 UTC · re: Uwe Kleine-König · lore

[PATCH] [TOPGIT] implement linearize export method

This is a draft that seems to work for my test case. The error handling is to be improved though.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 tg-export.sh |   67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 65 insertions(+), 2 deletions(-)

diff --git a/tg-export.sh b/tg-export.sh
index dea24d9..748ca54 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -27,8 +27,10 @@ while [ -n "$1" ]; do
 		driver=quilt;;
 	--collapse)
 		driver=collapse;;
+	--linearize)
+		driver=linearize;;
 	-*)
-		echo "Usage: tg [...] export ([--collapse] NEWBRANCH | [-b BRANCH1,BRANCH2...] --quilt DIRECTORY)" >&2
+		echo "Usage: tg [...] export ([--collapse] NEWBRANCH | [-b BRANCH1,BRANCH2...] --quilt DIRECTORY | --linearize NEWBRANCH)" >&2
 		exit 1;;
 	*)
 		[ -z "$output" ] || die "output already specified ($output)"
@@ -195,10 +197,60 @@ quilt()
 	fi
 }
 
+linearize()
+{
+	if test ! -f "$playground/^BASE"; then
+		head="$(git rev-parse --verify "$_dep")"
+		echo "$head" > "$playground/^BASE"
+		git checkout -q "$head"
+		return;
+	fi;
+
+	head=$(git rev-parse --verify HEAD)
+
+	if [ -z "$_dep_is_tgish" ]; then
+		# merge in $_dep unless already included
+		rev="$(git rev-parse --verify "$_dep")";
+		common="$(git merge-base --all HEAD "$_dep")";
+		if test "$rev" = "$common"; then
+			# already included, just skip
+			:;
+		else
+			git merge -s recursive "$_dep";
+			retmerge="$?";
+			if test "x$retmerge" != "x0"; then
+				echo fix up the merge, commit and then exit;
+				#todo error handling
+				sh -i
+			fi;
+		fi;
+	else
+		git merge-recursive "$(pretty_tree "refs/top-bases/$_dep")" -- HEAD "$(pretty_tree "refs/heads/$_dep")";
+		retmerge="$?";
+
+		if test "x$retmerge" != "x0"; then
+			echo "fix up the merge and update the index.  Don't commit!"
+			#todo error handling
+			sh -i
+		fi
+
+		result_tree=$(git write-tree)
+		# testing branch_empty might not always give the right answer.
+		# It can happen that the patch is non-empty but still after
+		# linearizing there is no change.  So compare the trees.
+		if test "x$result_tree" = "x$(git rev-parse $head^{tree})"; then
+			echo "skip empty commit $_dep";
+		else
+			newcommit=$(create_tg_commit "$_dep" "$result_tree" HEAD)
+			git update-ref HEAD $newcommit $head
+			echo "exported commit $_dep";
+		fi
+	fi
+}
 
 ## Machinery
 
-if [ "$driver" = "collapse" ]; then
+if [ "$driver" = "collapse" ] || [ "$driver" = "linearize" ]; then
 	[ -n "$output" ] ||
 		die "no target branch specified"
 	! ref_exists "$output"  ||
@@ -247,6 +299,17 @@ if [ "$driver" = "collapse" ]; then
 elif [ "$driver" = "quilt" ]; then
 	depcount="$(cat "$output/series" | wc -l)"
 	echo "Exported topic branch $name (total $depcount topics) to directory $output"
+
+elif [ "$driver" = "linearize" ]; then
+	git checkout -q -b $output
+
+	echo $name
+	if test $(git rev-parse "$(pretty_tree $name)^{tree}") != $(git rev-parse "HEAD^{tree}"); then
+		echo "Warning: Exported result doesn't match";
+		echo "tg-head=$(git rev-parse "$name"), exported=$(git rev-parse "HEAD")";
+		#git diff $head HEAD;
+	fi;
+
 fi
 
 # vim:noet

-- 
1.5.6.5

Petr Baudis· Feb 25, 2009, 21:23 UTC · re: Uwe Kleine-König · lore

Re: topgit patches

Hi,

On Wed, Feb 25, 2009 at 08:58:56PM +0100, Uwe Kleine-König wrote:

Show 30 quoted lines

> The following changes since commit 8c77c342166ddc6ecb3840628d89ddc5bb6b043b:
>   Kirill Smelkov (1):
>         tg-completion: complete options for `tg remote`
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/ukl/topgit.git pu
> 
> Uwe Kleine-König (5):
>       [TOPGIT] limit rev-list in branch_contains to a single rev
>       [TOPGIT] allow working with annihilated branches
>       [TOPGIT] make tg remote idempotent
>       [TOPGIT] make creating a commit from a topgit branch a function
>       [TOPGIT] implement linearize export method
> 
>  tg-export.sh  |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
>  tg-remote.sh  |    6 ++--
>  tg-summary.sh |   11 ++++++-
>  tg.sh         |   19 ++++++++++-
>  4 files changed, 113 insertions(+), 17 deletions(-)
> 
> I consider the first three as ready to pull (they form my master branch
> at the repo above).  The fourth commit is just preparing the fifth.  The
> fifth commit implements a new export method that I use often.  The error
> handling isn't well tested, just because I don't usually run into merge
> conflicts in my series :-)
> 
> I look forward to comments, especially for the last commit.
> 
> For review purposes I send the patches as a reply to this mail.

  I'm unfortunately not actively using topgit right now and I have no
time to maintain it or review patches. :-( Martin seems to be in similar
situation. So, would you like push access to the main repository? ;-)

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

Uwe Kleine-König· Feb 25, 2009, 23:15 UTC · re: Petr Baudis · lore

Re: topgit patches

Hi Petr,

On Wed, Feb 25, 2009 at 10:23:09PM +0100, Petr Baudis wrote:

Show 19 quoted lines

> On Wed, Feb 25, 2009 at 08:58:56PM +0100, Uwe Kleine-König wrote:
> > The following changes since commit 8c77c342166ddc6ecb3840628d89ddc5bb6b043b:
> >   Kirill Smelkov (1):
> >         tg-completion: complete options for `tg remote`
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/topgit.git pu
> > 
> > Uwe Kleine-König (5):
> >       [TOPGIT] limit rev-list in branch_contains to a single rev
> >       [TOPGIT] allow working with annihilated branches
> >       [TOPGIT] make tg remote idempotent
> >       [TOPGIT] make creating a commit from a topgit branch a function
> >       [TOPGIT] implement linearize export method
> > 
>   I'm unfortunately not actively using topgit right now and I have no
> time to maintain it or review patches. :-( Martin seems to be in similar
> situation. So, would you like push access to the main repository? ;-)

Well, I already wondered if there is someone using topgit apart from me. :-)

If you give me push access I'd only push the first three patches to master and maybe create a pu branch for the linearize method.

Given this situation it probably doesn't make sense to describe some problems I currently see using topgit :-|.

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686              | Fax:   +49-5121-206917-5555 |

Petr Baudis· Feb 25, 2009, 23:22 UTC · re: Uwe Kleine-König · lore

Re: topgit patches

Hi,

On Thu, Feb 26, 2009 at 12:15:50AM +0100, Uwe Kleine-König wrote:

Show 6 quoted lines

> On Wed, Feb 25, 2009 at 10:23:09PM +0100, Petr Baudis wrote:
> >   I'm unfortunately not actively using topgit right now and I have no
> > time to maintain it or review patches. :-( Martin seems to be in similar
> > situation. So, would you like push access to the main repository? ;-)
> Well, I already wondered if there is someone using topgit apart from me.
> :-)

  hehe, i think there are still quite a few people, though the initial
surge of interest fell a bit, understandably.

> If you give me push access I'd only push the first three patches to
> master and maybe create a pu branch for the linearize method.

  I wouldn't be so conservative, IMHO it's better to liberally test new
features rather than let them bitrot, in such a small project, but of
course it's up to you.

  What's your repo.or.cz username?

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

Uwe Kleine-König· Feb 26, 2009, 13:47 UTC · re: Petr Baudis · lore

Re: topgit patches

Hi Petr,

On Thu, Feb 26, 2009 at 12:22:37AM +0100, Petr Baudis wrote:

Show 6 quoted lines

> > If you give me push access I'd only push the first three patches to
> > master and maybe create a pu branch for the linearize method.
> 
>   I wouldn't be so conservative, IMHO it's better to liberally test new
> features rather than let them bitrot, in such a small project, but of
> course it's up to you.

OK, that's fine for me, too.  This way it might at least get a few more
users. :)

>   What's your repo.or.cz username?

ukleinek

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

martin f krafft· Feb 26, 2009, 06:06 UTC · re: Uwe Kleine-König · lore

Re: topgit patches

also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.0015 +0100]:

> Well, I already wondered if there is someone using topgit apart
> from me. :-)

I use it and would like to actively maintain it, but time is short and I wanted to push out a new option parser with 0.6, but it's just not finished yet. As soon as I find a few hours, I'll try to revisit it. But if someone else has the time, maybe we can prepare a 0.6 without a new option parser?

> Given this situation it probably doesn't make sense to describe
> some problems I currently see using topgit :-|.

Please do, I am interested.

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"auch der mutigste von uns hat nur selten den mut zu dem,
 was er eigentlich weiß."
                                                 - friedrich nietzsche

Uwe Kleine-König· Feb 26, 2009, 14:15 UTC · re: martin f krafft · lore

Re: topgit patches

Hi Martin,

On Thu, Feb 26, 2009 at 07:06:52AM +0100, martin f krafft wrote:

Show 9 quoted lines

> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.0015 +0100]:
> > Well, I already wondered if there is someone using topgit apart
> > from me. :-)
> 
> I use it and would like to actively maintain it, but time is short
> and I wanted to push out a new option parser with 0.6, but it's just
> not finished yet. As soon as I find a few hours, I'll try to revisit
> it. But if someone else has the time, maybe we can prepare a 0.6
> without a new option parser?

If you need help, I'm also interested to co-maintain the debian package.
Just an offer ...  (I don't know the exact way to become a maintainer,
if I need to meet a Debian developer, that's no problem, I know one.)

> > Given this situation it probably doesn't make sense to describe
> > some problems I currently see using topgit :-|.
> 
> Please do, I am interested.

Sometimes I get an error about being unable to delete a temp file, will try to track that down when it happens next.

Having many topgit controlled patches it's hard to get the overview. Updating patches with many interdependencies is hard and doing a merge wrong is hard to detect and fix. I don't have a good idea for that yet, but I will investigate some thought here.

Further ideas and plans of mine in no particular order:
 1 move all or most topgit-topic-branches to a private namespace, say
   refs/top-heads because the patch branches pollute the output of git
   branch.

 2 export method that works like the existing linearize but creates
   branches for topgit branches living in refs/heads and merges these
   properly without linearisation.
   (obviously depends on 1)

 3 address topgit bugs on bugs.debian.org

 4 factor out some code to helper functions in tg.sh

 5 convice my colleagues that topgit is the right tool to gain world
   domination :)

 6 I'm sure I will find some more while doing 1 to 5. :)

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

martin f krafft· Feb 27, 2009, 12:37 UTC · re: Uwe Kleine-König · lore

Re: topgit patches

also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.1515 +0100]:

> If you need help, I'm also interested to co-maintain the debian
> package. Just an offer ...  (I don't know the exact way to become
> a maintainer, if I need to meet a Debian developer, that's no
> problem, I know one.)

The Debian package is pretty trivial to maintain on top of upstream (thanks to topgit), and I am using it a bit as a test-case for workflow experiments. However, if you are interested in packaging, by all means, join me. In that case I'd suggest that you make the 0.6-1 Debian package after 0.6 is out, and I give you some hints up front and then simply stand by to help out.

>  1 move all or most topgit-topic-branches to a private namespace, say
>    refs/top-heads because the patch branches pollute the output of git
>    branch.

But aren't the topic branches essentially also plain Git branches?

>  2 export method that works like the existing linearize but creates
>    branches for topgit branches living in refs/heads and merges these
>    properly without linearisation.
>    (obviously depends on 1)

I am not sure I understand what you are trying to do.

>  3 address topgit bugs on bugs.debian.org

Awesome. I will try to be available for any support you might need. I just can't come up with a sufficiently long stretch of time to see through the next release right now.

Cheers,

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
ubuntu is an ancient african word meaning "i can't install debian."
                                                          -- unknown

Uwe Kleine-König· Feb 27, 2009, 19:42 UTC · re: martin f krafft · lore

Re: topgit patches

On Fri, Feb 27, 2009 at 01:37:31PM +0100, martin f krafft wrote:

Show 12 quoted lines

> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.1515 +0100]:
> > If you need help, I'm also interested to co-maintain the debian
> > package. Just an offer ...  (I don't know the exact way to become
> > a maintainer, if I need to meet a Debian developer, that's no
> > problem, I know one.)
> 
> The Debian package is pretty trivial to maintain on top of upstream
> (thanks to topgit), and I am using it a bit as a test-case for
> workflow experiments. However, if you are interested in packaging,
> by all means, join me. In that case I'd suggest that you make the
> 0.6-1 Debian package after 0.6 is out, and I give you some hints up
> front and then simply stand by to help out.

Great.

Show 5 quoted lines

> >  1 move all or most topgit-topic-branches to a private namespace, say
> >    refs/top-heads because the patch branches pollute the output of git
> >    branch.
> 
> But aren't the topic branches essentially also plain Git branches?

Yes, sure, but in my workflow I usually have "patch branches" that really introduce a change and "topic branches" that don't introduce own changes but only collect "patch branches" in .topdeps. For me it would be enough to let the "topic branches" appear in the output of git-branch. Currently I have 144 (non-remote) branches in my linux repo:

	-   3 branches are exported topgit developments;
	-   1 master branch (don't know off-hand what it contains);
	-   9 topgit topic branches; and
	- 131 topgit patch branches.

Skipping the 131 patch branches would greatly improve usability.

Show 6 quoted lines

> >  2 export method that works like the existing linearize but creates
> >    branches for topgit branches living in refs/heads and merges these
> >    properly without linearisation.
> >    (obviously depends on 1)
> 
> I am not sure I understand what you are trying to do.

For example I collect arm-linux related patches that are ready for upstream in a branch called t/armmisc-master, and patches that are not ready in t/armmisc-pu. t/armmisc-pu depends on t/armmisc-master. When I export t/armmisc-pu (usually to armmisc-pu) I want that a branch armmisc-master is created that is an ancestor of armmisc-pu that just contains the patches in t/armmisc-master.

Another scenario is if I'm working on a platform, say imx, I have several upstreams: arm, i2c, mtd etc. Here I want to have a topic branch that contains all my imx patches and provides proper branches to pull for my upstreams. So the involved topgit topic branches are named:

	t/imx-master
	t/imx/arm-master
	t/imx/i2c-master
	t/imx/mtd-master

and the exported result has to look like this:

	                 arm-patch1 -- arm-patch2 ... arm-patchK
	               /                                        \
	              /                                          \
	linus/master  -- i2c-patch1 -- i2c-patch2 ... i2c-patchL-- imx-master
	              \                                          /
	               \                                        /
	                 mtc-patch1 -- mtd-patch2 ... mtd-patchM

and arm-patchK, i2c-patchL and mtd-patchM are the heads of the branches imx/arm-master, imx/i2c-master and imx/mtd-master respectively.

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uwe Kleine-König· Mar 2, 2009, 16:26 UTC · re: martin f krafft · lore

Re: topgit patches

Hello,

On Thu, Feb 26, 2009 at 07:06:52AM +0100, martin f krafft wrote:

Show 9 quoted lines

> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.02.26.0015 +0100]:
> > Well, I already wondered if there is someone using topgit apart
> > from me. :-)
> 
> I use it and would like to actively maintain it, but time is short
> and I wanted to push out a new option parser with 0.6, but it's just
> not finished yet. As soon as I find a few hours, I'll try to revisit
> it. But if someone else has the time, maybe we can prepare a 0.6
> without a new option parser?

I assume you planned to use git rev-parse --parseopt?

Since topgit-0.5 we have some fixes, a new export method and improved bash completion. Just repackaging the current state into a new Debian package closes 4 bugs in the Debian BTS.

Before 0.6 I still need to write some documentation for the new export method, but after that I consider releasing the then current state as 0.6 is a good idea.

martin, Petr, others: any comments?  Should I just tag if I feel ready?

martin: I can try to prepare the Debian package, AFAIK I cannot upload it, so here I need your help. (And maybe you should check the package, because up to now I only created Debian packages for my private use.)

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686              | Fax:   +49-5121-206917-5555 |

martin f krafft· Mar 3, 2009, 07:54 UTC · re: Uwe Kleine-König · lore

Re: topgit patches

also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.03.02.1726 +0100]:

> > it. But if someone else has the time, maybe we can prepare a 0.6
> > without a new option parser?
> I assume you planned to use git rev-parse --parseopt?

Yes.

Show 9 quoted lines

> Since topgit-0.5 we have some fixes, a new export method and improved
> bash completion.  Just repackaging the current state into a new Debian
> package closes 4 bugs in the Debian BTS.
> 
> Before 0.6 I still need to write some documentation for the new export
> method, but after that I consider releasing the then current state as
> 0.6 is a good idea.
> 
> martin, Petr, others: any comments?  Should I just tag if I feel ready?

Sounds good to me, even without parseopt. Thanks Uwe for stepping in to help us!

> martin: I can try to prepare the Debian package, AFAIK I cannot
> upload it, so here I need your help.  (And maybe you should check
> the package, because up to now I only created Debian packages for
> my private use.)

Possibly the easiest way to do this is http://mentors.debian.net, so if that's okay with you, send me the URL to the uploaded .dsc file and I will look at it and get back to you. If you don't want to bother creating the source package, just let me know which commit ID to build (don't tag debian/* until after the upload).

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"if you are going to run a rinky-dink distro made by a couple of
 volunteers, why not run a rinky-dink distro made by a lot of
 volunteers?"
                                                    -- jaldhar h. vyas