Hello Thomas, On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote: > Junio C Hamano <gits...@pobox.com> writes: > > Conceptually I can see how this will change the history > > simplification in the vertical direction (skipping the ancestry > > chain and jumping directly to the closest grandparent that touched > > the specified path), but I am not sure how well this interacts with > > history simplification in the horizontal direciton (culling > > irrelevant side branches from the merge). > > But isn't that similarly confusing for the user as Uwe's original > problem? Suddenly we'd be showing a merge commit as an ordinary one, > simply because the merged history did not affect the filtered > pathspecs. Thus we would show everything that has been merged on the > *other* files as a big diff. Would that be useful? It would certainly > be a big difference in how the commit is shown. the merge is only included in the output if on both parent paths the file is touched. So this is a non-issue, isn't it? (Well, only if it has more than 2 parents and not all ancestor paths touch the file, the number of parents shown is changed.)
Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
