* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-22 7:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF2D436.3080303@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 12/22/2011 0:55, schrieb Junio C Hamano:
>> void advise(const char *advice, ...)
>> {
>> + struct strbuf buf = STRBUF_INIT;
>> va_list params;
>> + const char *cp, *np;
>>
>> va_start(params, advice);
>> - vreportf("hint: ", advice, params);
>> + strbuf_addf(&buf, advice, params);
>> va_end(params);
>> +
>> + for (cp = buf.buf; *cp; cp = np) {
>> + np = strchrnul(cp, '\n');
>> + fprintf(stderr, "%s%.*s\n", _("hint: "), (int)(np - cp), cp);
>> + if (*np)
>> + np++;
>> + }
>> + strbuf_release(&buf);
>> }
>
> IMHO, this logic should be moved into vreportf(), and we get proper
> prefixing of multi-line warning(), error(), and die() messages for free.
Very very good point.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-22 7:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF2D436.3080303@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> + advise(_("Fix them up in the work tree,\n"
>> + "and then use 'git add/rm <file>' as\n"
>> + "appropriate to mark resolution and make a commit,\n"
>> + "or use 'git commit -a'."));
>
> <rant>
> Can people please pay attention how they break multi-line messages? In
> ...
> </rant>
No need for ranting; please just make it so. The above is literal
translation without changing the current output.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Johannes Sixt @ 2011-12-22 6:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vr4zxeaz5.fsf@alter.siamese.dyndns.org>
Am 12/22/2011 0:55, schrieb Junio C Hamano:
> void advise(const char *advice, ...)
> {
> + struct strbuf buf = STRBUF_INIT;
> va_list params;
> + const char *cp, *np;
>
> va_start(params, advice);
> - vreportf("hint: ", advice, params);
> + strbuf_addf(&buf, advice, params);
> va_end(params);
> +
> + for (cp = buf.buf; *cp; cp = np) {
> + np = strchrnul(cp, '\n');
> + fprintf(stderr, "%s%.*s\n", _("hint: "), (int)(np - cp), cp);
> + if (*np)
> + np++;
> + }
> + strbuf_release(&buf);
> }
IMHO, this logic should be moved into vreportf(), and we get proper
prefixing of multi-line warning(), error(), and die() messages for free.
> + advise(_("Fix them up in the work tree,\n"
> + "and then use 'git add/rm <file>' as\n"
> + "appropriate to mark resolution and make a commit,\n"
> + "or use 'git commit -a'."));
<rant>
Can people please pay attention how they break multi-line messages? In
this particular case, (1) even in a 80-columns terminal the lines are
spectacularly short, and (2) a break in the middle of a word group can
easily be avoided such that the result does not look ugly:
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit,
hint: or use 'git commit -a'.
And, no, "It would break the 80-column limit of source code" does not
count for user-visible messages.
</rant>
-- Hannes
^ permalink raw reply
* Re: [PATCHv2 1/2] attr: map builtin userdiff drivers to well-known extensions
From: Ævar Arnfjörð Bjarmason @ 2011-12-22 1:47 UTC (permalink / raw)
To: Jeff King
Cc: git, Johannes Sixt, Junio C Hamano, Brandon Casey,
Jonathan Nieder, Philip Oakley
In-Reply-To: <20111219154938.GA19829@sigill.intra.peff.net>
On Mon, Dec 19, 2011 at 16:49, Jeff King <peff@peff.net> wrote:
> + "*.perl diff=perl",
> + "*.pl diff=perl",
This should also be:
*.pm (for Perl module files)
*.PL (for Makefile.PL)
And it's also very common for Perl code to use, for tests:
*.t
But that likely runs into the namespace clashing issue all over again.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-22 0:20 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <CACBZZX7bgjFz7mvTySPKhR24coqOeVVy8+CsKHVj8Q3LF_-5ww@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Thu, Dec 22, 2011 at 00:55, Junio C Hamano <gitster@pobox.com> wrote:
>
> Nice. Thanks for tackling this. I'll no doubt be submitting some of
> these myself once we start getting translations.
>
> This is not a regression, but note that something like this:
>
>> + fprintf(stderr, "%s%.*s\n", _("hint: "), (int)(np - cp), cp);
>
> Isn't going to cut it for RTL languages like Hebrew and Arabic, since
> for them the "hint: " would effectively be at the end of the line.
>
> I think the easiest way to tackle that sort of thing is to just do:
>
> _("hint: %.*s\n")
>
> And have a TRANSLATORS comment indicating that the format string
> should be kept, but that translators can move around the "hint", GNU
> gettext also has a msgcheck feature to check that format strings are
> compatible in the translations.
Good point. Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Ævar Arnfjörð Bjarmason @ 2011-12-22 0:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr4zxeaz5.fsf@alter.siamese.dyndns.org>
On Thu, Dec 22, 2011 at 00:55, Junio C Hamano <gitster@pobox.com> wrote:
Nice. Thanks for tackling this. I'll no doubt be submitting some of
these myself once we start getting translations.
This is not a regression, but note that something like this:
> + fprintf(stderr, "%s%.*s\n", _("hint: "), (int)(np - cp), cp);
Isn't going to cut it for RTL languages like Hebrew and Arabic, since
for them the "hint: " would effectively be at the end of the line.
I think the easiest way to tackle that sort of thing is to just do:
_("hint: %.*s\n")
And have a TRANSLATORS comment indicating that the format string
should be kept, but that translators can move around the "hint", GNU
gettext also has a msgcheck feature to check that format strings are
compatible in the translations.
^ permalink raw reply
* Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions
From: Philip Oakley @ 2011-12-22 0:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <20111216193253.GD19924@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net> Sent: Friday, December 16, 2011 7:32 PM
> On Fri, Dec 16, 2011 at 07:26:00PM -0000, Philip Oakley wrote:
>
>> >+ "*.m diff=objc",
>>
>> There is a conflict here with the Matlab community which also uses
>> "*.m" files for its scripts and code.
>> They fit the "It's not that hard to do, but it's an extra step that
>> the user might not even know is an option." rationale.
>>
>> If the objc.m is used as a default it must be overidable easily, and
>> listed in the appropriate documentation to mitigate the "might not
>> even know" risk.
>
> It is easily overridable; just put your own "*.m" (or anything that
> matches your files) entry into your gitattributes file. I'm more
> concerned that people will start getting worse results than with the
> default, and not know how to fix it.
>
> If you have some Matlab files, would you mind doing diffs with the
> default driver and with the objc driver, and comment on how good or bad
> the results are?
>
> -Peff
> --
Sorry for the delay.
I started with a fresh install of Msysgit 1.7.8 for my tests, and created a
test repo from a set of old project zip files, retaining only the *.m files.
i.e. it is a real hack project. The diff shown was a small tweak &
investigation step. Below are the three cases of:
1. plain vanilla install (no .gitattributes file)
2. with *.m=matlab in .gitattributes
3. with *.m=objc in .gitattributes
The "*.m=matlab" does give better (proper) hunk headers as it picks out the
"^%%" comment line which starts a code block . For option 3 (ObjC) they are
empty (which is poor). The plain vanila (default) hunk headers are so-so.
There is a vast quantity (10,000+) of Matlab examples on the Mathworks
(vendor) File exchange web site, if anyone is interested,
http://www.mathworks.com/matlabcentral/fileexchange/?sort=date_desc_updated&term=
Roughly my command sequence was:
$git diff HEAD HEAD~1 -p > test.txt
#rename test.txt to suitable name
$echo "*.m diff=matlab" >>.gitattributes
#repeat
$echo "*.m diff=objc" >>.gitattributes
#repeat
-----------------
1. plain vanilla install (no .gitattributes file)
diff --git a/detect_and_track.m b/detect_and_track.m
index 0f0356d..69d650f 100644
--- a/detect_and_track.m
+++ b/detect_and_track.m
@@ -161,9 +161,8 @@ sz = [960, 1280]; pixshrink = 10; % 10 is a guess!
parabolic = pararate(sz(2), pixshrink);
%% Set up the filters.
-% changed sizes to be an extra pixel all round both inner & outer
-hsize = [15 17]; % [11 13] size of (square) filter [vert horiz]
-inhsize = [7 7] ; % [5 5] size of inner filter
+hsize = [11 13]; % size of (square) filter [vert horiz]
+inhsize = [5 5] ; % size of inner filter
% siz=[hsize hsize];
sigma2 = [3.5 4.5]; % outer radius
sigma3 = [1.4 1.4]; % inner radius
@@ -290,7 +289,7 @@ for TframeNum = FrameRange; %change this value to read
in a different frame
% shrink the image
Image = Shrink2(Image);
end
- if any(find(J==[1 2 3 4])) % 5 6 7
+ if any(find(J==[1 2])) % 3 4 5 6 7
% list the levels you want procesed / rectangles shown
% i.e. [1 2 3 4 5 6 7]
[localmean localstdev ] = Point_Filter_cross3(Image,Table);
diff --git a/do_noise_ratios.m b/do_noise_ratios.m
index 663d898..dd73ed0 100644
--- a/do_noise_ratios.m
+++ b/do_noise_ratios.m
@@ -10,7 +10,7 @@
% NewFrame{J,2}=localstdev; %
-for baselev=1:3;
+for baselev=1:2;
Noise_Ratio = Stretch2(NewFrame{baselev+1,2}) ./ NewFrame{baselev,2} ;
Noise_Ratio(Noise_Ratio>5)=5;
figure(49+baselev); colorbar;
-----------------
2. with *.m=matlab in .gitattributes
diff --git a/detect_and_track.m b/detect_and_track.m
index 0f0356d..69d650f 100644
--- a/detect_and_track.m
+++ b/detect_and_track.m
@@ -161,9 +161,8 @@ %% set up the camera Configurations
parabolic = pararate(sz(2), pixshrink);
%% Set up the filters.
-% changed sizes to be an extra pixel all round both inner & outer
-hsize = [15 17]; % [11 13] size of (square) filter [vert horiz]
-inhsize = [7 7] ; % [5 5] size of inner filter
+hsize = [11 13]; % size of (square) filter [vert horiz]
+inhsize = [5 5] ; % size of inner filter
% siz=[hsize hsize];
sigma2 = [3.5 4.5]; % outer radius
sigma3 = [1.4 1.4]; % inner radius
@@ -290,7 +289,7 @@ %% Loop Starts here
% shrink the image
Image = Shrink2(Image);
end
- if any(find(J==[1 2 3 4])) % 5 6 7
+ if any(find(J==[1 2])) % 3 4 5 6 7
% list the levels you want procesed / rectangles shown
% i.e. [1 2 3 4 5 6 7]
[localmean localstdev ] = Point_Filter_cross3(Image,Table);
diff --git a/do_noise_ratios.m b/do_noise_ratios.m
index 663d898..dd73ed0 100644
--- a/do_noise_ratios.m
+++ b/do_noise_ratios.m
@@ -10,7 +10,7 @@ %% do_noise_ratios
% NewFrame{J,2}=localstdev; %
-for baselev=1:3;
+for baselev=1:2;
Noise_Ratio = Stretch2(NewFrame{baselev+1,2}) ./ NewFrame{baselev,2} ;
Noise_Ratio(Noise_Ratio>5)=5;
figure(49+baselev); colorbar;
-----------------
3. with *.m=objc in .gitattributes
diff --git a/detect_and_track.m b/detect_and_track.m
index 0f0356d..69d650f 100644
--- a/detect_and_track.m
+++ b/detect_and_track.m
@@ -161,9 +161,8 @@
parabolic = pararate(sz(2), pixshrink);
%% Set up the filters.
-% changed sizes to be an extra pixel all round both inner & outer
-hsize = [15 17]; % [11 13] size of (square) filter [vert horiz]
-inhsize = [7 7] ; % [5 5] size of inner filter
+hsize = [11 13]; % size of (square) filter [vert horiz]
+inhsize = [5 5] ; % size of inner filter
% siz=[hsize hsize];
sigma2 = [3.5 4.5]; % outer radius
sigma3 = [1.4 1.4]; % inner radius
@@ -290,7 +289,7 @@
% shrink the image
Image = Shrink2(Image);
end
- if any(find(J==[1 2 3 4])) % 5 6 7
+ if any(find(J==[1 2])) % 3 4 5 6 7
% list the levels you want procesed / rectangles shown
% i.e. [1 2 3 4 5 6 7]
[localmean localstdev ] = Point_Filter_cross3(Image,Table);
diff --git a/do_noise_ratios.m b/do_noise_ratios.m
index 663d898..dd73ed0 100644
--- a/do_noise_ratios.m
+++ b/do_noise_ratios.m
@@ -10,7 +10,7 @@
% NewFrame{J,2}=localstdev; %
-for baselev=1:3;
+for baselev=1:2;
Noise_Ratio = Stretch2(NewFrame{baselev+1,2}) ./ NewFrame{baselev,2} ;
Noise_Ratio(Noise_Ratio>5)=5;
figure(49+baselev); colorbar;
^ permalink raw reply related
* Re: Big Mess--How to use Git to resolve
From: Seth Robertson @ 2011-12-21 23:56 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: hs_glw, git
In-Reply-To: <4EF26F7B.90206@gmail.com>
In message <4EF26F7B.90206@gmail.com>, Neal Kreitzinger writes:
We are working on implementing this so some of what I said is
theoretical. Custom branches in combination with submodules seems like
it could get pretty unwieldy if not managed properly.
You might want to consider using gitslave (http://gitslave.sf.net)
which is easier to use when you are developing both the superproject
and the subprojects at the same time. You don't have to use the
"mother-may-I" commit protocol.
The trick with gitslave is that normally you run all git commands on
all repositories at the same time. So all repositories which are part
of the superproject will be on the same branch. This sounds like it
is ideal for you.
However, you do lose the strong binding between the superproject
commit and the subproject commit, so you would want to tag all
projects (trivial when using gitslave) when you go through a release
so that you can later go back and check out synchronized repositories
for a particular release.
-Seth Robertson
^ permalink raw reply
* [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-21 23:55 UTC (permalink / raw)
To: git; +Cc: Ævar Arnfjörð Bjarmason
Advice messages are by definition meant for human end-users, and prime
candidates for i18n/l10n. They tend to also be more verbose to be helpful,
and need to be longer than just one line.
Although we do not have parameterized multi-line advice messages yet, once
we do, we cannot emit such a message like this:
advise(_("Please rename %s to something else"), gostak);
advise(_("so that we can avoid distimming %s unnecessarily."), doshes);
because some translations may need to have the replacement of 'gostak' on
the second line (or 'doshes' on the first line). Some languages may even
need to use three lines in order to fit the same message within a
reasonable width.
Instead, it has to be a single advise() construct, like this:
advise(_("Please rename %s to something else\n"
"so that we can avoid distimming %s unnecessarily."),
gostak, doshes);
Update the advise() function and its existing callers to
- take a format string that can be multi-line and translatable as a
whole;
- use the string and the parameters to form a localized message; and
- append each line in the result to localization of the "hint: " prefix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
advice.c | 23 ++++++++++++++++-------
builtin/revert.c | 9 ++++-----
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/advice.c b/advice.c
index e02e632..fcdf66a 100644
--- a/advice.c
+++ b/advice.c
@@ -21,11 +21,21 @@ static struct {
void advise(const char *advice, ...)
{
+ struct strbuf buf = STRBUF_INIT;
va_list params;
+ const char *cp, *np;
va_start(params, advice);
- vreportf("hint: ", advice, params);
+ strbuf_addf(&buf, advice, params);
va_end(params);
+
+ for (cp = buf.buf; *cp; cp = np) {
+ np = strchrnul(cp, '\n');
+ fprintf(stderr, "%s%.*s\n", _("hint: "), (int)(np - cp), cp);
+ if (*np)
+ np++;
+ }
+ strbuf_release(&buf);
}
int git_default_advice_config(const char *var, const char *value)
@@ -46,16 +56,15 @@ int git_default_advice_config(const char *var, const char *value)
int error_resolve_conflict(const char *me)
{
error("'%s' is not possible because you have unmerged files.", me);
- if (advice_resolve_conflict) {
+ if (advice_resolve_conflict)
/*
* Message used both when 'git commit' fails and when
* other commands doing a merge do.
*/
- advise("Fix them up in the work tree,");
- advise("and then use 'git add/rm <file>' as");
- advise("appropriate to mark resolution and make a commit,");
- advise("or use 'git commit -a'.");
- }
+ advise(_("Fix them up in the work tree,\n"
+ "and then use 'git add/rm <file>' as\n"
+ "appropriate to mark resolution and make a commit,\n"
+ "or use 'git commit -a'."));
return -1;
}
diff --git a/builtin/revert.c b/builtin/revert.c
index fce3f92..440d2be 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -343,11 +343,10 @@ static void print_advice(int show_hint)
return;
}
- if (show_hint) {
- advise("after resolving the conflicts, mark the corrected paths");
- advise("with 'git add <paths>' or 'git rm <paths>'");
- advise("and commit the result with 'git commit'");
- }
+ if (show_hint)
+ advise(_("after resolving the conflicts, mark the corrected paths\n"
+ "with 'git add <paths>' or 'git rm <paths>'\n"
+ "and commit the result with 'git commit'"));
}
static void write_message(struct strbuf *msgbuf, const char *filename)
^ permalink raw reply related
* Re: Big Mess--How to use Git to resolve
From: Neal Kreitzinger @ 2011-12-21 23:44 UTC (permalink / raw)
To: hs_glw; +Cc: git
In-Reply-To: <1324147247781-7104493.post@n2.nabble.com>
On 12/17/2011 12:40 PM, hs_glw wrote:
> Randal, thank you for the comprehensive answer.
Note that Randal's solution leaves with a branch named Release that has
the history of the generic version of your software, and various
custom(er) branches that fork from the Release branch...
On 12/17/2011 6:32 AM, hs_glw wrote:
> Some clients have customizations of the code, some have version 5 of
> the software others have 5.2, 5.5 etc.
>
> My goal is to pull all the different versions in, put them all
> together, and create a master version of the software that runs for
> all clients.
Note that you don't have to make everyone run the same version. At my
shop we maintain dozens of concurrent divergent versions and that is the
main reason we chose git. We can maintain a generic version (which most
clients run) and also custom branches (for clients wanting to pay for
customizations) forked off of the generic branch. The custom branches
can periodically have the generic branch merged in to obtain the generic
fixes/enhancements. You can also merge the custom branches into the
generic branch if you want those custom features included in a new
release of the generic branch.
> There will still be some files that are completely unique to each
> client (style sheets and logos for instance).
If your logos are graphical files they are likely considered 'large
files' and are likely binary files in the context of git. It is
recommended you maintain these in a separate repository to keep them
from bogging down your main repo (performance and storage). You can
make the logo repo a submodule of the main repo (source repo). This
would then make your main repo a 'super project' (contains submodules)
in git terminology. Alternatively, I think your source repo and logo
repo can just both be submodules of a super project.
We are working on implementing this so some of what I said is
theoretical. Custom branches in combination with submodules seems like
it could get pretty unwieldy if not managed properly.
Some things to look into.
v/r,
neal
^ permalink raw reply
* Re: Big Mess--How to use Git to resolve
From: Neal Kreitzinger @ 2011-12-21 23:06 UTC (permalink / raw)
To: hs_glw; +Cc: git
In-Reply-To: <1324147247781-7104493.post@n2.nabble.com>
On 12/17/2011 12:40 PM, hs_glw wrote:
> Randal, thank you for the comprehensive answer.
The technique Randal described sounds like the 'vendor code drop' method
described in the git-rm manpage. There you will find detailed
instructions on the best way to 'erase' the previous version and drop in
a tarball of the 'newer' version.
Hope this helps.
v/r,
neal
^ permalink raw reply
* [ANNOUNCE] Git 1.7.8.1
From: Junio C Hamano @ 2011-12-21 22:34 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.7.8.1 is available. Note that this
is not a release with new features (upcoming 1.7.9 is expected to be
released late January next year to include the pulling of signed tags and
other goodies).
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
198e23e6e50245331590a6159ccdbdbe1792422c git-1.7.8.1.tar.gz
8f674dba39d9ae78928abfe9d924b0855e283e98 git-htmldocs-1.7.8.1.tar.gz
b49ce0b4da4f85671693c9b2c6f6a8b8ee65c809 git-manpages-1.7.8.1.tar.gz
Also the following public repositories all have a copy of the v1.7.8.1
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.8.1 Release Notes
==========================
Fixes since v1.7.8
------------------
* In some codepaths (notably, checkout and merge), the ignore patterns
recorded in $GIT_DIR/info/exclude were not honored. They now are.
* "git apply --check" did not error out when given an empty input
without any patch.
* "git archive" mistakenly allowed remote clients to ask for commits
that are not at the tip of any ref.
* "git checkout" and "git merge" treated in-tree .gitignore and exclude
file in $GIT_DIR/info/ directory inconsistently when deciding which
untracked files are ignored and expendable.
* LF-to-CRLF streaming filter used when checking out a large-ish blob
fell into an infinite loop with a rare input.
* The function header pattern for files with "diff=cpp" attribute did
not consider "type *funcname(type param1,..." as the beginning of a
function.
* The error message from "git diff" and "git status" when they fail
to inspect changes in submodules did not report which submodule they
had trouble with.
* After fetching from a remote that has very long refname, the reporting
output could have corrupted by overrunning a static buffer.
* "git pack-objects" avoids creating cyclic dependencies among deltas
when seeing a broken packfile that records the same object in both
the deflated form and as a delta.
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.8 are as follows:
Brandon Casey (2):
t/t4131-apply-fake-ancestor.sh: fix broken test
builtin/apply.c: report error on failure to recognize input
Carlos Martín Nieto (2):
convert: track state in LF-to-CRLF filter
clone: the -o option has nothing to do with <branch>
Erik Faye-Lund (1):
mingw: give waitpid the correct signature
Jack Nagel (1):
Documentation: fix formatting error in merge-options.txt
Jeff King (5):
http: drop "local" member from request struct
archive: don't let remote clients get unreachable commits
stripspace: fix outdated comment
fetch: create status table using strbuf
blame: don't overflow time buffer
Jens Lehmann (1):
diff/status: print submodule path when looking for changes fails
Junio C Hamano (9):
get_tree_entry(): do not call find_tree_entry() on an empty tree
unpack_object_header_buffer(): clear the size field upon error
receive-pack, fetch-pack: reject bogus pack that records objects twice
pack-object: tolerate broken packs that have duplicated objects
Git 1.7.6.5
Git 1.7.7.5
Update draft release notes for 1.7.8.1
lf_to_crlf_filter(): tell the caller we added "\n" when draining
Git 1.7.8.1
Martin von Zweigbergk (1):
am: don't persist keepcr flag
Michael Haggerty (1):
git symbolic-ref: documentation fix
Michael Schubert (2):
builtin/commit: add missing '/' in help message
builtin/log: remove redundant initialization
Mika Fischer (3):
http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
http.c: Use timeout suggested by curl instead of fixed 50ms timeout
http.c: Rely on select instead of tracking whether data was received
Nguyễn Thái Ngọc Duy (5):
tree-walk.c: do not leak internal structure in tree_entry_len()
read_directory_recursive: reduce one indentation level
tree_entry_interesting(): give meaningful names to return values
tree_entry_interesting: make use of local pointer "item"
checkout,merge: loosen overwriting untracked file check based on info/exclude
Sebastian Morr (1):
Add MYMETA.yml to perl/.gitignore
Thomas Rast (1):
userdiff: allow * between cpp funcname words
Ævar Arnfjörð Bjarmason (3):
apply: get rid of useless x < 0 comparison on a size_t type
cast variable in call to free() in builtin/diff.c and submodule.c
builtin/init-db.c: eliminate -Wformat warning on Solaris
^ permalink raw reply
* Re: [PATCH 4/4] Suppress "statement not reached" warnings under Sun Studio
From: Junio C Hamano @ 2011-12-21 20:41 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Elijah Newren, Jason Evans, David Barr
In-Reply-To: <CACBZZX4htZRQH+2xvoskwE7KoTz98Ox-3xQf0hyEbbFDYCZYHw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> That would make that warning go away, but I don't know if that changes
> the semantics of the code. I was aiming not to change any code, just
> to squash spurious warnings under Sun Studio.
Well, earlier we skipped "if it is NUL return 1 and otherwise make sure it
is a directory separator" check and went directly into whatever happens
after we see a directory separator. The patch causes the same without goto.
If the code is too complex to confuse not so bright compilers, it is
likely to confuse no so bright humans as well, and rewriting the logic in
a more straightforward way to help humans is independently a good thing.
I am not particularly interested in squashing spurious warnings, but if it
falls out of a side effect of helping humans, I wouldn't object to it.
^ permalink raw reply
* Re: [PATCH] git-commit: add option --date-now
From: Jeff King @ 2011-12-21 20:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Carlos Martín Nieto, Michael Schubert, git
In-Reply-To: <vpqmxalrixy.fsf@bauges.imag.fr>
On Wed, Dec 21, 2011 at 05:24:57PM +0100, Matthieu Moy wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > I was surpised when I tried 'git commit --amend --date=now' that git
> > didn't understand 'now' as a date, which seems like a more obvious
> > place to fix it.
>
> +1
>
> I really don't think Git wants yet-another-option for each use-case we
> find, and accepting "now" as a date (either by hardcoding "now" as an
> accepted value, or by running approxidate on the argument of --date).
I'm curious of the use case where one wants "--date=now" but not
"--reset-author". Or is it simply that "--reset-author" is a less
obvious thing to try?
At any rate, if we are going to do that, I agree it should be spelled
"--date=now", and not "--date-now".
-Peff
^ permalink raw reply
* Re: [PATCH] clone: don't say <branch> when we mean <remote>
From: Junio C Hamano @ 2011-12-21 19:25 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1324491249-5357-1-git-send-email-cmn@elego.de>
Carlos Martín Nieto <cmn@elego.de> writes:
> Looking through blame, the second line survived a typo fix and was
> introduced in 2008 when clone was made a builtin. The script used to
> say <name>. So it's clearly nothing urgent, but it bugged me, so I'm
> sending a patch.
Thanks.
How I hated these "rewrite in C" now comes back piece by piece, trickling
in. That's the price of progress, I guess.
^ permalink raw reply
* Re: [PATCH] bash completion: use read -r everywhere
From: Junio C Hamano @ 2011-12-21 19:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Kevin Ballard
In-Reply-To: <87wr9pkahw.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Perhaps we can then just fold it into the first paragraph after the
> POSIX quote, like
Well, that is what I tried say so we are on the same page ;-).
> We use the 'read' command without -r, so that it treats '\' as an
> escape character, in several places. This breaks the loop reading
> refnames from git-for-each-ref in __git_refs() if there are refnames
> such as "foo'bar", in which case for-each-ref helpfully quotes them as
> in
>
> Or some such. Do you want me to resend?
Nah, The above as-is is perfectly fine.
By the way, this is not a problem with the patch, but the for-each-ref
loop is a poor example. Its --shell option is meant to produce a scriptlet
that can be evaled without the buggy processing loop you are fixing, i.e.
script=$(git for-each-ref --shell --format='
ref=%(refname:short)
ref=${ref#*/}
if [[ "$ref" == "$cur"* ]]
then
...
' refs/remotes/) &&
eval "$script"
is how it was designed to be used avoiding shell loops.
>> Does this regress for zsh users in some ways, by the way?
>
> I'm not one of them, but...
Thanks, that was all I wanted to know before deciding if I should apply
this directly to 'master' or cook in 'next' to give real zsh users a
chance to object or tweak it.
^ permalink raw reply
* Re: [PATCH] builtin/commit: add missing '/' in help message
From: Junio C Hamano @ 2011-12-21 19:16 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4EF1F380.3090901@elegosoft.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] builtin/log: remove redundant initialization
From: Junio C Hamano @ 2011-12-21 19:16 UTC (permalink / raw)
To: Michael Schubert; +Cc: git
In-Reply-To: <4EF1CB87.8050801@elegosoft.com>
Thanks.
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-21 19:10 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Jonathan Nieder, git, schacon
In-Reply-To: <201112211820.45447.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> May be Scott Chacon can provide you commit access to git-scm.com ;)
> If you are interested in this of course.
>
> For example wikipedia lists git-scm.com as website for git.
> (http://en.wikipedia.org/wiki/Git_%28software%29)
No, thanks.
They volunteered to keep the site up to date and useful to the user
community and they have been doing a good job at it, and that is why we
advertise git-scm.com as the official site. A minor bug like this which I
know they are perfectly capable of fixing at their site is not a
justifiable incident to trigger taking control and credit over from them.
^ permalink raw reply
* Re: [PATCH] bash completion: use read -r everywhere
From: Thomas Rast @ 2011-12-21 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kevin Ballard
In-Reply-To: <7vipl9hht4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> POSIX specifies
>>
>> The read utility shall read a single line from standard input.
>> By default, unless the -r option is specified, backslash ('\')
>> shall act as an escape character...
>>
>> Our omission of -r breaks the loop reading refnames from
>> git-for-each-ref in __git_refs() if there are refnames such as
>> "foo'bar", in which case for-each-ref helpfully quotes them as in
[...]
> Thanks.
>
> As this script is specific to bash, it is secondary importance what POSIX
> says. The "-r" option is important only because "bash" happens to follow
> POSIX in this case. I'd like to see the early part of the message reworded
> perhaps like this:
>
> At various points in the script, we use "read" utility without
> giving it the "-r" option that prevents a backslash ('\')
> character to act as an escape character. This breaks e.g. reading
> refnames from ...
Perhaps we can then just fold it into the first paragraph after the
POSIX quote, like
We use the 'read' command without -r, so that it treats '\' as an
escape character, in several places. This breaks the loop reading
refnames from git-for-each-ref in __git_refs() if there are refnames
such as "foo'bar", in which case for-each-ref helpfully quotes them as
in
Or some such. Do you want me to resend?
> Does this regress for zsh users in some ways, by the way?
I'm not one of them, but a quick googling for "zsh builtin read" turns
up that it has a dozen options, and -r means
-r
Raw mode: a \ at the end of a line does not signify line continuation.
I can't discern whether it treats \ special at all with or without -r.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 4/4] Suppress "statement not reached" warnings under Sun Studio
From: Ævar Arnfjörð Bjarmason @ 2011-12-21 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Elijah Newren, Jason Evans, David Barr
In-Reply-To: <7vvcp9hjam.fsf@alter.siamese.dyndns.org>
On Wed, Dec 21, 2011 at 19:27, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> diff --git a/read-cache.c b/read-cache.c
>> index a51bba1..0a4e895 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -758,7 +758,13 @@ int verify_path(const char *path)
>> return 0;
>>
>> goto inside;
>> +#ifdef __sun
>> +# pragma error_messages (off, E_STATEMENT_NOT_REACHED)
>> +#endif
>> for (;;) {
>> +#ifdef __sun
>> +# pragma error_messages (on, E_STATEMENT_NOT_REACHED)
>> +#endif
>> if (!c)
>> return 1;
>
> Patches 1-3 makes sense, but this one is too ugly to live.
>
> Wouldn't something like this be equivalent and have the same effect
> without sacrificing the readablity?
>
> diff --git a/read-cache.c b/read-cache.c
> index a51bba1..73af797 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -757,12 +757,12 @@ int verify_path(const char *path)
> if (has_dos_drive_prefix(path))
> return 0;
>
> - goto inside;
> + /* we are at the beginning of a path component */
> + c = '/';
> for (;;) {
> if (!c)
> return 1;
> if (is_dir_sep(c)) {
> -inside:
> c = *path++;
> if ((c == '.' && !verify_dotfile(path)) ||
> is_dir_sep(c) || c == '\0')
That would make that warning go away, but I don't know if that changes
the semantics of the code. I was aiming not to change any code, just
to squash spurious warnings under Sun Studio.
We could also just wrap the whole function definition in the pragma,
which would make the code more readable since we wouldn't have 6 lines
of warning suppression in the middle of the function.
Or we could just drop this patch entirely, or rewrite the code. Your
pick.
^ permalink raw reply
* Re: [PATCH] bash completion: use read -r everywhere
From: Junio C Hamano @ 2011-12-21 18:59 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Kevin Ballard
In-Reply-To: <4502a0248bb843018335e9b5cdf70736c096ebe3.1324482693.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> POSIX specifies
>
> The read utility shall read a single line from standard input.
> By default, unless the -r option is specified, backslash ('\')
> shall act as an escape character...
>
> Our omission of -r breaks the loop reading refnames from
> git-for-each-ref in __git_refs() if there are refnames such as
> "foo'bar", in which case for-each-ref helpfully quotes them as in
>
> $ git update-ref "refs/remotes/test/foo'bar" HEAD
> $ git for-each-ref --shell --format="ref=%(refname:short)" "refs/remotes"
> ref='test/foo'\''bar'
>
> Interpolating the \' here will read "ref='test/foo'''bar'" instead,
> and eval then chokes on the unbalanced quotes.
>
> However, since none of the read loops _want_ to have backslashes
> interpolated, it's much safer to use read -r everywhere.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Thanks.
As this script is specific to bash, it is secondary importance what POSIX
says. The "-r" option is important only because "bash" happens to follow
POSIX in this case. I'd like to see the early part of the message reworded
perhaps like this:
At various points in the script, we use "read" utility without
giving it the "-r" option that prevents a backslash ('\')
character to act as an escape character. This breaks e.g. reading
refnames from ...
Does this regress for zsh users in some ways, by the way?
> ---
> contrib/completion/git-completion.bash | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 78257ae..e7a39ef 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -111,7 +111,7 @@ __git_ps1_show_upstream ()
>
> # get some config options from git-config
> local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
> - while read key value; do
> + while read -r key value; do
> case "$key" in
> bash.showupstream)
> GIT_PS1_SHOWUPSTREAM="$value"
> @@ -589,7 +589,7 @@ __git_refs ()
> local ref entry
> git --git-dir="$dir" for-each-ref --shell --format="ref=%(refname:short)" \
> "refs/remotes/" | \
> - while read entry; do
> + while read -r entry; do
> eval "$entry"
> ref="${ref#*/}"
> if [[ "$ref" == "$cur"* ]]; then
> @@ -602,7 +602,7 @@ __git_refs ()
> case "$cur" in
> refs|refs/*)
> git ls-remote "$dir" "$cur*" 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> case "$i" in
> *^{}) ;;
> *) echo "$i" ;;
> @@ -611,7 +611,7 @@ __git_refs ()
> ;;
> *)
> git ls-remote "$dir" HEAD ORIG_HEAD 'refs/tags/*' 'refs/heads/*' 'refs/remotes/*' 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> case "$i" in
> *^{}) ;;
> refs/*) echo "${i#refs/*/}" ;;
> @@ -636,7 +636,7 @@ __git_refs_remotes ()
> {
> local i hash
> git ls-remote "$1" 'refs/heads/*' 2>/dev/null | \
> - while read hash i; do
> + while read -r hash i; do
> echo "$i:refs/remotes/$1/${i#refs/heads/}"
> done
> }
> @@ -1863,7 +1863,7 @@ __git_config_get_set_variables ()
> done
>
> git --git-dir="$(__gitdir)" config $config_file --list 2>/dev/null |
> - while read line
> + while read -r line
> do
> case "$line" in
> *.*=*)
^ permalink raw reply
* Re: Patches for message-digest support
From: Bill Zaumen @ 2011-12-21 18:44 UTC (permalink / raw)
To: git, peff, pclouds
... sorry for an additional message. The patches I just sent
were based on commit 876a6f4991abdd72ea707b193b4f2b831096ad3c
(Update draft release notes to 1.7.9).
I should have also added that the function verify_commit was
tested via a compile-time option, but it is currently not used.
Its purpose is to verify that the (new) digest header in commit
messages is consistent with the commit's tree, parents, other
headers, and the commit message. For authentication, one
would want to sign the commit SHA-1 hash and the message digest
for the commit (which is stored separate from the commit object).
My patch doesn't do that, but there is a single function that
can be called to look up the digest, if one is present (which may
not be the case due to backwards compatibility issues) - I'd prefer
to have someone familiar with the signature code make any changes.
The version of Makefile in the patch turns off the commit message-digest
header because some of the test scripts won't run with it, due to
those encoding specific SHA-1 values and file lengths, but the test does
run far enough to have created and used a number of commits. I didn't
want to go to the trouble of updating the test scripts unless the patch
is actually going to get used - updating the scripts is a bit tedious
and you'd probably want to decide on the digest hash first.
Bill
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-21 18:39 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <87ipl9yik6.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> With an entry like below
>
> [remote "github"]
> fetch = +refs/tags/*:refs/tags/origin/*
> url = git://github.com/kvaneesh/QEMU.git
>
> when i do git fetch github for-anthony i get the below error
When you give refspecs from the command line like that, the default
refspec remote.github.fetch will not be used and what you configure there
is immaterial.
> [master@QEMU]$ git fetch github for-anthony
>>From git://github.com/kvaneesh/QEMU
> * tag for-anthony -> FETCH_HEAD
Sounds sane.
Does "git cat-file -t FETCH_HEAD" report "tag" (it should)? After doing
that fetch and inspecting "git log -p ..FETCH_HEAD", you should be able to
do "git merge FETCH_HEAD" and it should be like you did "git pull github
for-anthony".
> Also trying to do
>
> [master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git for-anthony:aneesh/for-anthony
> error: Trying to write non-commit object 12916047784615b7d8b879d9d39be6c1559e1b1b to branch refs/heads/aneesh/for-anthony
>>From git://github.com/kvaneesh/QEMU
> ! [new branch] for-anthony -> aneesh/for-anthony (unable to update local ref)
> * [new tag] for-anthony -> for-anthony
Sounds sane, too.
> I understand that replacing the above with below works. But we should
> not be required to specify refs/tags there right ?
>
> [master@QEMU]$ git fetch git://github.com/kvaneesh/QEMU.git refs/tags/for-anthony:refs/tags/aneesh/for-anthony
If the "for-anthony" name is ambiguous between branches and tags, then you
must disambiguate. I am guessing that the unqualified LHS "for-anthony" is
found in the branch namespace of the remote, and that is why RHS is qualified
with the same refs/heads/ prefix to store it to the branch namespace.
On the other hand, if "for-anthony" name is unambiguous, then you may have
found a bug. I cannot tell.
^ permalink raw reply
* Re: [PATCH 4/4] Suppress "statement not reached" warnings under Sun Studio
From: Junio C Hamano @ 2011-12-21 18:27 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Elijah Newren, Jason Evans, David Barr
In-Reply-To: <1324430302-22441-5-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> diff --git a/read-cache.c b/read-cache.c
> index a51bba1..0a4e895 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -758,7 +758,13 @@ int verify_path(const char *path)
> return 0;
>
> goto inside;
> +#ifdef __sun
> +# pragma error_messages (off, E_STATEMENT_NOT_REACHED)
> +#endif
> for (;;) {
> +#ifdef __sun
> +# pragma error_messages (on, E_STATEMENT_NOT_REACHED)
> +#endif
> if (!c)
> return 1;
Patches 1-3 makes sense, but this one is too ugly to live.
Wouldn't something like this be equivalent and have the same effect
without sacrificing the readablity?
diff --git a/read-cache.c b/read-cache.c
index a51bba1..73af797 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -757,12 +757,12 @@ int verify_path(const char *path)
if (has_dos_drive_prefix(path))
return 0;
- goto inside;
+ /* we are at the beginning of a path component */
+ c = '/';
for (;;) {
if (!c)
return 1;
if (is_dir_sep(c)) {
-inside:
c = *path++;
if ((c == '.' && !verify_dotfile(path)) ||
is_dir_sep(c) || c == '\0')
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox