Bug in "revision.c: --all adds HEAD from all worktrees" ?

Hi! I think there may be a regression caused by this change which means that "git fetch origin" doesn't work: commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad) Author: Nguyễn Thái Ngọc Duy Date: Wed Aug 23 19:36:59 2017 +0700 revision.c: --all adds HEAD

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 11 July 2017 at 23:53, Miguel Torroja wrote: > The option -G of p4 (python marshal output) gives more context about the > data being output. That's useful when using the command "change -o" as > we can distinguish between warning/error line and real change

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 3 July 2017 at 23:57, Miguel Torroja wrote: > The option -G of p4 (python marshal output) gives more context about the > data being output. That's useful when using the command "change -o" as > we can distinguish between warning/error line and real change description.

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 29 June 2017 at 23:41, miguel torroja <miguel.torr...@gmail.com> wrote: > On Thu, Jun 29, 2017 at 8:59 AM, Luke Diamand <l...@diamand.org> wrote: >> On 28 June 2017 at 14:14, miguel torroja <miguel.torr...@gmail.com> wrote: >>> Thanks Luke, >>>

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 28 June 2017 at 14:14, miguel torroja wrote: > Thanks Luke, > > regarding the error in t9800 (not ok 18 - unresolvable host in P4PORT > should display error), for me it's very weird too as it doesn't seem > to be related to this particular change, as the patch changes

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 28 June 2017 at 05:08, Junio C Hamano wrote: > Miguel Torroja writes: > >> The option -G of p4 (python marshal output) gives more context about the >> data being output. That's useful when using the command "change -o" as >> we can distinguish

Re: [PATCH] git-p4: changelist template with p4 -G change -o

On 22 June 2017 at 18:32, Junio C Hamano wrote: > Miguel Torroja writes: > >> The option -G of p4 (python marshal output) gives more context about the >> data being output. That's useful when using the command "change -o" as >> we can distinguish

Re: Git p4 sync changelist interval

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

Re: Git p4 sync changelist interval

On 6 June 2017 at 08:00, Luke Diamand <l...@diamand.org> wrote: > On 6 June 2017 at 00:29, Luke Diamand <l...@diamand.org> wrote: >> On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: >>> 2017-06-04 14:09 GMT+

Re: Git p4 sync changelist interval

On 6 June 2017 at 00:29, Luke Diamand <l...@diamand.org> wrote: > On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: >> 2017-06-04 14:09 GMT+03:00 Luke Diamand <l...@diamand.org>: >>> >>> >>> > >>> > The problem,

Re: Git p4 sync changelist interval

On 5 June 2017 at 19:50, Андрей Ефанов <1134t...@gmail.com> wrote: > 2017-06-04 14:09 GMT+03:00 Luke Diamand <l...@diamand.org>: >> >> On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@gmail.com> wrote: >> > Hello, >> > >> >

Re: Git p4 sync changelist interval

On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@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: > >

Re: [PATCH] git-p4: improve branch option handling

On 20 April 2017 at 14:52, Andrew Oakley wrote: > It is sometimes useful (much quicker) to request commands only operate > on a single branch. > > The P4Sync command has been updated to handle self.branch being None for > consitency with the P4Submit. Should that be

[PATCH 2/3] git-p4: add read_pipe_text() internal function

The existing read_pipe() function returns an empty string on error, but also returns an empty string if the command returns an empty string. This leads to ugly constructions trying to detect error cases. Add read_pipe_text() which just returns None on error. Signed-off-by: Luke Diamand &l

[PATCH 0/3] git-p4: use symbolic-ref instead of name-rev

Followup to earlier discussion about use of name-rev in git-p4. http://marc.info/?l=git=148979063421355 Luke Diamand (3): git-p4: add failing test for name-rev rather than symbolic-ref git-p4: add read_pipe_text() internal function git-p4: don't use name-rev to get current branch git-p4

