Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH] Resurrect diff-tree-helper -R

From: Petr Baudis <hidden>
Date: 2016-06-15 22:41:57

Dear diary, on Sat, May 14, 2005 at 02:33:11AM CEST, I got a letter
where Junio C Hamano [off-list ref] told me that...
Another possibility.  How about generating the following _only_
when mode changes (including create and delete), even for human
consumption?  There will be _no_ such line when mode or type
does not change.

# mode: 100644 100755 path/to/a/file/that/changed/mode
# mode: 100644 120000 path/to/a/file/that/changed/to/symlink
# mode: 100644 100644 path/to/a/file/with/no/mode/change
# mode: . 100644 path/to/a/new/file
# mode: 100644 . path/to/a/deleted/file

This is not "something like this", but a proposal for the exact
output format specification (I am going to code immediately).
Each token above is separated with exactly one ' ' (ASCII 0x20)
each, and such a line comes immediately before the patch for the
file.  Showing both mode bits is to prepare for the case you
would want to apply the patch in reverse.

This is for machine consumption and there is no need to force
them to parse out -> and (), so I dropped them.  And mode or
type change happens so rarely, it would be OK for human
consumption if we show these garbage (from human point of view)
only when things change.  Can you parse this, or do you always
want to have them even if nothing changes?

Let's see how this would look like to humans.
For humans I'd say "Mode change" instead of "mode" would be better, and
for machines I still think "@" would be better than "#". "#" can occur
quite naturally in some code snippets or whatever pasted to the commit
message, which is extremely unlikely for "@". What are the advantages
of "#"?

I like the rest. That's basically what I've imagined, and without the
arrows it's even better. :-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help