Produce a squashed version of SYCL history to make the life of the SYCL SC committee simpler

[keryell]

@VerenaBeckham @etomzak @AByzhynar I put an example of what a simplified history is: https://github.com/KhronosGroup/SYCL-Docs/tree/squashed-main
Interestingly, the link on the PR in the commit title correctly send to the original PR and its commits.
Note that it will be misleading when clicked from the SYCL-SC repository, but we could add a more precise link.

Here is the current recipe using https://github.com/newren/git-filter-repo quite faster than the old git filter-branch:

sudo apt install git-filter-repo
git clone [email protected]:KhronosGroup/SYCL-Doc
cd SYCL-Doc
# Just keep the first parent from each commit to give a squashed view
git filter-repo --refs main --commit-callback 'if len(commit.parents) > 1 : commit.parents = [commit.parents[0]]'
# Create a new squashed-main branch upstream.
git push origin main:squashed-main

[rolandschulz]

You were quicker. Alternative solution created by GPT:

#!/bin/bash

# Set the current branch and main branch names
main_branch="main"

# Find the most recent commit on the current branch with "cherry picked from commit" in the last line of the message
recent_commit=$(git log --format=%H -n 1 --grep="cherry picked from commit")

if [ -z "$recent_commit" ]; then
  echo "No recent commit with 'cherry picked from commit' found. Using HEAD as the original commit."
  original_commit=$(git rev-parse HEAD)
else
  echo "Most recent commit with cherry-pick found: $recent_commit"
  
  # Extract the original commit hash from the cherry-pick message (it's the last word of the commit message)
  original_commit=$(git log -1 --format=%B $recent_commit | grep "cherry picked from commit" | awk '{print $NF}' | tr -d ')')
  
  # Check if the original commit hash was extracted
  if [ -z "$original_commit" ]; then
    echo "Failed to extract the original commit hash."
    exit 1
  fi
fi

echo "Original commit hash: $original_commit"

# Get all commits after the original commit on the main branch (first-parent only)
commits_to_cherry_pick=$(git log --first-parent --format=%H --reverse $original_commit..$main_branch)

# Check if there are any commits to cherry-pick
if [ -z "$commits_to_cherry_pick" ]; then
  echo "No commits to cherry-pick from $main_branch after $original_commit."
  exit 0
fi

# Cherry-pick all commits (merge or non-merge) with -m 1 and -x to include the cherry-pick message
echo "Cherry-picking all commits from $main_branch after $original_commit..."
git cherry-pick -m 1 -x $commits_to_cherry_pick

# Check if the cherry-pick succeeded
if [ $? -ne 0 ]; then
  echo "Cherry-pick failed. Resolve conflicts, then run 'git cherry-pick --continue' to finish."
  exit 1
fi

echo "Successfully cherry-picked all relevant commits from $main_branch."

Advantage of this solution is that it automatically only adds the new commits added since it was called last time. So it can be run in post-commit without having to recreate the branch every time and it refers to the original commit. Disadvantage creating many commits is much slower than with Ronan's solution. But given that this only done once it shouldn't matter.

[keryell]

Whatever solution we pick, regenerating the branch from scratch seems idempotent (generating new hash values every time the script is done would be a nightmare) and is surprisingly done in only a fraction of second.

[keryell]

This is to be used as described in SYCL SC internal https://gitlab.khronos.org/syclsc/Specification/-/issues/6

[VerenaBeckham]

We have tried applying all the SYCL SC commits on this squashed branch (thank you, @keryell!) and it looks good so far.
Our next steps would be to try using this SYCL SC squashed branch as a basis for pulling new commits from the SYCL squashed branch.
Would you be able to update https://github.com/KhronosGroup/SYCL-Docs/tree/squashed-main with the latest commits in main, using the method that you would be using for the Github hook?
Then we can try merging in those changes and, if successful, go ahead with implementing the hook.

[VerenaBeckham]

Is there any update on setting up a hook to update a squashed branch? Thanks.

[gmlueck]

I created two new squashed branches named "main-squashed" and "sycl-2020-squashed". The first contains the squashed commits from the "main" branch and the second contains the squashed commits from the "sycl-2020" branch. Which does the SYCL SC project want to use? I thought you were tracking the SYCL 2020 spec, not the evolving SYCL-Next spec, right? In that case, I presume you want the "sycl-2020-squashed" branch.

I decided to use a @rolandschulz's script as a starting point. I liked that it includes the "cherry picked from ..." messages, and it doesn't require an external dependence on git-filter-repo project. The speed of running the command does not seem to be an issue.

BTW, I needed to choose some starting point for the squashed history. I arbitrarily chose the "SYCL-2020/final-rev8" tag as the starting point, so the branches above contain squashed commits starting at that point. I can choose a different starting point if you prefer.

[gmlueck]

See #657 for the script I used to create these branches.

Once I get feedback from the SYCL-SC group about which branch you want, I'll set up an automated CI task to update it whenever a PR is merged.

[keryell]

My script generates a simplified history since the beginning. I am confused about why mixing squashed and unsquashed? 🤔

[etomzak]

See #657 for the script I used to create these branches.

Once I get feedback from the SYCL-SC group about which branch you want, I'll set up an automated CI task to update it whenever a PR is merged.

Would it be prohibitively difficult to have both a squashed SYCL 2020 branch and a squashed SYCL Next branch? SYCL SC is currently tracking SYCL 2020, but at some point in the future it will switch to tracking the SYCL Next branch (or SYCL YYYY where YYYY is the next release). If there isn't a squashed SYCL Next branch, we'll run into the same problem that this issue is trying to solve. It's also looking likely that SYCL SC will need to cherry-pick specific changes from the SYCL Next branch even while being based on SYCL 2020, and the squashing would help with that as well.

[VerenaBeckham]

I agree with the cherry-picking point. Due to that I would also like to request squashed versions of both branches.
The SYCL SC WG sees no reason not to leave commits that SYCL SC has already merged in unsquashed.
The last commit we have is 2a2a8cc, so the commit after that would be a good logical starting point for squashing, if that works for you.