Git p4 sync changelist interval

> Hello,
>
> My goal is to sync the repository from p4 using an interval of
> changelists so that the first changelist version of the repository
> would be considered as an initial commit.
> So I used the following command:
>
>  git p4 clone //depot@cl1,cl2
>
> And when it finished, the files, that were created before the cl1 were
> not in the HEAD.

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

>
> On 4 June 2017 at 10:56, Андрей Ефанов <1134togo@gmail.com> wrote:
> > Hello,
> >
> > My goal is to sync the repository from p4 using an interval of
> > changelists so that the first changelist version of the repository
> > would be considered as an initial commit.
> > So I used the following command:
> >
> >  git p4 clone //depot@cl1,cl2
> >
> > And when it finished, the files, that were created before the cl1 were
> > not in the HEAD.
>
> Do you mean that if foo.c was created at cl1+1, that after doing the
> clone, it wasn't there?
>
> If so, that doesn't sound right to me.
>
> I have just tried doing what I think you mean:
>
> 1. Create p4 depot
> 2. Add foo.c (at CL 2)
> 3. Add bar.c (at CL 3)
> 4. git-p4 clone //depot@2,3
>
> I end up with both files.
>
> >
> > 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?

> 2017-06-04 14:09 GMT+03:00 Luke Diamand <luke@diamand.org>:
>>
>> On 4 June 2017 at 10:56, Андрей Ефанов <1134togo@gmail.com> wrote:
>> > Hello,
>> >
>> > My goal is to sync the repository from p4 using an interval of
>> > changelists so that the first changelist version of the repository
>> > would be considered as an initial commit.
>> > So I used the following command:
>> >
>> >  git p4 clone //depot@cl1,cl2
>> >
>> > And when it finished, the files, that were created before the cl1 were
>> > not in the HEAD.
>>
>> Do you mean that if foo.c was created at cl1+1, that after doing the
>> clone, it wasn't there?
>>
>> If so, that doesn't sound right to me.
>>
>> I have just tried doing what I think you mean:
>>
>> 1. Create p4 depot
>> 2. Add foo.c (at CL 2)
>> 3. Add bar.c (at CL 3)
>> 4. git-p4 clone //depot@2,3
>>
>> I end up with both files.
>>
>> >
>> > 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.

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

> 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

> 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

>>
>> 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
>
> I did the same change before and it worked for me. I'd like to find
> out if it is a bug (I think it is), a normal behavior or am I doing
> something wrong.
>
> So according to what you say, it is a bug.