Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/12/15 00:38, Sam Hocevar wrote:
I'm actually surprised that the patch changes the order at all,
since all it does is affect the decision (on a yes/no basis) to
include a given file into a changelist. I'm going to have a look at
that specific unit test, but of course as a user I'd prefer if the
default behaviour could remain the same, unless it was actually a
bug.


We ask for changes in
  //depot/sub1/...@1,6
  //depot/sub2/...@1,6'

which gives us [4, 6, 3, 5].

The old code used to sort this list but this change removes the sort.
Maybe putting the sort back would fix it?

I'm not sure if my opinion as an outsider is of use, but since the
perforce change number is monotonically increasing, my expectation as
a user would be for them to be applied in order by the perforce
change number.

In answer to James' question, the test checks that the most recent
change wins (i.e. applied in order).

Luke




--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]