{"thread":{"id":"8297","subject":"StGIT and conflicts","startedAt":"2007-05-24T16:40:38Z","lastAt":"2007-05-25T12:45:58Z","messageCount":3,"participants":["Karl Hasselström","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43146","messageId":"20070524164038.GA27661@diana.vm.bytemark.co.uk","threadId":"8297","inReplyTo":null,"subject":"StGIT and conflicts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-24T16:40:38Z","receivedAt":"2007-05-24T16:40:38Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"The current behavior of StGIT is to not use the index for conflicts\nlike git does. What advantages does this have that are great enough to\nmotivate a deviation from the git behavior?\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"43226","messageId":"b0943d9e0705250300o419d1d7ld175b273dbed2429@mail.gmail.com","threadId":"8297","inReplyTo":"20070524164038.GA27661@diana.vm.bytemark.co.uk","subject":"Re: StGIT and conflicts","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-05-25T10:00:33Z","receivedAt":"2007-05-25T10:00:33Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 24/05/07, Karl Hasselström <kha@treskal.com> wrote:\n> The current behavior of StGIT is to not use the index for conflicts\n> like git does. What advantages does this have that are great enough to\n> motivate a deviation from the git behavior?\n\nI don't think there are any advantages in deviating from the git\nbehaviour, only that when I first implementing it, git didn't have any\nsmarter behaviour and I used diff3 (or other external merger, which\ncan be used right now as well).\n\nI'm not sure if git-diff still works when there are conflicts in the\nindex. The current stg behaviour is to reset the index to the base of\nthe patch and a stg diff would show the diff (including the config\nmarkers) to the base. I find this quite handy.\n\n-- \nCatalin\n"},{"id":"43237","messageId":"20070525124558.GA11096@diana.vm.bytemark.co.uk","threadId":"8297","inReplyTo":"b0943d9e0705250300o419d1d7ld175b273dbed2429@mail.gmail.com","subject":"Re: StGIT and conflicts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-25T12:45:58Z","receivedAt":"2007-05-25T12:45:58Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-25 11:00:33 +0100, Catalin Marinas wrote:\n\n> On 24/05/07, Karl Hasselström <kha@treskal.com> wrote:\n>\n> > The current behavior of StGIT is to not use the index for\n> > conflicts like git does. What advantages does this have that are\n> > great enough to motivate a deviation from the git behavior?\n>\n> I don't think there are any advantages in deviating from the git\n> behaviour, only that when I first implementing it, git didn't have\n> any smarter behaviour and I used diff3 (or other external merger,\n> which can be used right now as well).\n>\n> I'm not sure if git-diff still works when there are conflicts in the\n> index. The current stg behaviour is to reset the index to the base\n> of the patch and a stg diff would show the diff (including the\n> config markers) to the base. I find this quite handy.\n\nTo be honest, I'm not very well versed in how git handles merge\nconflicts -- with all the nontrivial projects I touch, I use StGIT for\neverything that can conflict. :-) Grepping for \"conflict\" in the user\nmanual brings up a very good explanation, though; and to answer your\nquestion: it seems to work very well indeed, surprise surprise. You\ncan make the diff show anything you want, including between the patch\nbase and the working dir. Though, as the manual points out, the most\nimportant view is probably between index and working tree, which shows\nyou just the not-yet-fixed conflicts.\n\nStep one would be to simply stop messing with the index after merges,\nand just let \"stg resolved\" mean \"git add\".\n\nStep two (somewhat more ambitious) might be to stop trying to hide the\nindex, by providing a flag to \"stg refresh\" to make it refresh only\nwhat's in the index, and not everything -- that is, to make it do what\n\"git commit\" does when _not_ given the -a flag. And once we stop\nhiding the index, there's no point in having StGIT commands to do\nthings like add, remove, and so on -- we could just use what git\nprovides.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"}]}