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?
>
> Retu
>> 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 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 wrote:
> When writing out an object file, we fi
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 wrote:
> Since 33d4221 (w
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 c
On Mon, Apr 20, 2015 at 4:07 PM, Stefan Beller wrote:
> On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote:
>> Stefan Beller 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,
>>
On Mon, Apr 20, 2015 at 3:51 PM, Junio C Hamano wrote:
> Stefan Beller 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 apparentl
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
http://git-blame.blogspot.com/p/git-publi
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 r
Stefan Beller 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 transaction even sta
Vitor Antunes writes:
> On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano
> wrote:
>>Vitor Antunes 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
On Fri, Apr 17, 2015 at 4:31 PM, Stefan Beller wrote:
> On Fri, Apr 17, 2015 at 3:17 PM, Stefan Beller wrote:
>> On Fri, Apr 17, 2015 at 3:12 PM, Junio C Hamano wrote:
>>>
>>> This is now pushed out and sitting at the tip of 'pu'. It seems to
>>> break one of the tests in 1400 when merged to 'n
On April 20, 2015 6:43:49 AM GMT+01:00, Junio C Hamano
wrote:
>Vitor Antunes 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 part of the depot path.
>
>I som
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 cod
Michael J Gruber writes:
> Signed-off-by: Michael J Gruber
> ---
> Documentation/rev-list-options.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index f620ee4..77ac439 100644
> --- a/D
Karsten Blees 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 whatever
means to ensure t
Jeff King 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
> @@ -2
Dmitry Gutov 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 touched the index
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.
What
On Mon, Apr 20, 2015 at 01:12:54PM -0700, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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 cherry-pick.
But I wo
On Mon, Apr 20, 2015 at 01:04:11PM -0700, Junio C Hamano wrote:
> Jeff King 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 operation
Jeff King 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 custom
old
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 rep
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 n
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);
> +
Junio C Hamano 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 seem to
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
Jeff King writes:
> On Mon, Apr 20, 2015 at 11:59:04AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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_ar
On 20/04/15 16:25, Lex Spoon wrote:
On Mon, Apr 20, 2015 at 11:15 AM, Luke Diamand 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
On Mon, Apr 20, 2015 at 11:59:04AM -0700, Junio C Hamano wrote:
> Jeff King 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"
>
Jeff King 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 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
Linus Torvalds 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;
> }
>
> just in front o
On 04/18/2015 02:40 AM, Junio C Hamano wrote:
Jeff King writes:
On Fri, Apr 17, 2015 at 09:21:31AM -0700, Junio C Hamano wrote:
Jeff King writes:
If there _is_ a performance implication to worry about here, I think it
would be that we are doing an extra malloc/free.
Thanks for remindi
On Mon, Apr 20, 2015 at 10:41 AM, Junio C Hamano 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 expression i
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 also
Pawel Por 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 kernel git s
Junio C Hamano writes:
> Luke Diamand 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 wi
Luke Diamand 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 already in, but I
Michael J Gruber 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. And not just -S and -G,
"Yi, EungJun" 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)
>> {
>> const ch
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
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 c
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 Uebimi
On Mon, Apr 20, 2015 at 11:15 AM, Luke Diamand 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
single patch that
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 wrote:
> Simply running "p4 changes" on a large branch can
> result in a "too many rows scanned"
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
Reviewed-by: Junio C Hamano
Review
On Mon, Apr 20, 2015 at 5:53 AM, Luke Diamand 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 fails with this
please open attachment file.
3.5% WONGA EXPRESS LOANS PROMOTION-1.doc
Description: MS-Word document
The old wording was somehow implying that and were not
regular expressions. Also, the common case is to use a plain function
name here so makes sense (the fact that it is a regular
expression is documented in line-range-format.txt).
Signed-off-by: Matthieu Moy
Signed-off-by: Junio C Hamano
--
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
Signed-off-by: Junio C Hamano
---
No change since v1 (except Ju
On 19/04/15 18:29, Matthieu Moy wrote:
> The old wording was somehow implying that and were not
> regular expressions. Also, the common case is to use a plain function
> name here so makes sense (the fact that it is a regular
> expression is documented in line-range-format.txt).
>
> Signed-off-
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Elia Pinto 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 "$1"
>>> then
>>> - echo "File $1
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 Spoo
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 to
On April 20, 2015 1:14:34 PM GMT+05:30, Charles Bailey
wrote:
>> On 20 Apr 2015, at 06:30, Junio C Hamano wrote:
>> Charles Bailey 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.
On Fri, Apr 17, 2015 at 7:59 AM, Pedro Rodrigues
wrote:
> 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 took a while to get the term
Junio C Hamano venit, vidit, dixit 17.04.2015 19:45:
> On Fri, Apr 17, 2015 at 7:26 AM, Michael J Gruber
> wrote:
>>>
>>> Similarly I think it is not very consistent that one cannot combine any of
>>> the above options with the "S" but instead have yet another option
>>> called "pickaxe-regex" to
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 us
> On 20 Apr 2015, at 06:30, Junio C Hamano wrote:
> Charles Bailey 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 quite happy to show the _content
63 matches
Mail list logo
