Don't know if this was a mistake or not, but I see that commit e7f1e83
(the one to fix a clipping issue when a patch's line width is 1 but
there is no color) seems to have been merged back into itself...
somehow... in commit 0c886b8. I have seen things like this before, and
I never quite understood how they happen.
"git merge --no-ff" most likely, as it always creates a separate
merge commit, even if the branch in question has only a single commit.
I think we definitely need to see what sort of controls we can put in
place to prevent mix-ups in the future. One thing I did like about SVN
was that it was next to impossible to change the history. Meanwhile,
with git, it becomes possible.
Is there some way we can disallow forced pushes, maybe? Just a thought...
Disabling forced pushes will not help against what occurred here,
at least as far I understand, because the "additional" commits in the
pull requests come from valid merges done after the pull request branched.
The only difference to SVN here is that Git actually tracks the merge
... and, apparently, the Github UI (but not Git itself) gets confused
in some cases as to what's new in a branch.
On Wed, 18 May 2011 13:47:04 -0500, Benjamin Root wrote: