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

[Atharva Raykar <raykar.ath@gmail.com>]

On 08-Jun-2021, at 00:25, Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> 
> Hi Atharva,
> 
> On 06/06/21 5:56 pm, Atharva Raykar wrote:
>> Hi,
>> Here is my latest instalment in my weekly Git blog:
>> http://atharvaraykar.me/gitnotes/week3
> 
> Nice post!
> 
>> 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).

> You mention trying 'recursive' strategy. Given this isn't a
> fast-forward merge, I would've expected it to be one that would've
> been triggered by default. Was that not the case for you?

This was my bad. I had it mixed up in my head and assumed
'resolve' was the default strategy. Between all the
strategies I tried, 'recursive', ie, the default one worked
best. I'll tweak my post to reflect this.

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

>> Have a great weekend, and stay safe!
> 
> Thanks. Hope you stay safe too!
> 
> -- 
> Sivaraam