Re: [GSoC] My Git Dev Blog - Week 3

>
> On 08-Jun-2021, at 00:25, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> 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.
>

> > > 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).
>

> > 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.
>

> > 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.
>

> >> 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/]
>

> > [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 ;-)
>