> * am/p4-branches-excludes (2019-04-02) 8 commits
> - git-p4: respect excluded paths when detecting branches
> - git-p4: add failing test for "git-p4: respect excluded paths when
> detecting branches"
> - git-p4: don't exclude other files with same prefix
> - git-p4: add failing test for "don
> On Mon, Apr 01, 2019 at 06:02:21PM +0000, Mazo, Andrey wrote:
>> diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
>> index 6a86d6996b..c48532e12b 100755
>> --- a/t/t9801-git-p4-branch.sh
>> +++ b/t/t9801-git-p4-branch.sh
>> @@ -608,10 +608,102
Our Perforce server experienced some kind of database corruption a few years
ago.
While the file data and revision history are mostly intact,
some metadata for several changesets got lost.
For example, inspecting certain changelists produces errors.
"""
$ p4 describe -s 12345
Date 2019/02/26 16:46
This patch series introduces two experimental features to git-p4,
unrelated to each other.
1. The first patch adds support for "inexact" label detection.
The feature lets git-p4 find a git commit for a Perforce label
even if there is no git commit with exact same changelist number as in
P
Labels in Perforce are not global, but can be placed on a particular
view/subdirectory.
This might pose difficulties when importing only parts of Perforce depot into a
git repository.
For example:
1. Depot layout is as follows:
//depot/metaproject/branch1/subprojectA/...
//depot/metaproj
> This series fixes a few cases with branch detection
> and handling of excludes by git-p4.
>
> This is the third iteration of the patch series.
> Changes since v2 [2]:
> * Added new test cases for case-insensitive branch detection.
Forgot to add:
* Added a fix for case-insensitive branch detec
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files despite being told to
when handling multiple branches.
I.e., it should exclude //depot/branch2/file2 when run with
-//depot/branch2/file2,
but doesn't do this right now.
The test is based on 'git p4 clone
Currently, excluded paths are only handled in the following cases:
* no branch detection;
* branch detection with using clientspec.
However, excluded paths are not respected in case of
branch detection without using clientspec.
Fix this by consulting the list of excluded paths
when splitting fi
Make sure not to exclude files unintentionally
if exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
Do this by ensuring that paths without a trailing "/" are only matched
completely.
Also, abort path search on the first
git-p4 knows how to handle case insensitivity in file paths
if core.ignorecase is set.
However, when determining a branch for a file,
it still does a case-sensitive prefix match.
This may result in some file changes to be lost on import.
For example, given the following commits
1. add //depot/mai
Currently, `cloneExclude` array is being groomed (by removing trailing "...")
on every changeset.
(since `extractFilesFromCommit()` is called on every imported changeset)
As a micro-optimization, do it once while parsing arguments.
Also, prepend "/" and remove trailing "..." at the same time.
Sig
In preparation for a fix, add a failing test case to test that
git-p4 doesn't fold the case in file paths
when doing branch detection case insensitively.
(i.e. when core.ignorecase is set)
Signed-off-by: Andrey Mazo
---
t/t9801-git-p4-branch.sh | 92
1 fi
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files with the same prefix unintentionally
when exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
or don't exclude "//depot/discard_file
Under certain circumstances, gitCommitByP4Change() can enter an infinite
loop resulting in `git p4 sync` hanging forever.
The problem is that
`git rev-list --bisect ^` can return ``,
which would result in reinspecting and potentially an infinite loop.
This can happen when importing just a subse
This series fixes a few cases with branch detection
and handling of excludes by git-p4.
This is the third iteration of the patch series.
Changes since v2 [2]:
* Added new test cases for case-insensitive branch detection.
Changes since v1 [1]:
* Added new test case for excluded paths when detec
Labels in Perforce are not global, but can be placed on a particular
view/subdirectory.
This might pose difficulties when importing only parts of Perforce depot into a
git repository.
For example:
1. Depot layout is as follows:
//depot/metaproject/branch1/subprojectA/...
//depot/metaproj
>> Labels in Perforce are not global, but can be placed on a particular
>> view/subdirectory.
>> This might pose difficulties when importing only parts of Perforce depot
>> into a git repository.
>> For example:
>> 1. Depot layout is as follows:
>> //depot/metaproject/branch1/subprojectA/...
23.03.2019, 04:44, "Luke Diamand" :
> On Fri, 22 Mar 2019 at 19:54, Mazo, Andrey wrote:
>> Our Perforce server experienced some kind of database corruption a few
>> years ago.
>> While the file data and revision history are mostly intact,
>> some met
From: "Mazo, Andrey"
23.03.2019, 05:16, "Luke Diamand" :
> On Thu, 21 Mar 2019 at 22:32, Mazo, Andrey wrote:
>> git-p4 knows how to handle case insensitivity in file paths
>> if core.ignorecase is set.
>> However, when determining a branch for a
Our Perforce server experienced some kind of database corruption a few years
ago.
While the file data and revision history are mostly intact,
some metadata for several changesets got lost.
For example, inspecting certain changelists produces errors.
"""
$ p4 describe -s 12345
Date 2019/02/26 16:46
Labels in Perforce are not global, but can be placed on a particular
view/subdirectory.
This might pose difficulties when importing only parts of Perforce depot into a
git repository.
For example:
1. Depot layout is as follows:
//depot/metaproject/branch1/subprojectA/...
//depot/metaproj
This patch series introduces two experimental features to git-p4,
which unrelated to each other.
1. The first patch adds support for so-called "alien" branches.
The feature lets git-p4 create empty commits
to make the history or tags more accurate.
It is particularly useful when spli
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files despite being told to
when handling multiple branches.
I.e., it should exclude //depot/branch2/file2 when run with
-//depot/branch2/file2,
but doesn't do this right now.
The test is based on 'git p4 clone
Currently, excluded paths are only handled in the following cases:
* no branch detection;
* branch detection with using clientspec.
However, excluded paths are not respected in case of
branch detection without using clientspec.
Fix this by consulting the list of excluded paths
when splitting fi
Currently, `cloneExclude` array is being groomed (by removing trailing "...")
on every changeset.
(since `extractFilesFromCommit()` is called on every imported changeset)
As a micro-optimization, do it once while parsing arguments.
Also, prepend "/" and remove trailing "..." at the same time.
Sig
Make sure not to exclude files unintentionally
if exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
Do this by ensuring that paths without a trailing "/" are only matched
completely.
Also, abort path search on the first
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files with the same prefix unintentionally
when exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
or don't exclude "//depot/discard_file
Under certain circumstances, gitCommitByP4Change() can enter an infinite
loop resulting in `git p4 sync` hanging forever.
The problem is that
`git rev-list --bisect ^` can return ``,
which would result in reinspecting and potentially an infinite loop.
This can happen when importing just a subse
This series fixes a few cases with branch detection
and handling of excludes by git-p4.
This is the second iteration of the patch series.
Changes since the v1 [1]:
* Added new test case for excluded paths when detecting branches;
* Added a new fix for excluded paths when detecting branches.
[1]
git-p4 knows how to handle case insensitivity in file paths
if core.ignorecase is set.
However, when determining a branch for a file,
it still does a case-sensitive prefix match.
This may result in some file changes to be lost on import.
For example, given the following commits
1. add //depot/mai
>
> Hello,
>
> we are periodically doing a 'git p4 sync' on a p4 clone that was initially
> created by 'git p4 clone --bare //DEPOT'. Now on P4 side the mail addresses
> have
> changed, but git still uses the old addresses.
> p4 users already shows the new addresses but new changes in the git lo
This series fixes a couple of corner cases with branch detection
and handling of excludes by git-p4.
Andrey Mazo (5):
git-p4: detect/prevent infinite loop in gitCommitByP4Change()
git-p4: match branches case insensitively if configured
git-p4: don't groom exclude path list on every commit
Under certain circumstances, gitCommitByP4Change() can enter an infinite
loop resulting in `git p4 sync` hanging forever.
The problem is that
`git rev-list --bisect ^` can return ``,
which would result in reinspecting and potentially an infinite loop.
This can happen when importing just a subse
git-p4 knows how to handle case insensitivity in file paths
if core.ignorecase is set.
However, when determining a branch for a file,
it still does a case-sensitive prefix match.
This may result in some file changes to be lost on import.
For example, given the following commits
1. add //depot/mai
Make sure not to exclude files unintentionally
if exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
Do this by ensuring that paths without a trailing "/" are only matched
completely.
Also, abort path search on the first
Currently, `cloneExclude` array is being groomed (by removing trailing "...")
on every changeset.
(since `extractFilesFromCommit()` is called on every imported changeset)
As a micro-optimization, do it once while parsing arguments.
Also, prepend "/" and remove trailing "..." at the same time.
Sig
In preparation for a fix, add a failing test case to test that
git-p4 doesn't exclude files with the same prefix unintentionally
when exclude paths are specified without a trailing /.
I.e., don't exclude "//depot/file_dont_exclude" if run with "-//depot/file".
or don't exclude "//depot/discard_file
> This updates the patchset to support copy, as suggested by Andrey.
>
> Luke Diamand (2):
> git-p4: add failing test for shelved CL update involving move/copy
> git-p4: handle update of moved/copied files when updating a shelve
>
> git-p4.py| 2 ++
> t/t9807-git-p4-submit.s
>
> Updating a shelved P4 changelist where one or more files have
> been moved does not work. Add a test for this.
>
> The problem is that P4 requires a complete list of the files being
> changed, and move/rename only includes the _source_ in the case of
> updating a shelved changelist. This resu
> git-p4 can map a "git move" operation to a Perforce "move" operation.
> But by default this is disabled. You then end up with a P4 commit
> where the file is deleted, and a fresh file is created with the same
> contents at the new location at revision #1.
>
> Rename detection gets enabled either
On Sun, 6 Jan 2019 at 22:48, Peter Osterlund wrote:
> Hi,
>
> When I use "git p4 sync" to update a git repository from a perforce depot,
> the operation fails with error message:
>
> failure accessing depot: unknown error code info
>
I guess, this got broken in
commit 0ef67acdd78 ("git-p4
>> This was actually discussed in a separate thread [1] some time ago with
>> patches proposed by Thandesha and me.
>> I haven't yet got time to cook a final patch, which addresses both
>> Thandesha's and mine use-cases though,
>> so this wasn't submitted to Junio yet.
>> In the meantime, I guess
> The last one (i.e. "even if it is verbose, if fileSize is not
> reported, do not write the verbose output") does not look like it is
> limited to the unshelve feature, so it might, even though it is a
> one-liner, deserve to be a separate preparatory patch if you want.
> But I do not feel strongl
lematic file and keep
> moving (or should we abort??)
>
> Thanks
> Thandesha
>
> On Tue, Apr 17, 2018 at 2:18 PM, Mazo, Andrey wrote:
>> Luke,
>>
>> Thank you for reviewing and acking my patch!
>> By the way, did you see Thandesha's proposed patch [
Luke,
Thank you for reviewing and acking my patch!
By the way, did you see Thandesha's proposed patch [1] to print a warning in
case of the missing "fileSize" attribute?
Should we go that route instead?
Or should we try harder to get the size by running `p4 -G sizes`?
[1]
https://public-inbox.o
atever reason, the code below uses sys.stdout.write() instead of print().
Should it be used here for consistency as well?
> + size = "-1"
> + else:
> + size = self.stream_file['fileSize']
> + size = int(size)
>
Sure, I totally agree.
Sorry, I just wasn't clear enough in my previous email.
I meant that your patch suppresses "%s --> %s (%i MB)" line in case "fileSize"
is not available,
while my patch suppresses just "(%i MB)" portion if the "fileSize" is not known.
In other words,
* if "fileSize" is known
Huh, I actually have a slightly different fix for the same issue.
It doesn't suppress the corresponding verbose output completely, but just
removes the size information from it.
I'll (try to) post it as a reply to this email.
Also, I'd mention that the workaround is trivial -- simply omit the "--
48 matches
Mail list logo