On 30 April 2013 21:38, Junio C Hamano wrote:
> John Tapsell writes:
>
>> On 30 April 2013 20:44, Junio C Hamano wrote:
>>> John Tapsell writes:
>>>
Is there no way to fix --cc to work even in the edge cases?
>>>
>>> Can you clarify what you mean by "fix" and "edge cases"?
>>
>> My underst
John Tapsell writes:
> On 30 April 2013 20:44, Junio C Hamano wrote:
>> John Tapsell writes:
>>
>>> Is there no way to fix --cc to work even in the edge cases?
>>
>> Can you clarify what you mean by "fix" and "edge cases"?
>
> My understanding is that even with -cc there will be changes that
>
On 30 April 2013 20:44, Junio C Hamano wrote:
> John Tapsell writes:
>
>> Is there no way to fix --cc to work even in the edge cases?
>
> Can you clarify what you mean by "fix" and "edge cases"?
My understanding is that even with -cc there will be changes that
won't be seen - and hence why --cc
John Tapsell writes:
> Is there no way to fix --cc to work even in the edge cases?
Can you clarify what you mean by "fix" and "edge cases"?
--
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.
On 30 April 2013 18:58, John Szakmeister wrote:
> On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
> wrote:
>> Junio C Hamano writes:
>>
>>> By the way, these options are _not_ about "showing merge commits
>>> that introduce code", and they do not help your kind of "security".
>>> As I repeatedly s
On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> By the way, these options are _not_ about "showing merge commits
>> that introduce code", and they do not help your kind of "security".
>> As I repeatedly said, you would need "-p -m" for that.
>
> Actually, while
Junio C Hamano writes:
> By the way, these options are _not_ about "showing merge commits
> that introduce code", and they do not help your kind of "security".
> As I repeatedly said, you would need "-p -m" for that.
Actually, while defaulting to --cc may be convenient, it would indeed
increase
On Tue, Apr 30, 2013 at 12:37 PM, Junio C Hamano wrote:
> John Szakmeister writes:
>
>>> When I added -c/--cc, I contemplated making -p imply --cc, but
>>> decided against it primarily because it is a change in traditional
>>> behaviour, and it is easy for users to say --cc instead of -p from
>>>
John Szakmeister writes:
>> When I added -c/--cc, I contemplated making -p imply --cc, but
>> decided against it primarily because it is a change in traditional
>> behaviour, and it is easy for users to say --cc instead of -p from
>> the command line.
>
> FWIW, security aside, I would've like to
Sorta OT, but I'm curious,
On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder wrote:
> For example, whenever git adds (or plans) support for a new header
> line in commit objects, before you've upgraded, a prankster can
> provide a bad value for that header line in objects they hand-craft.
> "git
On Sun, Apr 21, 2013 at 2:42 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> The thing is, I'm not convinced this is a bad default. "Shows no diff
>> at all for merges" is easy for a person to understand. It is much
>> easier to understand its limitations than -c and --cc.
>
> Making "
Jonathan Nieder writes:
> The thing is, I'm not convinced this is a bad default. "Shows no diff
> at all for merges" is easy for a person to understand. It is much
> easier to understand its limitations than -c and --cc.
Making "log -p -m" a default before -c/--cc was introduced would
have bee
Jonathan Nieder writes:
> That's why if you want to review the code you are pulling in as a
> whole, it is worthwhile to do
>
> git diff HEAD...FETCH_HEAD
>
> That is how you ask "What code changes does FETCH_HEAD introduce?"
> before putting your stamp of approval on them by merging and pu
John Tapsell wrote:
> Jonathan Nieder wrote:
>> If anyone relies on "git log -p" or "git log -p --cc" output to make
>> sure that the untrusted code they use doesn't introduce unwanted
>> behavior, they are making a serious mistake.
[...]
> You can't just push all the blame on the user for bad def
John Tapsell writes:
> On 21 April 2013 11:21, Jonathan Nieder wrote:
>
>> A merge can completely
>> undo important changes made in a side branch and "-c" and "--cc" will
>> not show it.
>
> Wait, what? This is getting even worse then! Can you expand on this please?
>
> And then how do I show
On 21 April 2013 11:21, Jonathan Nieder wrote:
> John Tapsell wrote:
>
>> I'm concerned that noone is taking this security risk seriously.
>
> If anyone relies on "git log -p" or "git log -p --cc" output to make
> sure that the untrusted code they use doesn't introduce unwanted
> behavior, they ar
John Tapsell wrote:
> I'm concerned that noone is taking this security risk seriously.
If anyone relies on "git log -p" or "git log -p --cc" output to make
sure that the untrusted code they use doesn't introduce unwanted
behavior, they are making a serious mistake. A merge can completely
undo im
On 21 April 2013 08:26, Junio C Hamano wrote:
> Simon Ruderich writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 104579d..cd35ec7 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -24,6 +24,10 @@ ifndef::g
Simon Ruderich writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 104579d..cd35ec7 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -24,6 +24,10 @@ ifndef::git-format-patch[]
> --patch::
> Generate patch (
On Thu, Apr 11, 2013 at 11:36:26AM +0100, John Tapsell wrote:
> Is there a way to make --cc default?
If you use aliases, something like this is easy:
git config --global --add alias.lp 'log --patch --cc'
I use aliases heavily, so that's my fix for now.
But I think the current behaviour is
On Thu, Apr 11, 2013 at 6:36 PM, John Tapsell wrote:
> I noticed that code that you put in merge will not be visible by
> default. This seems like a pretty horrible security problem, no?
>
> I made the following test tree, with just 3 commits:
>
> https://github.com/johnflux/ExampleEvilness.git
Hi,
I noticed that code that you put in merge will not be visible by
default. This seems like a pretty horrible security problem, no?
I made the following test tree, with just 3 commits:
https://github.com/johnflux/ExampleEvilness.git
Doing "git log -p" shows all very innocent commits. Com
22 matches
Mail list logo
