2

Just thinking in stats, and trying to "understand" the potential "complexity" of a rebasing experience before starting.

Laura Elvira Hernández Lara
  • 94
  • 7
gal007
  • 6,911
  • 8
  • 47
  • 70
  • I would say that if you have a serious concern that there will be a ton of conflicts, then maybe consider just merging and avoiding a rebase. – Tim Biegeleisen Jul 09 '21 at 08:48
  • It's quite complicated. I'd suggest you evaluate the complexity by `git merge-tree`. See https://stackoverflow.com/a/6283843/6330106. – ElpieKay Jul 09 '21 at 09:54

1 Answers1

1

I guess for simple rebases (e.g. just a bunch of regular commits in a row that should all be rebased; with some common ancestor at some point),
a "dumb" way for an estimate could be to check if they changed the same files and how many lines each side changed.
The higher the number of Files/Lines, the higher the chance of merge issues.

A possible quick&dirty implementation (linux/bash) could look like this:

estrebase() { ( set -eu; oldbase="$(git merge-base "$1" "$2")"; oldhead="$2"; newbase="$3"; score="$(sort -k3 <(git diff --numstat --no-renames "$(git merge-base "$oldbase" "$newbase")" "$newbase") <(git diff --numstat --no-renames "$oldbase" "$oldhead") | uniq -D --skip-fields=2 | awk '{sum += $1 + $2} END {print sum + 0}')"; printf "score: %s\nrating: " "$score"; if [ "$score" -eq 0 ]; then echo no conflicts; exit 0; fi; if [ "$score" -lt 100 ]; then echo minor; elif [ "$score" -lt 500 ]; then echo medium; elif [ "$score" -lt 5000 ]; then echo major; else echo brutal; fi; exit 1; ) }

Arguments are oldbase oldhead newbase.

$ estrebase origin/development BRANCH-123 origin/master
score: 0
rating: no conflicts

$ estrebase origin/development BRANCH-124 origin/master
score: 114
rating: minor

$ estrebase initial_commit master origin/master
score: 13100296
rating: brutal
Jay
  • 3,640
  • 12
  • 17