From: Michael Haggerty mhag...@alum.mit.edu
Avoid confusion with the non-static function of the same name from
fetch-pack.h.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
http-walker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-walker.c
From: Michael Haggerty mhag...@alum.mit.edu
Use the names (nr_heads, heads) consistently across functions, instead
of sometimes naming the same values (nr_match, match).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 35 +--
1
From: Michael Haggerty mhag...@alum.mit.edu
This is the first of a few baby steps towards changing filter_refs()
to compress matched refs out of the list rather than overwriting the
first character of such references with '\0'.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
From: Michael Haggerty mhag...@alum.mit.edu
I cannot find a scenario in which this function is called any
significant number of times, so simplify the code by always allocating
an array for return_refs rather than trying to use a stack-allocated
array for small lists.
Signed-off-by: Michael
From: Michael Haggerty mhag...@alum.mit.edu
This simplifies the logic without changing the behavior.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch-pack.c
From: Michael Haggerty mhag...@alum.mit.edu
This fixes a test in t5500.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 2 +-
t/t5500-fetch-pack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
From: Michael Haggerty mhag...@alum.mit.edu
Set the final value at initialization rather than initializing it then
sometimes changing it.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
From: Michael Haggerty mhag...@alum.mit.edu
* Build linked list of return values as we go rather than recording
them in a temporary array and linking them up later.
* Handle ref in a single if...else statement in the main loop, to make
it clear that each ref has exactly two possible
From: Michael Haggerty mhag...@alum.mit.edu
Re-roll, incorporating Jeff's suggestions. Some commit messages have
also been improved, but the only interdiff is that match_pos is
renamed to head_pos in filter_refs().
This patch series applies to the merge between master and
From: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 8
fetch-pack.h | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index
From: Michael Haggerty mhag...@alum.mit.edu
Once a match has been found at head_pos, the entry is zeroed and no
future attempts will match that entry. So increment head_pos to avoid
checking against the zeroed-out entry during the next iteration.
Signed-off-by: Michael Haggerty
From: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/fetch-pack.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index a4bb0ff..c47090d 100644
---
From: Michael Haggerty mhag...@alum.mit.edu
fetch_pack() removes duplicates from the list (nr_heads, heads),
thereby shrinking the list. But previously, the caller was not
informed about the shrinkage. This would cause a spurious error
message to be emitted by cmd_fetch_pack() if git fetch-pack
From: Michael Haggerty mhag...@alum.mit.edu
It used to be that this function processed refnames in some arbitrary
order but wanted to return them in the order that they were requested,
not the order that they were processed. Now, the refnames are
processed in sorted order, so there is no reason
On 08/23/2012 10:31 PM, Jeff King wrote:
I think part of the confusion of this code is that inside the loop over
the refs it is sometimes checking aspects of the ref, and sometimes
checking invariants of the loop (like args.fetch_all). Splitting it into
separate loops makes it easier to see
Back when git apply was written, we made sure that the user can
skip more than the default number of path components (i.e. 1) by
giving -pn, but the logic for doing so was built around the
notion of we skip N slashes and stop. This obviously does not
work well when running under -p0 where we do
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Friday, August 24, 2012 11:51 PM
To: Joachim Schmitz
Cc: git@vger.kernel.org
Subject: Re: [RFC] Support for HP NonStop
Joachim Schmitz j...@schmitz-digital.de writes:
Reminds me of a related issue: in compat/fnmatch/fnmatch.c there
On 08/24/2012 04:02 PM, gree...@obbligato.org wrote:
What is the status of libgit2 WRT the overall git project? I recall
that there was some discussion of basing bits of git on libgit2 once it
matures.
I ask because I'm starting a project to improve the abysmal speed of
git-subtree split.
2012/8/25 Erik Faye-Lund kusmab...@gmail.com:
On Fri, Aug 24, 2012 at 4:17 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com
wrote:
1 tập tin đã bị thay đổi, 5 được thêm vào(+), 3 bị xóa(-)
Huh?
Oh, that's something we should fix soon, too. I suggested a project
language config key some time ago,
Florian Achleitner florian.achleitner.2.6...@gmail.com schrieb im
Newsbeitrag
news:1345662961-9587-16-git-send-email-florian.achleitner.2.6...@gmail.com...
fast-import mark files are stored outside the object database and are
therefore not fetched and can be lost somehow else. marks provide a
Thomas Gummerer t.gumme...@gmail.com schrieb im Newsbeitrag
news:134529-6925-3-git-send-email-t.gumme...@gmail.com...
Add the possibility of re-reading the index file, if it changed
while reading.
The index file might change during the read, causing outdated
information to be displayed.
The getline() function is a GNU extension (you need to define
_GNU_SOURCE before including stdio.h) and is, therefore, not
portable. In particular, getline() is not available on MinGW.
In order to support non-GNU systems, we replace the call to
getline() with (almost) equivalent code using
In particular, the urls passed to git-remote have an extra '/' given
after the schema prefix, like so:
git remote add svnsim testsvn::sim:///$TEST_DIRECTORY/t9154/svn.dump
git remote add svnfile testsvn::file:///$TEST_DIRECTORY/t9154/svn.dump
Once the prefix is removed, the remainder of
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Florian,
Since python is not installed on MinGW, this test fails with
an unable to spawn script type message when attempting to
execute svnrdump. So, could you, in addition to the previous
patch, squash this into commit 2d597d73 (Add
Branch names are usually in ASCII so they are not the problem. The
problem most likely comes from (no branch) translation, which is in
UTF-8 and makes length calculation just wrong.
Update document to mention the fact that we may want ref names in
UTF-8. Encodings that produce invalid UTF-8 are
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Saturday, August 25, 2012 5:55 PM
To: 'florian.achleitner.2.6...@gmail.com'
Cc: git@vger.kernel.org
Subject: Re: [PATCH v6 15/16] remote-svn: add marks-file regeneration
Florian Achleitner florian.achleitner.2.6...@gmail.com
Ramsay Jones wrote:
The getline() function is a GNU extension (you need to define
_GNU_SOURCE before including stdio.h) and is, therefore, not
portable. In particular, getline() is not available on MinGW.
In order to support non-GNU systems, we replace the call to
getline() with (almost)
On Sat, Aug 25, 2012 at 7:13 PM, Ramsay Jones
ram...@ramsay1.demon.co.uk wrote:
The getline() function is a GNU extension (you need to define
_GNU_SOURCE before including stdio.h) and is, therefore, not
portable. In particular, getline() is not available on MinGW.
Actually, getline is a
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/log.c | 1 +
diff.c| 4 ++--
diff.h| 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..62f4b7e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/apply.c | 2 +-
diff.c | 19 ---
diff.h | 2 +-
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index d453c83..3f2779f 100644
---
The l10n effort leads to a situation where a contributor can submit a
patch with some auto-generated information in his language, which may
not be the team's language. We need to make sure exchange medium like
patch is always in a common language that the team understands.
Now this team language
On Sat, Aug 25, 2012 at 03:56:01PM +0100, Iain Paton wrote:
It's like the initial http requests do not get a 401, and the push
proceeds, and then some later request causes a 401 when we do not expect
it. Which is doubly odd, since we should also be able to handle that
case (the first 401
On Sat, Aug 25, 2012 at 2:56 AM, Andreas Ericsson a...@op5.se wrote:
Politically, I'm not sure how keen the git community is on handing
over control to the core stuff of git to a commercial entity,
The development of libgit2 happens 100% in the open. I don't know what
commercial entity are you
The 25/08/12, Vicent Marti wrote:
The development of libgit2 happens 100% in the open. I don't know what
commercial entity are you talking about, but there are several
companies and independent contributors working on the Library at the
moment.
Right but as far as I'm aware of Junio had
Nicolas Sebrecht nicolas.s@gmx.fr writes:
The 25/08/12, Vicent Marti wrote:
The development of libgit2 happens 100% in the open. I don't know what
commercial entity are you talking about, but there are several
companies and independent contributors working on the Library at the
moment.
Robert Luberda rob...@debian.org wrote:
Eric Wong wrote:
Oops, I'll push the following out since Junio already merged your
original:
I can see that you haven't pushed the change yet. Maybe it would be a
good idea to fix other style mistakes (extra spaces after redirections,
lack of
Robert Luberda rob...@debian.org wrote:
Junio C Hamano wrote:
Eric Wong normalper...@yhbt.net writes:
I think having svn in svn.trimsvnlog twice is redundant and not ideal.
Perhaps just --trim-log and svn.trimlog?
Do we ever want to trim our log when relaying the Git commits back
From: AichnerAd adrian.aich...@gmail.com
Please let me know what you think of this patch.
The test mail I sent myself in gmail looked good with Show original.
Best regards
Adrian
---
Documentation/git-daemon.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
38 matches
Mail list logo
