Linus Torvalds wrote: > So the rule is: > > - using "--full-history" + "--parents" means that you want (surprise > surprise) full history with parenthood, which means that you get all > the connecting merges too. And since you asked for the _full_ history, > that means EVERY SINGLE MERGE. I just don't quite understand where <pathspec> filtering takes place in this case. Every single merge is for parents to be connected, or what? > So what you are asking for is pretty nonsensical. You ask for parenthood > info, but then you seem to not want to actually connect the dots. So why > do you ask for parents in the first place? If you don't want to connect > the commits to their parents, you shouldn't ask for it. When I though about it, git_history needs not parents of a commit; from parsed commit it needs only date, author and title/summary (and of course commit sha1), so we can skip '--parents' option to git-rev-list, and have nice _history of a file_, using only one call to git-rev-list to make it. This means that parse_rev_list has to be changes, and that '--parents' option must be specified explicitely as argument to parse_rev_list. Besides [primitive] benchmarking shows that there we gain only a little: 1.53s user+sys vs 2.13s user+sys when run from command line, 2.8s mean vs 3.6s mean when tested using ApacheBench... that is _after_ paginating history output. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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