Question

All the examples I’ve seen deal with branches where there is only one committer. What I am trying to achieve is an automatic git rebase -i where, for a given branch.. all commit made by a given user will be squashed together.

hence, if 3 people work on a branch.. when the branch is merged with master, we would see only 3 commits in the history.. one per user. Kind of a rebase + squash together with a twist of user.

Hope I made myself clear.. ;-/

Any pointers would help,

Sincerely,

Answer 1

I’m going to try to convince you that you simply do not do this for four reasons:

1. You are throwing away history.
2. History on the server will diverge from all of the committers’ history, because you are doing the rebase post-push. All committers will have to deal with the hassle of non-fastforward merges of the shared master each time you do this.
3. You are almost-surely creating non-atomic commits by combining multiple commits into one, a corollary of “don’t throw out history.” The point of atomic commits is to make history comprehensible, to easily identify the cause of regressions, and even to make code reuse possible through cherry-picks (and probably other good reasons I can’t think of off the top of my head).
4. You can alter changes and end up with a final product that is not the sum of each user’s commits, as I mentioned in my comment. Consider cases of committers A and B that modify the same files (especially the same content in the same files) when their contributions are interleaved like A, B, A A and you squash to AAA, B or B, AAA (where AAA is the squash result). This will bite you hard.