Code changes in merge commits

Hi, Our team just struggled with this problem, and I've created a simple, 3 commit large, example git repository to demonstrate the problem: https://github.com/johnflux/ExampleEvilness2 The code: Adds a file, adds a security fix commit, then removes the fix during a merge. This happened by

Re: Code changes in merge commits

to see all the code changes to a code base just with git log -p. Any thoughts? Thanks, John Tapsell -- 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

Re: Code changes in merge commits

What I'd love to see with git log -p is the diff between a trivial merge (possibly including conflict markers) and the actual merge commit. That would imply that git log would redo the merge before computing the diff (rather heavyweight :-( ), but an empty diff would mean no change other than

git reflog --date

Hi all, Could we add a default to --date so that: git reflog --date just works? (Currently you need to do: git reflog --date=iso) It should probably obey the default in log.date? Also, could we add this --date option to the man page please? It's an extremely useful option to know. At

Re: git reflog --date

. My opinion: 1. Add --date as an option to reflog. Perhaps using the log.date format as the default. 2. Document --date in the man page for git reflog 3. Document @{now} in the man page for git reflog Sound good? John On 21 October 2014 18:24, Junio C Hamano gits...@pobox.com wrote: John

Re: git reflog --date

Great - now I just need to persuade someone very nice nicely.. :-) On 21 October 2014 19:06, Junio C Hamano gits...@pobox.com wrote: John Tapsell johnf...@gmail.com writes: For me, writing git reflog @{now} is a lot less intuitive than git reflog --date Currently the top google search

RFC: Very useful script to SVG graph the git commits from a file orientated view

Hi, I made this script to help me see the logical connections between commits. It produces a .svg graph showing the commits that affected a file. For example, say you have the commits: commit1 - modify hello.c commit2 - modify goodbye.c commit3 - modify hello.c and goodbye.c It will draw a

Re: RFC: Very useful script to SVG graph the git commits from a file orientated view

Opps, somehow I forgot to actually attach it. It's now attached graph_git.pl Description: Binary data

git log -p unexpected behaviour - security risk?

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.

Re: git log -p unexpected behaviour - security risk?

On 21 April 2013 08:26, Junio C Hamano gits...@pobox.com wrote: Simon Ruderich si...@ruderich.org 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 @@

Re: git log -p unexpected behaviour - security risk?

On 21 April 2013 11:21, Jonathan Nieder jrnie...@gmail.com 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

Re: git log -p unexpected behaviour - security risk?

On 30 April 2013 18:58, John Szakmeister j...@szakmeister.net wrote: On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Junio C Hamano gits...@pobox.com writes: By the way, these options are _not_ about showing merge commits that introduce code, and they do not

Re: git log -p unexpected behaviour

On 30 April 2013 20:44, Junio C Hamano gits...@pobox.com wrote: John Tapsell johnf...@gmail.com 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

Improving git branch

I start making patches etc, what do people think? Would I have a chance of getting this in? Should I change some aspects etc? Thanks, John Tapsell -- 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

Re: Improving git branch

I don't fully understand - if I did that, then what difference would an average user actually see? On 17 December 2014 at 11:28, Michael J Gruber g...@drmicha.warpmail.net wrote: John Tapsell schrieb am 17.12.2014 um 12:10: Hi all, I'm interested in putting in some time and effort