Yann Dirson <ydirson@xxxxxxx> writes:
> OTOH, the quoting rules for diff output are quite minimalist, I don't
> know whether adding "*" as a character that requires quotes around the
> filename would be acceptable.
I suspect that would be an unacceptable entry to a slippery slope.
>> IOW, is the goal of this series
>> to use the "A/* -> B/" to label the change as bulk directory rename, if
>> the preimage has A/{1,2,3} and the postimage has their moved contents in
>> B/{one,two,three}?
>
> Yes. But --hide-bulk-move-details would not hide them, as they would
> not be strictly included in the bulk move. Desite their name change,
> they are however a confirmation that the contents of A/ was move to B/.
>
>> I am wondering about the utility of such an extra information. If there
>> were no "a/file0 -> b/file3" entry in the example, I would imagine that we
>> could use this "a/* -> b/" information to move "a/file5" to "b/file5" when
>> rebasing this patch to apply to a different preimage that had files other
>> than file{1,2} in directory "a", and I would further imagine that might be
>> a wonderful thing.
>
> I imagined that as well, and that situation would not be a problem:
> since "a/file0 -> b/file3" would be there in the rebased patch,
> "apply" would be able to spot the possible conflict.
>
> OTOH, I had the vision of "merge does automatic moves" when starting
> this project, but got convinced on-list that there are always cases
> where the "automatic move" on merge would be wrong, and that we should
> report a conflict instead.
>
> That would mostly shift the problem to...
That would mostly make this patch not worth worrying about, wouldn't it?
What's the point of spending extra cycles to say "many things have moved
in the same direction" without turning it into a usable information?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html