{"thread":{"id":"55852","subject":"[GSoC] My Git Dev Blog - Week 3","startedAt":"2021-06-06T12:27:30Z","lastAt":"2021-06-08T17:56:58Z","messageCount":7,"participants":["Atharva Raykar","Christian Couder","Bagas Sanjaya","Kaartic Sivaraam"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"426530","messageId":"FC56DF49-CEC5-4C9F-BDE4-B0119558E4B2@gmail.com","threadId":"55852","inReplyTo":null,"subject":"[GSoC] My Git Dev Blog - Week 3","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-06-06T12:26:11Z","receivedAt":"2021-06-06T12:27:30Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"Hi,\n\nHere is my latest instalment in my weekly Git blog:\nhttp://atharvaraykar.me/gitnotes/week3\n\n(In case you missed week two, here is where you can find it:\nhttp://atharvaraykar.me/gitnotes/week2)\n\nThis issue mostly consists of an update on the work I have\ndone since the last week, as well as the challenges I faced\nand overcame.\n\nI'm sure many of you will probably find things that are\nquite suboptimal about how I work, so feel free to nitpick\naway. I'll definitely learn something from it ;-)\n\nHave a great weekend, and stay safe!\n\n--\nAtharva Raykar\n"},{"id":"426560","messageId":"CAP8UFD16soOa5RGRaOtPjPbFQ0OjuecCFGM6mCftC+Z__9coCg@mail.gmail.com","threadId":"55852","inReplyTo":"FC56DF49-CEC5-4C9F-BDE4-B0119558E4B2@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2021-06-07T08:19:20Z","receivedAt":"2021-06-07T08:19:35Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Jun 6, 2021 at 2:30 PM Atharva Raykar <raykar.ath@gmail.com> wrote:\n\n> Here is my latest instalment in my weekly Git blog:\n> http://atharvaraykar.me/gitnotes/week3\n\nGreat, thanks!\n"},{"id":"426561","messageId":"37725450-9769-01f1-d615-b3869ebbb33d@gmail.com","threadId":"55852","inReplyTo":"FC56DF49-CEC5-4C9F-BDE4-B0119558E4B2@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-06-07T08:57:55Z","receivedAt":"2021-06-07T08:58:59Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi Atharva,\n\nOn 06/06/21 19.26, Atharva Raykar wrote:\n> Hi,\n> \n> Here is my latest instalment in my weekly Git blog:\n> http://atharvaraykar.me/gitnotes/week3\n> \n\nYou said:\n\n> Simple enough, I thought. Just fast-forward merge (A) on master, and then, uhh, cherry pick and apply (B) on top of the newly merged (A). Resolve any conflict in this stage. That way I get (A) and (B) in their pristine individuality, as well as a third branch that combines both the changes.\n\nBut before, you said:\n\n> Once it was becoming clear that would not happen, I thought of combining those two branches on another branch (that would hold all my patches so far).\n\nAre you merging two branches that contains your separated patchsets \ndirectly to your own `master` branch, or are you merging them to \ntemporary branch that is branched directly from `master`?\n\nAlso, you advised that:\n\n> Check your resolved conflict before continuing the merge\n\nIMO, once you have resolved all the conflicts, compile and test before \ncommit the resulting merge. This way, it will be nicer for review.\n\nThanks.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"426598","messageId":"D56DACFE-1E85-4765-80AC-0B60C2403CC8@gmail.com","threadId":"55852","inReplyTo":"37725450-9769-01f1-d615-b3869ebbb33d@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-06-07T12:52:20Z","receivedAt":"2021-06-07T12:53:25Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 07-Jun-2021, at 14:27, Bagas Sanjaya <bagasdotme@gmail.com> wrote:\n> \n> Hi Atharva,\n> \n> On 06/06/21 19.26, Atharva Raykar wrote:\n>> Hi,\n>> Here is my latest instalment in my weekly Git blog:\n>> http://atharvaraykar.me/gitnotes/week3\n> \n> You said:\n> \n>> Simple enough, I thought. Just fast-forward merge (A) on master, and then, uhh, cherry pick and apply (B) on top of the newly merged (A). Resolve any conflict in this stage. That way I get (A) and (B) in their pristine individuality, as well as a third branch that combines both the changes.\n> \n> But before, you said:\n> \n>> Once it was becoming clear that would not happen, I thought of combining those two branches on another branch (that would hold all my patches so far).\n> \n> Are you merging two branches that contains your separated patchsets directly to your own `master` branch, or are you merging them to temporary branch that is branched directly from `master`?\n\nI actually created another branch based off master, and then applied\nthose two patches on them. Me mentioning 'merge (A) on master' was a\nmistake. I'll correct it.\n\n> Also, you advised that:\n> \n>> Check your resolved conflict before continuing the merge\n> \n> IMO, once you have resolved all the conflicts, compile and test before commit the resulting merge. This way, it will be nicer for review.\n\nAgreed.\n\n> Thanks.\n> \n> -- \n> An old man doll... just what I always wanted! - Clara\n\n"},{"id":"426649","messageId":"4a4a3d6f-7d06-ccdb-7d5a-4057c7549927@gmail.com","threadId":"55852","inReplyTo":"FC56DF49-CEC5-4C9F-BDE4-B0119558E4B2@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2021-06-07T18:55:46Z","receivedAt":"2021-06-07T18:57:08Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Atharva,\n\nOn 06/06/21 5:56 pm, Atharva Raykar wrote:\n> Hi,\n> \n> Here is my latest instalment in my weekly Git blog:\n> http://atharvaraykar.me/gitnotes/week3\n> \n\nNice post!\n\n> My not-so-well-read guess: Some users want certain submodules\n> active in one worktree, but not the other. For that, there\n> presumably exists a per-worktree configuration, and the current\n> implementation just assumes a configuration that applies to the\n> full repo. Changing this is definitely a patch for some other time.\n\nI get to the same presumption. You could try exploring worktrees more to\nconfirm as you point out. You could also try Cc-ing people who you think\nwould have an idea of this. 'git blame' could you here.\n\n > A painful merge\n\nYou don't mention which branches you were trying to merge but\nfrom the context I sort of figured out it was the\n'submodule-add-in-c-add-config-v2' and\n'submodule-add-in-c-add-clone-v3' branches in your repository: \nhttps://github.com/tfidfwastaken/git/\n\nYou mention trying 'recursive' strategy. Given this isn't a\nfast-forward merge, I would've expected it to be one that would've\nbeen triggered by default. Was that not the case for you?\n\nAlso, which version of Git did you use to do the merge ?\n\nI tried reproducing the merge and it's indeed interesting that\neven '-Xpatience' didn't do the trick.\n\n> I still wonder how non-Emacs users deal with situations like these.\n\nGit lets you invoke external merge tools which could help you resolve\nmerge conflicts in a easy way. See mergetool doc [1] to get an idea\nabout it. `git mergetool --tool-help` would give you a list of supported\ntools. In your case, I happened to notice that P4Merge[2] does a good\njob of properly resolving the conflict by itself.\n\n[1]: https://www.git-scm.com/docs/git-mergetool\n[2]: \nhttps://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge\n\nSpeaking of resolving conflicts, there's also rerere [3] which should\nsave you from having to resolve the same conflict again and again.\n\n[3]: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere\n\n> So I’m glad there’s the reflog.\n\nNow that you've learned about and used reflog, I thought I'll let you\nknow about `git fsck --lost-found` [4] in case it might come in handy\nsomeday ;-)\n\n[4]: \nhttps://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt---lost-found\n\n> \n> Have a great weekend, and stay safe!\n> \n\nThanks. Hope you stay safe too!\n\n-- \nSivaraam\n"},{"id":"426725","messageId":"CBC56A4C-2D47-4C96-9621-73BCB1119B90@gmail.com","threadId":"55852","inReplyTo":"4a4a3d6f-7d06-ccdb-7d5a-4057c7549927@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Atharva Raykar","fromEmail":"raykar.ath@gmail.com","sentAt":"2021-06-08T07:13:16Z","receivedAt":"2021-06-08T07:14:37Z","isPatch":false,"sender":{"key":"raykar.ath@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24277692?v=4"},"body":"On 08-Jun-2021, at 00:25, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n> \n> Hi Atharva,\n> \n> On 06/06/21 5:56 pm, Atharva Raykar wrote:\n>> Hi,\n>> Here is my latest instalment in my weekly Git blog:\n>> http://atharvaraykar.me/gitnotes/week3\n> \n> Nice post!\n> \n>> My not-so-well-read guess: Some users want certain submodules\n>> active in one worktree, but not the other. For that, there\n>> presumably exists a per-worktree configuration, and the current\n>> implementation just assumes a configuration that applies to the\n>> full repo. Changing this is definitely a patch for some other time.\n> \n> I get to the same presumption. You could try exploring worktrees more to\n> confirm as you point out. You could also try Cc-ing people who you think\n> would have an idea of this. 'git blame' could you here.\n\nYes, I have actually been noting down these \"leftover bits\" as\nthings to look into after my GSoC period.\n\n> > A painful merge\n> \n> You don't mention which branches you were trying to merge but\n> from the context I sort of figured out it was the\n> 'submodule-add-in-c-add-config-v2' and\n> 'submodule-add-in-c-add-clone-v3' branches in your repository: https://github.com/tfidfwastaken/git/\n\nThat is correct. I felt like adding too many details like that\nmight make it harder for someone to get the big picture about\nwhat happened at a later time (like one year from now).\n\n> You mention trying 'recursive' strategy. Given this isn't a\n> fast-forward merge, I would've expected it to be one that would've\n> been triggered by default. Was that not the case for you?\n\nThis was my bad. I had it mixed up in my head and assumed\n'resolve' was the default strategy. Between all the\nstrategies I tried, 'recursive', ie, the default one worked\nbest. I'll tweak my post to reflect this.\n\n> Also, which version of Git did you use to do the merge ?\n\n2.31.1\n\nSince I'm now a Git developer, I should probably be running\non a more bleeding edge version, but I have still not got\naround to it.\n\n> I tried reproducing the merge and it's indeed interesting that\n> even '-Xpatience' didn't do the trick.\n\nYeah. It looks deceptively straightforward for the human eye,\nnot so much for algorithms. Most likely because both the\npatches have structurally very similar code, and many lines in\nbetween are identical.\n\n>> I still wonder how non-Emacs users deal with situations like these.\n> \n> Git lets you invoke external merge tools which could help you resolve\n> merge conflicts in a easy way. See mergetool doc [1] to get an idea\n> about it. `git mergetool --tool-help` would give you a list of supported\n> tools. In your case, I happened to notice that P4Merge[2] does a good\n> job of properly resolving the conflict by itself.\n> \n> [1]: https://www.git-scm.com/docs/git-mergetool\n> [2]: https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge\n\nThanks for the pointers. I currently use Ediff, which is what is\nthe default mergetool that is invoked from Magit (the porcelain\nI use). Magit is great, Ediff not so much.\n\n> Speaking of resolving conflicts, there's also rerere [3] which should\n> save you from having to resolve the same conflict again and again.\n\nYes. I had that enabled after learning about it from last week's\ndiscussion, that lead to it being the default in the next release.\n\n[https://lore.kernel.org/git/xmqqfsxvxjj2.fsf@gitster.g/]\n\n> [3]: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere\n> \n>> So I’m glad there’s the reflog.\n> \n> Now that you've learned about and used reflog, I thought I'll let you\n> know about `git fsck --lost-found` [4] in case it might come in handy\n> someday ;-)\n> \n> [4]: https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt---lost-found\n\nThanks for showing me this. Looks very useful. I hope I never\nneed it ;-)\n\n>> Have a great weekend, and stay safe!\n> \n> Thanks. Hope you stay safe too!\n> \n> -- \n> Sivaraam\n\n"},{"id":"426801","messageId":"CA+ARAtpm9NHoyiW84tnuXwvh25_du3AQaan11Aciq0gz_8nSuQ@mail.gmail.com","threadId":"55852","inReplyTo":"CBC56A4C-2D47-4C96-9621-73BCB1119B90@gmail.com","subject":"Re: [GSoC] My Git Dev Blog - Week 3","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2021-06-08T17:55:31Z","receivedAt":"2021-06-08T17:56:58Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Atharva,\n\nOn Tue, Jun 8, 2021 at 12:43 PM Atharva Raykar <raykar.ath@gmail.com> wrote:\n>\n> On 08-Jun-2021, at 00:25, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:\n> >\n> >> My not-so-well-read guess: Some users want certain submodules\n> >> active in one worktree, but not the other. For that, there\n> >> presumably exists a per-worktree configuration, and the current\n> >> implementation just assumes a configuration that applies to the\n> >> full repo. Changing this is definitely a patch for some other time.\n> >\n> > I get to the same presumption. You could try exploring worktrees more to\n> > confirm as you point out. You could also try Cc-ing people who you think\n> > would have an idea of this. 'git blame' could you here.\n>\n> Yes, I have actually been noting down these \"leftover bits\" as\n> things to look into after my GSoC period.\n>\n\nGood idea.\n\n> > > A painful merge\n> >\n> > You don't mention which branches you were trying to merge but\n> > from the context I sort of figured out it was the\n> > 'submodule-add-in-c-add-config-v2' and\n> > 'submodule-add-in-c-add-clone-v3' branches in your repository: https://github.com/tfidfwastaken/git/\n>\n> That is correct. I felt like adding too many details like that\n> might make it harder for someone to get the big picture about\n> what happened at a later time (like one year from now).\n>\n\nThat's fine. Just a suggestion, you could try balancing big-picture-view\nand detailed-view by mentioning additional details like this in a footnote.\n\n> > Also, which version of Git did you use to do the merge ?\n>\n> 2.31.1\n>\n> Since I'm now a Git developer, I should probably be running\n> on a more bleeding edge version, but I have still not got\n> around to it.\n>\n\n2.31.1 sounds very recent. But yeah, you could certainly try\nwriting a cron job of sorts that automatically fetches `next` daily,\nbuilds and then installs it ;-)\n\n> > I tried reproducing the merge and it's indeed interesting that\n> > even '-Xpatience' didn't do the trick.\n>\n> Yeah. It looks deceptively straightforward for the human eye,\n> not so much for algorithms. Most likely because both the\n> patches have structurally very similar code, and many lines in\n> between are identical.\n>\n\nYeah. That's very likely the cause.\n\n> >> I still wonder how non-Emacs users deal with situations like these.\n> >\n> > Git lets you invoke external merge tools which could help you resolve\n> > merge conflicts in a easy way. See mergetool doc [1] to get an idea\n> > about it. `git mergetool --tool-help` would give you a list of supported\n> > tools. In your case, I happened to notice that P4Merge[2] does a good\n> > job of properly resolving the conflict by itself.\n> >\n> > [1]: https://www.git-scm.com/docs/git-mergetool\n> > [2]: https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge\n>\n> Thanks for the pointers. I currently use Ediff, which is what is\n> the default mergetool that is invoked from Magit (the porcelain\n> I use). Magit is great, Ediff not so much.\n>\n> > Speaking of resolving conflicts, there's also rerere [3] which should\n> > save you from having to resolve the same conflict again and again.\n>\n> Yes. I had that enabled after learning about it from last week's\n> discussion, that lead to it being the default in the next release.\n>\n> [https://lore.kernel.org/git/xmqqfsxvxjj2.fsf@gitster.g/]\n>\n\nThat sounds like a good change.\n\n> > [3]: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere\n> >\n> >> So I’m glad there’s the reflog.\n> >\n> > Now that you've learned about and used reflog, I thought I'll let you\n> > know about `git fsck --lost-found` [4] in case it might come in handy\n> > someday ;-)\n> >\n> > [4]: https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt---lost-found\n>\n> Thanks for showing me this. Looks very useful. I hope I never\n> need it ;-)\n>\n\n:-)\n\nBTW, I should've mentioned this earlier. Feel free to Cc me\nin any patch related to your submodule conversion project.\nI'll try to take a look and review as and when I find time.\n\n-- \nSivaraam\n"}]}