Discussion:
[RFD] diff-tree -c (not --cc) in diff-raw format?
Junio C Hamano
2006-02-04 00:18:38 UTC
Permalink
The second paragraph from this log caught my attention:

commit cb80775b530a8a340a7f9e4fecc8feaaac13777c
Author: Marco Costalba <***@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).
Marco Costalba
2006-02-04 06:18:35 UTC
Permalink
Post by Junio C Hamano
commit cb80775b530a8a340a7f9e4fecc8feaaac13777c
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.
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.
Post by Junio C Hamano
So instead of 70 lines output from
$ git-diff-tree -m -r --abbrev v1.0.0
$ 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
$ 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?
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.
Post by Junio C Hamano
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).
No problem, I do not read C++ too well too. ;-)

Marco
Junio C Hamano
2006-02-04 06:39:33 UTC
Permalink
Post by Marco Costalba
As you see -c _could_ imply -m
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.

Loading...