Jonathan Nieder wrote:
> Nicolas Vigier wrote:
>
> > When parsing a commit object, git-svn wrongly think that a line
> > containing spaces means the end of headers and the start of the commit
> > message. In case of signed commit, the gpgsig entry contains a line with
> > one space, so "git svn d
Thanks for your answer.
I did not know about "dumb" and "smart" I will read on those in the future.
I found in google that the problem of Error: 403 can be solved.
I run on the git server, in the directory that had the repository: 'git
gc' which do git cleanup and the problem solved.
Thanks you
On Wed, Oct 09, 2013 at 11:35:19PM +0100, Philip Oakley wrote:
> >As a unix user I'd expect the SYNOPSIS section at the top of the
> >man page to include all options that the command accepts. Mutually
> >exclusive options are expected to be in the form [-q | --progress |
> >--all-progress], such
On Thu, Oct 10, 2013 at 01:35:47AM +, brian m. carlson wrote:
> > I don't have a GSS-enabled server to test on. Brian, can you try the
> > patch at the end of this message on your non-working server and see what
> > it outputs?
>
> It doesn't trigger. My server only requires authentication f
On Wed, Oct 09, 2013 at 05:37:42PM -0400, Jeff King wrote:
> On Wed, Oct 09, 2013 at 02:19:36PM -0700, Shawn O. Pearce wrote:
> > 206b099 was written because the Google web servers for
> > android.googlesource.com and code.google.com do not support
> > 100-continue semantics. This caused the client
On Tue, Oct 08, 2013 at 07:12:22PM +0100, Tony Finch wrote:
> We often need to patch the software that we run in order to fix bugs
> quickly rather than wait for an official release, or to add functionality
> that we need. In many cases we have to maintain a locally-developed patch
> for a signifi
On Tue, Oct 08, 2013 at 03:05:22PM +, Shlomit Afgin wrote:
> I do the following on the git server:
>cd /var/www/html/
> git clone --bare /path/to/dir/ gitproject.git
> cd gitproject.git/
> mv hooks/post-update.sample hooks/post-update
> chmod a+x hooks/post-update
OK, so on the next
From: "Loyall, David"
Sent: Tuesday, October 08, 2013 3:03 PM
As a unix user I'd expect the SYNOPSIS section at the top of the man
page to include all options that the command accepts. Mutually
exclusive options are expected to be in the form [-q | --progress
| --all-progress], such is alread
On Wed, Oct 09, 2013 at 02:19:36PM -0700, Shawn O. Pearce wrote:
> > I'd be more comfortable defaulting this to "on" if I understood more
> > about the original problem that led to 959dfcf and 206b099. It sounds
> > like enabling this all the time will cause annoying stalls in the
> > protocol, un
On Wed, Oct 9, 2013 at 12:30 PM, Jeff King wrote:
> On Tue, Oct 08, 2013 at 08:48:06PM +, brian m. carlson wrote:
>
>> When using GSS-Negotiate authentication with libcurl, the authentication
>> provided will change every time, and so the probe that git uses to determine
>> if
>> authenticati
Paolo Giarrusso wrote:
> Seeing the email, I wonder whether there's hope something like that
> can be preserved in an email, and whether the code should use some
> escape sequence instead.
Yes, please. Mind if I amend it to
printf "%s\r" "$revcount/$revmax ($createcount)" >&2
?
[...]
18th International Conference on Applied Mathematics (AMATH '13)
Budapest, Hungary, December 10-12, 2013
http://www.wseas.org/cms.action?id=6258
NEW! The Best Selected Papers will be promoted for (possible) publication in
WSEAS Transactions
(From the 16 WSEAS Journals, the 15 are indexed in SC
On Wed, Oct 09, 2013 at 02:03:24PM +0200, Paolo Giarrusso wrote:
> On Wed, Oct 9, 2013 at 1:26 PM, Matthieu Moy
> wrote:
> > Paolo Giarrusso writes:
> >
> >> Otherwise, one could
> >> change say to use printf, but that's more invasive.
> >
> > "invasive" in the sense that it impacts indirectly m
Stefan Beller wrote:
> This test was put in, but commented out in fed1b5ca (2007-11-09,
> git-checkout: Test for relative path use.)
> It's been a while since 2007 and the intended test case works now.
> (I could not find the enabling commit in ls-files however.)
Bisects to v1.5.5-rc0~184^2~3 (se
On Tue, Oct 08, 2013 at 08:48:06PM +, brian m. carlson wrote:
> When using GSS-Negotiate authentication with libcurl, the authentication
> provided will change every time, and so the probe that git uses to determine
> if
> authentication is needed is not sufficient to guarantee that data can
> Do you mean when you are on a branch that also happens to point at the
> same commit found at a tag? Or do you mean when you have detached your
> HEAD at a tag (e.g., by doing "git checkout v1.0").
I meant the latter. So I will just update git then.
Thank you!
--
本日も小田急線をご利用いただきまして、どうもありがとうござ
Hi Bartek,
bpuzon wrote:
> I was wondering if a patch that adds the tag information (something
> like what "git log --decorate" produces) to the "git status" would
> be welcome?
It would slow down "git status" a little. I haven't thought carefully
about whether that cost is worth it --- it's ha
On Wed, Oct 09, 2013 at 08:54:25PM +0200, bpuzon wrote:
> I was wondering if a patch that adds the tag information (something
> like what "git log --decorate" produces) to the "git status" would be
> welcome?
Do you mean when you are on a branch that also happens to point at the
same commit found
On 10/09/2013 08:55 PM, Jeff King wrote:
> On Wed, Oct 09, 2013 at 08:27:58PM +0200, Stefan Beller wrote:
>
>>> At least on Linux, if you checkout a revision with "foo/" directory,
>>> chdir to it and then checkout a revision with "foo" file to nuke
>>> your current place, I know "git checkout" wi
On Wed, Oct 09, 2013 at 08:27:58PM +0200, Stefan Beller wrote:
> > At least on Linux, if you checkout a revision with "foo/" directory,
> > chdir to it and then checkout a revision with "foo" file to nuke
> > your current place, I know "git checkout" will happily do so and you
> > will still be in
Hello Git,
I was wondering if a patch that adds the tag information (something like what
"git log --decorate" produces) to the "git status" would be welcome?
All the best,
Bartek
--
本日も小田急線をご利用いただきまして、どうもありがとうございました。
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Reigniting the discussion from three weeks ago:
I found it at http://git-blame.blogspot.de/search?q=leftover
On 09/17/2013 09:20 PM, Junio C Hamano wrote:
>
> At least on Linux, if you checkout a revision with "foo/" directory,
> chdir to it and then checkout a revision with "foo" file to nuke
>
On Wed, 9 Oct 2013, Nguyễn Thái Ngọc Duy wrote:
> I know I still have a lot of holes to plug, but this was more
> interesting because we could see some encouraging numbers.
> Unfortunately the result is disappointing. Maybe I did it in a stupid
> way and need to restart with a totally different wa
On Sat, Oct 5, 2013 at 1:55 AM, Duy Nguyen wrote:
> On Fri, Oct 4, 2013 at 9:20 PM, Stefan Beller
> wrote:
>> I think we should emit a warning additionally?
>>
>> Signed-off-by: Stefan Beller
>
> I think it's nice to credit Robert for reporting the fault in the
> commit message (something like "
If we move away from a detached HEAD that has broken or
corrupted commits, we might die in two places:
1. Printing the "old HEAD was..." message.
2. Printing the list of orphaned commits.
In both cases, we ignore the return value of parse_commit
and feed the resulting commit to the pretty-pr
The parse_commit function will check the "parsed" flag of
the object and do nothing if it is set. There is no need
for callers to check the flag themselves, and doing so only
clutters the code.
Signed-off-by: Jeff King
---
builtin/blame.c | 3 +--
builtin/name-rev.c| 3 +--
builtin/sho
Many calls to parse_commit detect errors and die. In some
cases, the custom error messages are more useful than what
parse_commit_or_die could produce, because they give some
context, like which ref the commit came from. Some, however,
just say "invalid commit". Let's convert the latter to use
pars
Some unchecked calls to parse_commit should obviously die on
error, because their next step is to start looking at the
parsed fields, which will cause a segfault. These are
obvious candidates for parse_commit_or_die, which will be a
strict improvement in behavior.
Signed-off-by: Jeff King
---
bu
On Sun, Oct 06, 2013 at 12:48:56AM -0400, Jeff King wrote:
> Instead of a segfault, let's print an error message and die
> a little more gracefully.
> [...]
> ---
> Not a huge deal, since we are terminating the program either way. There
> are other places in the code with a bare parse_commit that
The parse_commit function will check whether it was passed a
NULL commit pointer, and if so, return an error. There is no
need for callers to check this separately.
Signed-off-by: Jeff King
---
There are a few cases left untouched, because they actually produce a
different result for the NULL cas
Signed-off-by: Nguyễn Thái Ngọc Duy
---
list-objects.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index 6def897..39ad3e6 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -7,6 +7,7 @@
#include "t
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 13 ++---
packv4-parse.h | 5 +
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index f9db364..f5c486e 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -10,7 +10,6 @@
#incl
pv4_tree_desc_from_entry() cuts out SHA-1 index lookups when
possible. This patch provides a new set of lookup functions that avoid
looking up object hash table.
We maintain an object pointer array and use SHA-1 table as
key. Because we know index in SHA-1 table in v4 trees, we can skip
binary sea
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 31c89c7..7b096cb 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -443,6 +443,31 @@ stat
When PV4_TREE_CANONICAL is passed, decode_entries() generates
tree entries in canonical format. When this flag is not passed _and_
count is 1, decode_entries fills struct name_entry and saves
sha1_index.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 44 +++
I know I still have a lot of holes to plug, but this was more
interesting because we could see some encouraging numbers.
Unfortunately the result is disappointing. Maybe I did it in a stupid
way and need to restart with a totally different way.
"rev-list --objects" on v2 takes 4 secs, v4 with curr
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 2 +-
sha1_file.c | 3 +--
streaming.c | 9 -
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 20c2d6d..5028ded 100644
--- a/cache.h
+++ b/cache.h
@@ -1168,7 +1168,7 @@ struct object_info {
Best "explained" with an example
void walk(const unsigned char *sha1)
{
struct pv4_tree_desc desc;
/*
* Start pv4_tree_desc from an SHA-1. If it's a v4 tree, v4 walker
* will be used. Otherwise v2 is walked.
*/
pv4_tree_desc_from_sha1(&desc, sha1, 0);
recurse(&de
This struct is intended to be the successor of struct tree_desc. For
now it only holds a buffer for converting pv4 tree to canonical format.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 73 --
packv4-parse.h | 9
2 fil
This is mostly to avoid overhead on v2 only systems.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-parse.c | 5 -
sha1_file.c| 5 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index 7d257af..4354ee3 100644
--- a/packv4-parse.c
+++ b/
This test was put in, but commented out in fed1b5ca (2007-11-09,
git-checkout: Test for relative path use.)
It's been a while since 2007 and the intended test case works now.
(I could not find the enabling commit in ls-files however.)
The code in question however did not change into the sub direct
On Wed, Oct 9, 2013 at 3:34 AM, Eric Sunshine wrote:
> On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland wrote:
>> diff --git a/t/t9117-git-svn-init-clone.sh b/t/t9117-git-svn-init-clone.sh
>> index b7ef9e2..1c8d049 100755
>> --- a/t/t9117-git-svn-init-clone.sh
>> +++ b/t/t9117-git-svn-init-clone.sh
On Wed, Oct 9, 2013 at 3:33 AM, Eric Sunshine wrote:
> On Sat, Oct 5, 2013 at 7:30 PM, Johan Herland wrote:
>> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
>> index 4dd3bcb..da00671 100644
>> --- a/Documentation/git-svn.txt
>> +++ b/Documentation/git-svn.txt
>> @@ -973,6 +97
On Wed, Oct 9, 2013 at 1:26 PM, Matthieu Moy
wrote:
> Paolo Giarrusso writes:
>
>> Otherwise, one could
>> change say to use printf, but that's more invasive.
>
> "invasive" in the sense that it impacts indirectly more callers, but are
> there really cases where "echo" is needed when calling "say
Paolo Giarrusso writes:
> Otherwise, one could
> change say to use printf, but that's more invasive.
"invasive" in the sense that it impacts indirectly more callers, but are
there really cases where "echo" is needed when calling "say"? Aren't
there other potential bugs when arbitrary strings are
Am 10/9/2013 12:32, schrieb Paolo Giarrusso:
> On Wed, Oct 9, 2013 at 12:20 PM, Tay Ray Chuan wrote:
>> On Wed, Oct 9, 2013 at 11:57 AM, Paolo G. Giarrusso
>> wrote:
>>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>>> index 7d7af03..ebfb78f 100755
>>> --- a/contri
(Resending without HTML).
On Wed, Oct 9, 2013 at 12:20 PM, Tay Ray Chuan wrote:
>
> On Wed, Oct 9, 2013 at 11:57 AM, Paolo G. Giarrusso
> wrote:
> > diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> > index 7d7af03..ebfb78f 100755
> > --- a/contrib/subtree/git-subtre
diffcore_count_changes() can return -1 when src_copied is greater than
delta_limit, without counting all the src_copied.
By that, performance of "diff -M/-C" can be improved.
Signed-off-by: Tsuneo Yoshioka
---
diffcore-delta.c | 11 ---
diffcore-rename.c | 2 +-
2 files changed, 9 inse
On Wed, Oct 9, 2013 at 11:57 AM, Paolo G. Giarrusso
wrote:
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index 7d7af03..ebfb78f 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -592,7 +592,9 @@ cmd_split()
> eval "
I am the Chairman of the Audit Committee of a renowned Bank in Singapore. I
have a project worth lots of money and I believe you will be interested in it.
If indeed you are, reply for specifics
chmtsoo...@yahoo.com.sg
This message
50 matches
Mail list logo
