On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano gits...@pobox.com
wrote:
Vitor Antunes vitor@gmail.com writes:
Add failing scenario where branch detection is enabled together with
use client view. In this specific scenario git-p4 will break when the
perforce client view removes
Stefan Beller sbel...@google.com writes:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a fundamental issue with the code being broken, but
it turns out we just need a larger offset as we apparently have 9 files open
already, before the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a fundamental issue with the code being broken, but
it turns out we just need a
This is another attempt on enabling large transactions
(large in terms of open file descriptors). We keep track of how many
lock files are opened by the ref_transaction_commit function.
When more than a reasonable amount of files is open, we close
the file descriptors to make sure the transaction
Michael J Gruber g...@drmicha.warpmail.net writes:
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/rev-list-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt
On Mon, Apr 20, 2015 at 4:07 PM, Stefan Beller sbel...@google.com wrote:
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
The problem comes from guessing the number of fds we're allowed to use.
At first I thought it was a
Jeff King p...@peff.net writes:
I note that record_person does not seem to care about the commit at all,
so an alternative fix would be:
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 1d962dc..9f0e608 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
On 04/18, Erik Elfström wrote:
* Still have issues in the performance tests, see comments
from Thomas Gummerer on v2
I've looked at the modern style tests again, and I don't the code
churn is worth it just for using them for the performance tests. If
anyone wants to take a look at the code,
On 04/21/2015 12:11 AM, Junio C Hamano wrote:
But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no? That is, the
failed merge wouldn't have touched the index for the path if it
already had changes there in the first place.
I'm not
Vitor Antunes vitor@gmail.com writes:
On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano gits...@pobox.com
wrote:
Vitor Antunes vitor@gmail.com writes:
Add failing scenario where branch detection is enabled together with
use client view. In this specific scenario git-p4 will
I didn't expect anything else (as the patch is the same as the
previous one) but I verified that applying this patch has the desired
effect (https://bitbucket.org/snippets/ssaasen/9AXg).
Thanks for the fix Jeff.
On 21 April 2015 at 05:54, Jeff King p...@peff.net wrote:
When writing out an
Hi all,
After the user does 'git stash pop', it may result in conflicts.
However, in many cases they may not intend to commit the stashed changes
right away, so staging the applied changes is often not what they intend
to do. However, the conflict is there until you mark it as resolved.
Dmitry Gutov dgu...@yandex.ru writes:
Either will reset already-staged changes from the said file, which is
an irreversible operation.
But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no? That is, the
failed merge wouldn't have
Karsten Blees karsten.bl...@gmail.com writes:
Wouldn't it be better to just strip the BOM on commit, e.g. via a
clean filter or pre-commit hook (as suggested in [1])?
The users can do whatever they want and if they think having a BOM
in these files is a bad idea, I'd encourage them to use
On Fri, Apr 17, 2015 at 4:31 PM, Stefan Beller sbel...@google.com wrote:
On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller sbel...@google.com wrote:
On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano gits...@pobox.com wrote:
This is now pushed out and sitting at the tip of 'pu'. It seems to
break
I can confirm that this patch is equivalent to the previous one.
https://bitbucket.org/snippets/ssaasen/9AXg shows both the timing and
the NFS stats showing the effect of applying this patch.
Thanks for the fix Jeff!
Cheers,
Stefan
On 21 April 2015 at 05:55, Jeff King p...@peff.net wrote:
Hi,
On Sun, Apr 19, 2015 at 08:39:44PM -0400, Eric Sunshine wrote:
Other than being enuinely confused by the original, and having to
check the actual implementation for clarification, I don't feel
strongly about it either. Perhaps mentioning evaluation like this
might help?
Return a
If it is critical to some people, they can downmerge to their custom
old installations of Git they maintain with ease, of course, and
that with ease part is the reason why I try to apply fixes to tip
of the original topic branch even though they were merged to the
mainline eons ago ;-).
I
On Mon, Apr 20, 2015 at 01:04:11PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... But I don't know
if this counts as critical (it is for you, certainly, but I don't think
that many people are affected, as the crucial factor here is really the
slow NFS filesystem
Jeff King p...@peff.net writes:
Either way, though, I do not think it is the upstream Git project's
problem.
The commit to pick where to queue the fixes actually is my problem,
as I have this illusion that I'd be helping these derived works by
making it easier for them to merge, not
On Mon, Apr 20, 2015 at 01:12:54PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Either way, though, I do not think it is the upstream Git project's
problem.
The commit to pick where to queue the fixes actually is my problem,
as I have this illusion that I'd be helping
On 19/04/15 18:29, Matthieu Moy wrote:
The old wording was somehow implying that start and end were not
regular expressions. Also, the common case is to use a plain function
name here so funcname makes sense (the fact that it is a regular
expression is documented in line-range-format.txt).
The old wording was somehow implying that start and end were not
regular expressions. Also, the common case is to use a plain function
name here so funcname makes sense (the fact that it is a regular
expression is documented in line-range-format.txt).
Signed-off-by: Matthieu Moy
The old message did not mention the :regex:file form.
To avoid overly long lines, split the message into two lines (in case
item-string is long, it will be the only part truncated in a narrow
terminal).
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano
On Fri, Apr 17, 2015 at 7:59 AM, Pedro Rodrigues
prodrigues1...@gmail.com wrote:
snip
Not completely off topic, but for consistency consider that:
git-clone supports --recursive and --recurse-submodules, which do the
same thing.
git-pull and git-push only support --recurse-submodules.
It
please open attachment file.
3.5% WONGA EXPRESS LOANS PROMOTION-1.doc
Description: MS-Word document
On Mon, Apr 20, 2015 at 02:27:44PM +0530, Karthik Nayak wrote:
Sorry, but I didn't get you, broken objects created using hash-object
--literally do not work with cat-file without the --literally option.
Perhaps an example would help:
I cannot create a bad tree without --literally:
$ echo
On April 20, 2015 1:14:34 PM GMT+05:30, Charles Bailey char...@hashpling.org
wrote:
On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
The option isn't a true opposite of hash-object's --literally
because
that also allows the
On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
The option isn't a true opposite of hash-object's --literally because
that also allows the creation of known types with invalid contents (e.g.
corrupt trees) whereas cat-file is
On Thursday 16 April 2015 01:56 AM, Ilari Liusvaara wrote:
On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:
Q: Are the mosh principles relevant to other network applications?
We think so. The design principles that Mosh stands for are
conservative: warning the user if the
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Elia Pinto gitter.spi...@gmail.com writes:
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -478,7 +478,7 @@ test_external_without_stderr () {
test_path_is_file () {
if ! test -f
Junio C Hamano venit, vidit, dixit 17.04.2015 19:45:
On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Similarly I think it is not very consistent that one cannot combine any of
the above options with the Sstring but instead have yet another option
called
On 18/04/15 00:11, Lex Spoon wrote:
Simply running p4 changes on a large branch can
result in a too many rows scanned error from the
Perforce server. It is better to use a sequence
of smaller calls to p4 changes, using the -m
option to limit the size of each call.
Signed-off-by: Lex Spoon
Simply running p4 changes on a large branch can
result in a too many rows scanned error from the
Perforce server. It is better to use a sequence
of smaller calls to p4 changes, using the -m
option to limit the size of each call.
Signed-off-by: Lex Spoon l...@lexspoon.org
Reviewed-by: Junio C
On Mon, Apr 20, 2015 at 5:53 AM, Luke Diamand l...@diamand.org wrote:
I could be wrong about this, but it looks like importNewBranches() is taking
an extra argument, but that isn't reflected in the place where it gets
called. I think it just got missed.
As a result, t9801-git-p4-branch.sh
Sorry - could you resubmit your patch (PATCHv4 it will be) with this
change squashed in please? It will make life much easier, especially
for Junio!
Thanks!
Luke
On 20 April 2015 at 16:00, Lex Spoon l...@lexspoon.org wrote:
Simply running p4 changes on a large branch can
result in a too many
Pawel Por porpa...@gmail.com writes:
I've just upgraded the linux kernel git source tree and I want to
pop my stashed work. I do the following:
git stash pop
and I got the following message:
mm/Makefile: needs merge
unable to refresh index
The symptom indicates that upgraded the linux
Michael J Gruber g...@drmicha.warpmail.net writes:
They [jc: -S and -G] have different semantics, and *therefore*
they have different defaults, and *therefore* a user may want to
switch one of them (or --grep or --author or...) to
--fixed--strings and keep the other to --regexp.
Ahh, OK.
Luke Diamand l...@diamand.org writes:
Sorry - could you resubmit your patch (PATCHv4 it will be) with this
change squashed in please? It will make life much easier, especially
for Junio!
Thanks for caring, but this seems to be a full patch to replace v3.
It was sent with your Reviewed-by
Junio C Hamano gits...@pobox.com writes:
Luke Diamand l...@diamand.org writes:
Sorry - could you resubmit your patch (PATCHv4 it will be) with this
change squashed in please? It will make life much easier, especially
for Junio!
Thanks for caring, but this seems to be a full patch to
Hello,
Hopefully this is an appropriate place to ask questions about git-p4.
I started at a company that wants to migrate from Perforce to Git. I'm
new to Perforce and have been trying to learn just enough about it to
get through this migration. Anyway, I've been playing with git-p4 and
have one
Yi, EungJun semtlen...@gmail.com writes:
I'm trying to make my git server sends http messages in non-ASCII
encoding. And I have a question.
At 206-218 in remote-curl.c:
static int show_http_message(struct strbuf *type, struct strbuf *charset,
struct strbuf *msg)
{
On Mon, Apr 20, 2015 at 11:15 AM, Luke Diamand l...@diamand.org wrote:
Sorry - could you resubmit your patch (PATCHv4 it will be) with this
change squashed in please? It will make life much easier, especially
for Junio!
The message you just responded is already the squashed version. It's a
Hi,
I've just upgraded the linux kernel git source tree and I want to
pop my stashed work. I do the following:
git stash pop
and I got the following message:
mm/Makefile: needs merge
unable to refresh index
I also tried:
git stash pop --index
How can I overcome this obstacle.
I did git stash
Hello,
Hopefully this is an appropriate place to ask questions about git-p4.
I started at a company that wants to migrate from Perforce to Git. I'm new
to Perforce and have been trying to learn just enough about it to get
through this migration. Anyway, I've been playing with git-p4 and have run
On 04/20/2015 02:49 PM, Charles Bailey wrote:
On Mon, Apr 20, 2015 at 02:27:44PM +0530, Karthik Nayak wrote:
Sorry, but I didn't get you, broken objects created using hash-object
--literally do not work with cat-file without the --literally option.
Perhaps an example would help:
I cannot
Caledonia Mining Corporation, Canada is presently Recruiting.Send your
CV/RESUME to our HR-Department official E-mail ID:
(camincorporat...@gmail.com) if interested to Work.
Best regards,
Dr.Steven Lloyd.
Human Resources Department
Caledonia Mining Corporation, Canada
Sent to you using
Linus Torvalds torva...@linux-foundation.org writes:
And to clarify: I don't suggest always building with libpcre. I
literally suggest having something like
/* hacky mac-hack hack */
if (strncmp((?i), p-pattern, 4)) {
p-pattern += 4;
p-ignore_case = true;
}
Jeff King p...@peff.net writes:
@@ -334,7 +333,7 @@ true)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
eval=$eval $gpg_sign_args
- eval=$eval -m \\$merge_name\
On 04/20/2015 09:41 AM, FusionX86 wrote:
Hopefully this is an appropriate place to ask questions about git-p4.
I started at a company that wants to migrate from Perforce to Git. I'm
new to Perforce and have been trying to learn just enough about it to
get through this migration.
You might
On Mon, Apr 20, 2015 at 10:41 AM, Junio C Hamano gits...@pobox.com wrote:
Ahh, OK. And not just -S and -G, the fields in headers may be
something user may want to switch independently?
So personally, I hate extra command line flags for this. I'd much
rather see is use something in the regular
On 04/18/2015 02:40 AM, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Apr 17, 2015 at 09:21:31AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
If there _is_ a performance implication to worry about here, I think it
would be that we are doing an extra
On Mon, Apr 20, 2015 at 11:59:04AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
@@ -334,7 +333,7 @@ true)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
On Tue, Apr 21, 2015 at 12:13:30AM +0530, karthik nayak wrote:
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize, void *buffer,
+ unsigned long bufsiz, struct
Tim Friske m...@tifr.de writes:
I wonder why git log --author=pattern does not work with the
regexp-ignore-case option and the other regexp-related options
Wouldn't it be useful to make ...
I think the reason is because nobody bothered to make it so. That
does not necessarily say what you
On 20/04/15 16:25, Lex Spoon wrote:
On Mon, Apr 20, 2015 at 11:15 AM, Luke Diamand l...@diamand.org wrote:
Sorry - could you resubmit your patch (PATCHv4 it will be) with this
change squashed in please? It will make life much easier, especially
for Junio!
The message you just responded is
Jeff King p...@peff.net writes:
On Mon, Apr 20, 2015 at 11:59:04AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
@@ -334,7 +333,7 @@ true)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
eval=$eval $log_arg $strategy_args
On 20/04/15 17:41, FusionX86 wrote:
Hello,
Hopefully this is an appropriate place to ask questions about git-p4.
I started at a company that wants to migrate from Perforce to Git. I'm
new to Perforce and have been trying to learn just enough about it to
get through this migration. Anyway, I've
On Sat, Apr 18, 2015 at 01:35:51PM +1000, Stefan Saasen wrote:
Here are the timings for the two patches:
[...]
Thanks, that matches what I was hoping for.
My tweaked version of your second patch is:
[...]
- return find_pack_entry(sha1, e) freshen_file(e.p-pack_name);
+ if
When writing out an object file, we first check whether it
already exists and if so optimize out the write. Prior to
33d4221, we did this by calling has_sha1_file(), which will
check for packed objects followed by loose. Since that
commit, we check loose objects first.
For the common case of a
Jeff King p...@peff.net writes:
... But I don't know
if this counts as critical (it is for you, certainly, but I don't think
that many people are affected, as the crucial factor here is really the
slow NFS filesystem operations).
If it is critical to some people, they can downmerge to their
Junio C Hamano gits...@pobox.com writes:
This is primarily note-to-self; even though I haven't got around
bisecting yet, I think I know I did some bad change myself.
git pull $URL $tag seems to:
* fail to invoke the editor without --edit.
* show the summary merge log message twice.
We
Since 33d4221 (write_sha1_file: freshen existing objects,
2014-10-15), we update the mtime of existing objects that we
would have written out (had they not existed). For the
common case in which many objects are packed, we may update
the mtime on a single packfile repeatedly. This can result
in a
I'm trying to make my git server sends http messages in non-ASCII
encoding. And I have a question.
At 206-218 in remote-curl.c:
static int show_http_message(struct strbuf *type, struct strbuf *charset,
struct strbuf *msg)
{
const char *p, *eol;
/*
* We only
65 matches
Mail list logo
