ing file2 as source, making unnecessary assumptions about
implementation details. Is this correct, or do I misunderstand the
workings of diff-tree?
I'd be grateful for advice, both on whether this is a bug, and if so,
which branch to base a patch on.
Best regards
Christoph Bonitz
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 7, 2014 at 11:14 PM, Junio C Hamano wrote:
> "Choosing any of these as the copy source is fine" is a sensible way
> to fix the problem with this test. Would it be a better solution to
> avoid having multiple/ambiguous copy source candidates in the first
> place, by the way?
I agree
The scenario in the rename test makes unnecessary assumptions about
which file git file-tree will detect as a source for a copy-operations.
Furthermore, copy detection is not tested by checking the resulting
perforce revision history via p4 filelog, but via git diff-tree.
This patch makes the test
On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt wrote:
> Am 23.07.2014 23:28, schrieb Christoph Bonitz:
>> - test "$src" = file10 || test "$src" = file11 &&
>> + test "$src" = file2 || test "$src" = file10 || test "$src"
On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano wrote:
> Johannes Sixt writes:
>> I see a few other no-nos in the context of the changes, in particular,
>> pipelines where git is not the last command; these would not catch
>> failures in the git commands. But a fix for that is certainly outside
5 matches
Mail list logo