[PATCH 3/3] git-p4: don't use name-rev to get current branch

git-p4 was using "git name-rev" to find out the current branch. That is not safe, since if multiple branches or tags point at the same revision, the result obtained might not be what is expected. Instead use "git symbolic-ref". Signed-off-by: Luke Diamand <l...@diam

[PATCH 1/3] git-p4: add failing test for name-rev rather than symbolic-ref

wrong, as git-p4 gets confused about which branch is in use. This appears to be the only place that git-p4 actually cares about the current branch. Signed-off-by: Luke Diamand <l...@diamand.org> Signed-off-by: Junio C Hamano <gits...@pobox.com> --- t/t9807-git-p4-submit.sh | 16 +++

Re: [PATCH] git-p4: Add failing test case for name-rev vs symbolic-ref

On 27 March 2017 at 00:18, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> As per the discussion about use of "git name-rev" vs "git symbolic-ref" in >> git-p4 here: >> >> http://marc.inf

[PATCH] git-p4: Add failing test case for name-rev vs symbolic-ref

As per the discussion about use of "git name-rev" vs "git symbolic-ref" in git-p4 here: http://marc.info/?l=git=148979063421355 git-p4 could get confused about the branch it is on and affects the git-p4.allowSubmit option. This adds a failing test case for the problem. Luk

[PATCH] git-p4: add failing test for name-rev rather than symbolic-ref

wrong, as git-p4 gets confused about which branch is in use. This appears to be the only place that git-p4 actually cares about the current branch. Signed-off-by: Luke Diamand <l...@diamand.org> --- t/t9807-git-p4-submit.sh | 16 1 file changed, 16 insertions(+) diff --g

Re: [PATCH v2] git-p4: fix git-p4.pathEncoding for removed files

On 9 February 2017 at 23:39, Junio C Hamano wrote: > Lars Schneider writes: > >> unfortunately, I missed to send this v2. I agree with Luke's review and >> I moved the re-encode of the path name to the `streamOneP4File` and >> `streamOneP4Deletion`

Re: [PATCH v2] git-p4: Fix git-p4.mapUser on Windows

On 27 January 2017 at 17:33, Junio C Hamano wrote: > George Vanburgh writes: > >> From: George Vanburgh >> >> When running git-p4 on Windows, with multiple git-p4.mapUser entries in >> git config - no user mappings are applied to

Re: [PATCH] git-p4: Fix git-p4.mapUser on Windows

I'm confusedsee below. On 21 January 2017 at 15:21, George Vanburgh wrote: >> On 21 Jan 2017, at 13:33, Lars Schneider >> > On 21 Jan 2017, at 13:02, George Vanburgh >> wrote: >> > >> > From: George Vanburgh

Re: [PATCH v4 2/2] t9813: avoid using pipes

On 8 January 2017 at 16:55, Pranit Bauva wrote: > The exit code of the upstream in a pipe is ignored thus we should avoid > using it. By writing out the output of the git command to a file, we can > test the exit codes of both the commands. Looks good to me, thanks! Ack.

Re: [PATCH v2] git-p4: do not pass '-r 0' to p4 commands

On 3 January 2017 at 20:02, Ori Rawlings wrote: > Looks good to me. And me. > > > Ori Rawlings

Re: [PATCH v3 2/2] t9813: avoid using pipes

On 3 January 2017 at 19:57, Pranit Bauva wrote: > The exit code of the upstream in a pipe is ignored thus we should avoid > using it. By writing out the output of the git command to a file, we can > test the exit codes of both the commands. Do we also need to fix

Re: [PATCH] don't use test_must_fail with grep

On 1 January 2017 at 14:50, Johannes Sixt <j...@kdbg.org> wrote: > Am 01.01.2017 um 15:23 schrieb Luke Diamand: >> >> On 31 December 2016 at 11:44, Pranit Bauva <pranit.ba...@gmail.com> wrote: >>> >>> diff --git a/t/t9813-git-p4-preserve-users.sh >

