[RFD] diff-tree -c (not --cc) in diff-raw format?

The second paragraph from this log caught my attention:

    commit cb80775b530a8a340a7f9e4fecc8feaaac13777c
    Author: Marco Costalba <mcostalba@gmail.com>
    Date:   Sun Jan 29 12:27:34 2006 +0100

        Use git-diff-tree -c (combined) option to retrieve merge's
        file list

        Change un-interesting files pruning algorithm to use native
        git-diff-tree -c option when showing merge files in files
        list box.

The current diff-tree -c is rather expensive way to do this. I made both -c and --cc to always produce patches, but this suggests at least qgit would benefit if I allow -c in diff-raw format. Essentially, you are interested in paths that the results do not match _any_ of the parents.

So instead of 70 lines output from

	$ git-diff-tree -m -r --abbrev v1.0.0

I could give you:

        $ git-diff-tree -c -m -r --abbrev v1.0.0
        c2f3bf071ee90b01f2d629921bb04c4f798f02fa
        :100644 100644 92cfee4... e9bf860... M	Makefile
        :100644 100644 d36904c... 4fa6c16... M	debian/changelog
        c2f3bf071ee90b01f2d629921bb04c4f798f02fa
        :100644 100644 50392ff... e9bf860... M	Makefile
        :100644 100644 376f0fa... 4fa6c16... M	debian/changelog

or even:

        $ git-diff-tree -c -m -r --name-only v1.0.0
        c2f3bf071ee90b01f2d629921bb04c4f798f02fa
        Makefile
        debian/changelog

I am not so sure which one is more useful, though. What do you think?

On the other hand, git-diff-tree --cc needs to look at the diff between result and parents of the merge in order to do its job hunk-per-hunk, so producing diff-raw output fundamentally does not make sense for that option.

I should keep track of qgit repository more often but I haven't been doing so because the site used to be almost unpullable over http (it seems to work just fine these days so it is not an excuse for me anymore) and I do not read C++ too well (bad excuse perhaps but still an excuse for me).

On 2/4/06, Junio C Hamano <junkio@cox.net> wrote:

Yes. that would be great!

If you look at the patch you see I actually run something like this

         git-diff-tree -c <sha> | grep "diff --combined"

to get the 'interesting' file list.

The first one without --abbrev option

 git-diff-tree -c -m -r c2f3bf071ee90b01f2d629921bb04c4f798f02fa

So to recycle my common diff-tree parsing code. Peraphs better, if possible, I would suggest to treat -c option as all the other options, so to be possible to use something like

git-diff-tree -c -r c2f3bf071ee90b01f2d629921bb04c4f798f02fa git-diff-tree -c -r --name-only v1.0.0 git-diff-tree -c -r --abbrev v1.0.0 git-diff-tree -c -r c2f3bf071ee90b01f2d629921bb04c4f798f02fa foo.c

and so on....

As you see -c _could_ imply -m

The current -c behaviour _could_ be obtained with

git-diff-tree -c -r -p <sha>

I didn't check the combined code to see if what I suggest is easy/possible.

No problem, I do not read C++ too well too. ;-)

Marco

Marco Costalba <mcostalba@gmail.com> writes:

In case it was not clear, it already implies -m and does not skip merges even if you do not give -m. Otherwise you would not see anything without saying "diff-tree -c -m' to begin with.