{"thread":{"id":"1993","subject":"[ANNOUNCE] Stacked GIT 0.7","startedAt":"2005-10-02T09:17:07Z","lastAt":"2005-10-03T14:44:12Z","messageCount":5,"participants":["Catalin Marinas","Ingo Molnar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9601","messageId":"1128244627.9740.6.camel@localhost.localdomain","threadId":"1993","inReplyTo":null,"subject":"[ANNOUNCE] Stacked GIT 0.7","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-02T09:17:07Z","receivedAt":"2005-10-02T09:17:07Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Stacked GIT 0.7 release is available from http://www.procode.org/stgit/\n\nStGIT is a Python application providing similar functionality to Quilt\n(i.e. pushing/popping patches to/from a stack) on top of GIT. These\noperations are performed using GIT commands and the patches are stored\nas GIT commit objects, allowing easy merging of the StGIT patches into\nother repositories using standard GIT functionality.\n\nWhat's new in this release (the full ChangeLog is in the archive):\n\n      * Uses the renamed GIT commands (requires GIT >= 0.99.7) \n      * 'pick' command to cherry-pick a commit object as an StGIT patch\n        using a three-way merge. It also allows reverse-applying \n      * 'commit' command to permanently store the applied patches into\n        the repository \n      * 'push' can now fast-forward the patches if the base tree object\n        has not changed \n      * The configuration file supports the 'editor' field \n      * '--version' option for the 'mail' command to generate the e-mail\n        subject in the form '[PATCH version nr/total]' \n      * '--showpatch' option for 'refresh' to show the patch content\n        when editing the patch description \n      * '--branch' option for several commands to work on a given branch\n        instead of the current one without switching \n      * the 'pull' command was updated to follow the 'git pull' API \n      * '--base' option for 'import' to import a diff file on a\n        different base and perform a three-way merge with the HEAD\n        afterwards \n      * Support for the '.gitignore' file \n      * Several other optimisations \n      * Bug fixes\n\nMany thanks to Paolo 'Blaisorblade' Giarrusso, Chuck Lever, Pierre\nOssman and Junio C Hamano for contributing patches to this release.\n\n-- \nCatalin\n"},{"id":"9610","messageId":"20051002121059.GA32367@elte.hu","threadId":"1993","inReplyTo":"1128244627.9740.6.camel@localhost.localdomain","subject":"Re: [ANNOUNCE] Stacked GIT 0.7","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-10-02T12:10:59Z","receivedAt":"2005-10-02T12:10:59Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Catalin Marinas <catalin.marinas@gmail.com> wrote:\n\n> Stacked GIT 0.7 release is available from \n> http://www.procode.org/stgit/\n> \n> StGIT is a Python application providing similar functionality to Quilt \n> (i.e. pushing/popping patches to/from a stack) on top of GIT. These \n> operations are performed using GIT commands and the patches are stored \n> as GIT commit objects, allowing easy merging of the StGIT patches into \n> other repositories using standard GIT functionality.\n\ni'm wondering - have you (or anyone else) done performance comparisons \nof quilt vs. stgit, using the same stack of patches? One of the most \nimportant features of quilt (for me) is that it's very fast at \npopping/pushing through hundreds of patches.\n\n\tIngo\n"},{"id":"9614","messageId":"b0943d9e0510021233n39daa5bao@mail.gmail.com","threadId":"1993","inReplyTo":"20051002121059.GA32367@elte.hu","subject":"Re: [ANNOUNCE] Stacked GIT 0.7","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-02T19:33:54Z","receivedAt":"2005-10-02T19:33:54Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 02/10/05, Ingo Molnar <mingo@elte.hu> wrote:\n> i'm wondering - have you (or anyone else) done performance comparisons\n> of quilt vs. stgit, using the same stack of patches? One of the most\n> important features of quilt (for me) is that it's very fast at\n> popping/pushing through hundreds of patches.\n\nI've done some basic comparison and I must admit that Quilt is much\nfaster than StGIT. Popping is done in O(1) and it is equivalent to a\nswitch between two branches with 'git checkout' (can be less than 2\nseconds with warm caches). Pushing without merging required (i.e.\nfast-forwarding) is the same as popping.\n\nWhat's time consuming is pushing when the base of the stack was\nchanged and merging is required. If the base changes do not involve\nfile removals/additions, a push operations takes ~1.5s per patch with\nwarm caches. Most of the time is spent in \"git-read-tree -m\" (StGIT\ndoesn't consume resources since it mainly calls GIT tools). If the\nbase changes involve file removals/additions, it can take considerably\nlonger since for each file GIT needs to call an external merger. This\ncould be solved by providing a smarter git-merge-index to deal with\nfile removals/additions but the time won't be shorter than ~1.5s per\npatch.\n\nAn optimisation would be to keep the patches in diff format and apply\nthem but this would mean losing the advantages of the three-way\nmerging. Another issue is that git-apply doesn't support fuzzy\npatches, though I could emulate it using patch. But I'm not sure\nthat's a good approach since I don't intend to re-write Quilt in\nPython. My hope is that git-read-tree will get faster :-).\n\n--\nCatalin\n"},{"id":"9627","messageId":"b0943d9e0510030656l4535bec7u@mail.gmail.com","threadId":"1993","inReplyTo":"b0943d9e0510021233n39daa5bao@mail.gmail.com","subject":"Re: [ANNOUNCE] Stacked GIT 0.7","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-03T13:56:39Z","receivedAt":"2005-10-03T13:56:39Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 02/10/05, Catalin Marinas <catalin.marinas@gmail.com> wrote:\n> An optimisation would be to keep the patches in diff format and apply\n> them but this would mean losing the advantages of the three-way\n> merging.\n\nAfter some tests, it looks like 'git-diff-tree -p ... | git-apply\n--index' is about 3 times faster than 'git-read-tree -m' (in the best\ncase for git-read-tree with minor modifications of the base). It now\ntakes ~0.5s to push a single patch (compared to ~1.5s).\n\nSince most of the patches, for routine updates of the base, don't\ngenerate conflicts, git-apply should work fine. I'll modify StGIT to\nuse this method by default and fall back to the three-way merge in\ncase it fails. This will also solve the problem with complex\nmodifications of the base of the stack (i.e. file removals/additions)\nwhen there won't be any need to call the external index merger if\ngit-apply succeeds.\n\n--\nCatalin\n"},{"id":"9628","messageId":"tnxpsqmwthf.fsf@arm.com","threadId":"1993","inReplyTo":"b0943d9e0510030656l4535bec7u@mail.gmail.com","subject":"Re: [ANNOUNCE] Stacked GIT 0.7","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-03T14:44:12Z","receivedAt":"2005-10-03T14:44:12Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Catalin Marinas <catalin.marinas@gmail.com> wrote:\n> After some tests, it looks like 'git-diff-tree -p ... | git-apply\n> --index' is about 3 times faster than 'git-read-tree -m' (in the best\n> case for git-read-tree with minor modifications of the base). It now\n> takes ~0.5s to push a single patch (compared to ~1.5s).\n\nAnd that's the patch for whoever wants to try. I will also add it to\nthe repository tonight:\n\n\nOptimise 'push' to use git-apply instead of git-read-tree\n\nWith this patch, 'push' will use 'git-diff-tree | git-apply' first. If this\noperation fails, it will fall back to the three-way merge with\ngit-read-tree.\n\nSigned-off-by: Catalin Marinas <catalin.marinas@gmail.com>\n---\n\n stgit/git.py   |    9 +++++++++\n stgit/stack.py |   19 +++++++++++--------\n 2 files changed, 20 insertions(+), 8 deletions(-)\n\ndiff --git a/stgit/git.py b/stgit/git.py\n--- a/stgit/git.py\n+++ b/stgit/git.py\n@@ -355,6 +355,15 @@ def commit(message, files = [], parents \n \n     return commit_id\n \n+def apply_diff(rev1, rev2):\n+    \"\"\"Apply the diff between rev1 and rev2 onto the current\n+    index. This function doesn't need to raise an exception since it\n+    is only used for fast-pushing a patch. If this operation fails,\n+    the pushing would fall back to the three-way merge.\n+    \"\"\"\n+    return os.system('git-diff-tree -p %s %s | git-apply --index 2> /dev/null'\n+                     % (rev1, rev2)) == 0\n+\n def merge(base, head1, head2):\n     \"\"\"Perform a 3-way merge between base, head1 and head2 into the\n     local tree\ndiff --git a/stgit/stack.py b/stgit/stack.py\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -598,14 +598,17 @@ class Series:\n             # The current patch is empty after merge.\n             patch.set_bottom(head, backup = True)\n             patch.set_top(head, backup = True)\n-            # merge/refresh can fail but the patch needs to be pushed\n-            try:\n-                git.merge(bottom, head, top)\n-            except git.GitException, ex:\n-                print >> sys.stderr, \\\n-                      'The merge failed during \"push\". ' \\\n-                      'Use \"refresh\" after fixing the conflicts'\n-                pass\n+\n+            # Try the fast applying first. If this fails, fall back to the\n+            # three-way merge\n+            if not git.apply_diff(bottom, top):\n+                # merge can fail but the patch needs to be pushed\n+                try:\n+                    git.merge(bottom, head, top)\n+                except git.GitException, ex:\n+                    print >> sys.stderr, \\\n+                          'The merge failed during \"push\". ' \\\n+                          'Use \"refresh\" after fixing the conflicts'\n \n         append_string(self.__applied_file, name)\n \n\n\n-- \nCatalin\n"}]}