{"thread":{"id":"5975","subject":"StGIT and rerere","startedAt":"2006-10-20T22:39:09Z","lastAt":"2006-10-26T17:21:55Z","messageCount":3,"participants":["Robin Rosenberg","Junio C Hamano","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29428","messageId":"200610210039.10215.robin.rosenberg.lists@dewire.com","threadId":"5975","inReplyTo":null,"subject":"StGIT and rerere","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-10-20T22:39:09Z","receivedAt":"2006-10-20T22:39:09Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Hi,\n\nIt seems stgit does not use git-rerere, so why not? Any reason other than it\nhasn't been done yet?\n\nI abuse stgit heavily, by frequently reording patches, which for some patches\nresult in re-occuring conflicts. git-rerere seems to be the solution.\n\nWhat's the \"rules\" for when to invoke rerere? It seems it is mostly automatic \nin git, but since only the porcelainish commands use it, that means StGIT \ndoesn't.\n\nSo here is what I *think* needs to be done. Seems simple enough.\n\nstg push, stg pick, stg import, stg goto, stg fold, stg float\n\tdo what push does and invoke git-rerere at the end whether the push ends with \nconflicts or not\n\nstg pop\n\tnothing, or do I need to remove rr-cache/MERGE_RR, like git-reset does?\n\nstg status --reset, stg push --undo\n\tremove rr-cache/MERGE_RR ?\n\nstg refresh\n\tdo what stgit does normally and then invoke git-rerere\n\nstg resolved:\n\tdo what stgit does normally and then invoke git-rerere\n\nstg clean, stge delete:\n\tremove rr-cache/MERGE_RR ?\n\nAnything else or comments on this list?\n\n-- robin\n"},{"id":"297916","messageId":"tnxu01r2fzv.fsf@arm.com","threadId":"5975","inReplyTo":"200610210039.10215.robin.rosenberg.lists@dewire.com","subject":"Re: StGIT and rerere","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-10-26T16:34:12Z","receivedAt":"2006-10-26T16:34:12Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:\n> It seems stgit does not use git-rerere, so why not? Any reason other\n> than it hasn't been done yet?\n\nI didn't know it exists. I've been thinking at a way to avoid\nduplicating the conflict fixing but haven't got to any results. This\nlooks like a good idea.\n\n> I abuse stgit heavily, by frequently reording patches, which for\n> some patches result in re-occuring conflicts. git-rerere seems to be\n> the solution.\n\nMy problem was with maintaining a public branch where re-basing\npatches is not welcomed but I would still like to use StGIT in my\ndevelopment branch. When pulling from upstream in my devel branch, I\nget conflicts in some patches. The problem is that I get the same\nconflicts in the patches already merged in the public branch where the\npatches were previously checked in.\n\nAnother case is several branches with common patches that generate\nconflicts.\n\n> What's the \"rules\" for when to invoke rerere? It seems it is mostly\n> automatic in git, but since only the porcelainish commands use it,\n> that means StGIT doesn't.\n\nIt could probably be invoked by stgit.git.merge() if the git-read-tree\n(and maybe the diff3 merge) failed (BTW, I replaced git-read-tree with\ngit-recursive-merge in my local tree and seems to detect renames\nproperly; I'll push it once I'm convinced there are no problems).\n\nNote, however, that I haven't looked at how git-rerere works and I\nmight have misunderstood its functionality.\n\n> So here is what I *think* needs to be done. Seems simple enough.\n>\n> stg push, stg pick, stg import, stg goto, stg fold, stg float do\n> what push does and invoke git-rerere at the end whether the push\n> ends with conflicts or not\n\nthe git.merge() function handles all the merges.\n\n> stg pop\n> \tnothing, or do I need to remove rr-cache/MERGE_RR, like\n> git-reset does?\n\nI think pop shouldn't do anything.\n\n> stg status --reset, stg push --undo\n> \tremove rr-cache/MERGE_RR ?\n\nYes (not sure for push --undo).\n\n> stg refresh\n> \tdo what stgit does normally and then invoke git-rerere\n\nWhy should it invoke git-rerere? This just creates a commit. Or is it\nneeded for storing rerere ids?\n\n> stg resolved:\n> \tdo what stgit does normally and then invoke git-rerere\n\nNo need to call rerere here since resolved is an StGIT-only function,\nit doesn't affect the repository (it just unmarks the conflict files\nso that stgit allows you to refresh).\n\n> stg clean, stge delete:\n> \tremove rr-cache/MERGE_RR ?\n\nThat's not needed. Delete can act like pop for the top patch.\n\n-- \n"},{"id":"297010","messageId":"7vfydbkn64.fsf@assigned-by-dhcp.cox.net","threadId":"5975","inReplyTo":"tnxu01r2fzv.fsf@arm.com","subject":"Re: StGIT and rerere","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T17:21:55Z","receivedAt":"2006-10-26T17:21:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@arm.com> writes:\n\n> I didn't know it exists. I've been thinking at a way to avoid\n> duplicating the conflict fixing but haven't got to any results. This\n> looks like a good idea.\n> ...\n> My problem was with maintaining a public branch where re-basing\n> patches is not welcomed but I would still like to use StGIT in my\n> development branch. When pulling from upstream in my devel branch, I\n> get conflicts in some patches. The problem is that I get the same\n> conflicts in the patches already merged in the public branch where the\n> patches were previously checked in.\n>\n> Another case is several branches with common patches that generate\n> conflicts.\n> ...\n> Note, however, that I haven't looked at how git-rerere works and I\n> might have misunderstood its functionality.\n\nI think Documentation/git-rerere.txt describes its operation in\nenough details for the end user, but if there is anything\nunclear please ask away.\n\nThere are two details that are not mentoined in the end-user\ndocumentation.\n\n* Identifying \"same\" conflicts.\n\nThis is done by hashing the text inside the conflict markers:\n\n\t<<<<<<<\n        a\n        =======\n\tb\n        >>>>>>>\n\nEach conflicted section like the above are first canonicalized\nso that section \"a\" sorts alphabetically earlier than section\n\"b\" (in other words, if the conflict were <<< b === a >>> then\nthey are swapped to read <<< a === b >>>), concatenated and fed\ninto SHA-1 digest.  The final digest after conflicted file is\nread as a whole becomes the name of the conflict, and naming is\ndone per file.\n\nThe reason for this canonicalization is because the order in the\nconflicted section depends on the direction of the merge (if\nyou pull test into master you get the conflict marked the other\nway from the case you pulled master into test).\n\n* rerere's resolution can affect outside conflict markers.\n\nIf an earlier conflict read like this:\n\n\t...\n\tz\n\t<<<<<<<\n        a\n        =======\n        b\n        >>>>>>>\n        c\n\td\n\te\n        f\n        g\n\t...\n        \nand your earlier resolution was like this:\n\n\t...\n\tw\n        b\n        dd\n        e\n        f\n        g\n\t...\n\nThat is what rerere records (i.e. including removal of c and\nchange from z to w).\n\nThen, when you see the same conflict like this (notice that g is\nnow h):\n\n\t...\n\tz\n\t<<<<<<<\n        a\n        =======\n        b\n        >>>>>>>\n        c\n\td\n\te\n        f\n        h\n\t...\n\nit is resolved like this:\n\n\t...\n\tw\n        b\n        d\n        e\n        f\n        h\n\t...\n\nThis is often useful when e.g. a <<< === >>> section changes\nfunction signature of a (static) function; parts outside the\nconflicted section needs matching changes to adjust to it and\nthat is recorded and replayed by rerere.\n"}]}