Hi Atharva, On Tue, Jun 8, 2021 at 12:43 PM Atharva Raykar <raykar.ath@xxxxxxxxx> wrote: > > On 08-Jun-2021, at 00:25, Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> wrote: > > > >> My not-so-well-read guess: Some users want certain submodules > >> active in one worktree, but not the other. For that, there > >> presumably exists a per-worktree configuration, and the current > >> implementation just assumes a configuration that applies to the > >> full repo. Changing this is definitely a patch for some other time. > > > > I get to the same presumption. You could try exploring worktrees more to > > confirm as you point out. You could also try Cc-ing people who you think > > would have an idea of this. 'git blame' could you here. > > Yes, I have actually been noting down these "leftover bits" as > things to look into after my GSoC period. > Good idea. > > > A painful merge > > > > You don't mention which branches you were trying to merge but > > from the context I sort of figured out it was the > > 'submodule-add-in-c-add-config-v2' and > > 'submodule-add-in-c-add-clone-v3' branches in your repository: https://github.com/tfidfwastaken/git/ > > That is correct. I felt like adding too many details like that > might make it harder for someone to get the big picture about > what happened at a later time (like one year from now). > That's fine. Just a suggestion, you could try balancing big-picture-view and detailed-view by mentioning additional details like this in a footnote. > > Also, which version of Git did you use to do the merge ? > > 2.31.1 > > Since I'm now a Git developer, I should probably be running > on a more bleeding edge version, but I have still not got > around to it. > 2.31.1 sounds very recent. But yeah, you could certainly try writing a cron job of sorts that automatically fetches `next` daily, builds and then installs it ;-) > > I tried reproducing the merge and it's indeed interesting that > > even '-Xpatience' didn't do the trick. > > Yeah. It looks deceptively straightforward for the human eye, > not so much for algorithms. Most likely because both the > patches have structurally very similar code, and many lines in > between are identical. > Yeah. That's very likely the cause. > >> I still wonder how non-Emacs users deal with situations like these. > > > > Git lets you invoke external merge tools which could help you resolve > > merge conflicts in a easy way. See mergetool doc [1] to get an idea > > about it. `git mergetool --tool-help` would give you a list of supported > > tools. In your case, I happened to notice that P4Merge[2] does a good > > job of properly resolving the conflict by itself. > > > > [1]: https://www.git-scm.com/docs/git-mergetool > > [2]: https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge > > Thanks for the pointers. I currently use Ediff, which is what is > the default mergetool that is invoked from Magit (the porcelain > I use). Magit is great, Ediff not so much. > > > Speaking of resolving conflicts, there's also rerere [3] which should > > save you from having to resolve the same conflict again and again. > > Yes. I had that enabled after learning about it from last week's > discussion, that lead to it being the default in the next release. > > [https://lore.kernel.org/git/xmqqfsxvxjj2.fsf@gitster.g/] > That sounds like a good change. > > [3]: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere > > > >> So I’m glad there’s the reflog. > > > > Now that you've learned about and used reflog, I thought I'll let you > > know about `git fsck --lost-found` [4] in case it might come in handy > > someday ;-) > > > > [4]: https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt---lost-found > > Thanks for showing me this. Looks very useful. I hope I never > need it ;-) > :-) BTW, I should've mentioned this earlier. Feel free to Cc me in any patch related to your submodule conversion project. I'll try to take a look and review as and when I find time. -- Sivaraam
