All of lore.kernel.org
 help / color / mirror / Atom feed
* Git p4 sync changelist interval
@ 2017-06-04  9:56 Андрей Ефанов
  2017-06-04 11:09 ` Luke Diamand
  0 siblings, 1 reply; 8+ messages in thread
From: Андрей Ефанов @ 2017-06-04  9:56 UTC (permalink / raw)
  To: git

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?

Regards,
Andrew Yefanov

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  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>
  0 siblings, 1 reply; 8+ messages in thread
From: Luke Diamand @ 2017-06-04 11:09 UTC (permalink / raw)
  To: Андрей
	Ефанов
  Cc: Git Users

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?

Thanks!
Luke

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Fwd: Git p4 sync changelist interval
       [not found]   ` <CAKOu8-2iBV=sAP0WeRMQFT+0y5cJ1g6A3bQ5x=D=8q9ocxnBVg@mail.gmail.com>
@ 2017-06-05 18:50     ` Андрей Ефанов
  2017-06-05 23:29       ` Luke Diamand
  0 siblings, 1 reply; 8+ messages in thread
From: Андрей Ефанов @ 2017-06-05 18:50 UTC (permalink / raw)
  To: git, Luke Diamand

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.

Regards,
Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  2017-06-05 18:50     ` Fwd: " Андрей Ефанов
@ 2017-06-05 23:29       ` Luke Diamand
  2017-06-06  7:00         ` Luke Diamand
  0 siblings, 1 reply; 8+ messages in thread
From: Luke Diamand @ 2017-06-05 23:29 UTC (permalink / raw)
  To: Андрей
	Ефанов
  Cc: Git Users

On 5 June 2017 at 19:50, Андрей Ефанов <1134togo@gmail.com> wrote:
> 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.

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

Luke

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  2017-06-05 23:29       ` Luke Diamand
@ 2017-06-06  7:00         ` Luke Diamand
  2017-06-06  7:49           ` Luke Diamand
  0 siblings, 1 reply; 8+ messages in thread
From: Luke Diamand @ 2017-06-06  7:00 UTC (permalink / raw)
  To: Андрей
	Ефанов
  Cc: Git Users

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  2017-06-06  7:00         ` Luke Diamand
@ 2017-06-06  7:49           ` Luke Diamand
  2017-06-06  7:56             ` Андрей Ефанов
  0 siblings, 1 reply; 8+ messages in thread
From: Luke Diamand @ 2017-06-06  7:49 UTC (permalink / raw)
  To: Андрей
	Ефанов
  Cc: Git Users

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  2017-06-06  7:49           ` Luke Diamand
@ 2017-06-06  7:56             ` Андрей Ефанов
  2017-06-06 10:54               ` Luke Diamand
  0 siblings, 1 reply; 8+ messages in thread
From: Андрей Ефанов @ 2017-06-06  7:56 UTC (permalink / raw)
  To: Luke Diamand, git

2017-06-06 10:49 GMT+03:00 Luke Diamand <luke@diamand.org>:
> 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

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.

Andrew

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Git p4 sync changelist interval
  2017-06-06  7:56             ` Андрей Ефанов
@ 2017-06-06 10:54               ` Luke Diamand
  0 siblings, 0 replies; 8+ messages in thread
From: Luke Diamand @ 2017-06-06 10:54 UTC (permalink / raw)
  To: Андрей
	Ефанов
  Cc: Git Users

On 6 June 2017 at 08:56, Андрей Ефанов <1134togo@gmail.com> wrote:
>>
>> 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.

It's a bug!

I think you can workaround it by doing:

$ git p4 clone //depot@3
$ git p4 sync

I'll see if I can workout why my obvious fix caused the tests to fail.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-06-06 10:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2017-06-06  7:56             ` Андрей Ефанов
2017-06-06 10:54               ` Luke Diamand

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.