{"thread":{"id":"55666","subject":"Rebase Question","startedAt":"2021-05-12T00:07:00Z","lastAt":"2021-05-12T07:23:43Z","messageCount":6,"participants":["Andrew Ottaviano","Jacob Keller","Bryan Turner","Jeff King","Junio C Hamano","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"424230","messageId":"MN2PR07MB59526F40B255183931649AD19C529@MN2PR07MB5952.namprd07.prod.outlook.com","threadId":"55666","inReplyTo":null,"subject":"Rebase Question","fromName":"Andrew Ottaviano","fromEmail":"andrew_o1995@live.com","sentAt":"2021-05-12T00:06:57Z","receivedAt":"2021-05-12T00:07:00Z","isPatch":false,"sender":{"key":"andrew_o1995@live.com","avatar":null},"body":"Hello all! \n \nI’ve used git for a few years now and I\nthink it is an amazing tool! Thank you for your hard work in\ndeveloping/maintaining it! I really appreciate it! \n \nI have a question. Let’s say that my\ncolleague and I branch off of master and are working. Let’s say I’m 5 commits\nahead of master and my colleague merges in ahead of me. The logical thing in my\nmind is to rebase off of master. The difficulty with this is that if I have\nmerge conflicts that show up on my first commit, I have to resolve that stupid\nthing for every subsequent commit. I could squash, but then I loose branch\nhistory, so I don’t really want to do that. I could rebase in interactive mode,\nbut if I recall, I still need to resolve all the conflicts on every commit\nbefore it squashes. \n \nThe solution that I thought of is instead\nof resolving conflicts from the bottom up (starting with earliest history),\nresolving from the top down (latest to earliest) and resolving the conflict in\nthe commit it occurred. If that doesn’t work (or I guess it might be the same\nas a merge of master into my branch), then couldn’t git at least store the\nconflict resolution? \n \nMaybe I’m silly for asking this question,\nI just really like rebase because it is so clean and this is my one frustration\nwith this method. \n\n\nThanks for humoring me 😊 \nAndrew Ottaviano \n"},{"id":"424231","messageId":"CA+P7+xraXVhvjNhJqrzDGNh=RZqC0HnKLBved+7RukC9pmMthQ@mail.gmail.com","threadId":"55666","inReplyTo":"MN2PR07MB59526F40B255183931649AD19C529@MN2PR07MB5952.namprd07.prod.outlook.com","subject":"Re: Rebase Question","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2021-05-12T00:23:13Z","receivedAt":"2021-05-12T00:23:27Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, May 11, 2021 at 5:08 PM Andrew Ottaviano wrote:\n>\n> Hello all!\n>\n> I’ve used git for a few years now and I\n> think it is an amazing tool! Thank you for your hard work in\n> developing/maintaining it! I really appreciate it!\n>\n> I have a question. Let’s say that my\n> colleague and I branch off of master and are working. Let’s say I’m 5 commits\n> ahead of master and my colleague merges in ahead of me. The logical thing in my\n> mind is to rebase off of master. The difficulty with this is that if I have\n> merge conflicts that show up on my first commit, I have to resolve that stupid\n> thing for every subsequent commit. I could squash, but then I loose branch\n> history, so I don’t really want to do that. I could rebase in interactive mode,\n> but if I recall, I still need to resolve all the conflicts on every commit\n> before it squashes.\n>\n> The solution that I thought of is instead\n> of resolving conflicts from the bottom up (starting with earliest history),\n> resolving from the top down (latest to earliest) and resolving the conflict in\n> the commit it occurred. If that doesn’t work (or I guess it might be the same\n> as a merge of master into my branch), then couldn’t git at least store the\n> conflict resolution?\n\nYou might try looking at git imerge for this\nhttps://github.com/mhagger/git-imerge\n\nIt resolves conflicts by doing incremental merges, and then you can\nhave an option to produce the end result of a merge or a rebase.\n\n>\n> Maybe I’m silly for asking this question,\n> I just really like rebase because it is so clean and this is my one frustration\n> with this method.\n>\n\nIt's definitely a potential frustration that can occur during large\nrebases like this.\n\nThanks,\nJake\n\n>\n> Thanks for humoring me\n> Andrew Ottaviano\n"},{"id":"424232","messageId":"CAGyf7-GEA0mtxUxqEjYsfqM4Te-5JO5_nW0S6Vitdmywz1J7mg@mail.gmail.com","threadId":"55666","inReplyTo":"MN2PR07MB59526F40B255183931649AD19C529@MN2PR07MB5952.namprd07.prod.outlook.com","subject":"Re: Rebase Question","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2021-05-12T00:29:03Z","receivedAt":"2021-05-12T00:29:16Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Tue, May 11, 2021 at 5:07 PM Andrew Ottaviano wrote:\n>\n> Hello all!\n>\n> I’ve used git for a few years now and I\n> think it is an amazing tool! Thank you for your hard work in\n> developing/maintaining it! I really appreciate it!\n>\n> I have a question. Let’s say that my\n> colleague and I branch off of master and are working. Let’s say I’m 5 commits\n> ahead of master and my colleague merges in ahead of me. The logical thing in my\n> mind is to rebase off of master. The difficulty with this is that if I have\n> merge conflicts that show up on my first commit, I have to resolve that stupid\n> thing for every subsequent commit. I could squash, but then I loose branch\n> history, so I don’t really want to do that. I could rebase in interactive mode,\n> but if I recall, I still need to resolve all the conflicts on every commit\n> before it squashes.\n\nHave you investigated git rerere[1] at all? Documentation indicates it\nworks for rebase as well as merge, so it might be possible to train\nthat to resolve the conflicts.\n\n[1] https://git-scm.com/docs/git-rerere\n\n(Pardon the re-send; Gmail being trash.)\n"},{"id":"424236","messageId":"YJsk49WBd27NrCAA@coredump.intra.peff.net","threadId":"55666","inReplyTo":"CAGyf7-GEA0mtxUxqEjYsfqM4Te-5JO5_nW0S6Vitdmywz1J7mg@mail.gmail.com","subject":"Re: Rebase Question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-12T00:44:19Z","receivedAt":"2021-05-12T00:44:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 11, 2021 at 05:29:03PM -0700, Bryan Turner wrote:\n\n> On Tue, May 11, 2021 at 5:07 PM Andrew Ottaviano wrote:\n> >\n> > Hello all!\n> >\n> > I’ve used git for a few years now and I\n> > think it is an amazing tool! Thank you for your hard work in\n> > developing/maintaining it! I really appreciate it!\n> >\n> > I have a question. Let’s say that my\n> > colleague and I branch off of master and are working. Let’s say I’m 5 commits\n> > ahead of master and my colleague merges in ahead of me. The logical thing in my\n> > mind is to rebase off of master. The difficulty with this is that if I have\n> > merge conflicts that show up on my first commit, I have to resolve that stupid\n> > thing for every subsequent commit. I could squash, but then I loose branch\n> > history, so I don’t really want to do that. I could rebase in interactive mode,\n> > but if I recall, I still need to resolve all the conflicts on every commit\n> > before it squashes.\n> \n> Have you investigated git rerere[1] at all? Documentation indicates it\n> works for rebase as well as merge, so it might be possible to train\n> that to resolve the conflicts.\n\nI don't think rerere helps here. In a rebase like this, the problem is\nthat it _isn't_ the same conflict.\n\nImagine a case like this:\n\n-- >8 --\ngit init repo\ncd repo\n\n# both branches start with just the line \"base\"\necho base >file\ngit add file\ngit commit -m base\n\n# one side adds a new line\ngit checkout -b newline\necho another >>file\ngit commit -am 'add a line'\n\n# and the other modifies the first line\ngit checkout -b other HEAD^\necho one >file\ngit commit -am one\necho two >file\ngit commit -am two\n\n# and now we rebase on top of the newline branch\ngit rebase newline\n-- >8 --\n\nApplying the first commit gets this conflict (in diff3 form)\n\n <<<<<<< ours\n base\n another\n ||||||| base\n base\n =======\n one\n >>>>>>> theirs\n\nAfter we fix that up to \"one\\nanother\", the second conflict is:\n\n <<<<<<< ours\n one\n another\n ||||||| base\n one\n =======\n two\n >>>>>>> theirs\n\nLikewise, even if you had done the original merge between branch tips,\nyou'd have seen yet another conflict:\n\n <<<<<<< ours\n two\n ||||||| base\n base\n =======\n base\n another\n >>>>>>> theirs\n\nThe actual lines changed are the same, but as the nearby context is\ncontinually shifting, we don't consider these to be the \"same\" conflict.\n\n-Peff\n"},{"id":"424286","messageId":"xmqqy2ckfp3z.fsf@gitster.g","threadId":"55666","inReplyTo":"YJsk49WBd27NrCAA@coredump.intra.peff.net","subject":"Re: Rebase Question","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-12T06:22:24Z","receivedAt":"2021-05-12T06:22:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't think rerere helps here. In a rebase like this, the problem is\n> that it _isn't_ the same conflict.\n>\n> Imagine a case like this:\n> ...\n> Applying the first commit gets this conflict (in diff3 form)\n>\n> <<<<<<< ours\n> base\n> another\n> ||||||| base\n> base\n> =======\n> one\n> >>>>>>> theirs\n>\n> After we fix that up to \"one\\nanother\", the second conflict is:\n>\n> <<<<<<< ours\n> one\n> another\n> ||||||| base\n> one\n> =======\n> two\n> >>>>>>> theirs\n>\n> Likewise, even if you had done the original merge between branch tips,\n> you'd have seen yet another conflict:\n>\n> <<<<<<< ours\n> two\n> ||||||| base\n> base\n> =======\n> base\n> another\n> >>>>>>> theirs\n>\n> The actual lines changed are the same, but as the nearby context is\n> continually shifting, we don't consider these to be the \"same\" conflict.\n\nCorrect. The conflict you see at each step may be trivial to\nresolve, but would not \"replay\" at all, exactly because they are not\nthe same conflicts. Knowing that the user would resolve\n\n base --> base/another\n \\ \\\n ---> one--------- one/another\n\ndoes not help us to decide that\n\n base --> two -----------\n \\ \\\n ---> base/another---???\n\nis resolved to two/another.\n\n"},{"id":"424295","messageId":"609b827884bfd_6e0fc2083c@natae.notmuch","threadId":"55666","inReplyTo":"MN2PR07MB59526F40B255183931649AD19C529@MN2PR07MB5952.namprd07.prod.outlook.com","subject":"RE: Rebase Question","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-12T07:23:36Z","receivedAt":"2021-05-12T07:23:43Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andrew Ottaviano wrote:\n> The difficulty with this is that if I have merge conflicts that show\n> up on my first commit, I have to resolve that stupid thing for every\n> subsequent commit.\n\nI don't quite understand that. If you have resolved the chunk, then that\nchunk is resolved, and the rest of the commits don't have to worry\nabout that...\n\nUnless they touch *precisely* the same lines as the first commit, in\nwhich case... Yeah, you have to resolve that stupid thing over and over.\n\n> The solution that I thought of is instead of resolving conflicts from\n> the bottom up (starting with earliest history), resolving from the top\n> down (latest to earliest) and resolving the conflict in the commit it\n> occurred.\n\nWell, this is interesting because it's something I've wanted to write\nabout for a long time, and it's what I call my \"pronged approach\".\n\n\nI actually do *both*; I do a rebase and fix the problems from 1) the bottom-up,\nbut after I have resolved the conflicts from 2) the top-down. In 1)\n(bottom-up) I resolve the conflicts in a rebase, and in 2) I resolve the\nconflicts in merge, but in *both* the end result sould be the exactly\nsame [`git diff 1) 2)` is empty].\n\nYes, it is more work, but at the end of the day I'm 100% sure I did the\nrebase right, so I don't have to think about it that much; either\nthere's a diff or there isn't.\n\nIn fact, I rarely do just one rebase, because quite often I miss things,\nso I do a second, or third, or fourth rebase, but at the end I make sure\nthat the diff with the merge (top-down approach) is the same.\n\nTo facilitate this work I use two tools: 1) git rerere [1] (others have\nmentioned this), and 2) git reintegrate [2] (only useful if there's more\nthan one branch you are merging).\n\n\nYeah, it's a lot of work, but I'd rather do a lot of tedious work that\nI'm 100% sure is correct, than do a little bit of work that I can't\neasily verify.\n\nCheers.\n\n[1] https://git-scm.com/docs/git-rerere\n[2] https://github.com/felipec/git-reintegrate\n\n-- \nFelipe Contreras\n"}]}