All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@inf.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
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: Sat, 3 Aug 2013 12:55:15 +0200	[thread overview]
Message-ID: <87a9kz3uy4.fsf@hexa.v.cablecom.net> (raw)
In-Reply-To: <7vbo5hqe6r.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Thu, 01 Aug 2013 14:44:12 -0700")

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.

If you care about it, I can introduce a new flag that lets the user
pick; it's pretty trivial.  But it seems very strange to me.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  parent reply	other threads:[~2013-08-03 10:55 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 ` Thomas Rast [this message]
2013-08-05 15:18   ` What's cooking in git.git (Aug 2013, #01; Thu, 1) Junio C Hamano
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

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

  git send-email \
    --in-reply-to=87a9kz3uy4.fsf@hexa.v.cablecom.net \
    --to=trast@inf.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.