In message <4C981475.10404@xxxxxxxxx>, Artur Skawina writes:
$ time git-what-branch 1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4
1f9c381fa3e0b9b9042e310c69df87eaf9b46ea4 first merged onto v2.6.32.n using the following minimal path:
v2.6.12-rc3-450-g1f9c381 merged up at v2.6.12-rc4-39-gad34ea2 (Fri May 20 22:27:44 2005)
v2.6.12-rc4-39-gad34ea2 merged up at v2.6.12-rc3-590-gbfd4bda (Thu May 5 14:59:37 2005)
v2.6.12-rc3-590-gbfd4bda merged up at v2.6.12-rc3-461-g84e48b6 (Wed May 4 00:27:24 2005)
v2.6.12-rc3-461-g84e48b6 is on v2.6.32.n
18m29.771s user 0m29.681s system 18m4.897s elapsed 105.03% CPU
I found two minor bugs in my script which caused it to return something
other than the most optimal path in all cases. I then got crazy and
added a --date-order and --topo-order -- the former orders paths by
commit date and the latter orders paths by the number of merges that
took place (and then by commit date) and then path summarization if
multiple branches were obtained through the same path.
Results are similar, that one extra merge i'll have to take a look at
later, but the cost difference...
As we discussed privately, the cost difference is because instead of
looking at just one branch, it is looking at 150+ branches. If you
use --reference-branch to specify the one branch you are looking at,
it takes a much more reasonable 15-20 seconds. Likewise if you select
a commit more recent than 2005, the number of branches that it could
apply to goes down and the command runs faster.
Also in my most recent version I was able to find an even shorter path
(two merges to master).
I have cleaned everything up and made a formal release out of it.
It is available at: http://github.com/SethRobertson/git-what-branch
-Seth Robertson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html