{"thread":{"id":"6677","subject":"Use of \"stg sync\"","startedAt":"2007-02-04T14:42:33Z","lastAt":"2007-02-06T10:07:15Z","messageCount":2,"participants":["Yann Dirson","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33573","messageId":"20070204144233.GP5362@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6677","inReplyTo":null,"subject":"Use of \"stg sync\"","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-02-04T14:42:33Z","receivedAt":"2007-02-04T14:42:33Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Hi,\n\nIn the context of Debian packaging, I have a tree with an \"upstream\"\nbranch, and 2 stgit stack, one for maintainance (\"etch\") and one for\nthe next Debian version (\"lenny\").  I maintain them as stgit stacks to\nbe able to easily port changes to new upstream releases, and tag\ndebian revisions on the stack heads - so the ancestry of a revision to\nthe previous can only be tracked through stgit patch logs.\n\nThe recent history of those stack is a bit tricky, and that may not\nhelp here: there was originally a single \"debian\" stack, and I had\nalready done some unreleased work in existing patches, when the need\nfor a bugfix release appeared.  So I cloned the \"main\" branch, and\nreproduced the previous release by deleting the only patch that had\nmoved since the last release, and picking it from the relevant commit.\n\nThen to make things more interresting I imported a new release on\n\"upstream\", and rebased stack \"lenny\" onto this new release.\n\nThen I wanted to integrate the bugfix from \"etch\" into \"lenny\".  So I\njust tried to use \"stg sync\" on this patch.  It should be noted that\nthis particular patch is the one that adds the Debian packaging files\n(as opposed to the other ones, which modify the upstream source\nfiles).\n\nHere is what I get.  I suppose that could have been expected, but that\nlooks nevertheless annoying...\n\ntau-git$ stg sync -b etch debian\nChecking for changes in the working directory... done\nSynchronising \"debian\"...Error: File \"debian/tau.files\" added in branches but different\nError: File \"debian/tau-racy.files\" added in branches but different\nError: File \"debian/rules\" added in branches but different\nError: File \"debian/changelog\" added in branches but different\nstg sync: GIT index merging failed (possible conflicts)\n\nTraceback (most recent call last):\n  File \"/export/work/yann/git/stgit/stg\", line 43, in ?\n    main()\n  File \"/export/work/yann/git/stgit/stgit/main.py\", line 268, in main\n    command.func(parser, options, args)\n  File \"/export/work/yann/git/stgit/stgit/commands/sync.py\", line 163, in func\n    merge_patch(patch, p)\n  File \"/export/work/yann/git/stgit/stgit/commands/sync.py\", line 96, in <lambda>\n    merge_patch = lambda patch, pname: \\\n  File \"/export/work/yann/git/stgit/stgit/commands/sync.py\", line 58, in __branch_merge_patch\n    git.merge(patch.get_bottom(), git.get_head(), patch.get_top())\n  File \"/export/work/yann/git/stgit/stgit/git.py\", line 664, in merge\n    raise GitException, 'GIT index merging failed (possible conflicts)'\nstgit.git.GitException: GIT index merging failed (possible conflicts)\n\nbest regards,\n-- \nYann.\n"},{"id":"33710","messageId":"b0943d9e0702060207v3a6ed16fs61feb34f03211a6@mail.gmail.com","threadId":"6677","inReplyTo":"20070204144233.GP5362@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Use of \"stg sync\"","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-02-06T10:07:15Z","receivedAt":"2007-02-06T10:07:15Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 04/02/07, Yann Dirson <ydirson@altern.org> wrote:\n[...]\n> Then I wanted to integrate the bugfix from \"etch\" into \"lenny\".  So I\n> just tried to use \"stg sync\" on this patch.  It should be noted that\n> this particular patch is the one that adds the Debian packaging files\n> (as opposed to the other ones, which modify the upstream source\n> files).\n>\n> Here is what I get.  I suppose that could have been expected, but that\n> looks nevertheless annoying...\n\nHave you modified the last try/except block in stgit.main.main? You\nshould only get an error message, not the full backtrace.\n\nThe interesting messages are:\n\n> Synchronising \"debian\"...Error: File \"debian/tau.files\" added in branches but different\n> Error: File \"debian/tau-racy.files\" added in branches but different\n> Error: File \"debian/rules\" added in branches but different\n> Error: File \"debian/changelog\" added in branches but different\n> stg sync: GIT index merging failed (possible conflicts)\n\nWhich are what I would expect the 'sync' command to do - it tries a\nthree-way merge between the debian//top, debian@etch//top and\ndebian@etch//bottom (the order is probably different). Since the\ndebian/rules etc. files aren't present in debian@etch//bottom and you\nmodified them in debian@etch//top, you get a merge conflict - files\nadded in both branches but different.\n\n'stg status' should show the conflict files and you have to manually\nfix them. If you know that you only modified the patch in etch, you\ncan do 'stg resolved -a -r patched'. You could also add 'recursive =\nTrue' argument to the git.merge() call in\nstgit.commands.sync.__branch_merge_patch(). This would perform a merge\nwith 'git-merge-recursive' rather than 'git-read-tree -m' and it is\nsupposed to do a smarter two-way merging. You might not get a conflict\nat all or, at least, the conflicted file would have some markers.\n\nThe reason I didn't add the recursive merge for 'sync' was the\nslowness of this operation (git-read-tree -m was faster but maybe\ngit-merge-recursive was improved in the last weeks). Please try this\nand let me know whether you get better results so I can modify the\n'sync' command.\n\nAnyway, this is a limitation of 'sync' three-way merging and I\ncouldn't find an easy solution. For me, the best thing is that if the\npatch was synchronised, there won't be any conflicts reported and I\ncan be sure they are the same. You mentioned patches of patches some\ntime ago but these would get lost on the first rebase (unless you want\nto have a patch made of sub-stacks but you get to a fractal structure\nwith sub-sub-...-sub-stacks :-))\n\n-- \nCatalin\n"}]}