Add "squash merge" support to merge API

[arielshaqed]

Squashing really just means removing the source branch as a parent of the
resulting commit.

Fixes #7382.

[github-actions]

♻️ PR Preview 9980ba3 has been successfully destroyed since this PR has been closed.

_{🤖 By surge-preview}

[arielshaqed]

This turned out to be a really small feature, about 3 lines of actual code. Useful e.g. for this, required for delta-rs support.

[github-actions]

E2E Test Results - DynamoDB Local - Local Block Adapter

[github-actions]

E2E Test Results - Quickstart

[arielshaqed]

@ion-elgreco I think this will help your use-case.

[ion-elgreco]

@ion-elgreco I think this will help your use-case.

Awesome! 🙏😎

[Jonathan-Rosenberg]

I need to understand a bit further:
Examining Git's squash semantics, it looks a bit different from the suggested change. According to Git, the changes from the list of commits being squashed are combined to a single commit, thus rewriting the history. That means that I cannot traverse the changes throughout the commits because they all exist in a single commit.
Are those the semantics expressed in this feature? If so, how are they reflected in the suggested implementation?

[arielshaqed]

I need to understand a bit further: Examining Git's squash semantics, it looks a bit different from the suggested change. According to Git, the changes from the list of commits being squashed are combined to a single commit, thus rewriting the history. That means that I cannot traverse the changes throughout the commits because they all exist in a single commit. Are those the semantics expressed in this feature? If so, how are they reflected in the suggested implementation?

You're right but so am I! Git merge --squash prepares a commit but does not actually commit it. So it's a bit like --no-commit would be. This API is like more like git merge --squash ; git commit.

This PR is more like GitHub squash-merge! You get a new commit on the destination branch, with all the changes on the search branch from the merge base. There is no way to traverse from the destination branch to those changes - the source branch parent is missing.

@ion-elgreco is this what you want, or do you actually want the Git "bring-me-the-changes-but-only-stage-them" behaviour?

[ion-elgreco]

@arielshaqed actually both things are useful, however currently I was mainly looking for a GitHub squash-merge like you say!

An additional commit API though that can do squash from head, so all new commits since it was branched off to squash into one commit can be practical for other usecases

[Jonathan-Rosenberg]

@arielshaqed Got it! Thank you.
Will now continue the review...

[Jonathan-Rosenberg]

Thank you.
Looks very good, although a sassy developer might be surprised to get the GitHub version of a squash merge rather than the Git version. You might add some clarification in the docs (description) on that, and you might not 😀
I've also noticed that lakeCTL isn't updated with the new capability and it might be a quick win here (of course that it's not a part of the PR, but releasing a version with the client already updated can be nice)...

[arielshaqed]

Great, thanks!

Thank you. Looks very good, although a sassy developer might be surprised to get the GitHub version of a squash merge rather than the Git version. You might add some clarification in the docs (description) on that, and you might not 😀

Done! 9ca1331

I've also noticed that lakeCTL isn't updated with the new capability and it might be a quick win here (of course that it's not a part of the PR, but releasing a version with the client already updated can be nice)...

Did that too, in 54dbde3. I even added a lakectl test as 9980ba3; it took a while but is somewhat cool.

Pulling once tests pass.