Linus Torvalds torva...@linux-foundation.org writes:
...
So the whole don't show diffs for merges by default actually made a
lot of sense originally, because our merge diffs were not very useful.
I agree with most of your analysis of the history, but not with -m
(rather, a part of what -m
Linus Torvalds torva...@linux-foundation.org writes:
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
* When '-p' is given, we show only diff with first-parent by
default, regardless of the traversal (i.e. --first-parent option
currently controls both
On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p; I
wasn't very enthused by the idea to turn --cc when user said -p
without telling them what we are doing. In other
On Wed, Jul 15, 2015 at 11:17 AM, Junio C Hamano gits...@pobox.com wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p
Oh, in that case I say NAK NAK NAK.
That would be totally horrible, and completely unacceptable.
I do git log
Jeff King p...@peff.net writes:
On Wed, Jul 15, 2015 at 11:17:50AM -0700, Junio C Hamano wrote:
So this is a suggested change to -p -m behavior?
Not really. This is a suggested behaviour for git log -p; I
wasn't very enthused by the idea to turn --cc when user said -p
without telling
On Wed, Jul 15, 2015 at 9:29 AM, Junio C Hamano gits...@pobox.com wrote:
I would think git log -p that implies --cc would be a good
change, as long as there is an easy escape hatch to let us do what
we have to do with a rather lengthy git log -p --first-parent -m
(i.e. show the change
On Wed, Jul 15, 2015 at 10:58 AM, Junio C Hamano gits...@pobox.com wrote:
* When '-p' is given, we show only diff with first-parent by
default, regardless of the traversal (i.e. --first-parent option
currently controls both traversal and patch display, but in the
new world order, it
Linus Torvalds torva...@linux-foundation.org writes:
That said, I do wonder if we should just make -p imply --cc. Right
now we have the kind of odd situation that git log -p doesn't show
merge patches, but git show cmit does show them. And you kind of
have to know a lot about git to know the
On Tue, Jul 14, John Keeping wrote:
It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
try:
git log -p -M --stat --cc -- drivers/hv/channel_mgmt.c
Thanks. Thats rather useless output...
@@@ -404,7 -365,7 +404,7 @@@ static u32 next_vp
* performance critical
On Tue, Jul 14, 2015 at 09:30:35AM +0200, Olaf Hering wrote:
I wonder why this command fails to show all commits that modify a given
function:
linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c
With commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has
const
I wonder why this command fails to show all commits that modify a given
function:
linux.git $ git log -p -M --stat -- drivers/hv/channel_mgmt.c
With commit 1f656ff3fdddc2f59649cc84b633b799908f1f7b init_vp_index() has
const uuid_le *type_guid already. And somewhere between commit
On Tue, Jul 14, 2015 at 12:59 AM, Olaf Hering o...@aepfle.de wrote:
On Tue, Jul 14, John Keeping wrote:
It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
That's not an evil merge. That's just a regular merge. One side had
changed the argument to const:
- 1b9d48f2a579
Olaf Hering o...@aepfle.de writes:
On Tue, Jul 14, John Keeping wrote:
It was added in an evil merge (f9da455b93f6ba076935b4ef4589f61e529ae046),
try:
git log -p -M --stat --cc -- drivers/hv/channel_mgmt.c
Thanks. Thats rather useless output...
Why do you think this is useless?
13 matches
Mail list logo
