Re: linux-next: manual merge of the security-testing tree with the tree

2011/6/30 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

The problem with that is that it's *way* too expensive an operation to do for the normal "git log" kind of operations.

Also, truly re-doing the merge actually requires workspace access and/or require new objects to be created, so it would be inappropriate anyway: git log/show absolutely has to be a read-only operation, anything else would be totally insane.

So there's no way - both for performance and 'fundamental' reasons - to make the normal logging code truly re-do the merge and then compare the end result of the merge with the end result that is in the tree.

That said, what the current "git show/log" does is to just compare the end points with the merge result, which means that if the end result matches either of the end-points, nothing will be shown. That works for the common cases, but it absolutely doesn't work if somebody does something crazy, and just picks one end-point over another without doing a proper merge (ie "-s ours" or just a mis-merge). But the reason it's done that way is that it's possible to do without re-doing the merge.

It would be lovely if "git show" (and log operations) had some option to do a "expensive merge check" and did actually figure out the common ancestor and at least took that into account.

It would be doable to do it at least better than we do now - the common ancestor is not cheap to compute, but it's much cheaper than a full merge, and would at least allow us to flag dangerous merges. Of course, it gets fun when there are multiple common ancestors and renames. It's entirely possible that it's never going to be practical to do anything but "re-do the merge and compare result".

                      Linus