Great minds think alike.
(It does _truly_ trivial collapsing, but I think we both agree: it doesn't
do anything that we used to go git-merge-one-file on)
I was considering perhaps doing a first cut at that in git-merge-tree
already. Not sure.
One issue is that I think I may have to change the output format if I do
that. I should anyway.
Why?
It's hard to see where "one event" stops, and another starts. I stupidly
initially thought that you can do it entirely based on looking at the
numbers, but you can't. Right now you have to look at the pathname too,
which is kind of sad, and doesn't work after rename detection (since then
the pathnames won't be sorted any more, and one "event" can have different
pathnames in different stages).
[ Side note: it doesn't even work for file/directory conflicts, which can
have the same name, but are two different "events". So you'd actually
have to look at both mode _and_ filename to sort out if two lines that
start with "1" and "3" respectively are one event (removal in first
branch) or two events ("1" on one file: removal in both branches + "3"
on another file: add in second branch) ]
So to do the rename output, you can't use the same format as merge-tree
uses right _now_. We'd have to add a marker to mark what the event
boundaries are.
The "mark" could be a running "event number", or even as easy as an
alternating character ("#" vs " " as the second character in the line or
similar)
So instead of
2 100644 ff280e2e1613e808e4d7844376134dfa2bb1fc21 Documentation/cputopology.txt
2 100644 28c5b7d1eb90f0ccd8e0307c170f89bd7954dc9c Documentation/hwmon/f71805f
1 100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
3 100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
2 100644 00a009b977e92b1a942d1138afdccf1b725df956 Documentation/i2c/busses/i2c-sis96x
2 100644 90a5e9e5bef1daa9d0f0621e209827f0d180f384 Documentation/unshare.txt
2 100644 5127f39fa9bf9a384a6529c6d5deb1002e945de5 arch/arm/mach-s3c2410/s3c2400-gpio.c
2 100644 8b2394e1ed4088c3b8d38e87e58bde2f38152bf7 arch/arm/mach-s3c2410/s3c2400.h
...
it migth be
2#100644 ff280e2e1613e808e4d7844376134dfa2bb1fc21 Documentation/cputopology.txt
2 100644 28c5b7d1eb90f0ccd8e0307c170f89bd7954dc9c Documentation/hwmon/f71805f
1#100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
3#100644 b88953dfd58022aef1680c266c7438605b146fc8 Documentation/i2c/busses/i2c-sis69x
2 100644 00a009b977e92b1a942d1138afdccf1b725df956 Documentation/i2c/busses/i2c-sis96x
2#100644 90a5e9e5bef1daa9d0f0621e209827f0d180f384 Documentation/unshare.txt
2 100644 5127f39fa9bf9a384a6529c6d5deb1002e945de5 arch/arm/mach-s3c2410/s3c2400-gpio.c
2#100644 8b2394e1ed4088c3b8d38e87e58bde2f38152bf7 arch/arm/mach-s3c2410/s3c2400.h
...
where you can clearly see the "grouping" without having to even look at
the filename.
(The example I show actually has a rename-with-modifications that was made
on the first branch: notice that i2c-sis69x vs i2c-sis96x thing?)
I don't know exactly what the "after rename detection" output format would
be, but it _might_ turn that
...
1#b889... i2c-sis69x
3#b889... i2c-sis69x
2 00a0... i2c-sis96x
...
into one event:
...
1#b889... i2c-sis69x
2#00a0... i2c-sis96x
3#b889... i2c-sis69x
...
and then the actual file-merge logic would have to merge the names as well
as the file contents (and in this case, the final name would thus be
"i2c-sis96x", since one branch hadn't changed it).
Hmm?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