Re: [PATCH] don't use test_must_fail with grep

On 31 December 2016 at 11:44, Pranit Bauva wrote: > test_must_fail should only be used for testing git commands. To test the > failure of other commands use `!`. > > Reported-by: Stefan Beller > Signed-off-by: Pranit Bauva >

Re: [PATCH] git-p4: do not pass '-r 0' to p4 commands

On 29 December 2016 at 09:05, Igor Kushnir wrote: > git-p4 crashes when used with a very old p4 client version > that does not support the '-r ' option in its commands. > > Allow making git-p4 work with old p4 clients by setting git-p4.retries to 0. > > Alternatively

Re: [PATCH v1] git-p4: add diff/merge properties to .gitattributes for GitLFS files

On 19 December 2016 at 21:29, Junio C Hamano wrote: > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> The `git lfs track` command generates a .gitattributes file with diff >> and merge properties [1]. Set the same .gitattributes

Re: [PATCH v1] git-p4: fix git-p4.pathEncoding for removed files

On 19 December 2016 at 21:29, Junio C Hamano wrote: > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> In a9e38359e3 we taught git-p4 a way to re-encode path names from what >> was used in Perforce to UTF-8. This path re-encoding

Re: [PATCH v2] git-p4: Fix multi-path changelist empty commits

