[GSoC] My Git Dev Blog - Week 3

[GSoC] My Git Dev Blog - Week 3

[Atharva Raykar]

Hi,

Here is my latest instalment in my weekly Git blog:
http://atharvaraykar.me/gitnotes/week3

(In case you missed week two, here is where you can find it:
http://atharvaraykar.me/gitnotes/week2)

This issue mostly consists of an update on the work I have
done since the last week, as well as the challenges I faced
and overcame.

I'm sure many of you will probably find things that are
quite suboptimal about how I work, so feel free to nitpick
away. I'll definitely learn something from it ;-)

Have a great weekend, and stay safe!

--
Atharva Raykar

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

[Christian Couder]

On Sun, Jun 6, 2021 at 2:30 PM Atharva Raykar <raykar.ath@gmail.com> wrote:

> Here is my latest instalment in my weekly Git blog:
> http://atharvaraykar.me/gitnotes/week3

Great, thanks!

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

[Bagas Sanjaya]

Hi Atharva,

On 06/06/21 19.26, Atharva Raykar wrote:
> Hi,
> 
> Here is my latest instalment in my weekly Git blog:
> http://atharvaraykar.me/gitnotes/week3
> 

You said:

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

But before, you said:

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

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`?

Also, you advised that:

> Check your resolved conflict before continuing the merge

IMO, once you have resolved all the conflicts, compile and test before 
commit the resulting merge. This way, it will be nicer for review.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

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

[Atharva Raykar]

On 07-Jun-2021, at 14:27, Bagas Sanjaya <bagasdotme@gmail.com> wrote:
> 
> Hi Atharva,
> 
> On 06/06/21 19.26, Atharva Raykar wrote:
>> Hi,
>> Here is my latest instalment in my weekly Git blog:
>> http://atharvaraykar.me/gitnotes/week3
> 
> You said:
> 
>> 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.
> 
> But before, you said:
> 
>> 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).
> 
> 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`?

I actually created another branch based off master, and then applied
those two patches on them. Me mentioning 'merge (A) on master' was a
mistake. I'll correct it.

> Also, you advised that:
> 
>> Check your resolved conflict before continuing the merge
> 
> IMO, once you have resolved all the conflicts, compile and test before commit the resulting merge. This way, it will be nicer for review.

Agreed.

> Thanks.
> 
> -- 
> An old man doll... just what I always wanted! - Clara

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

[Kaartic Sivaraam]

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.

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

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?

Also, which version of Git did you use to do the merge ?

I tried reproducing the merge and it's indeed interesting that
even '-Xpatience' didn't do the trick.

> 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

Speaking of resolving conflicts, there's also rerere [3] which should
save you from having to resolve the same conflict again and again.

[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

> 
> Have a great weekend, and stay safe!
> 

Thanks. Hope you stay safe too!

-- 
Sivaraam

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

[Atharva Raykar]

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

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

[Kaartic Sivaraam]

Hi Atharva,

On Tue, Jun 8, 2021 at 12:43 PM Atharva Raykar <raykar.ath@gmail.com> wrote:
>
> 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.
>

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