Junio,
27.08.2019, 00:25, "Andrey Mazo" :
> From: Andrey Mazo
>
> I don't have access to my old work email since 20 Apr 2019.
> Replace with my personal email address.
>
> Signed-off-by: Andrey Mazo
> ---
> .mailmap | 1 +
> 1 file changed, 1 insert
real P4 repository to
test on,
so I can't really test anything beyond unit tests.
I'll be glad to review any changes though.
[1]
https://public-inbox.org/git/34d6121da46f35e4b81d38169b1b86ca123cef37.ca...@gmx.net/
[2] https://python3statement.org/
Thank you,
Andrey.
From: Andrey Mazo
I don't have access to my old work email since 20 Apr 2019.
Replace with my personal email address.
Signed-off-by: Andrey Mazo
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 9a5ff04753..14fa041043 100644
--- a/.mailmap
etes after implicit close leaving with scope.
Original code had double-open exception on Windows
platform because file still open from NamedTemporaryFile()
using generated filename instead of object.
Thanks to Andrey for patiently suggesting several
iterations on this change for avoiding exceptions!
> On Aug 26, 2019, at 11:33 AM, Jeff King wrote:
>
> On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
>
>> "Andrey Portnoy via GitGitGadget" writes:
>>
>>> Previously sprintf was the argument to the BANNED macro, where vsprintf
> On Aug 26, 2019, at 11:33 AM, Jeff King wrote:
>
> On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
>
>> "Andrey Portnoy via GitGitGadget" writes:
>>
>>> Previously sprintf was the argument to the BANNED macro, where vsprintf
From: Andrey Portnoy
Previously sprintf was the argument to the BANNED macro, where vsprintf
is expected.
Signed-off-by: Andrey Portnoy
---
banned.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/banned.h b/banned.h
index 447af24807..60a18d4403 100644
--- a/banned.h
+++ b
Previously sprintf was the argument to the BANNED macro, where vsprintf is
expected.
Andrey Portnoy (1):
banned.h: fix vsprintf warning
banned.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 75b2f01a0f642b39b0f29b6218515df9b5eb798e
Published-As:
https://github.com
Perforce
branches.
(some files may exist in git when they are deleted from Perforce due to the
aforementioned branch-into-non-empty directory issue)
> These are great tips, thanks! Maybe what I will do is sync each branch
> separately with no branch mappings, then use this technique to create
> merge commits for the initial branch creation commits only and not
> worry about any other integrations.
If commits for integrations have consistent commit messages,
you might be able to get merge commits using `git replace` cheaper than by
modifying git-p4 itself (which can't rely on commit messages).
--
Andrey.
a low-tech low-risk option for me.
Also, beware that git-p4 doesn't handle branch-into-non-empty directory
properly.
If I remember correctly, something like
`p4 copy //depot/branchA/... //depot/branchB/... ; p4 submit; p4 copy
//depot/branchC/... //depot/branchB/...; p4 submit`
will result in branchB having _both_ branchA and branchC contents in git.
`git filter-branch` or `git rebase` are your friends to workaround this.
(or better fix git-p4, of course)
> I'm using Git 2.22.1.
>
> Thanks,
> Aaron
Hope this help,
Andrey.
01.08.2019, 11:30, "Philip McGraw" :
>> From: Andrey
>> Sent: Wednesday, 31 July, 2019 21:35
>> To: Philip McGraw
>> Cc: git@vger.kernel.org; l...@diamand.org
>> Subject: Re: [PATCH] git-p4: close temporary file before removing
>>
>> 3
ws platform from using
> already open NamedTemporaryFile() generated filename instead of object.
>
> Thanks to Andrey for patiently suggesting several iterations on this change
> for avoiding exceptions!
>
> Also print error details after resulting IOError to make debugging cause of
se-temporary-file-before-remove-v2-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/301
> --
> gitgitgadget
Please, feel free to add
Reviewed-by: Andrey Mazo
Thank you,
Andrey.
31.07.2019, 17:52, "Philip McGraw" :
> 2019.07.31 10:09 Andrey
>> 31.07.2019, 09:53, "Philip McGraw" :
>>>> 30.07.2019, 13:37, "Philip McGraw" :
>>>> > python os.remove() throws exceptions on Windows platform when
>&
>
>> I'm not sure why NamedTemporaryFile() is called with delete=False above,
>> but it appears to me that it can have delete=True instead,
>> so that there is no need to call os.remove() explicitly
>> and thus worry about remove vs close ordering at all.
>>
ed with delete=False above,
but it appears to me that it can have delete=True instead,
so that there is no need to call os.remove() explicitly
and thus worry about remove vs close ordering at all.
> if compressedContentsSize >
> gitConfigInt('git-p4.largeFileCompressedThreshold'):
> return True
> return False
> --
> 2.21.0.windows.1
Thank you,
Andrey.
On Tue, Jul 30, 2019 at 3:13 PM Junio C Hamano wrote:
>
> Dmitry Safonov writes:
>
> > I was almost certain that git won't let me send the same patch twice,
>
> Why? And more importantly, does it matter to readers of this
> message what you thought?
Sounds rude. What matter to readers except au
25.06.2019, 13:44, "Junio C Hamano" :
> Andrey writes:
>
>>> Thanks. When I ask "Is this ready", I am asking for opinion(s) from
>>> third-party, not self nomination ;-)
>>
>> Ah, ok, sorry. :)
>> I just haven't seen any r
24.06.2019, 13:05, "Junio C Hamano" :
> Andrey writes:
>
>> 20.06.2019, 00:35, "Junio C Hamano" :
>>> * am/p4-branches-excludes (2019-04-02) 8 commits
>>> - git-p4: respect excluded paths when detecting branches
>>> - git-p4
ing test for "git-p4: match branches case insensitively if
> configured"
> - git-p4: detect/prevent infinite loop in gitCommitByP4Change()
>
> "git p4" update.
>
> Is this ready for 'next'?
Junio,
I haven't got any new feedback on the patch series in the past 2.5 months.
>From my point of view, these are ready for next.
Thank you,
Andrey.
ed
discussions starting tomorrow, April 11.
Should I resend my patches from my personal address and/or add another s-o-b?
Like
"""
Signed-off-by: Andrey Mazo
Signed-off-by: Andrey Mazo
"""
Also, I won't have access to a large Perforce server after April 19,
which was good for testing.
--
Andrey
> On Mon, Apr 01, 2019 at 06:02:21PM +, 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
p4_unmarshal(p4_changes_output)
p4_files_unmarshalled = p4_unmarshal(p4_files_output)
described_cl = p4_changes_unmarshalled[0] # there is usually only
one entry
described_cl['desc'] += '\n'
assert described_cl['c
oading changelist descriptions
from files
[1] https://public-inbox.org/git/cover.1554141338.git.am...@checkvideo.com/
Andrey Mazo (2):
git-p4: inexact label detection
git-p4: support loading changelist descriptions from files
Documentation/git-p4.txt | 41 +++
git
ps://public-inbox.org/git/b02df749b9266ac8c73707617a171122156621ab.1553283214.git.am...@checkvideo.com/
Signed-off-by: Andrey Mazo
Suggested-by: Luke Diamand
---
Documentation/git-p4.txt | 14
git-p4.py| 48 +++-
2 files changed, 56 inse
5: 3330f88a0d = 6: 035abfff2a git-p4: don't exclude other files with same
> prefix
> 6: 6170d45951 = 7: 2bde24b7e4 git-p4: add failing test for "git-p4: respect
> excluded paths when detecting branches"
> 7: 758d8e8486 = 8: 6d3ffb98a7 git-p4: respect excluded paths when detecting
> branches
--
Andrey
cted to be missing from all branches due to explicit exclude.
Signed-off-by: Andrey Mazo
---
t/t9801-git-p4-branch.sh | 40
1 file changed, 40 insertions(+)
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index 4779448b4c..7530d22de2 100
files across branches.
Signed-off-by: Andrey Mazo
---
git-p4.py| 3 +--
t/t9801-git-p4-branch.sh | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index c47bd8c4d8..96c4b78dc7 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2708,12 +2708,11
ly.
Also, abort path search on the first match as a micro-optimization.
Signed-off-by: Andrey Mazo
---
git-p4.py | 21 ++---
t/t9817-git-p4-exclude.sh | 4 ++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 7edcbad055
StartsWith() function
for path prefix matches instead of always case-sensitive match.
Signed-off-by: Andrey Mazo
---
git-p4.py| 4 ++--
t/t9801-git-p4-branch.sh | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index c0a3068b6f..f3e5ccb7af 10
uot;..." at the same time.
Signed-off-by: Andrey Mazo
---
git-p4.py | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index f3e5ccb7af..7edcbad055 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1314,11 +1314,11 @@ class Command:
def __ini
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 ++
ot;.
or don't exclude "//depot/discard_file_not" if run with "-//depot/discard_file".
Signed-off-by: Andrey Mazo
---
t/t9817-git-p4-exclude.sh | 51 +++
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/t/t9817-git-p4-exclude.sh b
re, `git rev-list --bisect` can't return "latestCommit" again
by excluding it from the rev-list range explicitly.
Signed-off-by: Andrey Mazo
---
Notes:
I don't have a simple test-case for this yet,
and I was able to perform a few complex initial `git p4 sync` runs
without hi
035abfff2a git-p4: don't exclude other files with same
prefix
6: 6170d45951 = 7: 2bde24b7e4 git-p4: add failing test for "git-p4: respect
excluded paths when detecting branches"
7: 758d8e8486 = 8: 6d3ffb98a7 git-p4: respect excluded paths when detecting
branches
Andr
ps://public-inbox.org/git/b02df749b9266ac8c73707617a171122156621ab.1553283214.git.am...@checkvideo.com/
Signed-off-by: Andrey Mazo
Suggested-by: Luke Diamand
---
git-p4.py | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/git-p4.py b/git-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/...
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
'edit',
'rev1': '43',
'type1': 'text',
'depotFile2': '//depot/branch1/baz.doc',
'action2':'edit',
'rev2': '8',
&#
imported because it's placed on a commit which is
excluded.
For this use case, the config would be
```
git config --add git-p4.alienLabelBranchMap branch1/exclude_me:branch1
```
Note that the current implementation doesn't process alien branches
when a clientspec is used.
Diff best viewe
the first place.
This patch series should be applied on top of
"[PATCH v2 0/7] git-p4: a few assorted fixes for branches, excludes" [1]
[1]
https://public-inbox.org/git/cover.1551485349.git.am...@checkvideo.com/t/#m965fb5895d25d6b42638dd8efbb96e9fa9182978
Andrey Mazo (2):
git-p4: introd
cted to be missing from all branches due to explicit exclude.
Signed-off-by: Andrey Mazo
---
t/t9801-git-p4-branch.sh | 40
1 file changed, 40 insertions(+)
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index 6a86d6996b..4729f470b2 100
files across branches.
Signed-off-by: Andrey Mazo
---
git-p4.py| 3 +--
t/t9801-git-p4-branch.sh | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 162877aa82..148ea6f1b0 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2708,12 +2708,11
uot;..." at the same time.
Signed-off-by: Andrey Mazo
---
git-p4.py | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 91c610f960..a9f53e5b88 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1314,11 +1314,11 @@ class Command:
def __ini
ly.
Also, abort path search on the first match as a micro-optimization.
Signed-off-by: Andrey Mazo
---
git-p4.py | 21 ++---
t/t9817-git-p4-exclude.sh | 4 ++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index a9f53e5b88
ot;.
or don't exclude "//depot/discard_file_not" if run with "-//depot/discard_file".
Signed-off-by: Andrey Mazo
---
t/t9817-git-p4-exclude.sh | 51 +++
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/t/t9817-git-p4-exclude.sh b
re, `git rev-list --bisect` can't return "latestCommit" again
by excluding it from the rev-list range explicitly.
Signed-off-by: Andrey Mazo
---
Notes:
I don't have a simple test-case for this yet,
and I was able to perform a few complex initial `git p4 sync` runs
without hi
; 6: 6170d45951 git-p4: add failing test for "git-p4: respect
excluded paths when detecting branches"
-: -- > 7: 758d8e8486 git-p4: respect excluded paths when detecting
branches
Andrey Mazo (7):
git-p4: detect/prevent infinite loop in gitCommitByP4Change()
git-p4: match
StartsWith() function
for path prefix matches instead of always case-sensitive match.
Signed-off-by: Andrey Mazo
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index c0a3068b6f..91c610f960 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2721,11 +2721
usercache.txt"
(on Windows, it's under %USERPROFILE% as far as I can tell)
and repeat clone/sync.
Hope, this helps.
--
Andrey
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 c
re, `git rev-list --bisect` can't return "latestCommit" again
by excluding it from the rev-list range explicitly.
Signed-off-by: Andrey Mazo
---
Notes:
I don't have a simple test-case for this yet,
and I was able to perform a few complex initial `git p4 sync` runs
without hi
StartsWith() function
for path prefix matches instead of always case-sensitive match.
Signed-off-by: Andrey Mazo
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index c0a3068b6f..91c610f960 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2721,11 +2721
ly.
Also, abort path search on the first match as a micro-optimization.
Signed-off-by: Andrey Mazo
---
git-p4.py | 21 ++---
t/t9817-git-p4-exclude.sh | 4 ++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index a9f53e5b88
uot;..." at the same time.
Signed-off-by: Andrey Mazo
---
git-p4.py | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 91c610f960..a9f53e5b88 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1314,11 +1314,11 @@ class Command:
def __ini
ot;.
or don't exclude "//depot/discard_file_not" if run with "-//depot/discard_file".
Signed-off-by: Andrey Mazo
---
t/t9817-git-p4-exclude.sh | 51 +++
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/t/t9817-git-p4-exclude.sh b
> 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
oks very similar to the "move" case, so will probably fail in a
similar way, right?
For the "move" test case and the fix, please, feel free to add my
Acked-by: Andrey Mazo
(if it's of any use)
Thank you,
Andrey
t;
> Another option is to add a warning, but people just ignore warnings!
When such a warning would be shown?
Just before `p4 submit`?
I think, It might be hard to notice for large changesets.
Thank you,
Andrey
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
5207.1523981210.git.am...@checkvideo.com/
>
> Should I re-roll my patch without this change then?
If it's the question to me, then I'm fine either way -- I can rebase my changes
easily.
However, re-rolling your patch would probably make the aforementioned fileSize
patch apply cleanly to both maint and master branches.
Thank you,
Andrey Mazo
il.gmail.com/t/#mee2ec50a40242089741f808f06214a44278055b3
[2] "[PATCH 1/1] git-p4: fix `sync --verbose` traceback due to 'fileSize'"
https://public-inbox.org/git/2e2b2add4e4fffa4228b8ab9f6cd47fa9bf25207.1523981210.git.am...@checkvideo.com/
Thank you,
Andrey Mazo
ize".
So, it's definitely not a reason to abort.
Thank you,
Andrey
From: Thandesha VK
> My fix is for the case where p4 -G sizes not returning the key and
> value for fileSize. This can happen in some cases. Only option at that
> point of time is to warn the user about the prob
https://public-inbox.org/git/cajjpmi-plb4qcka5alkxa8b1vozfff+oaq0fguq9yviobrp...@mail.gmail.com/t/#m6053d2031020e08edd24ada6c9eb49721ebc4e27
Thank you,
Andrey
From: Luke Diamand
> On Tue, 17 Apr 2018, 09:22 Andrey Mazo, wrote:
>> Perforce server 2007.2 (and maybe others) doesn't retu
7;t know for sure.
However, `p4 -G sizes` works fine even with our p4 server.
Should we then go one step further and use `p4 -G sizes` to obtain the
"fileSize" when it's not returned by `p4 -G print`?
Or is it an overkill for a simple verbose print out?
Also, please, find one comment
s not known.
In other words,
* if "fileSize" is known:
** both yours and mine patches don't change existing behavior;
* if "fileSize" is not known:
** your patch makes streamOneP4File() not print anything;
** my patch makes streamOneP4File() print "%s --> %s".
simply omit the "--verbose"
option.
Thank you,
Andrey
by omitting the file size information from the verbose print out.
Also, don't use "self.stream_file" directly,
but rather use passed in "file" argument.
(which point to the same "self.stream_file" for all existing callers)
Signed-off-by: Andrey Mazo
---
gi
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.
Also, I'd mention that the workaround is trivial -- simply omit the "--verbose"
option.
Andre
Get rid of the duplicated getenv('GIT_MERGE_VERBOSITY') calls with the same
constant string argument. This makes code more readable and prevents typo in
the further development.
Signed-off-by: Andrey Okoshkin
Reviewed-by: Stefan Beller
---
Commit message is reworked according to th
ade via the environment as the one we checked earlier), and I
> can understand that it feels a bit redundant and ugly.
Yes, you absolutely right.
I believe this patch makes code more beautiful :-)
>>> Signed-off-by: Andrey Okoshkin
>>> Reviewed-by: Stefan Beller
>
trtol()
as these environment related functions could modify the string pointer returned
by the initial getenv() call.
Signed-off-by: Andrey Okoshkin
Reviewed-by: Stefan Beller
---
Added 'reviewed-by' field.
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Add lstat() error handling not only for ENOENT case.
Otherwise uninitialised 'struct stat st' variable is used later in case of
lstat() non-ENOENT failure which leads to processing of rubbish values of
file mode ('S_ISLNK(st.st_mode)' check) or size ('xsize_t(st.st_size)&
trtol()
as these environment related functions could modify the string pointer returned
by the initial getenv() call.
Signed-off-by: Andrey Okoshkin
---
I tried to rework the commit message.
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/merge-rec
Thanks, Eric, indeed it's better to change the commit message.
25.10.2017 14:53, Eric Sunshine wrote:
> On Wed, Oct 25, 2017 at 7:39 AM, Andrey Okoshkin
> wrote:
>> Check 'GIT_MERGE_VERBOSITY' environment variable only once in
>> init_merge_options().
>
ned-off-by: Andrey Okoshkin
Reviewed-by: Stefan Beller
---
Changes since the previous patch:
* no actions are taken between the merge_verbosity assignment and check.
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index
24.10.2017 22:52, Jeff King wrote:
> On Tue, Oct 24, 2017 at 07:11:24PM +0200, Martin Ågren wrote:
>
>> On 24 October 2017 at 18:45, Eric Sunshine wrote:
>>> On Tue, Oct 24, 2017 at 12:28 PM, Stefan Beller wrote:
>>>> On Tue, Oct 24, 2017 at 8:27 AM, Andrey
adable/maintainable when presenting this part of the code
> to the user.)
>
> With or without this change:
> Reviewed-by: Stefan Beller
Yes, in current situation it's more for readability. And I'll make the usage
of merge_verbosity just after the assignment.
--
Best regards,
Andrey Okoshkin
t regards,
Andrey Okoshkin
thread as getenv() is not thread-safe.
Signed-off-by: Andrey Okoshkin
---
merge-recursive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1494ffdb8..eaac98145 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2163
Add usage of xmalloc() instead of malloc() in add_to_trie() as xmalloc wraps
and checks memory allocation result.
Signed-off-by: Andrey Okoshkin
---
Hello,
I'm not sure but it looks like there is a missing check of the malloc result.
memcpy() may crash with SIGSEGV due to the memory alloc
Add check of the resolved HEAD reference while printing of a commit summary.
resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or
open() fail in files_read_raw_ref().
Such situation can be caused by race: file becomes inaccessible to this moment.
Signed-off-by: Andrey
Add check of the resolved HEAD reference while printing of a commit summary.
resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or
open() fail in files_read_raw_ref().
Such situation can be caused by race: file becomes inaccessible to this moment.
Signed-off-by: Andrey
19.10.2017 20:44, Jeff King wrote:
On Thu, Oct 19, 2017 at 12:36:50PM +0300, Andrey Okoshkin wrote:
Thanks, this looks good to me. One other possible minor improvement:
head = resolve_ref_unsafe("HEAD", 0, junk_oid.hash, NULL);
+ if (!head)
+ die(_(
: Andrey Okoshkin
---
Thank you for your review.
Changes since the previous patch:
* BUG is replaced with die, message;
* Message is changed.
builtin/commit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1a0da71a4..cc27c9af7 100644
--- a/builtin
x27;t know how much trouble it is
worth going to for that. It's buried behind a ref_transaction, and I
don't think builtin/commit.c ever sees the real name (though maybe it
would be a good feature of the transaction to record the destinations of
any symrefs we updated).
--
Best regards,
Andrey Okoshkin
Add check of the resolved HEAD reference while printing of a commit summary.
resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or
open() fail in files_read_raw_ref().
Such situation can be caused by race: file becomes inaccessible to this moment.
Signed-off-by: Andrey
:
> 'bdfdaa497 (strbuf.h: integrate api-strbuf.txt documentation,
> 2015-01-16)'
>
Also available from the context menu in gitk as "Copy commit summary".
--
Best regards, Andrey Rybak
Hi,
On 04.10.2016 11:11, Sandro Santilli wrote:
> The "post via gmane" link on https://git-scm.com/community points
> to an unexistent server 'post.gmane.org':
> http://post.gmane.org/post.php?group=gmane.comp.version-control.git
It would probably be better to address this on git-scm.com
github pa
On Thu, Jul 14, 2016 at 10:56 PM, Johannes Sixt wrote:
> Am 15.07.2016 um 04:42 schrieb Andrey Vagin:
>>
>> Currently git-clean removes only links and files, but
>> there can be special files like fifo, sockets, devices.
>>
>> I think git-clean has to remove th
Currently git-clean removes only links and files, but
there can be special files like fifo, sockets, devices.
I think git-clean has to remove them too.
Signed-off-by: Andrey Vagin
---
cache.h | 8
dir.c | 4
2 files changed, 12 insertions(+)
diff --git a/cache.h b/cache.h
Thanks Junio, I understand the option's meaning now :)
On Thu, Apr 14, 2016 at 4:37 AM, Junio C Hamano wrote:
> Andrey Hsiao writes:
>
>> Dear list:
>>
>> Just encountered the --merge option for git log.
>>
>> In the man page, it has the following exp
Dear list:
Just encountered the --merge option for git log.
In the man page, it has the following explanation:
- After a failed merge, show refs that touch files having a conflict
and don't exist on all heads to merge.
I tried this option and get below results:
1. For a failed merge (with confl
On Mon, Feb 8, 2016 at 2:42 AM, Jeff Merkey wrote:
> Try this page. Some good gmail config info.
>
> http://kernelnewbies.org/FirstKernelPatch
>
> Jeff
Thanks Jeff, but I believe there's nothing new for me. I have
successfully sent my first kernel patch a long time ago.
Also my gitconfig sendema
On Sun, Jan 3, 2016 at 3:52 PM, Andrey Utkin
wrote:
> After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and
> before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':"
> prompt I always have a delay of 2-3 minutes. It is weird! "Uns
Additional note - when I use the command line git push doesn't display
any errors but no updates on github...
git status says :
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
On 1/27/2016 2:51 PM, Andrey Chernyshov wrote:
On 1/27/2016 2:35 PM, Andrey C
On 1/27/2016 2:35 PM, Andrey Chernyshov wrote:
On 1/27/2016 2:32 PM, Andrey Chernyshov wrote:
Hi
I'm using PHP storm with git for windows. Once I do a push to the
github I get the following error
Problem signature:
Problem Event Name:APPCRASH
Application Name:git-r
On Tue, Jan 5, 2016 at 1:27 PM, Geert Uytterhoeven wrote:
> Does it work better if you store the (preferably app-specific) password in
> smtppass in .gitconfig?
No.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordo
After "Send this email? ([y]es|[n]o|[q]uit|[a]ll): y" prompt and
before "Password for 'smtp://x...@gmail.com@smtp.gmail.com:587':"
prompt I always have a delay of 2-3 minutes. It is weird! "Unsafe
clients" are allowed in Gmail settings.
I experience this both with @gmail.com mailbox and with gmail-
1 - 100 of 116 matches
Mail list logo
