All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Diamand <luke@diamand.org>
To: Sam Hocevar <sam@hocevar.net>, James Farwell <jfarwell@vmware.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Users <git@vger.kernel.org>,
	Lars Schneider <larsxschneider@gmail.com>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths
Date: Wed, 16 Dec 2015 07:51:39 +0000	[thread overview]
Message-ID: <5671180B.9010008@diamand.org> (raw)
In-Reply-To: <20151216003834.GG48528@hocevar.net>

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

      reply	other threads:[~2015-12-16  7:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-13 20:07 [PATCH 0/2] git-p4: fix for handling of multiple depot paths Luke Diamand
2015-12-13 20:07 ` [PATCH 1/2] git-p4: failing test case for skipping changes with multiple depots Luke Diamand
2015-12-13 20:07 ` [PATCH 2/2] git-p4: fix handling of multiple depot paths Luke Diamand
2015-12-13 20:19 ` [PATCH 0/2] git-p4: fix for " Luke Diamand
2015-12-14 19:16   ` Junio C Hamano
2015-12-14 20:58     ` Luke Diamand
2015-12-14 22:06       ` Junio C Hamano
2015-12-14 23:09         ` Luke Diamand
2015-12-15 22:56           ` James Farwell
2015-12-16  0:38             ` Sam Hocevar
2015-12-16  7:51               ` Luke Diamand [this message]

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=5671180B.9010008@diamand.org \
    --to=luke@diamand.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jfarwell@vmware.com \
    --cc=larsxschneider@gmail.com \
    --cc=sam@hocevar.net \
    --cc=sunshine@sunshineco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.