[mikepurvis]

I'm sympathetic to a lot of what they have to say, but this has always been a sticking point for me:

> Cherry-picks work better with small check-ins

Maybe it's just bad git tooling or me using the tools wrong, but if I need to cherry-pick and there are conflicts, it is always way easier to squash everything down and pick it in one go— if I don't do that, I end up resolving the same conflict over and over as new commits pile in on top of it and meet a conflict-resolved state that they then have a further conflict with.

[samatman]

The author of pijul is of the opinion that cherry-picks only work in accordance with the developer's mental model, if the VCS is based on patches.

I've been persuaded by his argument, and I'm really looking forward to the pijul rewrite landing, so I can play around with it again.

[quesera]

> if I don't do that, I end up resolving the same conflict over and over

You should check out git rerere.

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

[mikepurvis]

Interesting, thanks for that! Will try in the future.

[aidenn0]

I don't cherry-pick much in git, but I'm guesing rerere doesn't work with it?

[mikepurvis]

I think it probably would for at least some cases, and I'll give it a try definitely.