* 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
* [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: 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
* 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: [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: [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: [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: 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: [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: 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:38 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:
> IMHO, this logic should be moved into vreportf(), and we get proper
> prefixing of multi-line warning(), error(), and die() messages for free.
I agree with this, so here is a rewrite to do so.
Two points to note.
- Existing users of vreportf() and vwritef() are modified to pass the
prefix like "error", "warning", etc. without colon+SP. The formatting
convention regarding how the "prefix" is separated from the body of the
message should also be locale specific.
- I expect some tests will fail, as there would be existing users that
pass multi-line strings to die(), error() and friends.
For the latter, I didn't bother to check, but I would not be surprised if
everybody thinks the updated output that repeats the same prefix line to
every line is easier to read and formatted more consistently. Updating the
tests to go with this change is left as an exercise for the reader.
-- >8 --
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 | 13 +++++------
builtin/revert.c | 9 +++----
http-backend.c | 2 +-
run-command.c | 2 +-
usage.c | 63 +++++++++++++++++++++++++++++++++++++++++------------
5 files changed, 60 insertions(+), 29 deletions(-)
diff --git a/advice.c b/advice.c
index e02e632..93a03f5 100644
--- a/advice.c
+++ b/advice.c
@@ -24,7 +24,7 @@ void advise(const char *advice, ...)
va_list params;
va_start(params, advice);
- vreportf("hint: ", advice, params);
+ vreportf("hint", advice, params);
va_end(params);
}
@@ -46,16 +46,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 1ea525c..3ad14a1 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -332,11 +332,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)
diff --git a/http-backend.c b/http-backend.c
index 59ad7da..d372252 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -490,7 +490,7 @@ static NORETURN void die_webcgi(const char *err, va_list params)
hdr_nocache();
end_headers();
- vreportf("fatal: ", err, params);
+ vreportf("fatal", err, params);
}
exit(0); /* we successfully reported a failure ;-) */
}
diff --git a/run-command.c b/run-command.c
index 1c51043..f7a7b5c 100644
--- a/run-command.c
+++ b/run-command.c
@@ -78,7 +78,7 @@ static void notify_parent(void)
static NORETURN void die_child(const char *err, va_list params)
{
- vwritef(child_err, "fatal: ", err, params);
+ vwritef(child_err, "fatal", err, params);
exit(128);
}
diff --git a/usage.c b/usage.c
index a2a6678..2d392a4 100644
--- a/usage.c
+++ b/usage.c
@@ -6,45 +6,78 @@
#include "git-compat-util.h"
#include "cache.h"
+typedef void (*emit_fn)(struct strbuf *, void *);
+
+static void v_format(const char *prefix, const char *fmt, va_list params,
+ emit_fn emit, void *cb_data)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf line = STRBUF_INIT;
+ const char *cp, *np;
+
+ strbuf_vaddf(&buf, fmt, params);
+ for (cp = buf.buf; *cp; cp = np) {
+ np = strchrnul(cp, '\n');
+ /*
+ * TRANSLATORS: the format is designed so that in RTL
+ * languages you could reorder and put the "prefix" at
+ * the end instead of the beginning of a line if you
+ * wanted to.
+ */
+ strbuf_addf(&line,
+ _("%s: %.*s\n"),
+ prefix,
+ (int)(np - cp), cp);
+ emit(&line, cb_data);
+ strbuf_reset(&line);
+ if (*np)
+ np++;
+ }
+ strbuf_release(&buf);
+ strbuf_release(&line);
+}
+
+static void emit_report(struct strbuf *line, void *cb_data)
+{
+ fprintf(stderr, "%.*s", (int)line->len, line->buf);
+}
+
void vreportf(const char *prefix, const char *err, va_list params)
{
- char msg[4096];
- vsnprintf(msg, sizeof(msg), err, params);
- fprintf(stderr, "%s%s\n", prefix, msg);
+ v_format(prefix, err, params, emit_report, NULL);
}
-void vwritef(int fd, const char *prefix, const char *err, va_list params)
+static void emit_write(struct strbuf *line, void *cb_data)
{
- char msg[4096];
- int len = vsnprintf(msg, sizeof(msg), err, params);
- if (len > sizeof(msg))
- len = sizeof(msg);
+ int *fd = cb_data;
+ write_in_full(*fd, line->buf, line->len);
+}
- write_in_full(fd, prefix, strlen(prefix));
- write_in_full(fd, msg, len);
- write_in_full(fd, "\n", 1);
+void vwritef(int fd, const char *prefix, const char *err, va_list params)
+{
+ v_format(prefix, err, params, emit_write, &fd);
}
static NORETURN void usage_builtin(const char *err, va_list params)
{
- vreportf("usage: ", err, params);
+ vreportf("usage", err, params);
exit(129);
}
static NORETURN void die_builtin(const char *err, va_list params)
{
- vreportf("fatal: ", err, params);
+ vreportf("fatal", err, params);
exit(128);
}
static void error_builtin(const char *err, va_list params)
{
- vreportf("error: ", err, params);
+ vreportf("error", err, params);
}
static void warn_builtin(const char *warn, va_list params)
{
- vreportf("warning: ", warn, params);
+ vreportf("warning", warn, params);
}
/* If we are in a dlopen()ed .so write to a global variable would segfault
--
1.7.8.1.389.gc5932
^ permalink raw reply related
* Re: [RFC/PATCH] i18n of multi-line messages
From: Johannes Sixt @ 2011-12-22 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vaa6ldpk6.fsf@alter.siamese.dyndns.org>
Am 12/22/2011 8:38, schrieb Junio C Hamano:
> +static void v_format(const char *prefix, const char *fmt, va_list params,
> + emit_fn emit, void *cb_data)
> +{
> + struct strbuf buf = STRBUF_INIT;
> + struct strbuf line = STRBUF_INIT;
> + const char *cp, *np;
> +
> + strbuf_vaddf(&buf, fmt, params);
...
> void vreportf(const char *prefix, const char *err, va_list params)
> {
> - char msg[4096];
> - vsnprintf(msg, sizeof(msg), err, params);
> - fprintf(stderr, "%s%s\n", prefix, msg);
> + v_format(prefix, err, params, emit_report, NULL);
> }
Using strbuf (or xmalloc for that matter) from a function that can be
called from die() is a big no-no. You should keep the fixed-sized buffer.
-- Hannes
^ permalink raw reply
* Warning from AV software about kill.exe
From: Erik Blake @ 2011-12-22 7:47 UTC (permalink / raw)
To: git
I'm running git under Win7 64. As I selected "Repository|Visualize all
branch history" in the git gui, my AV software (Trustport) trapped the
bin\kill.exe program for "trying to modify system global settings (time,
timezone, registry quota, etc.)"
Does anyone know the details of this process and what it's function is?
First time I've seen it, though I'm a relatively new user.
Cheers,
e.
^ permalink raw reply
* Patch to support proxy authentication through NTLM?
From: Schmidt, Marco @ 2011-12-22 8:45 UTC (permalink / raw)
To: git
After debugging git proxy authentication and creating my own fix to
support git+https over an NTLM proxy I found a set of patches inside of
the mailing list archives [1]. What is the state of this patch set? The
essence of the patch would be to allow NTLM authentification by giving
the correct options to libcurl.
Marco
E: marco point schmidt at taugamma.de
[1] http://kerneltrap.org/mailarchive/git/2009/2/2/4873274
^ permalink raw reply
* Re: Warning from AV software about kill.exe
From: Thomas Rast @ 2011-12-22 8:45 UTC (permalink / raw)
To: Erik Blake; +Cc: git
In-Reply-To: <4EF2E08C.3050502@icefield.yk.ca>
Erik Blake <erik@icefield.yk.ca> writes:
> I'm running git under Win7 64. As I selected "Repository|Visualize all
> branch history" in the git gui, my AV software (Trustport) trapped the
> bin\kill.exe program for "trying to modify system global settings
> (time, timezone, registry quota, etc.)"
>
> Does anyone know the details of this process and what it's function
> is? First time I've seen it, though I'm a relatively new user.
'kill' is a standard unix utility that sends signals to processes, in
particular signals that cause the processes to exit or be killed
forcibly by the kernel, hence the name. (I don't know how the windows
equivalent works under the hood, but presumably it's something similar.)
git-gui and gitk use kill to terminate background worker processes that
are no longer needed because you closed the window their output would
have been displayed in, etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Chris Packham @ 2011-12-22 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Ævar Arnfjörð Bjarmason
In-Reply-To: <7vaa6ldpk6.fsf@alter.siamese.dyndns.org>
Hi Junio,
On 12/22/2011 08:38 PM, Junio C Hamano wrote:
> + for (cp = buf.buf; *cp; cp = np) {
> + np = strchrnul(cp, '\n');
> + /*
> + * TRANSLATORS: the format is designed so that in RTL
> + * languages you could reorder and put the "prefix" at
> + * the end instead of the beginning of a line if you
> + * wanted to.
> + */
> + strbuf_addf(&line,
> + _("%s: %.*s\n"),
> + prefix,
> + (int)(np - cp), cp);
> + emit(&line, cb_data);
> + strbuf_reset(&line);
> + if (*np)
> + np++;
> + }
Forgive my ignorance if I've missed something, but how is this going to
work for RTL languages? Translators can change the format string but
they can't change the order of parameters passed to strbuf_addf.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Andreas Schwab @ 2011-12-22 11:56 UTC (permalink / raw)
To: Chris Packham
Cc: Junio C Hamano, Johannes Sixt, git,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF30907.8070101@gmail.com>
Chris Packham <judge.packham@gmail.com> writes:
> Hi Junio,
>
> On 12/22/2011 08:38 PM, Junio C Hamano wrote:
>> + for (cp = buf.buf; *cp; cp = np) {
>> + np = strchrnul(cp, '\n');
>> + /*
>> + * TRANSLATORS: the format is designed so that in RTL
>> + * languages you could reorder and put the "prefix" at
>> + * the end instead of the beginning of a line if you
>> + * wanted to.
>> + */
>> + strbuf_addf(&line,
>> + _("%s: %.*s\n"),
>> + prefix,
>> + (int)(np - cp), cp);
>> + emit(&line, cb_data);
>> + strbuf_reset(&line);
>> + if (*np)
>> + np++;
>> + }
>
> Forgive my ignorance if I've missed something, but how is this going to
> work for RTL languages? Translators can change the format string but
> they can't change the order of parameters passed to strbuf_addf.
Translations can select the parameters to use with the n$ specification,
eg. "%3$.*2$s: %$1s\n"
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Dirk Süsserott @ 2011-12-22 15:49 UTC (permalink / raw)
To: Git Mailing List
Hi!
Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
I often use cmdline and gitk at the same time, switch branches, stash,
rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
highlighted commit is focused again and my HEAD is far off the screen.
Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
fingertip?
TIA
Dirk
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Thomas Rast @ 2011-12-22 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð Bjarmason, git
In-Reply-To: <7vmxale9so.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> 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.
Note that your commit message in pu still says
- append each line in the result to localization of the "hint: " prefix.
even though you now fixed that to be more general.
(It also has a very weird case of mixed indentation when I view it with
'git show':
advise(_("Please rename %s to something else"), gostak);
advise(_("so that we can avoid distimming %s unnecessarily."), doshes);
Apparently the first line is indented with a tab, and the second with 8
spaces.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Martin von Zweigbergk @ 2011-12-22 17:09 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4EF3517A.8030108@dirk.my1.cc>
2011/12/22 Dirk Süsserott <newsletter@dirk.my1.cc>:
> Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
Not sure it's fast enough for you, but you can always enter "HEAD" in
the "SHA1 ID" box (and press Enter).
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Dirk Süsserott @ 2011-12-22 17:23 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Git Mailing List
In-Reply-To: <CAOeW2eGFw0RfU0FHL4CEMVPwSNvrRLv9_iG7Gy_qCheY3GxWxw@mail.gmail.com>
Am 22.12.2011 18:09 schrieb Martin von Zweigbergk:
> 2011/12/22 Dirk Süsserott <newsletter@dirk.my1.cc>:
>> Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
>
> Not sure it's fast enough for you, but you can always enter "HEAD" in
> the "SHA1 ID" box (and press Enter).
Martin, that's fast enough for me. Works great! Thank you.
^ permalink raw reply
* Re: [RFC/PATCH] i18n of multi-line messages
From: Junio C Hamano @ 2011-12-22 18:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <4EF2E824.7020509@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 12/22/2011 8:38, schrieb Junio C Hamano:
>> +static void v_format(const char *prefix, const char *fmt, va_list params,
>> + emit_fn emit, void *cb_data)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + struct strbuf line = STRBUF_INIT;
>> + const char *cp, *np;
>> +
>> + strbuf_vaddf(&buf, fmt, params);
> ...
>> void vreportf(const char *prefix, const char *err, va_list params)
>> {
>> - char msg[4096];
>> - vsnprintf(msg, sizeof(msg), err, params);
>> - fprintf(stderr, "%s%s\n", prefix, msg);
>> + v_format(prefix, err, params, emit_report, NULL);
>> }
>
> Using strbuf (or xmalloc for that matter) from a function that can be
> called from die() is a big no-no. You should keep the fixed-sized buffer.
I _think_ I liked the simplicity of having the logic to
- format localized message to a multi-line buffer; and
- split the contents of that buffer into lines and add prefix in an
i18n friendly way
in vreportf(), but there are many problems in this approach, it seems. We
may need to limit the message length for error()/die() codepath, but we do
not want to be limited in others, definitely not from advise().
Also some calls to error() are meant to produce plumbing error message and
should never be localized. The approach to localize the prefix in vreportf()
will not work for this reason.
I think we should start from the original "advise-only" way. In the longer
term (if somebody cares about it deeply), things can be fixed up and the
mechanism can then be unified in the following order:
(1) figure out a way to allow error() and die() tell if they are called
to produce a plumbing message that should not be translated (multiple
approaches are possible, ranging from adding error_plumb() function
to marking the message format string specially);
(2) update the existing error()/die() calls that are used to produce
plumbing message and mark them as such, using the mechanism decided
in (1);
(3) Take the v_format/vreport code from my patch I am discarding with
this message, enhance them to turn the "prefix" i18n part
consitional, and use that to reimplement the mechanism (1).
But that is not for this year.
^ permalink raw reply
* Re: Gitk: shortcut to jump to the current HEAD (yellow spot)?
From: Pat Thoyts @ 2011-12-22 18:26 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4EF3517A.8030108@dirk.my1.cc>
Dirk Süsserott <newsletter@dirk.my1.cc> writes:
>Hi!
>
>Does anybody know about a shortcut in gitk to "jump to the yellow spot"?
>
>I often use cmdline and gitk at the same time, switch branches, stash,
>rebase and so on from bash. When hitting [Ctrl-]F5 in gitk, the last
>highlighted commit is focused again and my HEAD is far off the screen.
>
>Is there a way to jump to the HEAD (the yellow bubble in gitk) with a
>fingertip?
>
>TIA
> Dirk
Hit the Home key. The binding for that takes you to the first commit.
End to the last (oldest) commit.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Warning from AV software about kill.exe
From: Pat Thoyts @ 2011-12-22 18:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: Erik Blake, git
In-Reply-To: <87mxalkn9q.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>Erik Blake <erik@icefield.yk.ca> writes:
>
>> I'm running git under Win7 64. As I selected "Repository|Visualize all
>> branch history" in the git gui, my AV software (Trustport) trapped the
>> bin\kill.exe program for "trying to modify system global settings
>> (time, timezone, registry quota, etc.)"
>>
>> Does anyone know the details of this process and what it's function
>> is? First time I've seen it, though I'm a relatively new user.
>
>'kill' is a standard unix utility that sends signals to processes, in
>particular signals that cause the processes to exit or be killed
>forcibly by the kernel, hence the name. (I don't know how the windows
>equivalent works under the hood, but presumably it's something similar.)
>
>git-gui and gitk use kill to terminate background worker processes that
>are no longer needed because you closed the window their output would
>have been displayed in, etc.
You might try replacing the command in the tcl scripts with 'exec
taskkill /f /pid $pid' and see if that avoids the error. taskkill is
present on XP and above as part of the OS distribution so shouldn't
suffer any AV complaints.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* "Nested quantifiers" error in gitweb with "++" in the filename
From: Jehan Bing @ 2011-12-22 20:37 UTC (permalink / raw)
To: git
Hi,
I'm getting an error when trying to look at a blob when the filename has
"++" in it:
http://.../blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++.txt
And I get the following error page:
gitprojects /
500 - Internal Server Error
Nested quantifiers in regex; marked by <-- HERE in
m//test.git/blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++ <--
HERE .txt$/ at (eval 10) line 7.
OPML TXT
The Apache log show the same thing:
gitweb.cgi: Nested quantifiers in regex; marked by <-- HERE in
m//test.git/blob/13ec1624fefc23d20d0407aac3337b35844a2ceb:/foo-++ <--
HERE .txt$/ at (eval 10) line 7.
It works fine if the filename has a single '+' sign (tried "foo-+.txt").
There is a same error when browsing a tree and clicking a directory with
the "++"
We notice the error when looking at the Qt source code. They have a
bunch of "*g++*" files and directories.
We use git-1.7.6 but updating to gitweb.cgi from 1.7.8.1 didn't fix it.
Regards,
Jehan
^ permalink raw reply
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