<@U02KAN6061E>: it looks like the cherry-pick job ...
# development
w
@bitter-ability-32190: it looks like the cherry-pick job might have picked more than it should have here: https://github.com/pantsbuild/pants/actions/runs/5026777727/jobs/9015456286
b
My SWAG is that without the full depth its doing a 2-way merge, and not a 3-way merge? I'm really lost and confused. I tried everything locally and it worked, so the only difference I can spot is depth
w
a cherry-pick doesn’t involve a merge, afaik?
b
I mean, we're getting merge conflicts. I think its in the name 🙂
c
it should be called a change conflict.
w
but what i mean is that a cherry-pick is never a merge. it’s more like a rebase. so i don’t think depth matters
👍 1
b
Well, feel free to experiment 😛 We do half-day fridays so I'm about to kick it
Otherwise ill maybe try tonight. I think attempts should use a fresh depth: 1 clone of the repo to mimick GHA
w
no worries: have a good weekend!
p
git still refers to cherry-pick conflicts as merge conflicts
w
yea. the point of my comment was rather that regardless of how it is implemented, nothing other than the picked commit should be relevant (which is unlike a merge, and more like a rebase)
running that script with
set -x
for a bit probably wouldn’t hurt.
b
So some observations: Cherry pick has merge strategy options. So there might be some amount of "merging" The error is that both we and the other branch added the same files (seemingly every file in the repo
Also @happy-kitchen-89482 pile in 😂
I suppose my next attempt will just use
-Xtheirs
It's weird to me that cherry-pick is erroring on files not in the patch though. I thought cherry pick just applied the patch associated for the commit
☝️ 1
w
exactly
b
I'm declaring a bit of bankruptcy at the moment. I'll revisit later 😮‍💨
Wow, so running this action locally with
act
also "works" and doesn't go kaboom. 😮‍💨
Annnd manually running it now "works"?! Failed run: https://github.com/pantsbuild/pants/actions/runs/5060909395 Passed run: https://github.com/pantsbuild/pants/actions/runs/5060928020/jobs/9084453166 same PR number... 😮‍💨 😡
Oh the ONE difference I can think of is that on the passing job, the PR commit wasn't the tip of
main
😐
w
my hope is that the
set -x
exposes that the actual commit being picked on the
git cherry-pick $SHA
line is different somehow in failing cases. that seems like the only thing that could explain unrelated files being conflicted.
b
Yeah. That was my one and only thought. "What if the value to
cherry-pick
wasn't what we thought? You could specify a range, or..." and that led to wanting to use
-x
Guess we'll need to find something that needs cherry-picking 😉