This reduces the number of false positives in untranslated.log when we
check for unmarked strings.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-parse-options.c | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/test-parse-op
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Hard coding path obviously won't fly..
.gitignore | 1 +
wrap-for-bin.sh | 6 ++
2 files changed, 7 insertions(+)
diff --git a/.gitignore b/.gitignore
index bb5c91e..f2d0fe5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -195,6 +195,7 @@
/test-sig
Gettext poison was a macro and _() always returned
"# GETTEXT POISON #". Now that we use real gettext(),
it has to be initialized or it won't work.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
test-date.c | 1 +
test-delta.c| 1 +
test-dump-cache-tree.c | 5 -
test-index-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 45 ++---
gettext.c | 10 --
gettext.h | 10 +-
git-sh-i18n.sh| 14 --
po/.gitignore | 1 +
po/README
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index ddeb04d..485978f 100644
--- a/Makefile
+++ b/Makefile
@@ -2409,7 +2409,7 @@ LOCALIZED_SH += t/t0200/test.sh
LOCALIZED_PERL += t/t0200/test.perl
endif
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 6b0c961..ddeb04d 100644
--- a/Makefile
+++ b/Makefile
@@ -2398,7 +2398,8 @@ XGETTEXT_FLAGS_C = $(XGETTEXT_FLAGS) --language=C \
XGETTEXT_FLAGS_SH = $(
Still WIP but I'm getting closer. I dropped test-poisongen and started
to use podebug [2] instead. Less code in git. podebug does not preserve
shell variables yet. I'll follow that up at upstream [1].
With this series, if you have translation toolkit installed, you could
do
make pseudo-locale
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Thursday, August 23, 2012 11:27 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
>
> "Joachim Schmitz" writes:
>
> >> From: Joachim Schmitz [mailto:j...@schmitz-di
Jeff King writes:
>> It may be (?) that it is a good time to think about a 'datedepth'
>> capability to bypass the current counted-depth shallow fetch that can
>> cause so much trouble. With a date limited depth the relevant tags
>> could also be fetched.
>
> I don't have anything against such an
Hi,
I am new to Git and I am trying to add my machine with Git but it is failing
through ssh method.
Error received:
$ ssh-add -l
2048 5f:6f:39:ed:b0:76:2e:d0:xx:xx:xx:xx:xx:xx:xx:xx id_rsa (RSA)
Gokul$ ssh -vT g...@github.com
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configurat
On Thu, Aug 23, 2012 at 02:40:19PM -0700, Junio C Hamano wrote:
> > This last sentence confuses me. Now we are documenting that "yes, ..
> > really means HEAD..HEAD, which is the empty range". But isn't the point
> > of this patch to say "sure, it would be the empty range, but because
> > that is
From: "Jeff King"
Sent: Thursday, August 23, 2012 8:56 PM
On Thu, Aug 23, 2012 at 08:13:29PM +0100, Philip Oakley wrote:
>>I'm still suspicious about the logic related to args.fetch_all and
>>args.depth, but I don't think I've made anything worse.
>
>I think the point of that is that when doin
Jeff King writes:
>> --- a/Documentation/revisions.txt
>> +++ b/Documentation/revisions.txt
>> @@ -213,6 +213,13 @@ of 'r1' and 'r2' and is defined as
>> It is the set of commits that are reachable from either one of
>> 'r1' or 'r2' but not from both.
>>
>> +In these two shorthands, you can o
"Joachim Schmitz" writes:
>> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
>> Sent: Wednesday, August 22, 2012 11:06 PM
>> To: 'Junio C Hamano'
>> Cc: 'git@vger.kernel.org'
>> Subject: RE: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
>>
>> > From: Junio C Hamano [mailto:git
Carlos Martín Nieto writes:
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> index e9019ac..93e5d6e 100755
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -383,6 +383,22 @@ test_expect_success 'use --set-upstream-to modify a
> particular branch' \
> test "$(git config branch
Carlos Martín Nieto writes:
> The 'track' in the message is still not great, but it does fit with
> the one above. Maybe if we make it say "If youw wanted [...] track the
> remote-tracking branch 'origin/master'" it would be clearer?
The verb "track" in the phrase "remote-tracking branch" means
Junio C Hamano writes:
> The objective of this second traversal is very different from the
> first one, though. We do not need _all_ the merge bases between '1'
> and '2'; we do not even need merge bases.
>
> The only thing we need to prove that '1' is a merge base (i.e. not
> an ancestor of any
On Thu, Aug 23, 2012 at 6:28 PM, Ævar Arnfjörð Bjarmason
wrote:
> I'm planning on using Git for a deployment process where the steps are
> basically:
>
> 1. You log into a deployment host, cd into software.git, do git pull
> 2. A tool runs "make" for you, creates a deployment-MMDD-HHMMSS tag
Junio C Hamano writes:
> Thomas Rast writes:
>
>> At the very least it should be possible to change in_merge_bases() to
>> not do any of the post-filtering; perhaps like the patch below.
>
> I do not recall the details but the post-filtering was added after
> the initial naive version without it
On Thu, Aug 23, 2012 at 03:56:48PM -0400, Jeff King wrote:
> This code blames back to:
>
> commit 4bcb310c2539b66d535e87508d1b7a90fe29c083
> Author: Alexandre Julliard
> Date: Fri Nov 24 16:00:13 2006 +0100
>
> fetch-pack: Do not fetch tags for shallow clones.
>
> A better fix may
On Thu, Aug 23, 2012 at 08:13:29PM +0100, Philip Oakley wrote:
> >>I'm still suspicious about the logic related to args.fetch_all and
> >>args.depth, but I don't think I've made anything worse.
> >
> >I think the point of that is that when doing "git fetch-pack --all
> >--depth=1", the meaning of
From: "Jeff King"
Sent: Thursday, August 23, 2012 10:26 AM
On Thu, Aug 23, 2012 at 10:10:25AM +0200, mhag...@alum.mit.edu wrote:
There were various confusing things (and a couple of bugs) in the way
that fetch_pack() handled the list (nr_heads, heads) of references to
be sought from the remote
This interface is error prone, and a better one (--set-upstream-to)
exists. Add a message listing the alternatives and suggest how to fix
a --set-upstream invocation in case the user only gives one argument
which causes a local branch with the same name as a remote-tracking
one to be created. The t
Am 23.08.2012 03:43, schrieb Junio C Hamano:
> Stefan Zager writes:
>
>> Currently, it will only do a checkout if the sha1 registered in the
>> containing
>> repository doesn't match the HEAD of the submodule, regardless of whether the
>> submodule is dirty. As discussed on the mailing list, th
Thomas Rast writes:
> At the very least it should be possible to change in_merge_bases() to
> not do any of the post-filtering; perhaps like the patch below.
I do not recall the details but the post-filtering was added after
the initial naive version without it that was posted to the list did
no
Signed-off-by: Ramsay Jones
---
Hi Florian,
The build on pu is currently broken:
CC remote-testsvn.o
LINK git-remote-testsvn
cc: vcs-svn/lib.a: No such file or directory
make: *** [git-remote-testsvn] Error 1
This is caused by a dependency missing from the git-remote-
Ævar Arnfjörð Bjarmason writes:
> 5. Copy those to to software-generated.git, removing any that we
> didn't just create, adding any that are new
> 6. Commit that, tag it with generated-deployment-MMDD-HHMMSS
> 9. Do git clean -dxf on software.git remove old generated files
> 10. Copy new
Thomas Rast writes:
> I don't think that ".." is really a no-op. It is true that HEAD..HEAD
> does not itself result in any revisions, but it *could* be used as a
> silly shorthand to introduce ^HEAD into the objects being walked. This
> can make a difference if it then excludes other objects,
David Aguilar writes:
>> After hinting a low-hanging-fruit that would be an easy way for new
>> people to dip their toes, I saw no takers for one month, so I ended
>> up doing it myself.
>
> My bad,...
Not yours. These hints I drop from time to time are meant for eager
new people who want to di
From: "Philipp A. Hartmann"
This adds a generic implementation for credential helpers.
It provides a header file credential_helper.h containing
a simplified credential API and common helper functions.
The implementation in credential_helper.c already provides
a main() function and chooses the cr
From: "Philipp A. Hartmann"
This reduces code duplication in the osxkeychain helper by
basing the implementation on the generic helper implementation.
Alongside, the return codes of the helper are tightened to be
more consistent in corner cases and the memory containing
cleartext passwords is ex
From: "Philipp A. Hartmann"
Use generic credential helper implementation in the
GnomeKeyring credential helper.
The GnomeKeyring helper has been using the generic implementation
internally already and therefore only drops the duplicate code.
Signed-off-by: Philipp A. Hartmann
---
contrib/cred
From: "Philipp A. Hartmann"
With this installed in your $PATH, you can store
git-over-http passwords in your keyring by doing:
git config credential.helper gnome-keyring
The code is based in large part on the work of John Szakmeister
who wrote the helper originally for the initial, unpublished
All,
the following patch series proposes enhancements to the credential helper
implementations in the contrib section. The detailed development history
can be found at GitHub [1].
The first patch adds a GnomeKeyring credential backend. The GnomeKeyring
specific parts are based on the work by
Subject: [PATCH] git svn: Only follow first parents when populating
svn:mergeinfo
properties.
When svn.pushmergeinfo is set, git-svn tries to correctly populate mergeinfo
properties when encountering a merge commit. It does so by first aggregating
the mergeinfo property of the merged parent into
On 23 August 2012 08:10, Catalin Pol wrote:
> Hi everyone,
>
> This is my first email to this mailing list, so this may be somehow
> too straight forward... the idea is that I was thinking to develop a
> new feature in Git (although I'm kind of new to git myself).
> I wrote a small description of
Nguyen Thai Ngoc Duy writes:
> I just did a "git fetch". It took 19 seconds (measured with
> gettimeofday) to finish in_merge_bases() in update_local_ref() in
> fetch.c, just to print this line
>
> + a4f2db3...b95a282 pu -> origin/pu (forced update)
>
> It's partly my fault because I'm
I just did a "git fetch". It took 19 seconds (measured with
gettimeofday) to finish in_merge_bases() in update_local_ref() in
fetch.c, just to print this line
+ a4f2db3...b95a282 pu -> origin/pu (forced update)
It's partly my fault because I'm on gcc -O0. But should it not take
that muc
Jeff King writes:
> On Wed, Aug 22, 2012 at 03:59:43PM -0700, Junio C Hamano wrote:
>
>> Either end of revision range operator can be omitted to default to HEAD,
>> as in "origin.." (what did I do since I forked) or "..origin" (what did
>> they do since I forked). But the current parser interpre
On Wed, Aug 22, 2012 at 11:43 PM, Junio C Hamano wrote:
> why are you special casing a run of non-blank letters that begin
> with a dollar sign (swapping two ints is done with "%2$d %1$d", a
> percent still at the beginning, so there must be something else I am
> missing)?
'$' is for shell variab
On Wed, Aug 22, 2012 at 11:22 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> But a better way could be
>> replacing "tracked" with "t r a c k e d". We know the rule so we can
>> recreate the that string from "tracked" in test_i18n*. Or reverse the
>> upper/lower case, whichever is
2012/8/22 Nguyễn Thái Ngọc Duy :
> The trailing spaces in msgid can be used to separate the next
> word. Accidentally removing it means we may see "On branchmaster"
> instead of "On branch master".
I don't speak Portugese but I think that translation has the same
problem. This is on git.git by the
On Thu, Aug 23, 2012 at 10:10:25AM +0200, mhag...@alum.mit.edu wrote:
> There were various confusing things (and a couple of bugs) in the way
> that fetch_pack() handled the list (nr_heads, heads) of references to
> be sought from the remote:
Aside from the minor comments I made to individual pat
> From: Andreas Ericsson [mailto:a...@op5.se]
> Sent: Thursday, August 23, 2012 10:24 AM
> To: Joachim Schmitz
> Cc: 'Junio C Hamano'; 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org
> Subject: Re: git on HP NonStop
>
> On 08/22/2012 06:38 PM, Joachim Schmitz wrote:
> >
> >
> >> -Origin
On Thu, Aug 23, 2012 at 10:10:42AM +0200, mhag...@alum.mit.edu wrote:
> Subject: Re: [PATCH 17/17] fetch_refs(): simplify logic
> [...]
> static void filter_refs(struct ref **refs, int *nr_heads, char **heads)
The subject should be "filter_refs", no?
-Peff
--
To unsubscribe from this list: send
On Thu, Aug 23, 2012 at 10:10:41AM +0200, mhag...@alum.mit.edu wrote:
> From: Michael Haggerty
>
> fetch_pack() used to delete entries from the input list (*nr_heads,
> heads) and drop them on the floor. (Even earlier versions dropped
> some names on the floor and modified others.) This forced
On Thu, Aug 23, 2012 at 10:10:31AM +0200, mhag...@alum.mit.edu wrote:
> From: Michael Haggerty
>
> fetch_pack() remotes 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
On Thu, Aug 23, 2012 at 10:10:30AM +0200, mhag...@alum.mit.edu wrote:
> From: Michael Haggerty
>
> Once a match has been found at match_pos, the entry is zeroed and no
> future attempts will match that entry. So increment match_pos to
> avoid checking against the zeroed-out entry during the nex
On Thu, Aug 23, 2012 at 10:10:29AM +0200, mhag...@alum.mit.edu wrote:
> From: Michael Haggerty
>
> Use the names (nr_heads, heads) consistently across functions, instead
> of sometimes naming the same values (nr_match, match).
I think this is fine, although:
> --- a/builtin/fetch-pack.c
> +++
On Wed, Aug 22, 2012 at 03:59:43PM -0700, Junio C Hamano wrote:
> Date: Mon, 2 May 2011 13:39:16 -0700
>
> Either end of revision range operator can be omitted to default to HEAD,
> as in "origin.." (what did I do since I forked) or "..origin" (what did
> they do since I forked). But the current
On 08/22/2012 06:38 PM, Joachim Schmitz wrote:
>
>
>> -Original Message-
>> From: Junio C Hamano [mailto:gits...@pobox.com]
>> Sent: Tuesday, August 21, 2012 4:06 AM
>> To: Joachim Schmitz
>> Cc: 'Johannes Sixt'; 'Jan Engelhardt'; git@vger.kernel.org
>> Subject: Re: git on HP NonStop
>>
>
From: Michael Haggerty
This fixes a test in t5500.
Signed-off-by: Michael Haggerty
---
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
index 4794839..5b1e603 100644
--- a/buil
From: Michael Haggerty
Remove any references that were received from the remote from the list
(*nr_heads, heads) of requested references by squeezing them out of
the list (rather than overwriting their names with NUL characters, as
before). On exit, *nr_heads is the number of requested reference
From: Michael Haggerty
fetch_pack() used to delete entries from the input list (*nr_heads,
heads) and drop them on the floor. (Even earlier versions dropped
some names on the floor and modified others.) This forced
fetch_refs_via_pack() to create a separate copy of the original list
so that it
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index d3ff166..5905dae 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -595,7 +5
From: Michael Haggerty
* 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 destinies.
Signed-off-by: Mi
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
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 5905dae..0426cf4 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@
From: Michael Haggerty
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
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3
From: Michael Haggerty
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 to go to the extra
ef
From: Michael Haggerty
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 Haggerty
---
builtin/fe
From: Michael Haggerty
Use the names (nr_heads, heads) consistently across functions, instead
of sometimes naming the same values (nr_match, match).
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
dif
From: Michael Haggerty
This simplifies the logic without changing the behavior.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index cc9af80..4794839 100644
--- a/bui
From: Michael Haggerty
fetch_pack() remotes 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" is
called with dup
From: Michael Haggerty
Once a match has been found at match_pos, the entry is zeroed and no
future attempts will match that entry. So increment match_pos to
avoid checking against the zeroed-out entry during the next iteration.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 2 +-
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
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 7912d2b..cc21047 100644
--- a/builtin/fetch-
From: Michael Haggerty
Avoid confusion with the non-static function of the same name from
fetch-pack.h.
Signed-off-by: Michael Haggerty
---
http-walker.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-walker.c b/http-walker.c
index 51a906e..1516c5e 100644
--- a/ht
From: Michael Haggerty
There were various confusing things (and a couple of bugs) in the way
that fetch_pack() handled the list (nr_heads, heads) of references to
be sought from the remote:
* Different names were used for the list in different functions for no
special reason.
* fetch_pack() m
From: Michael Haggerty
Set the final value at initialization rather than initializing it then
sometimes changing it.
Signed-off-by: Michael Haggerty
---
builtin/fetch-pack.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin/fetch-pack.c b/built
From: Michael Haggerty
If "git fetch-pack" is called with reference names that do not exist
on the remote, then it should emit an error message
error: no such remote ref refs/heads/xyzzy
This is currently broken if *only* missing references are passed to
"git fetch-pack".
Signed-off-by: Mi
On Wed, Aug 22, 2012 at 10:33 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> This way we do not have to risk the list of tools go out of sync
>> between the implementation and the documentation.
>>
>> Signed-off-by: Junio C Hamano
>> ---
>> Junio C Hamano writes:
>>
+--tool-help::
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Wednesday, August 22, 2012 11:06 PM
> To: 'Junio C Hamano'
> Cc: 'git@vger.kernel.org'
> Subject: RE: [PATCH] Don't use curl_easy_strerror prior to curl-7.12.0
>
> > From: Junio C Hamano [mailto:gits...@pobox.com]
> > Sent: Wednesday
On 23/08/12 04:57, David Aguilar wrote:
On Wed, Aug 22, 2012 at 2:44 PM, Carlos Martín Nieto wrote:
Lanoxx writes:
Hi,
Git and Gitk are currently using the ~/.gitconfig and ~/.gitk files in
the $HOME directory. It would be nice to use the XDG Base Directory
standard for the location instea
72 matches
Mail list logo
