Oops sorry about this one!!! :-/ On Thu, Nov 20, 2008 at 14:51, Jonas Fonseca <fonseca@xxxxxxx> wrote: > Signed-off-by: Jonas Fonseca <fonseca@xxxxxxx> > > --- > README [m | 11 [32m+++++ [m [31m------ [m > 1 files changed, 5 insertions(+), 6 deletions(-) [m > > [1mdiff --git a/README b/README [m > [1mindex 5bfe3ee..9e291da 100644 [m > [1m--- a/README [m > [1m+++ b/README [m > [36m@@ -22,7 +22,7 @@ version control of patches (reordering of patches is not [m > version-controlled at all). But there are several disadvantages - [m > for one, these tools (especially StGIT) do not actually fit well [m > with plain Git at all: it is basically impossible to take advantage [m > [31m-of the index efectively when using StGIT. But more importantly, [m > [32m+ [m [32mof the index effectively when using StGIT. But more importantly, [m > these tools horribly fail in the face of distributed environment. [m > [m > TopGit has been designed around three main tenets: [m > [36m@@ -45,7 +45,7 @@ them. [m > [m > As mentioned above, the main intended use-case for TopGit is tracking [m > third-party patches, where each patch is effectively a single topic [m > [31m-branch. In order to flexibly accomodate even complex scenarios when [m > [32m+ [m [32mbranch. In order to flexibly accommodate even complex scenarios when [m > you track many patches where many are independent but some depend [m > on others, TopGit ignores the ancient Quilt heritage of patch series [m > and instead allows the patches to freely form graphs (DAGs just like [m > [36m@@ -222,7 +222,7 @@ tg create [m > [m > After `tg create`, you should insert the patch description [m > to the '.topmsg' file, which will already contain some [m > [31m- pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc [m > [32m+ [m [32mprefilled bits. You can set topgit.to, topgit.cc and topgit.bcc [m > configuration variables in order to have `tg create` [m > add these headers with given default values to '.topmsg'. [m > [m > [36m@@ -350,7 +350,7 @@ tg export [m > in the cleaned up history (corresponding basically exactly [m > to `tg patch` output for the topic branch). [m > [m > [31m- The command has two posible outputs now - either a Git branch [m > [32m+ [m [32mThe command has two possible outputs now - either a Git branch [m > with the collapsed history, or a quilt series in new directory. [m > [m > In case of producing collapsed history in new branch, [m > [36m@@ -455,7 +455,6 @@ tg update [m > [m > TODO: tg update -a for updating all topic branches [m > [m > [31m-TODO: tg depend for adding/removing dependencies smoothly [m > TODO: tg rename [m > [m > [m > [36m@@ -485,7 +484,7 @@ whatever Cc headers you choose or the post-three-dashes message. [m > When mailing out your patch, basically only few extra headers [m > mail headers are inserted and the patch itself is appended. [m > Thus, as your patches evolve, you can record nuances like whether [m > [31m-the paricular patch should have To-list/Cc-maintainer or vice [m > [32m+ [m [32mthe particular patch should have To-list/Cc-maintainer or vice [m > versa and similar nuances, if your project is into that. [m > From is prefilled from your current GIT_AUTHOR_IDENT, other headers [m > can be prefilled from various optional topgit.* config options. [m > -- > tg: (f17218e..) jf/readme-update (depends on: master) > -- Jonas Fonseca -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