On 19 December 2016 at 17:49, Junio C Hamano wrote: > George Vanburgh writes: > >> From: George Vanburgh >> >> When importing from multiple perforce paths - we may attempt to import >> a changelist that contains files from two (or

[PATCHv2] git-p4: handle symlinked directories

commands (which also treat symlinks uniformaly). This is a very slight change in behaviour, but I don't think it can break anything since it is only when generating the summary that goes after the P4 change template. Luke Diamand (1): git-p4: avoid crash adding symlinked directory git-p4.py

[PATCHv2] git-p4: avoid crash adding symlinked directory

When submitting to P4, if git-p4 came across a symlinked directory, then during the generation of the submit diff, it would try to open it as a normal file and fail. Spot symlinks (of any type) and output a description of the symlink instead. Add a test case. Signed-off-by: Luke Diamand &l

Re: [PATCH] git-p4: Fix multi-path changelist empty commits

On 15 December 2016 at 17:14, George Vanburgh wrote: > From: George Vanburgh > > When importing from multiple perforce paths - we may attempt to import a > changelist that contains files from two (or more) of these depot paths. > Currently, this

[PATCHv1 0/1] git-p4: handle symlinked directories

There's a long-standing bug around handling of symlinked directories in git-p4. If in git you create a directory, and then symlink it, when git-p4 tries to create the diff-summary of what it's about to do, it tries to open the symlink as a regular file, and fails. Luke Diamand (1): git-p4

[PATCHv1 1/1] git-p4: avoid crash adding symlinked directory

When submitting to P4, if git-p4 came across a symlinked directory, then during the generation of the submit diff, it would try to open it as a normal file and fail. Spot this case, and instead output the target of the symlink in the submit diff. Add a test case. Signed-off-by: Luke Diamand &l

[PATCHv3] git-p4 worktree support

Support for git-p4 worktrees. Adds test cases for using git from a worktree, and specifying the git directory either with the --git-dir command-line option, or with $ENV{GIT_DIR}. Luke Diamand (1): git-p4: support git worktrees git-p4.py | 17 + t/t9800-git-p4

[PATCHv3] git-p4: support git worktrees

git-p4 would attempt to find the git directory using its own specific code, which did not know about git worktrees. Rework it to use "git rev-parse --git-dir" instead. Add test cases for worktree usage and specifying git directory via --git-dir and $GIT_DIR. Signed-off-by: Luke

Re: [PATCHv2] git-p4: support git worktrees

On 10 December 2016 at 21:57, Luke Diamand <l...@diamand.org> wrote: > git-p4 would attempt to find the git directory using > its own specific code, which did not know about git > worktrees. This caused git operations to fail needlessly. > > Rework it to use "git re

[PATCHv2] git-p4 worktree support

Second attempt at teaching git-p4 about worktrees. Earlier discussion here: http://marc.info/?l=git=148097985622294 Git-p4 exports GIT_DIR so that when it chdirs into the P4 client area to apply the change, git commands called from there will work correctly. Luke Diamand (1): git-p4: support

[PATCHv2] git-p4: support git worktrees

git-p4 would attempt to find the git directory using its own specific code, which did not know about git worktrees. This caused git operations to fail needlessly. Rework it to use "git rev-parse --git-dir" instead, which knows about worktrees. Signed-off-by: Luke Diamand <l..

Re: [PATCH] git-p4: add p4 shelf support

On 6 December 2016 at 16:12, Nuno Subtil wrote: > Yeah, it looks similar. This change can be ignored if those have already > been accepted. Thanks, that's appreciated! Luke

Re: [PATCH] git-p4: add p4 shelf support

On 6 December 2016 at 02:02, Nuno Subtil wrote: > Extends the submit command to support shelving a commit instead of > submitting it to p4 (similar to --prepare-p4-only). Is this just the same as these two changes? http://www.spinics.net/lists/git/msg290755.html

Re: [PATCHv1 1/2] git-p4: support git-workspaces

On 5 December 2016 at 21:24, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> On 5 December 2016 at 20:53, Junio C Hamano <gits...@pobox.com> wrote: >>> Luke Diamand <l...@diamand.org> writes: >>> >&g

Re: [PATCHv1 1/2] git-p4: support git-workspaces

On 5 December 2016 at 20:53, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> Teach git-p4 about git-workspaces. > > Is this what we call "git worktree", or something else? Ah, I think you're right! > >>

Re: [PATCH v1] git-p4: add config to retry p4 commands; retry 3 times by default

On 4 December 2016 at 14:03, wrote: > From: Lars Schneider > > P4 commands can fail due to random network issues. P4 users can counter > these issues by using a retry flag supported by all p4 commands [1]. > > Add an integer Git config

[PATCHv1 1/2] git-p4: support git-workspaces

Teach git-p4 about git-workspaces. Signed-off-by: Luke Diamand <l...@diamand.org> --- git-p4.py | 6 ++ 1 file changed, 6 insertions(+) diff --git a/git-p4.py b/git-p4.py index 0c4f2afd2..5e2db1919 100755 --- a/git-p4.py +++ b/git-p4.py @@ -566,6 +566,12 @@ def isValidGitDi

[PATCHv1 0/2] git-p4 patches

you update an existing shelved changelist. This is a bit like using "git commit --amend" only far more painful Luke Diamand (2): git-p4: support git-workspaces git-p4: support updating an existing shelved changelist Documentation/git-p4.txt | 4 git-p4.py

[PATCHv1 2/2] git-p4: support updating an existing shelved changelist

ut shelved changelist make corrections git commit --amend git p4 submit --update-shelve $CHANGELIST $mail interested parties about shelved changelist etc Signed-off-by: Luke Diamand <l...@diamand.org> --- Documentation/git-p4.txt | 4 git-p4.py

Re: [PATCH] allow git-p4 to create shelved changelists

On 28 November 2016 at 19:06, Junio C Hamano wrote: > Vinicius Kursancew writes: > >> This patch adds a "--shelve" option to the submit subcommand, it will >> save the changes to a perforce shelve instead of commiting them. Looks good to me,

Re: [PATCH] [git-p4.py] Add --checkpoint-period option to sync/clone

On 12 September 2016 at 23:02, Ori Rawlings wrote: > Importing a long history from Perforce into git using the git-p4 tool > can be especially challenging. The `git p4 clone` operation is based > on an all-or-nothing transactionality guarantee. Under real-world > conditions

Re: [BUG] t9801 and t9803 broken on next

On 14 May 2016 at 19:15, Junio C Hamano wrote: > Lars Schneider writes: > >>> On 13 May 2016, at 18:37, Junio C Hamano wrote: >>> >>> Are you saying that "git p4" itself breaks unless fast-import always >>> writes a new (tiny)

Re: [PATCHv1] git-p4: workaround p4 removal of client directory

[+Git, Junio] On 29 April 2016 at 15:10, Jacob Smith <jaros...@gmail.com> wrote: > That's the identical patch I'm maintaining internally; it appears to work. Thanks, I think that counts as a "Tested-by" then. Luke > > Sent from my iPhone > >> On Apr 29,

Re: [PATCH] t9824: fix wrong reference value

On 29 April 2016 at 21:29, Lars Schneider wrote: > > On 29 Apr 2016, at 19:34, Junio C Hamano wrote: > >> Lars Schneider writes: >> >>> 0492eb4 fixed a broken &&-chain in this test which broke the test as it >>> checked for

Re: [PATCHv1] git-p4: workaround p4 removal of client directory

Adding correct email for Jacob. On 29 April 2016 at 08:40, Luke Diamand <l...@diamand.org> wrote: > On some platforms, "p4 sync -f" will remove the workspace > directory after we have just created it; on some it won't. > This causes problems later when git finds itself i

[PATCHv1] git-p4: workaround p4 removal of client directory

This is a proposed fix for the problem reported by Jacob on OSX where "p4 sync -f" removes the client directory. http://www.spinics.net/lists/git/msg274356.html I tried just moving the "cd", but lots of the tests then fail as the "p4 sync" needs to be in the corre

[PATCHv1] git-p4: workaround p4 removal of client directory

On some platforms, "p4 sync -f" will remove the workspace directory after we have just created it; on some it won't. This causes problems later when git finds itself in an orphaned directory. Workaround this by cd'ing back to the directory after the "p4 sync -f". Signed-off

Re: BUG on OSX `git p4 submit` can fail when the workspace root doesn't exist locally.

On 27 April 2016 at 21:53, Stefan Beller wrote: > On Wed, Apr 27, 2016 at 11:06 AM, Jacob Smith wrote: >> I debugged the issue using the script here: >> https://github.com/git/git/blob/master/git-p4.py >> I'm not sure how close to the main repo that

Re: [PATCHv2 2/3] git-p4 tests: work with python3 as well as python2

On 26 April 2016 at 18:48, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> Update the git-p4 tests so that they work with both >> Python2 and Python3. >> >> We have to be explicit about the difference betwee

[PATCHv2 3/3] git-p4 tests: time_in_seconds should use $PYTHON_PATH

The time_in_seconds script should use $PYTHON_PATH, rather than just hard-coded python, so that users can override which version gets used, as is done for other python invocations. Signed-off-by: Luke Diamand <l...@diamand.org> --- t/lib-git-p4.sh | 2 +- 1 file changed, 1 insertion

[PATCHv2 1/3] git-p4 tests: cd to / before running python

The python one-liner for getting the current time prints out error messages if the current directory is deleted while it is running if using python3. Avoid these messages by switching to "/" before running it. This problem does not arise if using python2. Signed-off-by: Luke

[PATCHv2 2/3] git-p4 tests: work with python3 as well as python2

-by: Luke Diamand <l...@diamand.org> --- t/lib-git-p4.sh| 5 +++-- t/t9802-git-p4-filetype.sh | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index 724bc43..7393ee2 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -198,9 +

[PATCHv2 0/3] git-p4: support python3 in the tests

Updates to my patches to allow the git-p4 tests to work with python3. Incorporates suggestions from Junio to just switch to "/" and to use $PYTHON_PATH. Luke Diamand (3): git-p4 tests: cd to / before running python git-p4 tests: work with python3 as well as python2 gi

Re: [PATCH 0/2] git-p4: support python3 in the tests

On 25 April 2016 at 23:07, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> This patchset updates the git-p4 tests so that they work with >> either Python2 or Python3. >> >> Note that this does *not* fix git-p4 to w

[PATCH 2/2] git-p4 tests: work with python3 as well as python2

-by: Luke Diamand <l...@diamand.org> --- t/lib-git-p4.sh| 5 +++-- t/t9802-git-p4-filetype.sh | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index 77802fe..b97d27c 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -198,9 +

[PATCH 1/2] git-p4 tests: cd to testdir before running python

-by: Luke Diamand <l...@diamand.org> --- t/lib-git-p4.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index f9ae1d7..77802fe 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -50,7 +50,7 @@ native_path() { # at runtime (e.g. v

[PATCH 0/2] git-p4: support python3 in the tests

This patchset updates the git-p4 tests so that they work with either Python2 or Python3. Note that this does *not* fix git-p4 to work with Python3 - that's a much bigger challenge. Luke Diamand (2): git-p4 tests: cd to testdir before running python git-p4 tests: work with python3 as well

Re: [PATCH v2] git-p4: add P4 jobs to git commit message

On 20 April 2016 at 16:51, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> One thing I wondered about is whether this should be enabled by >> default or not. Long-time users of git-p4 might be a bit surprised to >> fin

Re: [PATCH] Update git-p4 to be compatible with git-lfs 1.2

On 20 April 2016 at 19:28, Ben Woosley wrote: > From: Ben Woosley > > The git lfs pointer output was changed in: > https://github.com/github/git-lfs/pull/1105 > > This was causing Mac Travis runs to fail, as homebrew had updated to 1.2 > while Linux

Re: [PATCH v2] git-p4: add P4 jobs to git commit message

On 19 April 2016 at 22:39, Junio C Hamano wrote: > Jan Durovec writes: > >> On Tue, Apr 19, 2016 at 11:09 PM, Junio C Hamano wrote: >> >>> For a series this small it does not matter, but anything longer it >>> would be easier to

Re: [PATCH v2] git-p4: add P4 jobs to git commit message

On 19 April 2016 at 22:44, Jan Durovec wrote: >> By the way, you may or may not have noticed that I've been >> reordering the lines of your message quoted in my responses; around >> here, top-posting is frowned upon. > > I haven't noticed. Thanks for pointing out. > > As

Re: [PATCH v2] git-p4: add P4 jobs to git commit message

On 19 April 2016 at 02:15, Junio C Hamano wrote: > Jan Durovec writes: > >> When migrating from Perforce to git the information about P4 jobs >> associated with P4 changelists is lost. >> >> Having these jobs listed on messages of related git commits

Re: [PATCH] Adding list of p4 jobs to git commit message

On 15 April 2016 at 21:27, Junio C Hamano wrote: > Jan Durovec writes: > >> --- > > A few issues. Please: > > (1) Sign-off your work. > > (2) Try to find those who are familiar with the area and Cc them. > > "git shortlog -s -n --since=18.months

Re: [PATCH v2] git-p4: map a P4 user to Git author name and email address

Yes please. On 15 March 2016 at 16:52, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >>> Is the patch uninteresting for git-p4 as it handles only an occasional >>> exception or did the patch get lost in the noise?

Re: [PATCH v1] git-p4: fix AsciiDoc formatting

On 14 March 2016 at 03:51, Junio C Hamano wrote: > Lars Schneider writes: > >>> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt >>> index 738cfde..140fc12 100644 >>> --- a/Documentation/git-p4.txt >>> +++ b/Documentation/git-p4.txt

Re: [PATCH v2] git-p4: map a P4 user to Git author name and email address

On 13 March 2016 at 17:41, Lars Schneider <larsxschnei...@gmail.com> wrote: > > On 02 Mar 2016, at 10:25, Lars Schneider <larsxschnei...@gmail.com> wrote: > >> >>> On 02 Mar 2016, at 06:06, Luke Diamand <l...@diamand.org> wrote: >>>

Re: [PATCH v2] git-p4: map a P4 user to Git author name and email address

On 1 March 2016 at 19:15, Eric Sunshine wrote: > On Tue, Mar 1, 2016 at 5:49 AM, wrote: >> Map a P4 user to a specific name and email address in Git with the >> "git-p4.mapUser" config. The config value must be a string adhering >> to the

Re: [PATCH] git-p4.py: Make submit working on bare repository

On 28 February 2016 at 20:46, Amadeusz Żołnowski wrote: > > True. For now I have these cases covered by wrapper scripts. The minimum > I need from git-p4 is just not to fail on git submit from bare > repository which is covered by patch I have submitted. If I get my >

Re: [PATCH v1] git-p4: map a P4 user to Git author name and email address

On 28 February 2016 at 10:25, wrote: > From: Lars Schneider > > Map a P4 user to a specific name and email address in Git with the > "git-p4.mapUser" config. The config value must be a string adhering > to the format "p4user -> First

Re: [PATCH] git-p4.py: Make submit working on bare repository

On 23 February 2016 at 20:56, Amadeusz Żołnowski wrote: > > To simplify things, why not just update ref during submit from bare > repository? As you have pointed out, if user invokes submit in this > context he/she actually wants to submit from bare repo and probably > knows

Re: [PATCH] git-p4.py: Make submit working on bare repository

On 23 February 2016 at 06:59, Junio C Hamano wrote: > Amadeusz Żołnowski writes: > >> Junio C Hamano writes: >>> I wonder if it makes sense to just silently allowing submit without >>> rebasing, and without telling the user how to

Re: [PATCH] git-p4.py: Don't try to rebase on submit from bare repository

On 17 February 2016 at 22:46, Amadeusz Żołnowski wrote: > git-p4 can be successfully used from bare repository (which acts as a > bridge between Perforce repository and pure Git repositories). On submit > git-p4 performs unconditional rebase. Do rebase only on non-bare >

Re: [PATCH v2] git-p4.py: add support for filetype change

On 4 January 2016 at 10:52, Romain Picard wrote: > After changing the type of a file in the git repository, it is not possible to > "git p4 publish" the commit to perforce. This is due to the fact that the git > "T" status is not handled in git-p4.py. This can typically

Re: [PATCH] git-p4.py: add support for filetype change

On 21 December 2015 at 13:09, Romain Picard wrote: > After changing the type of a file in the git repository, it is not possible to > "git p4 publish" the commit to perforce. This is due to the fact that the git > "T" status is not handled in git-p4.py. This can

Re: [PATCH v1 2/2] git-p4: suppress non test relevant output

On 22/12/15 08:47, Lars Schneider wrote: On 21 Dec 2015, at 21:38, Junio C Hamano wrote: If so, why not do it there instead? You seem to run only "kill" to send some signal to a process using this helper function, and it would be silent on its standard output stream

[PATCHv2 2/3] git-p4: support multiple depot paths in p4 submit

ed-off-by: Sam Hocevar <s...@hocevar.net> Signed-off-by: Luke Diamand <l...@diamand.org> --- git-p4.py | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/git-p4.py b/git-p4.py index 7a9dd6a..122aff2 100755 --- a/git-p4.py +++ b/git-p4.py @@ -1458,6 +1458,8

[PATCHv2 0/3] git-p4: fixing p4ChangesForPaths

' problem. This followup just fixes Sam's original fix to restore the behavior of p4ChangesForPaths() so that it returns a sorted list of changes. That fixes a failing a testcase. Luke Diamand (1): git-p4: failing test case for skipping changes with multiple depots Sam Hocevar (2): git-p4

[PATCHv2 1/3] git-p4: failing test case for skipping changes with multiple depots

James Farwell reported that with multiple depots git-p4 would skip changes. http://article.gmane.org/gmane.comp.version-control.git/282297 Add a failing test case demonstrating the problem. Signed-off-by: Luke Diamand <l...@diamand.org> --- t/t9818-git-p4-block.s

[PATCHv2 3/3] git-p4: reduce number of server queries for fetches

esults and remove duplicates. Signed-off-by: Sam Hocevar <s...@hocevar.net> Signed-off-by: Luke Diamand <l...@diamand.org> --- git-p4.py | 44 +--- t/t9818-git-p4-block.sh | 2 +- 2 files changed, 22 insertions(+), 24 deletions(-) d

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

On 16/12/15 00:38, Sam Hocevar wrote: I'm actually surprised that the patch changes the order at all, since all it does is affect the decision (on a yes/no basis) to include a given file into a changelist. I'm going to have a look at that specific unit test, but of course as a user I'd prefer if

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

On 14 December 2015 at 19:16, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> Having just fixed this, I've now just spotted that Sam Hocevar's fix >> to reduce the number of P4 transactions also fixes it: >>

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

be fine, but it needs to be thought about a bit. Sam - do you have any thoughts on this? Thanks Luke On 14 December 2015 at 22:06, Junio C Hamano <gits...@pobox.com> wrote: > Luke Diamand <l...@diamand.org> writes: > >> On 14 December 2015 at 19:16, Junio C Hamano &

[PATCH 1/2] git-p4: failing test case for skipping changes with multiple depots

James Farwell reported that with multiple depots git-p4 would skip changes. http://article.gmane.org/gmane.comp.version-control.git/282297 Add a failing test case demonstrating the problem. Signed-off-by: Luke Diamand <l...@diamand.org> --- t/t9818-git-p4-block.s

[PATCH 2/2] git-p4: fix handling of multiple depot paths

es Farwell <jfarw...@vmware.com> Signed-off-by: Luke Diamand <l...@diamand.org> --- git-p4.py | 8 +--- t/t9818-git-p4-block.sh | 2 +- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/git-p4.py b/git-p4.py index 7a9dd6a..a8b5278 100755 --- a/git-p4.py +++

[PATCH 0/2] git-p4: fix for handling of multiple depot paths

James Farwell reported a bug I introduced into git-p4 with handling of multiple depot paths: http://article.gmane.org/gmane.comp.version-control.git/282297 This patch series adds a failing test case, and a fix for this problem. Luke Luke Diamand (2): git-p4: failing test case for skipping

Re: [PATCH 0/2] git-p4: fix for handling of multiple depot paths

Having just fixed this, I've now just spotted that Sam Hocevar's fix to reduce the number of P4 transactions also fixes it: https://www.mail-archive.com/git%40vger.kernel.org/msg81880.html That seems like a cleaner fix. Luke On 13 December 2015 at 20:07, Luke Diamand <l...@diamand.org>

Re: Bug: git-p4 can skip changes when syncing large from multiple depot paths

On 12 December 2015 at 02:52, James Farwell wrote: > > Reproduction Steps: > > 1. Have a git repo cloned from a perforce repo using multiple depot paths > (e.g. //depot/foo/ and //depot/bar/). > 2. Add changes to the perforce repo in both depot paths. (e.g. 5 changes in >

Re: [PATCH v2] git-p4: Add option to keep empty commits

On 8 December 2015 at 09:36, wrote: > From: Lars Schneider > > A changelist that contains only excluded files due to a client spec was > imported as an empty commit. Fix that issue by ignoring these commits. > Add option

Re: [PATCH 1/2] git-p4: support multiple depot paths in p4 submit

On 8 December 2015 at 11:41, Sam Hocevar wrote: > On Tue, Dec 08, 2015, Lars Schneider wrote: > >> > Would a refactor of lib-git-p4.sh (and probably all git-p4 tests) to >> > support multiple depots be acceptable and/or welcome? I prefer to ask >> > before I dig into the task.

<    1   2   3   4   >