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

Hi Atharva,

On Tue, Jun 8, 2021 at 12:43 PM Atharva Raykar [off-list ref] wrote:

On 08-Jun-2021, at 00:25, Kaartic Sivaraam [off-list ref] wrote:

quoted

quoted

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.

quoted

quoted

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.

quoted

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

quoted

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.

quoted

quoted

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.

quoted

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/ (local)]

That sounds like a good change.

quoted

[3]: https://www.git-scm.com/book/en/v2/Git-Tools-Rerere

quoted

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