All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Diamand <luke@diamand.org>
To: "Андрей Ефанов" <1134togo@gmail.com>
Cc: Git Users <git@vger.kernel.org>
Subject: Re: Git p4 sync changelist interval
Date: Tue, 6 Jun 2017 08:49:24 +0100	[thread overview]
Message-ID: <CAE5ih7-+EzUhjXCCOu_oELof_2X_qf5snoqUZyuRNqEu+p=ewg@mail.gmail.com> (raw)
In-Reply-To: <CAE5ih7_yt4zjju3F34gUTKLPip9T98ow=shZY7EPe3yE8gk32Q@mail.gmail.com>

On 6 June 2017 at 08:00, Luke Diamand <luke@diamand.org> wrote:
> On 6 June 2017 at 00:29, Luke Diamand <luke@diamand.org> wrote:
>> On 5 June 2017 at 19:50, Андрей Ефанов <1134togo@gmail.com> wrote:
>>> 2017-06-04 14:09 GMT+03:00 Luke Diamand <luke@diamand.org>:
>>>>
>>>>
>>>> >
>>>> > The problem, as I see it, is that before syncing changes in the given
>>>> > range, p4 task does not sync to cl1 version of the repo, and applies
>>>> > commits to the empty repository.
>>>> > Is it a bug or my misunderstanding of how git p4 should work?
>>>>
>>>> Possibly I'm misunderstanding what you're doing! Can you give a
>>>> sequence of steps to show the problem?
>>>
>>> What I meant is:
>>>
>>> 1. Create p4 depot
>>> 2. Add first.file (CL 2)
>>> 3. Add second.file (at CL 3)
>>> 4. Add third.file (at CL 4)
>>> 5. Modify first.file (at CL 5)
>>> 4. git-p4 clone //depot@3,5
>>>
>>> In this case first.file, will not be represented in the repository.
>>
>> Hmmm, it's not working right for me. Although in my case I seem to be
>> missing the second file.
>>
>> It's fine if I don't use the revision range "3,5".
>
> It's also fine if I do:
>
> git p4 sync //depot@3
> cd depot
> git p4 rebase

It seems to be something to do with the code around line 3395 that says:

    if self.changeRange == "@all":
        self.changeRange = ""
    elif ',' not in self.changeRange:

It's finding a lower revision number with which to later call
importHeadRevision(), but that only seems to be called if the revision
range does *not* have a "," in it. As a result, we never actually call
importHeadRevision() and so files end up missing.

The obvious fix of fishing out the "@3" from the "@3,5" revision range
works in this instance, but breaks some of the regression tests.

Luke

  reply	other threads:[~2017-06-06  7:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-04  9:56 Git p4 sync changelist interval Андрей Ефанов
2017-06-04 11:09 ` Luke Diamand
     [not found]   ` <CAKOu8-2iBV=sAP0WeRMQFT+0y5cJ1g6A3bQ5x=D=8q9ocxnBVg@mail.gmail.com>
2017-06-05 18:50     ` Fwd: " Андрей Ефанов
2017-06-05 23:29       ` Luke Diamand
2017-06-06  7:00         ` Luke Diamand
2017-06-06  7:49           ` Luke Diamand [this message]
2017-06-06  7:56             ` Андрей Ефанов
2017-06-06 10:54               ` Luke Diamand

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='CAE5ih7-+EzUhjXCCOu_oELof_2X_qf5snoqUZyuRNqEu+p=ewg@mail.gmail.com' \
    --to=luke@diamand.org \
    --cc=1134togo@gmail.com \
    --cc=git@vger.kernel.org \
    /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.