Alternative to re-basing for code review?

Question

I want to do some CR in a project. bitbucket allows me to review one commit at a time. So I wanted to collapse commits into one commit (squashing --> Collapsing a Group of Commits into One on Git) and then review all he changes in one commit.

However, when squashing I lose all the commit history, and I don't really want it.

Are there any alternatives (I know that I can always clone and rebase)? Also, A simple CR tool (not web-platform please) is just fine.

Answer 1

If your limitation for review purposes is one commit and you want to squash to review a list of commits, you should branch and then squash (via rebase), reviewing on a separate dedicated branch. That would be the easiest road to take, and you won’t change the mainline history that have been presumably, already pushed and published.

---

But I also want to address your comment,

However, when squashing I lose all the commit history, and I don't really want it.

Generally speaking you cannot lose commit history with git. What happens with rebase is that the history splits and your branch tip will be pointing to the new ramus, but your old commits are still there – it is just that they cannot be conveniently accessed by a branch name, and will have to be accessed by a commit hash.

Example.

Let’s say you wanted to squash B,C,D,E for the purpose of the review as a single commit.

              A--B--C--D--E  topic
             /
H---I---F---G master

After rebasing is done and B,C,D,E are squashed into S, the original commits are available, but don’t have a branch associated with them:

                B--C--D--E
               /
              A--S  topic
             /
H---I---F---G master

So if you checkout E you will be in a detached head state, but you can simply make topic point back to E:

git update-ref refs/heads/topic E

And the tree will look like this:

                B--C--D--E  topic
               /
              A--S
             /
H---I---F---G master

For the above you have to remember the commit hash of E to be able to refer to it after the rebase in the topic branch. It’s somewhat inconvenient, but you can apply a git tag to E and then git reset to the tag.