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
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
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:
quoted
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:
quoted
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
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.
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.
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).
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.
quoted
I still wonder how non-Emacs users deal with situations like these.
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.
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.
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.
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