1

I've read the wonderful replies to this post.

There is one answer with interactive rebase and exec that lets you sign all commit up to the one specified (excluding) or from the start using --root.

However I don't want to sign every commits since what's on the main branch is already on the remote private repo.

Since this is a various month old branch with various merge conflicts resolutions, this has resulted in the branch having various merge commits and commits in common with the main branch.

Is there a way to only rebase or only run the exec command that sign on commits that are specific to the branch in question ? Leaving the commits already on main untouched. Then using push --force it should only change the current branch making it ready to merge with main.

edit : For anyone interested I found a way to achieve what I wanted, though it's not exactly what I asked for in the beginning.

I searched for a way to squash all my branch commits into one and found this other page. I first tried the orphan branch solution, but I then couldn't create a Pull request on github.

I then used the second solution : I created a copy of the branch I was working with and then did a soft reset to the first commit of the branch. Since I set git to sign everytime it was signed. Committing again made all the commits into this first commit, I then could rename the commit message with commit --amend -m "My new message". Pushing this new branch to the gitHub repo allowed me to do a pull request from this branch to the main one.

So in the end, I had a single commit that was signed.

Afterwards I had to resolve some merge conflicts, but weirldy, even if there was like more than 20 files affected, when I made a new commit for those conflicts, only three files remained in the staged state when I added them.

So those two commits could be pushed to the repo and are both signed and the pull request could be made.

Triup Lauro
  • 11
  • 3
  • If you want to verify the whole history of a branch as authentic, it's sufficient to sign the last commit, since the commit hash is only valid with those specific parent commits, so you're effectively signing the whole history by signing the last commit. – Joachim Sauer Aug 05 '22 at 09:03

1 Answers1

0

If you have a pretty straightforward history with no merges :

You can get the commit where your branch forked from master using git merge-base :

git merge-base master HEAD

If you rebase onto that commit, you will select commits that are not on master :

git rebase <sha_above> -x ...

If you need to rewrite a more complex history with merges, I would advise you to use a history rewritiing tool such as git filter-repo (or the older git filter-branch)

You can select all the commits that are on your branch and not on master master..mybranch.

LeGEC
  • 46,477
  • 5
  • 57
  • 104