On 04/07/15 04:27, Luke Diamand wrote:
Sorry for not replying earlier, and thanks for taking the time to
investigate this!
It's a pretty subtle corner case: I think a test case would be useful.
I'm going to try to put something together, unless you beat me to it!
(I think t9811-gi
On 02/08/15 16:15, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Hi,
I want to propose this patch as it helped us to migrate a big source code base
successfully from P4 to Git. I am sorry that I don't provide a test case, yet.
Case sensitivity is a pretty tricky area with p4 - it's ve
Lars - thanks for persisting with this!
I'm still trying to fully understand what's going on here - can you
point out where I've got it wrong below please!
The server is on Linux, and is case-sensitive. For whatever reason
(probably people committing changes on Windows in the first place)
we've e
On 24 August 2015 at 10:51, Lars Schneider wrote:
>>
>> I'm still trying to fully understand what's going on here - can you
>> point out where I've got it wrong below please!
> Your welcome + sure :)
>
>
> While I was working on the examples for this email reply I realized that the
> problem i
On 24 August 2015 at 13:43, Lars Schneider wrote:
>>
>> https://github.com/luked99/quick-git-p4-case-folding-test
> As mentioned I realized that the problem occurs only if you use client specs.
> Can you take a look at this test case / run it?
> https://github.com/larsxschneider/git/blob/d3a191cb
On 24/08/15 22:30, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Thanks to Luke Diamand I realized the core problem and propose here a
substiantially simpler fix to my PATCH v4.
The test cases remain and prove the problem. In particular
"8 - Clone path (ignorecase)" and
"
On 25/08/15 11:30, larsxschnei...@gmail.com wrote:
> Unfortunately the command line option is not sufficient as the resulting
> paths are still messed up. I added the switch but it looks like as
> core.ignorecase does some additional magic on fast-import. You can see my
> changes here:
> https
On 25/08/15 14:14, Lars Schneider wrote:
So the choices are:
1. A new command-line option which would silently set core.ignorecase
2. Users just have to know to set core.ignorecase manually before
using git-p4 (i.e. Lars' patch v5)
3. Fix fast-import to take a --casefold option (but that's a mu
On 25 August 2015 at 19:24, Luke Diamand wrote:
> On 25/08/15 14:14, Lars Schneider wrote:
>>>
>>>
>>> So the choices are:
>>>
>>> 1. A new command-line option which would silently set core.ignorecase
>>> 2. Users just have to know to
If p4 reports a tag for a commit that git-p4 does not know
about (e.g. because it references a P4 changelist that was
imported prior to the point at which the repo was cloned into
git), make sure that the error is correctly caught and handled.
rather than just crashing.
Signed-off-by: Luke
s that have not been
imported during this run of the program (and so won't have marks).
A test case is added to demonstrate the problem.
Marcus - if you're able to take a look at this and see if it
fixes your problem that would be very useful.
Thanks,
Luke
Luke Diamand (3):
git-p4: failin
rt the P4 label.
Teach git-p4 to use fast-import "marks" when creating tags
which reference commits created during the current run of the
program.
Commits created before the current run are still referenced
in the old way using a normal git commit.
Signed-off-by: Luk
: Luke Diamand
---
t/t9811-git-p4-label-import.sh | 45 ++
1 file changed, 45 insertions(+)
diff --git a/t/t9811-git-p4-label-import.sh b/t/t9811-git-p4-label-import.sh
index 095238f..f7d5048 100755
--- a/t/t9811-git-p4-label-import.sh
+++ b/t/t9811-git-p4-label
On 28 August 2015 at 13:24, wrote:
> From: Lars Schneider
>
> I am migrating huge Perforce repositories including history to Git. Some of
> them contain large files that would blow up the resulting Git repositories.
> This patch adds an option to store these files in Git LFS [1] on git-p4 clon
Comments below.
>
> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
> index 82aa5d6..a188840 100644
> --- a/Documentation/git-p4.txt
> +++ b/Documentation/git-p4.txt
> @@ -252,6 +252,18 @@ Git repository:
> Use a client spec to find the list of interesting files in p4.
>
On 30 August 2015 at 11:18, Lars Schneider wrote:
> Thanks for your feedback!
>
> I like the “handle big files” plugin kind of idea. However, I wonder if it
> makes sense to put more and more stuff into git-p4.py (>3000 LOC already).
> What do you think about splitting git-p4 into multiple files
On 31 August 2015 at 14:22, Ehsan Akhgari wrote:
> Signed-off-by: Ehsan Akhgari
> ---
> INSTALL | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/INSTALL b/INSTALL
> index ffb071e..5b7fe91 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -148,6 +148,11 @@ Issues of note:
> suppo
On 2 September 2015 at 21:39, wrote:
> From: Lars Schneider
>
> Perforce keeps the encoding of a path as given by the originating OS.
> Git expects paths encoded as UTF-8. Add a config to tell git-p4 what
> encoding Perforce had used for the paths. This encoding is used to
> transcode the paths
>>>
>>> Regarding Python 3:
>>> Would you drop Python 2 support or do you want to support Python 2/3 in
>>> parallel? I would prefer the former…
>>
>> For quite some time we would need to support both; we can't just have
>> a release of git that one day breaks git-p4 for people stuck on Python
>>
On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
From: Lars Schneider
I think this commit may need some explanation!
Signed-off-by: Lars Schneider
---
git-p4.py | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 073f87b..c139ca
On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Explanation?
Signed-off-by: Lars Schneider
---
git-p4.py | 11 +++
1 file changed, 11 insertions(+)
diff --git a/git-p4.py b/git-p4.py
index c139cab..ae1a4d3 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -623,6
On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Perforce repositories can contain large (binary) files. Migrating these
repositories to Git generates very large local clones. External storage
systems such as LFS [1] or git-annex [2] try to address this problem.
Add a ge
On 03/09/15 21:17, Lars Schneider wrote:
On 03 Sep 2015, at 21:57, Luke Diamand wrote:
On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Explanation?
Add a git config reader for integer variables. Please note that the git config
implementation automatically
and
submit successfully.
Signed-off-by: Luke Diamand
---
git-p4.py | 18 --
t/t9800-git-p4-basic.sh | 2 +-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 2677c89..a22ae01 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -1651
ing it for the last few days.
Luke Diamand (2):
git-p4: add failing test for submit from detached head
git-p4: work with a detached head
git-p4.py | 18 --
t/t9800-git-p4-basic.sh | 16
2 files changed, 28 insertions(+), 6 deletions(-)
--
2.6
git-p4 can't submit from a detached head. This test case
demonstrates the problem.
Signed-off-by: Luke Diamand
---
t/t9800-git-p4-basic.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 90d41ed..114b19f 100755
On 7 September 2015 at 13:21, wrote:
> From: Lars Schneider
>
> One thing I don't like about the current implementation is that I don't see a
> way to test the "git-p4.pushLargeFiles" config. I could start a git lfs server
> locally but that seems a bit too much, no?
Perhaps add a trivial large
On 9 September 2015 at 22:52, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> def run(self, args):
>> if len(args) == 0:
>> self.master = currentGitBranch()
>> -if len(self.master) == 0 or not gitBranchExists(&qu
On 10 September 2015 at 02:59, Jacob Keller wrote:
> On Wed, Sep 9, 2015 at 6:57 PM, Jacob Keller wrote:
>> On Wed, Sep 9, 2015 at 5:03 AM, Lars Schneider
>> wrote:
>>> I wanted to play with the patch and apply it to my source but the process
>>> is really complicated for me. I wonder if you c
On 14/09/15 17:55, larsxschnei...@gmail.com wrote:
From: Lars Schneider
A P4 repository can get into a state where it contains a file with
type UTF-16 that does not contain a valid UTF-16 BOM. If git-p4
Sorry - what's a BOM? I'm assuming it's not a Bill of Materials?
Do we know the mechanism
On 14/09/15 18:10, larsxschnei...@gmail.com wrote:
From: Lars Schneider
If a path with non-ASCII characters is detected then print always the
s/print always/print/
encoding and the encoded string in verbose mode.
Signed-off-by: Lars Schneider
---
git-p4.py | 19 +--
1
On 14/09/15 14:26, larsxschnei...@gmail.com wrote:
From: Lars Schneider
The functions “gitConfig” and “gitConfigBool” are almost identical. Make
“gitConfig” more generic by adding an optional type specifier. Use the type
specifier “—bool” with “gitConfig” to implement “gitConfigBool. This pre
On 15/09/15 08:31, Luke Diamand wrote:
On 14/09/15 18:10, larsxschnei...@gmail.com wrote:
It would be better to query this once at startup. Otherwise we're
potentially forking "git config" twice per file which on a large repo
could become significant. Make it an instance v
On 15/09/15 16:38, Lars Schneider wrote:
On 15 Sep 2015, at 08:43, Luke Diamand wrote:
Do we know the mechanism by which we end up in this state?
Unfortunately no. I tried hard to reproduce the error with “conventional”
methods. As you can see I ended up manipulating the P4 database
On 14/09/15 14:26, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Perforce repositories can contain large (binary) files. Migrating these
repositories to Git generates very large local clones. External storage
systems such as Git LFS [1], Git Fat [2], Git Media [3], git-annex [4]
try to a
Lars,
When I run t9822-git-p4-path-encoding.sh, the last test fails (it's
supposed to pass) with the following backtrace.
This is with 'next' at 3dd15c02a81a280c83c8d5e32c6cb71a64177ca6.
Any ideas as to what I'm doing wrong?
Thanks,
Luke
Reinitialized existing Git repository in /home/lgd/g
On 20/09/15 23:29, Eric Sunshine wrote:
On Sun, Sep 20, 2015 at 5:34 PM, Lars Schneider
wrote:
What is the preferred way by the Git community? Combine patch and
test in one commit or a patch commit followed by a test commit? I
would prefer to have everything in one commit.
If the tests are i
On 20/09/15 17:22, larsxschnei...@gmail.com wrote:
From: Lars Schneider
When I run this, I get errors reported on the sed usage:
t9824-git-p4-handle-utf16-without-bom.sh:25: error: sed -i is not
portable: sed -i.bak "$ d" depot/file1,v &&
t9824-git-p4-handle-utf16-without-bom.sh:
On 21/09/15 08:01, Luke Diamand wrote:
Lars,
When I run t9822-git-p4-path-encoding.sh, the last test fails (it's
supposed to pass) with the following backtrace.
This is with 'next' at 3dd15c02a81a280c83c8d5e32c6cb71a64177ca6.
Any ideas as to what I'm doing wrong?
I th
On 21/09/15 09:49, larsxschnei...@gmail.com wrote:
From: Lars Schneider
I broke a test in "[PATCH v2] git-p4: improve path encoding verbose output" on
the next branch.
This patch on top of next (3dd15c0) fixes the issue.
Thanks to Luke for finding the issue!
Looks good to me, apart from usi
On 20/09/15 21:26, larsxschnei...@gmail.com wrote:
From: Lars Schneider
diff to v5:
* remove superfluous flush call (thanks Luke!)
* keep &&-chain intact in test cases (thanks Luke, Junio and Eric!)
* add mock LFS test case for deleting files (thanks Luke!)
* add mock LFS test case for git-p4.l
On 21 September 2015 at 23:41, wrote:
> From: Lars Schneider
>
> diff to v6:
> * fix spaces in .gitattributes for Git-LFS files (old "[:space:]", new
> "[[:space:]]")
> * generated patch on top of next (95c4325) to resolve merge conflicts
Trying this out by hand (rather than using the test cas
Lars,
I just noticed that your change "git-p4: honor core.ignorecase when
using P4 client specs" seems to break t9819.
I suspect that the problem is just that t9819 needs to be updated to
reflect your change - do you have any thoughts on that?
Thanks!
Luke
--
To unsubscribe from this list: send
On 23 September 2015 at 11:27, Lars Schneider wrote:
>
> On 23 Sep 2015, at 11:27, Luke Diamand wrote:
>
>> Lars,
>>
>> I just noticed that your change "git-p4: honor core.ignorecase when
>> using P4 client specs" seems to break t9819.
>>
>>
Adding back git@vger.kernel.org, which I inadvertently dropped off the thread.
On 23 September 2015 at 12:22, Luke Diamand wrote:
> On 23 September 2015 at 11:09, Lars Schneider
> wrote:
>>
>> On 23 Sep 2015, at 11:22, Luke Diamand wrote:
>>
>>> On 23 Septem
On 23 September 2015 at 13:28, Lars Schneider wrote:
>
>> Here's the last bit of the crash dump from git-p4 I get:
>>
>> File "/home/ldiamand/git/git/git-p4", line 2580, in streamP4FilesCbSelf
>>self.streamP4FilesCb(entry)
>> File "/home/ldiamand/git/git/git-p4", line 2497, in streamP4FilesC
OK, slight correction there - it now doesn't crash getting the disk
usage, but I think it still needs to be updated following the other
changes to case-handling.
Luke
On 24 September 2015 at 08:45, Luke Diamand wrote:
> On 23 September 2015 at 13:28, Lars Schneider
> wrote:
>&g
On 23 September 2015 at 12:42, Lars Schneider wrote:
>
> On 23 Sep 2015, at 13:25, Luke Diamand wrote:
>
>> Adding back git@vger.kernel.org, which I inadvertently dropped off the
>> thread.
>>
>> On 23 September 2015 at 12:22, Luke Diamand wrote:
>&g
On 25 September 2015 at 08:27, Johannes Schindelin
wrote:
> Hi,
>
> On 2015-09-25 05:14, Dennis Kaarsemaker wrote:
>> On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote:
>>> larsxschnei...@gmail.com writes:
>>>
>>> > My idea is that the owner of "https://github.com/git/git"; enables this
>>>
On 25/09/15 09:35, Lars Schneider wrote:
size: 3 flags: 0
What's going on?
I believe this is correct. Git-LFS uses the clean/smudge filter to replace the
LFS pointer with the actual file on checkout. Therefore you see the actual file!
You can find details here:
https://github.com/gi
One tiny comment, otherwise this looks good to me.
Can we use test_path_is_missing in place of !test_path_is_file ?
On 21 September 2015 at 23:41, wrote:
> From: Lars Schneider
>
> Perforce repositories can contain large (binary) files. Migrating these
> repositories to Git generates very la
On 26 September 2015 at 08:54, wrote:
> From: Lars Schneider
>
> diff to v7:
> * fix commit message line length (thanks Junio)
> * fix sync command for large file system support (thanks Luke!)
> * add test case for sync command
> * rename git-p4.pushLargeFiles to git-p4.largeFilePush for consist
o ever happen in practice.
I think I've covered everything in this fix, but it's possible that there
are still bugs to be uncovered; I find the way that these limits interact
somewhat tricky to understand.
Thanks,
Luke
Luke Diamand (3):
git-p4: additional testing of --changes-
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
---
t/t9818-git-p4-block.sh | 56 +
1
anrows" changes seem
(experimentally) to be impossible to print. There's no good way to
work around this.
Signed-off-by: Luke Diamand
---
t/t9818-git-p4-block.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t9818-git-p4-block.sh
e to
workaround this problem, although in the real world this shouldn't
normally happen.
Signed-off-by: Luke Diamand
---
git-p4.py | 48 +++-
t/t9818-git-p4-block.sh | 12 ++--
2 files changed, 41 insertions(+), 19 deletions(-)
d
On 07/06/15 17:01, Lex Spoon wrote:
Great work.
Thanks! I actually found the problem in my day job, so it was very handy
having all the infrastructure already in place!
For curiosity's sake, the -m solution has been observed to work on at
least one Perforce installation. However clearly it d
On 07/06/15 17:33, Lex Spoon wrote:
The implementation looks fine, especially given the test cases that
back it up. I am only curious why the block size is set to a default
of None. To put it as contcretely as possible: is there any expected
configuration where None would work but 500 would not?
anrows" changes seem
(experimentally) to be impossible to print. There's no good way to
work around this.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 56
this is tested and hasn't been broken
by these changes.
Luke
Luke Diamand (3):
git-p4: additional testing of --changes-block-size
git-p4: test with limited p4 server results
git-p4: fixing --changes-block-size handling
git-p4.py | 45 ++
t/t
pass.
Note that many other Perforce operations can fail for the same
reason (p4 print, p4 files, etc) and it's probably not possible
to workaround this. In the real world, this is probably not
usually a problem.
Signed-off-by: Luke Diamand
---
git-p4.py | 45 ++
Add additional tests of some corner-cases of the
--changes-block-size git-p4 parameter.
Also reduce the number of p4 changes created during the
tests, so that they complete faster.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 56
g from years down
to seconds to find a range that works?) and then take the lowest
revision supplied. But that's quite a bit more complex.
Luke Diamand (4):
git-p4: additional testing of --changes-block-size
git-p4: test with limited p4 server results
git-p4: add tests for non-numeric revisi
Test that git-p4 can handle a sync with a non-numeric revision
range (e.g. a date).
Signed-off-by: Luke Diamand
---
t/t9800-git-p4-basic.sh | 38 ++
1 file changed, 38 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 5b56212
pass.
Note that many other Perforce operations can fail for the same
reason (p4 print, p4 files, etc) and it's probably not possible
to workaround this. In the real world, this is probably not
usually a problem.
Signed-off-by: Luke Diamand
---
git-p4.py | 85 ++
anrows" changes seem
(experimentally) to be impossible to print. There's no good way to
work around this.
Signed-off-by: Luke Diamand
Acked-by: Lex Spoon
---
t/t9818-git-p4-block.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/
On 10/06/15 18:04, Christopher Dunn wrote:
Sorry. I thought empty patches were made to work in other cases.
'git-p4' needs to skip these. Wrong mailing list then.
Possibly the right mailing list - can you explain what you mean here
w.r.t git-p4 please?
Thanks!
Luke
On Tue, Jun 9, 2015
This is probably user error, but I'm not sure what I'm doing wrong.
I'm posting here in case anyone else gets the same thing
I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today.
I've somehow ended up with history skipping back in time, but git not
prepared to let let me fix it, or something.
$
The other thing about these files is that they were all deleted a few
weeks ago and have now come back.
On 18 June 2015 at 23:07, Luke Diamand wrote:
> This is probably user error, but I'm not sure what I'm doing wrong.
> I'm posting here in case anyone else gets the sam
On 18 June 2015 at 23:28, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> This is probably user error, but I'm not sure what I'm doing wrong.
>> I'm posting here in case anyone else gets the same thing
>>
>> I'm using 2.4.4.598.gd7bed1d, i.
On 18 June 2015 at 23:53, Junio C Hamano wrote:
> Luke Diamand writes:
>
>>>> $ git checkout upstream/master -- subtree
>>>> $ git diff upstream/master -- subtree
>>>> -- still lots of deltas
>>>
>>> Does this show _ONLY_ additions? Or
On 23/06/15 19:49, Josh Hagins wrote:
If neither git-submodule nor git-subtree is palatable to you, here are
a couple of alternatives you might try:
* https://github.com/ingydotnet/git-subrepo
* https://github.com/tdd/git-stree
You could also use Android's "repo" tool:
https://code.goog
Sorry for not replying earlier, and thanks for taking the time to
investigate this!
It's a pretty subtle corner case: I think a test case would be useful.
I'm going to try to put something together, unless you beat me to it!
(I think t9811-git-p4-label-import.sh is the one that needs extendin
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 results in multiple git commits - one containing
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 git
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
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 more) of these depot
>> paths. Currently, this results in multipl
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 worked properly for
>> "added" paths. "Removed" pat
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 format for files
>> tracked with GitLFS in git-p4.
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 git-p4.retries could be made o
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
> ---
> t/t3510-cherry-pick-sequence.sh | 6 +++---
> t/t5504-fetch-re
On 1 January 2017 at 14:50, Johannes Sixt wrote:
> Am 01.01.2017 um 15:23 schrieb Luke Diamand:
>>
>> On 31 December 2016 at 11:44, Pranit Bauva wrote:
>>>
>>> diff --git a/t/t9813-git-p4-preserve-users.sh
>>> b/t/t9813-git-p4-preserve-users.sh
>>
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 t9814-git-p4-rename.sh ?
>
> Sig
On 3 January 2017 at 20:02, Ori Rawlings wrote:
> Looks good to me.
And me.
>
>
> Ori Rawlings
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.
>
> Signed-off-by: Pran
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
>> >
>> > When running git-p4 on Windows, with multiple git-p4.mapUser entries
>>
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 the generated repository.
>> ...
>> Using splitlines solves this i
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` explicitly.
>>
>> Discussion:
>> http://public-i
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, thanks!
Works a treat.
Ack.
>>
>> Vinicius Kursance
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
---
Documentation/git-p4.txt | 4
git-p4.py| 33 ++
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
Teach git-p4 about git-workspaces.
Signed-off-by: Luke Diamand
---
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 isValidGitDir(path):
if (os.path.exists
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 value `git-p4.retries` to define the number of
> retries for
On 5 December 2016 at 20:53, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> Teach git-p4 about git-workspaces.
>
> Is this what we call "git worktree", or something else?
Ah, I think you're right!
>
>>
>> Signed-off-by: Luke Diamand
>&
On 5 December 2016 at 21:24, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> On 5 December 2016 at 20:53, Junio C Hamano wrote:
>>> Luke Diamand writes:
>>>
>>>> Teach git-p4 about git-workspaces.
>>>
>>> Is this what we call "
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
http://www.spinics.net/lists/git/
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
Second attempt at teaching git-p4 about worktrees.
Earlier discussion here:
http://marc.info/?l=git&m=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):
gi
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
---
1 - 100 of 407 matches
Mail list logo
