From: Junio C Hamano <gitster@pobox.com>
To: Yann Dirson <ydirson@free.fr>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v7 1/3] Introduce bulk-move detection in diffcore.
Date: Thu, 28 Oct 2010 13:20:00 -0700 [thread overview]
Message-ID: <7vr5fa9ij3.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20101025201227.GB3347@home.lan> (Yann Dirson's message of "Mon\, 25 Oct 2010 22\:12\:27 +0200")
Yann Dirson <ydirson@free.fr> 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?
next prev parent reply other threads:[~2010-10-28 20:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-23 21:06 [PATCH v7 0/3] Detection of directory renames Yann Dirson
2010-10-23 21:07 ` [PATCH v7 1/3] Introduce bulk-move detection in diffcore Yann Dirson
2010-10-25 8:08 ` Junio C Hamano
2010-10-25 20:12 ` Yann Dirson
2010-10-26 18:13 ` Bulk move and some of its close relatives Yann Dirson
2010-10-27 7:05 ` Yann Dirson
2010-10-28 20:20 ` Junio C Hamano [this message]
2010-10-28 21:42 ` [PATCH v7 1/3] Introduce bulk-move detection in diffcore Yann Dirson
2010-10-23 21:07 ` [PATCH v7 2/3] Add testcases for the --detect-bulk-moves diffcore flag Yann Dirson
2010-10-23 21:07 ` [PATCH v7 3/3] [WIP] Allow hiding renames of individual files involved in a directory rename Yann Dirson
2010-10-24 21:10 ` [PATCH] [RFC] Add --detect-bulk-moves output to unidiff format Yann Dirson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vr5fa9ij3.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ydirson@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).