From: Petr Baudis <hidden> Date: 2016-06-15 22:45:06
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
On Sun, Aug 03, 2008 at 05:14:24AM +0200, Petr Baudis [off-list ref] 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? ;-)
From: Russell Steicke <hidden> Date: 2016-06-15 22:45:06
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(-)
@@ -21,9 +21,11 @@ die() setup_hook(){hook_call="\"\$(tg --hooks-path)\"/$1 \"\$@\""-iffgrep-q"$hook_call""$git_dir/hooks/$1";then-# Another job well done!-return+if[-x"$git_dir/hooks/$1"];then+iffgrep-q"$hook_call""$git_dir/hooks/$1";then+# Another job well done!+return+fifi# Prepare incanationif[-x"$git_dir/hooks/$1"];then
From: Petr Baudis <hidden> Date: 2016-06-15 22:45:06
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.
From: Jon Smirl <hidden> Date: 2016-06-15 22:45:06
On 8/2/08, Petr Baudis [off-list ref] 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
From: Karl Hasselström <hidden> Date: 2016-06-15 22:45:06
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
From: martin f krafft <hidden> Date: 2016-06-15 22:45:07
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 [off-list ref]
: :' : 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'.
Hi,
On Thu, Aug 7, 2008 at 19:56, martin f krafft [off-list ref] 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
From: martin f krafft <hidden> Date: 2016-06-15 22:45:07
also sprach Bert Wesarg [off-list ref] [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 [off-list ref]
: :' : 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.
On Fri, Aug 8, 2008 at 19:06, martin f krafft [off-list ref] wrote:
also sprach Bert Wesarg [off-list ref] [2008.08.07.1658 -0300]:
quoted
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.
From: Sam Vilain <hidden> Date: 2016-06-15 22:45:07
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.