I use my own integration branch manager[1] to manage my WIP changes to
various projects, including git.git and one of the features of this is a
--status option that shows whether anything that I'm tracking has been
merged to the base branch I'm building on top of. Since the commit IDs
will be different after being sent to the list, this uses the --cherry
option to git-log.
Today I realised that I wasn't tracking a git-gui change I sent to the
list a couple of weeks ago [2] and so I pulled that in and added it.
Getting the status for this is significantly slower than anything else
because it does this:
git log --cherry --oneline origin/master...git-gui-fix-subdir
and although there are only 5 commits in git-gui-fix-subdir not in
master there are 31964 commits in master not in git-gui-fix-subdir and
--cherry seems to inspect all of those. So I get:
$ time git log --oneline --cherry master...git-gui-fix-subdir \
>/dev/null
real 0m41.378s
user 0m40.248s
sys 0m0.986s
Now I know that I don't need to check anything older than commit 8ead1bf
(Merge tag 'gitgui-0.17.0' of git://repo.or.cz/git-gui, 2012-10-17) and
if I tell Git that it gets significantly better:
$ time git log --oneline --cherry master...git-gui-fix-subdir \
--not 8ead1bfe111085ef1ad7759e67340f074996b244 >/dev/null
real 0m2.163s
user 0m2.070s
sys 0m0.084s
I'd like a way to automatically find the last merge that pulled in a
subtree so that my script can construct the above command line without
me needing to tell it the correct SHA-1 every time I have a branch that
is affected by this.
I guess this boils down to having a way to ask Git to list merges that
have a parent in a specified range, but perhaps I'm missing an easier
solution to this.
I also wonder if it would be interesting to cache patch IDs rather than
generating them every time...
[1] http://johnkeeping.github.io/git-integration/
[2] http://article.gmane.org/gmane.comp.version-control.git/222646
--
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