git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: git@vger.kernel.org,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Jeff King" <peff@peff.net>
Subject: Re: What's cooking in git.git (Aug 2013, #01; Thu, 1)
Date: Mon, 05 Aug 2013 08:18:31 -0700	[thread overview]
Message-ID: <7vsiyonp2w.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <87a9kz3uy4.fsf@hexa.v.cablecom.net> (Thomas Rast's message of "Sat, 3 Aug 2013 12:55:15 +0200")

Thomas Rast <trast@inf.ethz.ch> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * tr/log-full-diff-keep-true-parents (2013-08-01) 1 commit
>>  - log: use true parents for diff even when rewriting
>>
>>  Output from "git log --full-diff -- <pathspec>" looked strange,
>>  because comparison was done with the previous ancestor that touched
>>  the specified <pathspec>, causing the patches for paths outside the
>>  pathspec to show more than the single commit has changed.
>>
>>  I am not sure if that is necessarily a problem, though.  Output
>>  from "git log --full-diff -2 -- <pathspec>" without this change
>>  will be applicable to some codebase, but after this change that
>>  will no longer be true (you will get only tiny parts of the change
>>  that were made by the two commits in question, while missing all
>>  the other changes).
>
> Hmm.  Uwe's original complaint was that --stat -- as in "what other
> things are touched when we modify foo" -- is nonsensical.
>
> In addition, applying what you describe above would be a very strange
> form of rebase: one that squashes everything into the commits that
> affect the given files.  When would it ever make sense to do such
> squashing?  After all, you'd lose all the commit splits&messages in
> between.

I am not so worried about actually applying that kind of patch, but
more about reviewing what happened in each of the single logical
step shown.  If you made two changes in two far-apart commits to
files you are interested in and want to look at the changes made to
other files to make each of them a complete solution, depending on
how the change was split across files, you would get useful to
useless result with your patch.  In one extreme, if your commits are
too fine-grained and you committed one path at a time, then
"full-diff" will not show anything useful, as the commits that hit
the pathspec do not have changes to any other paths.  In another
extreme, you may have preparatory changes to other paths in commits
that immediately precede the commit that hits the pathspec and then
finally conclude the topic by introducing a caller of the prepared
codepath in other files to the file you are interested in, and your
patch will show only the endgame change without showing the
preparatory steps, which may or may not be useful, depending on what
you are looking for.

So while I do understand why sometimes you wish to see full diff 
"git log --full-diff -- <pathspec>" to match output from "git show"
without pathspec, I am not sure doing it unconditionally and by
default like your patch does is the best way to go.

In the meantime:

    git rev-list --header --parents HEAD -- <pathspec> |
    git -p diff-tree -p --stdin

would be one way to do so.

  reply	other threads:[~2013-08-05 15:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 21:44 What's cooking in git.git (Aug 2013, #01; Thu, 1) Junio C Hamano
2013-08-01 21:44 ` What's in "What's cooking" Junio C Hamano
2013-08-03 10:55 ` What's cooking in git.git (Aug 2013, #01; Thu, 1) Thomas Rast
2013-08-05 15:18   ` Junio C Hamano [this message]
2013-08-06  9:12     ` Thomas Rast
2013-08-06 16:37       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vsiyonp2w.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=trast@inf.ethz.ch \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).