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.
19 See the file ``INSTALL``.
25 Why not use something like StGIT or Guilt or ``rebase -i`` for maintaining
26 your patch queue? The advantage of these tools is their simplicity;
27 they work with patch *series* and defer to the reflog facility for
28 version control of patches (reordering of patches is not
29 version-controlled at all). But there are several disadvantages -- for
30 one, these tools (especially StGIT) do not actually fit well with plain
31 Git at all: it is basically impossible to take advantage of the index
32 effectively when using StGIT. But more importantly, these tools
33 horribly fail in the face of a distributed environment.
35 TopGit has been designed around three main tenets:
37 (i) TopGit is as thin a layer on top of Git as possible. You
38 still maintain your index and commit using Git; TopGit will only
39 automate a few indispensable tasks.
41 (ii) TopGit is anxious about *keeping* your history. It will
42 never rewrite your history, and all metadata is also tracked
43 by Git, smoothly and non-obnoxiously. It is good to have a
44 *single* point when the history is cleaned up, and that is at
45 the point of inclusion in the upstream project; locally, you
46 can see how your patch has evolved and easily return to older
49 (iii) TopGit is specifically designed to work in a
50 distributed environment. You can have several instances of
51 TopGit-aware repositories and smoothly keep them all
52 up-to-date and transfer your changes between them.
54 As mentioned above, the main intended use-case for TopGit is tracking
55 third-party patches, where each patch is effectively a single topic
56 branch. In order to flexibly accommodate even complex scenarios when
57 you track many patches where many are independent but some depend on
58 others, TopGit ignores the ancient Quilt heritage of patch series and
59 instead allows the patches to freely form graphs (DAGs just like Git
60 history itself, only "one level higher"). For now, you have to manually
61 specify which patches the current one depends on, but TopGit might help
62 you with that in the future in a darcs-like fashion.
64 A glossary plug: The union (i.e. merge) of patch dependencies is called
65 a *base* of the patch (topic branch).
67 Of course, TopGit is perhaps not the right tool for you:
69 (i) TopGit is not complicated, but StGIT et al. are somewhat
70 simpler, conceptually. If you just want to make a linear
71 purely-local patch queue, deferring to StGIT instead might
74 (ii) When using TopGit, your history can get a little hairy
75 over time, especially with all the merges rippling through.
84 ## Create and evolve a topic branch
85 $ tg create t/gitweb/pathinfo-action
86 tg: Automatically marking dependency on master
87 tg: Creating t/gitweb/pathinfo-action base from master...
93 ## Create another topic branch on top of the former one
94 $ tg create t/gitweb/nifty-links
95 tg: Automatically marking dependency on t/gitweb/pathinfo-action
96 tg: Creating t/gitweb/nifty-links base from t/gitweb/pathinfo-action...
100 ## Create another topic branch on top of master and submit
101 ## the resulting patch upstream
102 $ tg create t/revlist/author-fixed master
103 tg: Creating t/revlist/author-fixed base from master...
107 tg: Sent t/revlist/author-fixed
109 To: git@vger.kernel.org
110 Cc: gitster@pobox.com
111 Subject: [PATCH] Fix broken revlist --author when --fixed-string
113 ## Create another topic branch depending on two others non-trivially
114 $ tg create t/whatever t/revlist/author-fixed t/gitweb/nifty-links
115 tg: Creating t/whatever base from t/revlist/author-fixed...
116 tg: Merging t/whatever base with t/gitweb/nifty-links...
118 tg: Please commit merge resolution and call: tg create
119 tg: It is also safe to abort this operation using `git reset --hard`
120 tg: but please remember you are on the base branch now;
121 tg: you will want to switch to a different branch.
125 tg: Resuming t/whatever setup...
129 ## Update a single topic branch and propagate the changes to
131 $ git checkout t/gitweb/nifty-links
134 $ git checkout t/whatever
136 Topic Branch: t/whatever (1 commit)
137 Subject: [PATCH] Whatever patch
139 Depends: t/revlist/author-fixed t/gitweb/nifty-links
141 t/gitweb/nifty-links (1 commit)
143 tg: Updating base with t/gitweb/nifty-links changes...
145 tg: Please commit merge resolution and call `tg update` again.
146 tg: It is also safe to abort this operation using `git reset --hard`,
147 tg: but please remember you are on the base branch now;
148 tg: you will want to switch to a different branch.
152 tg: Updating t/whatever against new base...
154 tg: Please resolve the merge and commit. No need to do anything else.
155 tg: You can abort this operation using `git reset --hard` now
156 tg: and retry this merge later using `tg update`.
160 ## Update a single topic branch and propagate the changes
161 ## further through the dependency chain
162 $ git checkout t/gitweb/pathinfo-action
165 $ git checkout t/whatever
167 Topic Branch: t/whatever (1/2 commits)
168 Subject: [PATCH] Whatever patch
170 Depends: t/revlist/author-fixed t/gitweb/nifty-links
172 t/gitweb/pathinfo-action (<= t/gitweb/nifty-links) (1 commit)
174 tg: Recursing to t/gitweb/nifty-links...
175 [t/gitweb/nifty-links] tg: Updating base with t/gitweb/pathinfo-action changes...
177 [t/gitweb/nifty-links] tg: Please commit merge resolution and call `tg update` again.
178 [t/gitweb/nifty-links] tg: It is also safe to abort this operation using `git reset --hard`,
179 [t/gitweb/nifty-links] tg: but please remember you are on the base branch now;
180 [t/gitweb/nifty-links] tg: you will want to switch to a different branch.
181 [t/gitweb/nifty-links] tg: You are in a subshell. If you abort the merge,
182 [t/gitweb/nifty-links] tg: use `exit` to abort the recursive update altogether.
183 [t/gitweb/nifty-links] $ ..resolve..
184 [t/gitweb/nifty-links] $ git commit
185 [t/gitweb/nifty-links] $ tg update
186 [t/gitweb/nifty-links] tg: Updating t/gitweb/nifty-links against new base...
188 [t/gitweb/nifty-links] tg: Please resolve the merge and commit.
189 [t/gitweb/nifty-links] tg: You can abort this operation using `git reset --hard`.
190 [t/gitweb/nifty-links] tg: You are in a subshell. After you either commit or abort
191 [t/gitweb/nifty-links] tg: your merge, use `exit` to proceed with the recursive update.
192 [t/gitweb/nifty-links] $ ..resolve..
193 [t/gitweb/nifty-links] $ git commit
194 [t/gitweb/nifty-links] $ exit
195 tg: Updating base with t/gitweb/nifty-links changes...
196 tg: Updating t/whatever against new base...
198 ## Clone a TopGit-controlled repository
201 $ tg remote --populate origin
206 ## Add a TopGit remote to a repository and push to it
207 $ git remote add foo URL
211 ## Update from a non-default TopGit remote
220 The ``tg`` tool has several subcommands:
224 Our sophisticated integrated help facility. Mostly duplicates
225 what is below, except for adding summary Usage lines::
229 # to get help for a particular command:
234 Create a new TopGit-controlled topic branch of the given name
235 (required argument) and switch to it. If no dependencies are
236 specified (by extra arguments passed after the first one), the
237 current branch is assumed to be the only dependency.
239 After ``tg create``, you should insert the patch description into
240 the ``.topmsg`` file, which will already contain some prefilled
241 bits. You can set the ``topgit.to``, ``topgit.cc`` and ``topgit.bcc``
242 git configuration variables (see ``man git-config``) in order to
243 have ``tg create`` add these headers with the given default values
246 The main task of ``tg create`` is to set up the topic branch base
247 from the dependencies. This may fail due to merge conflicts.
248 In that case, after you commit the conflict resolution, you
249 should call ``tg create`` again (without any arguments); it will
250 detect that you are on a topic branch base ref and resume the
251 topic branch creation operation.
253 In an alternative use case, if ``-r BRANCH`` is given instead of a
254 dependency list, the topic branch is created based on the given
259 Remove a TopGit-controlled topic branch of the given name
260 (required argument). Normally, this command will remove only an
261 empty branch (base == head) without dependendents; use ``-f`` to
262 remove a non-empty branch or a branch that is depended upon by
265 The ``-f`` option is also useful to force removal of a branch's
266 base, if you used ``git branch -D B`` to remove branch B, and then
267 certain TopGit commands complain, because the base of branch B
270 IMPORTANT: Currently, this command will *NOT* remove the branch
271 from the dependency list in other branches. You need to take
272 care of this *manually*. This is even more complicated in
273 combination with ``-f`` -- in that case, you need to manually
274 unmerge the removed branch's changes from the branches depending
277 See also ``tg annihilate``.
279 | TODO: ``-a`` to delete all empty branches, depfix, revert
283 Make a commit on the current TopGit-controlled topic branch
284 that makes it equal to its base, including the presence or
285 absence of .topmsg and .topdeps. Annihilated branches are not
286 displayed by ``tg summary``, so they effectively get out of your
287 way. However, the branch still exists, and ``tg push`` will
288 push it (except if given the ``-a`` option). This way, you can
289 communicate that the branch is no longer wanted.
291 Normally, this command will remove only empty branch
292 (base == head, except for changes to the .top* files); use
293 ``-f`` to annihilate a non-empty branch.
297 Change the dependencies of a TopGit-controlled topic branch.
298 This should have several subcommands, but only ``add`` is
301 The ``add`` subcommand takes an argument naming a topic branch to
302 be added, adds it to ``.topdeps``, performs a commit and then
303 updates your topic branch accordingly. If you want to do other
304 things related to the dependency addition, like adjusting
305 ``.topmsg``, prepare them in the index before calling ``tg depend
308 | TODO: Subcommand for removing dependencies, obviously
312 List files changed by the current or specified topic branch.
315 -i list files based on index instead of branch
316 -w list files based on working tree instead of branch
320 Show summary information about the current or specified topic
325 Generate a patch from the current or specified topic branch.
326 This means that the diff between the topic branch base and head
327 (latest commit) is shown, appended to the description found in
328 the ``.topmsg`` file.
330 The patch is simply dumped to stdout. In the future, ``tg patch``
331 will be able to automatically send the patches by mail or save
332 them to files. (TODO)
335 -i base patch generation on index instead of branch
336 -w base patch generation on working tree instead of branch
340 Send a patch from the current or specified topic branch as
343 Takes the patch given on the command line and emails it out.
344 Destination addresses such as To, Cc and Bcc are taken from the
347 Since it actually boils down to ``git send-email``, please refer
348 to the documentation for that for details on how to setup email
349 for git. You can pass arbitrary options to this command through
350 the ``-s`` parameter, but you must double-quote everything. The
351 ``-r`` parameter with a msgid can be used to generate in-reply-to
352 and reference headers to an earlier mail.
354 WARNING: be careful when using this command. It easily sends
355 out several mails. You might want to run::
357 git config sendemail.confirm always
359 to let ``git send-email`` ask for confirmation before sending any
363 -i base patch generation on index instead of branch
364 -w base patch generation on working tree instead of branch
366 | TODO: ``tg mail patchfile`` to mail an already exported patch
367 | TODO: mailing patch series
368 | TODO: specifying additional options and addresses on command line
372 Register the given remote as TopGit-controlled. This will create
373 the namespace for the remote branch bases and teach ``git fetch``
374 to operate on them. However, from TopGit 0.8 onwards you need to
375 use ``tg push``, or ``git push --mirror``, for pushing
376 TopGit-controlled branches.
378 ``tg remote`` takes an optional remote name argument, and an
379 optional ``--populate`` switch. Use ``--populate`` for your
380 origin-style remotes: it will seed the local topic branch system
381 based on the remote topic branches. ``--populate`` will also make
382 ``tg remote`` automatically fetch the remote, and ``tg update`` look
383 at branches of this remote for updates by default.
387 Show overview of all TopGit-tracked topic branches and their
391 marks the current topic branch
394 indicates that it introduces no changes of its own
397 indicates respectively whether it is local-only
401 indicates respectively if it is ahead or out-of-date
402 with respect to its remote mate
405 indicates that it is out-of-date with respect to its
409 indicates that it has missing dependencies [even if
410 they are recursive ones]
413 indicates that it is out-of-date with respect to
416 This can take a long time to accurately determine all the
417 relevant information about each branch; you can pass ``-t`` to get
418 just a terse list of topic branch names quickly. Alternately,
419 you can pass ``--graphviz`` to get a dot-suitable output to draw a
420 dependency graph between the topic branches.
422 You can also use the ``--sort`` option to sort the branches using
423 a topological sort. This is especially useful if each
424 TopGit-tracked topic branch depends on a single parent branch,
425 since it will then print the branches in the dependency order.
426 In more complex scenarios, a text graph view would be much more
427 useful, but that has not yet been implemented.
429 The --deps option outputs dependency information between
430 branches in a machine-readable format. Feed this to ``tsort`` to
431 get the output from --sort.
434 -i Use TopGit metadata from the index instead of the branch
435 -w Use TopGit metadata from the working tree instead of the branch
437 | TODO: Speed up by an order of magnitude
438 | TODO: Text graph view
442 Switch to a topic branch. You can use ``git checkout <branch>``
443 to get the same effect, but this command helps you navigate
444 the dependency graph, or allows you to match the topic branch
445 name using a regular expression, so it can be more convenient.
447 There following subcommands are available:
450 Check out a branch that directly
451 depends on your current branch.
454 Check out a branch that this branch
457 ``tg checkout goto <pattern>``
458 Check out a topic branch that
459 matches ``<pattern>``. ``<pattern>``
460 is used as a sed pattern to filter
461 all the topic branches.
464 An alias for ``push``.
466 ``tg checkout child``
467 An alias for ``push``.
470 An alias for ``push``.
473 An alias for ``pop``.
475 ``tg checkout parent``
476 An alias for ``pop``.
479 An alias for ``pop``.
481 If any of the above commands can find more than one possible
482 branch to switch to, you will be presented with the matches
483 and ask to select one of them.
485 The ``<pattern>`` of ``tg checkout goto`` is optional. If you don't
486 supply it, all the available topic branches are listed and you
487 can select one of them.
489 Normally, the ``push`` and ``pop`` commands moves one step in
490 the dependency graph of the topic branches. The ``-a`` option
491 causes them (and their aliases) to move as far as possible.
492 That is, ``tg checkout push -a`` moves to a topic branch that
493 depends (directly or indirectly) on the current branch and
494 that no other branch depends on. ``tg checkout pop -a``
495 moves to a regular branch that the current topic branch
496 depends on (directly or indirectly). If there is more than
497 one possibility, you will be prompted for your selection.
501 Export a tidied-up history of the current topic branch and its
502 dependencies, suitable for feeding upstream. Each topic branch
503 corresponds to a single commit or patch in the cleaned up
504 history (corresponding basically exactly to ``tg patch`` output
505 for the topic branch).
507 The command has three possible outputs now -- either a Git branch
508 with the collapsed history, a Git branch with a linearized
509 history, or a quilt series in new directory.
511 In the case where you are producing collapsed history in a new
512 branch, you can use this collapsed structure either for
513 providing a pull source for upstream, or for further
514 linearization e.g. for creation of a quilt series using git log::
516 git log --pretty=email -p --topo-order origin..exported
518 To better understand the function of ``tg export``, consider this
519 dependency structure::
521 origin/master - t/foo/blue - t/foo/red - master
522 `- t/bar/good <,----------'
523 `- t/baz ------------'
525 (where each of the branches may have a hefty history). Then::
527 master$ tg export for-linus
529 will create this commit structure on the branch ``for-linus``::
531 origin/master - t/foo/blue -. merge - t/foo/red -.. merge - master
532 `- t/bar/good <,-------------------'/
533 `- t/baz ---------------------'
535 In this mode, ``tg export`` works on the current topic branch, and
536 can be called either without an option (in that case,
537 ``--collapse`` is assumed), or with the ``--collapse`` option, and
538 with one mandatory argument: the name of the branch where the
539 exported result will be stored.
541 When using the linearize mode::
543 master$ tg export --linearize for-linus
545 you get a linear history respecting the dependencies of your
546 patches in a new branch ``for-linus``. The result should be more
547 or less the same as using quilt mode and then reimporting it
548 into a Git branch. (More or less because the topological order
549 can usually be extended in more than one way into a total order,
550 and the two methods may choose different ones.) The result
551 might be more appropriate for merging upstream, as it contains
554 Note that you might get conflicts during linearization because
555 the patches are reordered to get a linear history.
557 When using the quilt mode::
559 master$ tg export --quilt for-linus
561 would create the following directory ``for-linus``::
563 for-linus/t/foo/blue.diff
564 for-linus/t/foo/red.diff
565 for-linus/t/bar/good.diff
573 With ``--quilt``, you can also pass the ``-b`` parameter followed
574 by a comma-separated explicit list of branches to export, or
575 the ``--all`` parameter (which can be shortened to ``-a``) to
576 export them all. These options are currently only supported
579 In ``--quilt`` mode the patches are named like the originating
580 topgit branch. So usually they end up in subdirectories of the
581 output directory. With the ``--flatten`` option the names are
582 mangled so that they end up directly in the output dir (slashes
583 are substituted by underscores). With the ``--strip[=N]`` option
584 the first ``N`` subdirectories (all if no ``N`` is given) get
585 stripped off. Names are always ``--strip``'d before being
586 ``--flatten``'d. With the option ``--numbered`` (which implies
587 ``--flatten``) the patch names get a number as prefix to allow
588 getting the order without consulting the series file, which
589 eases sending out the patches.
591 | TODO: Make stripping of non-essential headers configurable
592 | TODO: Make stripping of [PATCH] and other prefixes configurable
593 | TODO: ``--mbox`` option to export instead as an mbox file
594 | TODO: support ``--all`` option in other modes of operation
595 | TODO: For quilt exporting, export the linearized history created in
596 a temporary branch--this would allow producing conflict-less
601 Import commits within the given revision range into TopGit,
602 creating one topic branch per commit. The dependencies are set
603 up to form a linear sequence starting on your current branch --
604 or a branch specified by the ``-d`` parameter, if present.
606 The branch names are auto-guessed from the commit messages and
607 prefixed by ``t/`` by default; use ``-p <prefix>`` to specify an
608 alternative prefix (even an empty one).
610 Alternatively, you can use the ``-s NAME`` parameter to specify
611 the name of the target branch; the command will then take one
612 more argument describing a *single* commit to import.
616 Update the current, specified or all topic branches with respect
617 to changes in the branches they depend on and remote branches.
618 This is performed in two phases -- first, changes within the
619 dependencies are merged to the base, then the base is merged
620 into the topic branch. The output will guide you on what to do
621 next in case of conflicts.
623 When ``-a`` is specifed, updates all topic branches matched by
624 ``<pattern>``'s (see ``git-for-each-ref(1)`` for details), or all if
625 no ``<pattern>`` is given.
627 After the update, if a single topic branch was specified, it is
628 left as the current one; if ``-a`` was specified, it returns to
629 the branch which was current at the beginning.
631 If your dependencies are not up-to-date, ``tg update`` will first
632 recurse into them and update them.
634 If a remote branch update brings in dependencies on branches
635 that are not yet instantiated locally, you can either bring in
636 all the new branches from the remote using ``tg remote
637 --populate``, or only pick out the missing ones using ``tg create
638 -r`` (``tg summary`` will point out branches with incomplete
639 dependencies by showing an ``!`` next to them).
641 | TODO: ``tg update -a -c`` to autoremove (clean) up-to-date branches
645 If ``-a`` or ``--all`` was specified, pushes all non-annihilated
646 TopGit-controlled topic branches, to a remote repository.
647 Otherwise, pushes the specified topic branches -- or the
648 current branch, if you don't specify which. By default, the
649 remote gets all the dependencies (both TopGit-controlled and
650 non-TopGit-controlled) and bases pushed to it too. If
651 ``--tgish-only`` was specified, only TopGit-controlled
652 dependencies will be pushed, and if ``--no-deps`` was specified,
653 no dependencies at all will be pushed.
655 The remote may be specified with the ``-r`` option. If no remote
656 was specified, the configured default TopGit remote will be
661 Prints the base commit of each of the named topic branches, or
662 the current branch if no branches are named. Prints an error
663 message and exits with exit code 1 if the named branch is not
668 Prints the git log of the named topgit branch -- or the current
669 branch, if you don't specify a name.
671 NOTE: if you have merged changes from a different repository, this
672 command might not list all interesting commits.
676 Outputs the direct dependencies for the current or named branch.
679 -i show dependencies based on index instead of branch
680 -w show dependencies based on working tree instead of branch
684 Outputs all branches which directly depend on the current or
688 -i show dependencies based on index instead of branch
689 -w show dependencies based on working tree instead of branch
697 TopGit stores all the topic branches in the regular ``refs/heads/``
698 namespace (so we recommend distinguishing them with the ``t/`` prefix).
699 Apart from that, TopGit also maintains a set of auxiliary refs in
700 ``refs/top-*``. Currently, only ``refs/top-bases/`` is used, containing the
701 current *base* of the given topic branch -- this is basically a merge of
702 all the branches the topic branch depends on; it is updated during ``tg
703 update`` and then merged to the topic branch, and it is the base of a
704 patch generated from the topic branch by ``tg patch``.
706 All the metadata is tracked within the source tree and history of the
707 topic branch itself, in ``.top*`` files; these files are kept isolated
708 within the topic branches during TopGit-controlled merges and are of
709 course omitted during ``tg patch``. The state of these files in base
710 commits is undefined; look at them only in the topic branches
711 themselves. Currently, two files are defined:
714 Contains the description of the topic branch in a
715 mail-like format, plus the author information, whatever
716 Cc headers you choose or the post-three-dashes message.
717 When mailing out your patch, basically only a few extra
718 mail headers are inserted and then the patch itself is
719 appended. Thus, as your patches evolve, you can record
720 nuances like whether the particular patch should have
721 To-list / Cc-maintainer or vice-versa and similar
722 nuances, if your project is into that. ``From`` is
723 prefilled from your current ``GIT_AUTHOR_IDENT``; other
724 headers can be prefilled from various optional
725 ``topgit.*`` git config options.
728 Contains the one-per-line list of branches this branch
729 depends on, pre-seeded by `tg create`. A (continuously
730 updated) merge of these branches will be the *base* of
733 IMPORTANT: DO NOT EDIT ``.topdeps`` MANUALLY!!! If you do so, you need to
734 know exactly what are you doing, since this file must stay in sync with
735 the Git history information, otherwise very bad things will happen.
737 TopGit also automagically installs a bunch of custom commit-related
738 hooks that will verify whether you are committing the ``.top*`` files in a
739 sane state. It will add the hooks to separate files within the ``hooks/``
740 subdirectory, and merely insert calls to them to the appropriate hooks
741 and make them executable (but will make sure the original hook's code is
742 not called if the hook was not executable beforehand).
744 Another automagically installed piece is a ``.git/info/attributes``
745 specifier for an ``ours`` merge strategy for the files ``.topmsg`` and
746 ``.topdeps``, and the (intuitive) ``ours`` merge strategy definition in
753 There are two remaining issues with accessing topic branches in remote
756 (i) Referring to remote topic branches from your local repository
757 (ii) Developing some of the remote topic branches locally
759 There are two somewhat contradictory design considerations here:
761 (a) Hacking on multiple independent TopGit remotes in a single
763 (b) Having a self-contained topic system in local refs space
765 To us, (a) does not appear to be very convincing, while (b) is quite
766 desirable for ``git-log topic`` etc. working, and increased conceptual
769 Thus, we choose to instantiate all the topic branches of given remote
770 locally; this is performed by ``tg remote --populate``. ``tg update``
771 will also check if a branch can be updated from its corresponding remote
772 branch. The logic needs to be somewhat involved if we are to "do the
773 right thing". First, we update the base, handling the remote branch as
774 if it was the first dependency; thus, conflict resolutions made in the
775 remote branch will be carried over to our local base automagically.
776 Then, the base is merged into the remote branch and the result is merged
777 to the local branch -- again, to carry over remote conflict resolutions.
778 In the future, this order might be adjustable on a per-update basis, in
779 case local changes happen to be diverging more than the remote ones.
781 All commands by default refer to the remote that ``tg remote --populate``
782 was called on the last time (stored in the ``topgit.remote`` git
783 configuration variable). You can manually run any command with a
784 different base remote by passing ``-r REMOTE`` *before* the subcommand
791 The following references are useful to understand the development of
792 topgit and its subcommands.
795 http://lists-archives.org/git/688698-add-list-and-rm-sub-commands-to-tg-depend.html
801 The following software understands TopGit branches:
803 * `magit <http://magit.github.io/>`_ -- a git mode for emacs
805 IMPORTANT: Magit requires its topgit mode to be enabled first, as
806 described in its documentation, in the "Activating extensions"
807 subsection. If this is not done, it will not push TopGit branches
808 correctly, so it's important to enable it even if you plan to mostly use
809 TopGit from the command line.