Michael Muller e3ab5ed4c1 Don't use --fork-point to determine merge base (#1001) ... * Don't use --fork-point to determine merge base It turns out that the --fork-point option is subtle and error-prone. Its intent is not to show the nearest common base commit, but rather the commit on a branch that the HEAD (in this case) was originally forked off of, _whether it is currently part of the history of the specified branch or not_ (this can happen if the branch is rewritten). The option also relies on the presence of the fork point in the reflog for the branch, which can be discarded in the course of a "git gc". It is fairly easy to construct a case where the use of --fork-point causes an error and outputs nothing. In fact, I discovered the problem as a result of this occuring spontaneously on one of my own branches (likely related to a rebase). Since the fork-point is empty, we end up diffing against the index instead of the common commit. This may have been a factor in some of the unrelated reformatting that we've seen in past PRs. Change this to a simple "merge-base origin/master HEAD", which outputs the commit id of the most recent common base revision. This change also quotes the forkPoint variable, which likely would have resulted in an error in this case instead of silently producing the wrong output.		2021-03-12 11:08:28 -05:00
..
google-java-format-1.8-all-deps.jar	Enable Java 11 features (#737)	2020-08-03 16:08:29 -04:00
google-java-format-diff.py	Print out env variables in java format (#998)	2021-03-10 08:55:14 -05:00
google-java-format-git-diff.sh	Don't use --fork-point to determine merge base (#1001)	2021-03-12 11:08:28 -05:00