topgit patches

topgit patches

[Uwe Kleine-König]

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

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

[Uwe Kleine-König]

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

[PATCH] [TOPGIT] allow working with annihilated branches

[Uwe Kleine-König]

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

[PATCH] [TOPGIT] make tg remote idempotent

[Uwe Kleine-König]

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

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

[Uwe Kleine-König]

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

[PATCH] [TOPGIT] implement linearize export method

[Uwe Kleine-König]

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

Re: topgit patches

[Petr Baudis]

  Hi,

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

Re: topgit patches

[Uwe Kleine-König]

Hi Petr,

On Wed, Feb 25, 2009 at 10:23:09PM +0100, Petr Baudis wrote:
> 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 |

Re: topgit patches

[Petr Baudis]

  Hi,

On Thu, Feb 26, 2009 at 12:15:50AM +0100, Uwe Kleine-König wrote:
> 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

Re: topgit patches

[Uwe Kleine-König]

Hi Petr,

On Thu, Feb 26, 2009 at 12:22:37AM +0100, Petr Baudis wrote:
> > 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/  |

Re: topgit patches

[martin f krafft]

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

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

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

Re: topgit patches

[Uwe Kleine-König]

Hi Martin,

On Thu, Feb 26, 2009 at 07:06:52AM +0100, martin f krafft wrote:
> 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/  |

Re: topgit patches

[martin f krafft]

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

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

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

Re: topgit patches

[Uwe Kleine-König]

On Fri, Feb 27, 2009 at 01:37:31PM +0100, martin f krafft wrote:
> 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.

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

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

Re: topgit patches

[Uwe Kleine-König]

Hello,

On Thu, Feb 26, 2009 at 07:06:52AM +0100, martin f krafft wrote:
> 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 |

Re: topgit patches

[martin f krafft]

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

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.

> 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

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