1 =========================================
2 TopGit -- A different patch queue manager
3 =========================================
9 TopGit aims to make handling of large amounts of interdependent topic
10 branches easier. In fact, it is designed especially for the case where
11 you maintain a queue of third-party patches on top of another (perhaps
12 Git-controlled) project and want to easily organize, maintain and submit
13 them -- TopGit achieves that by keeping a separate topic branch for each
14 patch and providing some tools to maintain the branches.
20 See the file ``INSTALL``.
26 The TopGit git repository can be found at <http://repo.or.cz/topgit/pro>.
32 Why not use something like StGIT or Guilt or ``rebase -i`` for maintaining
33 your patch queue? The advantage of these tools is their simplicity;
34 they work with patch *series* and defer to the reflog facility for
35 version control of patches (reordering of patches is not
36 version-controlled at all). But there are several disadvantages -- for
37 one, these tools (especially StGIT) do not actually fit well with plain
38 Git at all: it is basically impossible to take advantage of the index
39 effectively when using StGIT. But more importantly, these tools
40 horribly fail in the face of a distributed environment.
42 TopGit has been designed around three main tenets:
44 (i) TopGit is as thin a layer on top of Git as possible. You
45 still maintain your index and commit using Git; TopGit will only
46 automate a few indispensable tasks.
48 (ii) TopGit is anxious about *keeping* your history. It will
49 never rewrite your history, and all metadata is also tracked
50 by Git, smoothly and non-obnoxiously. It is good to have a
51 *single* point when the history is cleaned up, and that is at
52 the point of inclusion in the upstream project; locally, you
53 can see how your patch has evolved and easily return to older
56 (iii) TopGit is specifically designed to work in a
57 distributed environment. You can have several instances of
58 TopGit-aware repositories and smoothly keep them all
59 up-to-date and transfer your changes between them.
61 As mentioned above, the main intended use-case for TopGit is tracking
62 third-party patches, where each patch is effectively a single topic
63 branch. In order to flexibly accommodate even complex scenarios when
64 you track many patches where many are independent but some depend on
65 others, TopGit ignores the ancient Quilt heritage of patch series and
66 instead allows the patches to freely form graphs (DAGs just like Git
67 history itself, only "one level higher"). For now, you have to manually
68 specify which patches the current one depends on, but TopGit might help
69 you with that in the future in a darcs-like fashion.
71 A glossary plug: The union (i.e. merge) of patch dependencies is called
72 a *base* of the patch (topic branch).
74 Of course, TopGit is perhaps not the right tool for you:
76 (i) TopGit is not complicated, but StGIT et al. are somewhat
77 simpler, conceptually. If you just want to make a linear
78 purely-local patch queue, deferring to StGIT instead might
81 (ii) When using TopGit, your history can get a little hairy
82 over time, especially with all the merges rippling through.
91 ## Create and evolve a topic branch
92 $ tg create t/gitweb/pathinfo-action
93 tg: Automatically marking dependency on master
94 tg: Creating t/gitweb/pathinfo-action base from master...
100 ## Create another topic branch on top of the former one
101 $ tg create t/gitweb/nifty-links
102 tg: Automatically marking dependency on t/gitweb/pathinfo-action
103 tg: Creating t/gitweb/nifty-links base from t/gitweb/pathinfo-action...
107 ## Create another topic branch on top of master and submit
108 ## the resulting patch upstream
109 $ tg create t/revlist/author-fixed master
110 tg: Creating t/revlist/author-fixed base from master...
114 tg: Sent t/revlist/author-fixed
116 To: git@vger.kernel.org
117 Cc: gitster@pobox.com
118 Subject: [PATCH] Fix broken revlist --author when --fixed-string
120 ## Create another topic branch depending on two others non-trivially
121 $ tg create t/whatever t/revlist/author-fixed t/gitweb/nifty-links
122 tg: Creating t/whatever base from t/revlist/author-fixed...
123 tg: Merging t/whatever base with t/gitweb/nifty-links...
125 tg: Please commit merge resolution and call: tg create
126 tg: It is also safe to abort this operation using `git reset --hard`
127 tg: but please remember you are on the base branch now;
128 tg: you will want to switch to a different branch.
132 tg: Resuming t/whatever setup...
136 ## Update a single topic branch and propagate the changes to
138 $ git checkout t/gitweb/nifty-links
141 $ git checkout t/whatever
143 Topic Branch: t/whatever (1 commit)
144 Subject: [PATCH] Whatever patch
146 Depends: t/revlist/author-fixed t/gitweb/nifty-links
148 t/gitweb/nifty-links (1 commit)
150 tg: Updating base with t/gitweb/nifty-links changes...
152 tg: Please commit merge resolution and call `tg update` again.
153 tg: It is also safe to abort this operation using `git reset --hard`,
154 tg: but please remember you are on the base branch now;
155 tg: you will want to switch to a different branch.
159 tg: Updating t/whatever against new base...
161 tg: Please resolve the merge and commit. No need to do anything else.
162 tg: You can abort this operation using `git reset --hard` now
163 tg: and retry this merge later using `tg update`.
167 ## Update a single topic branch and propagate the changes
168 ## further through the dependency chain
169 $ git checkout t/gitweb/pathinfo-action
172 $ git checkout t/whatever
174 Topic Branch: t/whatever (1/2 commits)
175 Subject: [PATCH] Whatever patch
177 Depends: t/revlist/author-fixed t/gitweb/nifty-links
179 t/gitweb/pathinfo-action (<= t/gitweb/nifty-links) (1 commit)
181 tg: Recursing to t/gitweb/nifty-links...
182 [t/gitweb/nifty-links] tg: Updating base with t/gitweb/pathinfo-action changes...
184 [t/gitweb/nifty-links] tg: Please commit merge resolution and call `tg update` again.
185 [t/gitweb/nifty-links] tg: It is also safe to abort this operation using `git reset --hard`,
186 [t/gitweb/nifty-links] tg: but please remember you are on the base branch now;
187 [t/gitweb/nifty-links] tg: you will want to switch to a different branch.
188 [t/gitweb/nifty-links] tg: You are in a subshell. If you abort the merge,
189 [t/gitweb/nifty-links] tg: use `exit` to abort the recursive update altogether.
190 [t/gitweb/nifty-links] $ ..resolve..
191 [t/gitweb/nifty-links] $ git commit
192 [t/gitweb/nifty-links] $ tg update
193 [t/gitweb/nifty-links] tg: Updating t/gitweb/nifty-links against new base...
195 [t/gitweb/nifty-links] tg: Please resolve the merge and commit.
196 [t/gitweb/nifty-links] tg: You can abort this operation using `git reset --hard`.
197 [t/gitweb/nifty-links] tg: You are in a subshell. After you either commit or abort
198 [t/gitweb/nifty-links] tg: your merge, use `exit` to proceed with the recursive update.
199 [t/gitweb/nifty-links] $ ..resolve..
200 [t/gitweb/nifty-links] $ git commit
201 [t/gitweb/nifty-links] $ exit
202 tg: Updating base with t/gitweb/nifty-links changes...
203 tg: Updating t/whatever against new base...
205 ## Clone a TopGit-controlled repository
208 $ tg remote --populate origin
213 ## Add a TopGit remote to a repository and push to it
214 $ git remote add foo URL
218 ## Update from a non-default TopGit remote
227 The ``tg`` tool has several subcommands:
231 Our sophisticated integrated help facility. Mostly duplicates
232 what is below, except for adding summary Usage lines::
236 # to get help for a particular command:
238 # to get help for a particular command in a browser window:
239 $ tg help -w <command>
243 Create a new TopGit-controlled topic branch of the given name
244 (required argument) and switch to it. If no dependencies are
245 specified (by extra arguments passed after the first one), the
246 current branch is assumed to be the only dependency.
248 After ``tg create``, you should insert the patch description into
249 the ``.topmsg`` file, which will already contain some prefilled
250 bits. You can set the ``topgit.to``, ``topgit.cc`` and ``topgit.bcc``
251 git configuration variables (see ``man git-config``) in order to
252 have ``tg create`` add these headers with the given default values
255 The main task of ``tg create`` is to set up the topic branch base
256 from the dependencies. This may fail due to merge conflicts.
257 In that case, after you commit the conflict resolution, you
258 should call ``tg create`` again (without any arguments); it will
259 detect that you are on a topic branch base ref and resume the
260 topic branch creation operation.
262 In an alternative use case, if ``-r BRANCH`` is given instead of a
263 dependency list, the topic branch is created based on the given
268 Remove a TopGit-controlled topic branch of the given name
269 (required argument). Normally, this command will remove only an
270 empty branch (base == head) without dependendents; use ``-f`` to
271 remove a non-empty branch or a branch that is depended upon by
274 The ``-f`` option is also useful to force removal of a branch's
275 base, if you used ``git branch -D B`` to remove branch B, and then
276 certain TopGit commands complain, because the base of branch B
279 IMPORTANT: Currently, this command will *NOT* remove the branch
280 from the dependency list in other branches. You need to take
281 care of this *manually*. This is even more complicated in
282 combination with ``-f`` -- in that case, you need to manually
283 unmerge the removed branch's changes from the branches depending
286 See also ``tg annihilate``.
288 | TODO: ``-a`` to delete all empty branches, depfix, revert
292 Make a commit on the current TopGit-controlled topic branch
293 that makes it equal to its base, including the presence or
294 absence of .topmsg and .topdeps. Annihilated branches are not
295 displayed by ``tg summary``, so they effectively get out of your
296 way. However, the branch still exists, and ``tg push`` will
297 push it (except if given the ``-a`` option). This way, you can
298 communicate that the branch is no longer wanted.
300 Normally, this command will remove only empty branch
301 (base == head, except for changes to the .top* files); use
302 ``-f`` to annihilate a non-empty branch.
306 Change the dependencies of a TopGit-controlled topic branch.
307 This should have several subcommands, but only ``add`` is
310 The ``add`` subcommand takes an argument naming a topic branch to
311 be added, adds it to ``.topdeps``, performs a commit and then
312 updates your topic branch accordingly. If you want to do other
313 things related to the dependency addition, like adjusting
314 ``.topmsg``, prepare them in the index before calling ``tg depend
317 | TODO: Subcommand for removing dependencies, obviously
321 List files changed by the current or specified topic branch.
324 -i list files based on index instead of branch
325 -w list files based on working tree instead of branch
329 Show summary information about the current or specified topic
334 Generate a patch from the current or specified topic branch.
335 This means that the diff between the topic branch base and head
336 (latest commit) is shown, appended to the description found in
337 the ``.topmsg`` file.
339 The patch is simply dumped to stdout. In the future, ``tg patch``
340 will be able to automatically send the patches by mail or save
341 them to files. (TODO)
344 -i base patch generation on index instead of branch
345 -w base patch generation on working tree instead of branch
349 Send a patch from the current or specified topic branch as
352 Takes the patch given on the command line and emails it out.
353 Destination addresses such as To, Cc and Bcc are taken from the
356 Since it actually boils down to ``git send-email``, please refer
357 to the documentation for that for details on how to setup email
358 for git. You can pass arbitrary options to this command through
359 the ``-s`` parameter, but you must double-quote everything. The
360 ``-r`` parameter with a msgid can be used to generate in-reply-to
361 and reference headers to an earlier mail.
363 WARNING: be careful when using this command. It easily sends
364 out several mails. You might want to run::
366 git config sendemail.confirm always
368 to let ``git send-email`` ask for confirmation before sending any
372 -i base patch generation on index instead of branch
373 -w base patch generation on working tree instead of branch
375 | TODO: ``tg mail patchfile`` to mail an already exported patch
376 | TODO: mailing patch series
377 | TODO: specifying additional options and addresses on command line
381 Register the given remote as TopGit-controlled. This will create
382 the namespace for the remote branch bases and teach ``git fetch``
383 to operate on them. However, from TopGit 0.8 onwards you need to
384 use ``tg push``, or ``git push --mirror``, for pushing
385 TopGit-controlled branches.
387 ``tg remote`` takes an optional remote name argument, and an
388 optional ``--populate`` switch. Use ``--populate`` for your
389 origin-style remotes: it will seed the local topic branch system
390 based on the remote topic branches. ``--populate`` will also make
391 ``tg remote`` automatically fetch the remote, and ``tg update`` look
392 at branches of this remote for updates by default.
396 Show overview of all TopGit-tracked topic branches and their
400 marks the current topic branch
403 indicates that it introduces no changes of its own
406 indicates respectively whether it is local-only
410 indicates respectively if it is ahead or out-of-date
411 with respect to its remote mate
414 indicates that it is out-of-date with respect to its
418 indicates that it has missing dependencies [even if
419 they are recursive ones]
422 indicates that it is out-of-date with respect to
425 This can take a long time to accurately determine all the
426 relevant information about each branch; you can pass ``-t`` to get
427 just a terse list of topic branch names quickly. Alternately,
428 you can pass ``--graphviz`` to get a dot-suitable output to draw a
429 dependency graph between the topic branches.
431 You can also use the ``--sort`` option to sort the branches using
432 a topological sort. This is especially useful if each
433 TopGit-tracked topic branch depends on a single parent branch,
434 since it will then print the branches in the dependency order.
435 In more complex scenarios, a text graph view would be much more
436 useful, but that has not yet been implemented.
438 The --deps option outputs dependency information between
439 branches in a machine-readable format. Feed this to ``tsort`` to
440 get the output from --sort.
443 -i Use TopGit metadata from the index instead of the branch
444 -w Use TopGit metadata from the working tree instead of the branch
446 | TODO: Speed up by an order of magnitude
447 | TODO: Text graph view
451 Switch to a topic branch. You can use ``git checkout <branch>``
452 to get the same effect, but this command helps you navigate
453 the dependency graph, or allows you to match the topic branch
454 name using a regular expression, so it can be more convenient.
456 There following subcommands are available:
459 Check out a branch that directly
460 depends on your current branch.
463 Check out a branch that this branch
466 ``tg checkout goto <pattern>``
467 Check out a topic branch that
468 matches ``<pattern>``. ``<pattern>``
469 is used as a sed pattern to filter
470 all the topic branches.
473 An alias for ``push``.
475 ``tg checkout child``
476 An alias for ``push``.
479 An alias for ``push``.
482 An alias for ``pop``.
484 ``tg checkout parent``
485 An alias for ``pop``.
488 An alias for ``pop``.
490 If any of the above commands can find more than one possible
491 branch to switch to, you will be presented with the matches
492 and ask to select one of them.
494 The ``<pattern>`` of ``tg checkout goto`` is optional. If you don't
495 supply it, all the available topic branches are listed and you
496 can select one of them.
498 Normally, the ``push`` and ``pop`` commands moves one step in
499 the dependency graph of the topic branches. The ``-a`` option
500 causes them (and their aliases) to move as far as possible.
501 That is, ``tg checkout push -a`` moves to a topic branch that
502 depends (directly or indirectly) on the current branch and
503 that no other branch depends on. ``tg checkout pop -a``
504 moves to a regular branch that the current topic branch
505 depends on (directly or indirectly). If there is more than
506 one possibility, you will be prompted for your selection.
510 Export a tidied-up history of the current topic branch and its
511 dependencies, suitable for feeding upstream. Each topic branch
512 corresponds to a single commit or patch in the cleaned up
513 history (corresponding basically exactly to ``tg patch`` output
514 for the topic branch).
516 The command has three possible outputs now -- either a Git branch
517 with the collapsed history, a Git branch with a linearized
518 history, or a quilt series in new directory.
520 In the case where you are producing collapsed history in a new
521 branch, you can use this collapsed structure either for
522 providing a pull source for upstream, or for further
523 linearization e.g. for creation of a quilt series using git log::
525 git log --pretty=email -p --topo-order origin..exported
527 To better understand the function of ``tg export``, consider this
528 dependency structure::
530 origin/master - t/foo/blue - t/foo/red - master
531 `- t/bar/good <,----------'
532 `- t/baz ------------'
534 (where each of the branches may have a hefty history). Then::
536 master$ tg export for-linus
538 will create this commit structure on the branch ``for-linus``::
540 origin/master - t/foo/blue -. merge - t/foo/red -.. merge - master
541 `- t/bar/good <,-------------------'/
542 `- t/baz ---------------------'
544 In this mode, ``tg export`` works on the current topic branch, and
545 can be called either without an option (in that case,
546 ``--collapse`` is assumed), or with the ``--collapse`` option, and
547 with one mandatory argument: the name of the branch where the
548 exported result will be stored.
550 When using the linearize mode::
552 master$ tg export --linearize for-linus
554 you get a linear history respecting the dependencies of your
555 patches in a new branch ``for-linus``. The result should be more
556 or less the same as using quilt mode and then reimporting it
557 into a Git branch. (More or less because the topological order
558 can usually be extended in more than one way into a total order,
559 and the two methods may choose different ones.) The result
560 might be more appropriate for merging upstream, as it contains
563 Note that you might get conflicts during linearization because
564 the patches are reordered to get a linear history.
566 When using the quilt mode::
568 master$ tg export --quilt for-linus
570 would create the following directory ``for-linus``::
572 for-linus/t/foo/blue.diff
573 for-linus/t/foo/red.diff
574 for-linus/t/bar/good.diff
582 With ``--quilt``, you can also pass the ``-b`` parameter followed
583 by a comma-separated explicit list of branches to export, or
584 the ``--all`` parameter (which can be shortened to ``-a``) to
585 export them all. These options are currently only supported
588 In ``--quilt`` mode the patches are named like the originating
589 topgit branch. So usually they end up in subdirectories of the
590 output directory. With the ``--flatten`` option the names are
591 mangled so that they end up directly in the output dir (slashes
592 are substituted by underscores). With the ``--strip[=N]`` option
593 the first ``N`` subdirectories (all if no ``N`` is given) get
594 stripped off. Names are always ``--strip``'d before being
595 ``--flatten``'d. With the option ``--numbered`` (which implies
596 ``--flatten``) the patch names get a number as prefix to allow
597 getting the order without consulting the series file, which
598 eases sending out the patches.
600 | TODO: Make stripping of non-essential headers configurable
601 | TODO: Make stripping of [PATCH] and other prefixes configurable
602 | TODO: ``--mbox`` option to export instead as an mbox file
603 | TODO: support ``--all`` option in other modes of operation
604 | TODO: For quilt exporting, export the linearized history created in
605 a temporary branch--this would allow producing conflict-less
610 Import commits within the given revision range into TopGit,
611 creating one topic branch per commit. The dependencies are set
612 up to form a linear sequence starting on your current branch --
613 or a branch specified by the ``-d`` parameter, if present.
615 The branch names are auto-guessed from the commit messages and
616 prefixed by ``t/`` by default; use ``-p <prefix>`` to specify an
617 alternative prefix (even an empty one).
619 Alternatively, you can use the ``-s NAME`` parameter to specify
620 the name of the target branch; the command will then take one
621 more argument describing a *single* commit to import.
625 Update the current, specified or all topic branches with respect
626 to changes in the branches they depend on and remote branches.
627 This is performed in two phases -- first, changes within the
628 dependencies are merged to the base, then the base is merged
629 into the topic branch. The output will guide you on what to do
630 next in case of conflicts.
632 When ``-a`` is specifed, updates all topic branches matched by
633 ``<pattern>``'s (see ``git-for-each-ref(1)`` for details), or all if
634 no ``<pattern>`` is given.
636 After the update, if a single topic branch was specified, it is
637 left as the current one; if ``-a`` was specified, it returns to
638 the branch which was current at the beginning.
640 If your dependencies are not up-to-date, ``tg update`` will first
641 recurse into them and update them.
643 If a remote branch update brings in dependencies on branches
644 that are not yet instantiated locally, you can either bring in
645 all the new branches from the remote using ``tg remote
646 --populate``, or only pick out the missing ones using ``tg create
647 -r`` (``tg summary`` will point out branches with incomplete
648 dependencies by showing an ``!`` next to them).
650 | TODO: ``tg update -a -c`` to autoremove (clean) up-to-date branches
654 If ``-a`` or ``--all`` was specified, pushes all non-annihilated
655 TopGit-controlled topic branches, to a remote repository.
656 Otherwise, pushes the specified topic branches -- or the
657 current branch, if you don't specify which. By default, the
658 remote gets all the dependencies (both TopGit-controlled and
659 non-TopGit-controlled) and bases pushed to it too. If
660 ``--tgish-only`` was specified, only TopGit-controlled
661 dependencies will be pushed, and if ``--no-deps`` was specified,
662 no dependencies at all will be pushed.
664 The remote may be specified with the ``-r`` option. If no remote
665 was specified, the configured default TopGit remote will be
670 Prints the base commit of each of the named topic branches, or
671 the current branch if no branches are named. Prints an error
672 message and exits with exit code 1 if the named branch is not
677 Prints the git log of the named topgit branch -- or the current
678 branch, if you don't specify a name.
680 NOTE: if you have merged changes from a different repository, this
681 command might not list all interesting commits.
685 Outputs the direct dependencies for the current or named branch.
688 -i show dependencies based on index instead of branch
689 -w show dependencies based on working tree instead of branch
693 Outputs all branches which directly depend on the current or
697 -i show dependencies based on index instead of branch
698 -w show dependencies based on working tree instead of branch
706 TopGit stores all the topic branches in the regular ``refs/heads/``
707 namespace (so we recommend distinguishing them with the ``t/`` prefix).
708 Apart from that, TopGit also maintains a set of auxiliary refs in
709 ``refs/top-*``. Currently, only ``refs/top-bases/`` is used, containing the
710 current *base* of the given topic branch -- this is basically a merge of
711 all the branches the topic branch depends on; it is updated during ``tg
712 update`` and then merged to the topic branch, and it is the base of a
713 patch generated from the topic branch by ``tg patch``.
715 All the metadata is tracked within the source tree and history of the
716 topic branch itself, in ``.top*`` files; these files are kept isolated
717 within the topic branches during TopGit-controlled merges and are of
718 course omitted during ``tg patch``. The state of these files in base
719 commits is undefined; look at them only in the topic branches
720 themselves. Currently, two files are defined:
723 Contains the description of the topic branch in a
724 mail-like format, plus the author information, whatever
725 Cc headers you choose or the post-three-dashes message.
726 When mailing out your patch, basically only a few extra
727 mail headers are inserted and then the patch itself is
728 appended. Thus, as your patches evolve, you can record
729 nuances like whether the particular patch should have
730 To-list / Cc-maintainer or vice-versa and similar
731 nuances, if your project is into that. ``From`` is
732 prefilled from your current ``GIT_AUTHOR_IDENT``; other
733 headers can be prefilled from various optional
734 ``topgit.*`` git config options.
737 Contains the one-per-line list of branches this branch
738 depends on, pre-seeded by `tg create`. A (continuously
739 updated) merge of these branches will be the *base* of
742 IMPORTANT: DO NOT EDIT ``.topdeps`` MANUALLY!!! If you do so, you need to
743 know exactly what are you doing, since this file must stay in sync with
744 the Git history information, otherwise very bad things will happen.
746 TopGit also automagically installs a bunch of custom commit-related
747 hooks that will verify whether you are committing the ``.top*`` files in a
748 sane state. It will add the hooks to separate files within the ``hooks/``
749 subdirectory, and merely insert calls to them to the appropriate hooks
750 and make them executable (but will make sure the original hook's code is
751 not called if the hook was not executable beforehand).
753 Another automagically installed piece is a ``.git/info/attributes``
754 specifier for an ``ours`` merge strategy for the files ``.topmsg`` and
755 ``.topdeps``, and the (intuitive) ``ours`` merge strategy definition in
762 There are two remaining issues with accessing topic branches in remote
765 (i) Referring to remote topic branches from your local repository
766 (ii) Developing some of the remote topic branches locally
768 There are two somewhat contradictory design considerations here:
770 (a) Hacking on multiple independent TopGit remotes in a single
772 (b) Having a self-contained topic system in local refs space
774 To us, (a) does not appear to be very convincing, while (b) is quite
775 desirable for ``git-log topic`` etc. working, and increased conceptual
778 Thus, we choose to instantiate all the topic branches of given remote
779 locally; this is performed by ``tg remote --populate``. ``tg update``
780 will also check if a branch can be updated from its corresponding remote
781 branch. The logic needs to be somewhat involved if we are to "do the
782 right thing". First, we update the base, handling the remote branch as
783 if it was the first dependency; thus, conflict resolutions made in the
784 remote branch will be carried over to our local base automagically.
785 Then, the base is merged into the remote branch and the result is merged
786 to the local branch -- again, to carry over remote conflict resolutions.
787 In the future, this order might be adjustable on a per-update basis, in
788 case local changes happen to be diverging more than the remote ones.
790 All commands by default refer to the remote that ``tg remote --populate``
791 was called on the last time (stored in the ``topgit.remote`` git
792 configuration variable). You can manually run any command with a
793 different base remote by passing ``-r REMOTE`` *before* the subcommand
800 The following references are useful to understand the development of
801 topgit and its subcommands.
804 http://lists-archives.org/git/688698-add-list-and-rm-sub-commands-to-tg-depend.html
810 The following software understands TopGit branches:
812 * `magit <http://magit.github.io/>`_ -- a git mode for emacs
814 IMPORTANT: Magit requires its topgit mode to be enabled first, as
815 described in its documentation, in the "Activating extensions"
816 subsection. If this is not done, it will not push TopGit branches
817 correctly, so it's important to enable it even if you plan to mostly use
818 TopGit from the command line.