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

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

Reply via email to