* [PATCH] "git help" and "git help -a" shouldn't exit(1) unless they error
From: Scott R Parish @ 2007-10-21 21:47 UTC (permalink / raw)
To: git
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 1cd33ec..b0d2dd4 100644
--- a/help.c
+++ b/help.c
@@ -204,14 +204,14 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (!help_cmd) {
printf("usage: %s\n\n", git_usage_string);
list_common_cmds_help();
- exit(1);
+ exit(0);
}
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
if(exec_path)
list_commands(exec_path, "git-*");
- exit(1);
+ exit(0);
}
else
--
1.5.3.4.209.g5d1ce-dirty
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 20:21 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211056580.4818@asgard>
On Oct 21, 2007, at 7:57 PM, david@lang.hm wrote:
> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
>>
>>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>>>>> But this is really hard to solve. We would need to compare
>>>>>> attributes before and after for _all_ files that have attributes
>>>>>> in one of the two commits and check if they changed. If so, we
>>>>>> need to do a fresh checkout according to the new attributes.
>>>>> if you know that you will get the new .gitattributes if it
>>>>> changes, setup a post-checkout hook to checkout everything if
>>>>> it has changed. it's far from ideal, but it should be a good,
>>>>> safe, first approximation.
>>>> That's not good enough. I'll stop using .gitattributes. I
>>>> need to teach >40 devs how to use git on Windows. I only use
>>>> features that work flawlessly. .gitattributes doesn't. It bit
>>>> me twice now.
>>> why would checking everything out if .gitattributes has changed
>>> not work? I can see why _not_ doing so would cause problems, and
>>> I freely acknowledge that this approach imposes a performance hit
>>> by checking everything out twice, but I don't see how it would
>>> not be reliable.
>>
>> What do you mean by "checking out everything"?
>> Which command do you propose?
>
> something like git checkout -f
I suspected this. I see two problems:
1) it's too dangerous: I throws away _all_ changes, not only
changes that are related to gitattributes.
2) it doesn't work reliably. git checkout -f will only update
files that git detects as changed. But you could have files that
should have crlf in the working copy but actually have only lf.
Those would not be updated.
I'll not recommend this. Not using .gitattributes is the only
sane solution.
Steffen
^ permalink raw reply
* [PATCH] Split out "exact content match" phase of rename detection
From: Linus Torvalds @ 2007-10-21 18:40 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <alpine.LFD.0.999.0710201158580.10525@woody.linux-foundation.org>
Split out "exact content match" phase of rename detection
This makes the exact content match a separate function of its own.
Partly to cut down a bit on the size of the diffcore_rename() function
(which is too complex as it is), and partly because there are smarter
ways to do this than an O(m*n) loop over it all, and that function
should be rewritten to take that into account.
Whether I'll get to the rewrite or not is not clear, but this is a
worthy cleanup regardless.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
So, I'm looking a bit at rename handling, since it's got the scalability
problems. Andy Chu of google pointed to an algorithm that doesn't use a
m*n array, but instead a hash table to match things up, and that should be
much better. No promises as to whether I'll ever actually implement it,
but just looking at that diffcore_rename function makes your head ache,
and while this doesn't improve any code, at least it splits one
independent thing out of it..
---
diffcore-rename.c | 90 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 56 insertions(+), 34 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 142e537..2077a9b 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -262,6 +262,58 @@ static int compute_stays(struct diff_queue_struct *q,
return 1;
}
+/*
+ * Find exact renames first.
+ *
+ * The first round matches up the up-to-date entries,
+ * and then during the second round we try to match
+ * cache-dirty entries as well.
+ *
+ * Note: the rest of the rename logic depends on this
+ * phase also populating all the filespecs for any
+ * entry that isn't matched up with an exact rename,
+ * see "is_exact_match()".
+ */
+static int find_exact_renames(void)
+{
+ int rename_count = 0;
+ int contents_too;
+
+ for (contents_too = 0; contents_too < 2; contents_too++) {
+ int i;
+
+ for (i = 0; i < rename_dst_nr; i++) {
+ struct diff_filespec *two = rename_dst[i].two;
+ int j;
+
+ if (rename_dst[i].pair)
+ continue; /* dealt with an earlier round */
+ for (j = 0; j < rename_src_nr; j++) {
+ int k;
+ struct diff_filespec *one = rename_src[j].one;
+ if (!is_exact_match(one, two, contents_too))
+ continue;
+
+ /* see if there is a basename match, too */
+ for (k = j; k < rename_src_nr; k++) {
+ one = rename_src[k].one;
+ if (basename_same(one, two) &&
+ is_exact_match(one, two,
+ contents_too)) {
+ j = k;
+ break;
+ }
+ }
+
+ record_rename_pair(i, j, (int)MAX_SCORE);
+ rename_count++;
+ break; /* we are done with this entry */
+ }
+ }
+ }
+ return rename_count;
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
@@ -270,12 +322,11 @@ void diffcore_rename(struct diff_options *options)
struct diff_queue_struct *q = &diff_queued_diff;
struct diff_queue_struct outq;
struct diff_score *mx;
- int i, j, rename_count, contents_too;
+ int i, j, rename_count;
int num_create, num_src, dst_cnt;
if (!minimum_score)
minimum_score = DEFAULT_RENAME_SCORE;
- rename_count = 0;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
@@ -318,40 +369,11 @@ void diffcore_rename(struct diff_options *options)
if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit)
goto cleanup;
- /* We really want to cull the candidates list early
+ /*
+ * We really want to cull the candidates list early
* with cheap tests in order to avoid doing deltas.
- * The first round matches up the up-to-date entries,
- * and then during the second round we try to match
- * cache-dirty entries as well.
*/
- for (contents_too = 0; contents_too < 2; contents_too++) {
- for (i = 0; i < rename_dst_nr; i++) {
- struct diff_filespec *two = rename_dst[i].two;
- if (rename_dst[i].pair)
- continue; /* dealt with an earlier round */
- for (j = 0; j < rename_src_nr; j++) {
- int k;
- struct diff_filespec *one = rename_src[j].one;
- if (!is_exact_match(one, two, contents_too))
- continue;
-
- /* see if there is a basename match, too */
- for (k = j; k < rename_src_nr; k++) {
- one = rename_src[k].one;
- if (basename_same(one, two) &&
- is_exact_match(one, two,
- contents_too)) {
- j = k;
- break;
- }
- }
-
- record_rename_pair(i, j, (int)MAX_SCORE);
- rename_count++;
- break; /* we are done with this entry */
- }
- }
- }
+ rename_count = find_exact_renames();
/* Have we run out the created file pool? If so we can avoid
* doing the delta matrix altogether.
^ permalink raw reply related
* Re: [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Scott Parish @ 2007-10-21 18:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202258440.25221@racer.site>
Earlier, we tried to find the git commands in several possible exec
dirs. Now, if all of these failed, try to find the git command in
PATH.
This allows you to install the git programs somewhere else than
originally specified when building git, as long as you add that location
to the PATH.
Implementation by Johannes Schindelin
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..374ffc9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
int i;
const char *paths[] = { current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
+ builtin_exec_path,
+ "" };
for (i = 0; i < ARRAY_SIZE(paths); ++i) {
size_t len;
@@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
const char *exec_dir = paths[i];
const char *tmp;
- if (!exec_dir || !*exec_dir) continue;
+ if (!exec_dir) continue;
- if (*exec_dir != '/') {
+ if (!*exec_dir)
+ /* try PATH */
+ *git_command = '\0';
+ else if (*exec_dir != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr, "git: cannot determine "
"current directory: %s\n",
@@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
len = strlen(git_command);
rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
+ "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
if (rc < 0 || rc >= sizeof(git_command) - len) {
fprintf(stderr,
"git: command name given is too long.\n");
@@ -99,8 +103,8 @@ int execv_git_cmd(const char **argv)
trace_argv_printf(argv, -1, "trace: exec:");
- /* execve() can only ever return if it fails */
- execve(git_command, (char **)argv, environ);
+ /* execvp() can only ever return if it fails */
+ execvp(git_command, (char **)argv);
trace_printf("trace: exec failed: %s\n", strerror(errno));
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 17:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1A07FEE6-88D8-4ED7-BEFD-F7F3B71310A5@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
>
>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>>
>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>>
>>>>> But this is really hard to solve. We would need to compare
>>>>> attributes before and after for _all_ files that have attributes
>>>>> in one of the two commits and check if they changed. If so, we
>>>>> need to do a fresh checkout according to the new attributes.
>>>> if you know that you will get the new .gitattributes if it changes, setup
>>>> a post-checkout hook to checkout everything if it has changed. it's far
>>>> from ideal, but it should be a good, safe, first approximation.
>>>
>>>
>>> That's not good enough. I'll stop using .gitattributes. I
>>> need to teach >40 devs how to use git on Windows. I only use
>>> features that work flawlessly. .gitattributes doesn't. It bit
>>> me twice now.
>>
>> why would checking everything out if .gitattributes has changed not work? I
>> can see why _not_ doing so would cause problems, and I freely acknowledge
>> that this approach imposes a performance hit by checking everything out
>> twice, but I don't see how it would not be reliable.
>
> What do you mean by "checking out everything"?
> Which command do you propose?
something like git checkout -f
David Lang
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 17:25 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710211007430.4818@asgard>
On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:
> On Sun, 21 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>>
>>>> But this is really hard to solve. We would need to compare
>>>> attributes before and after for _all_ files that have attributes
>>>> in one of the two commits and check if they changed. If so, we
>>>> need to do a fresh checkout according to the new attributes.
>>> if you know that you will get the new .gitattributes if it
>>> changes, setup a post-checkout hook to checkout everything if it
>>> has changed. it's far from ideal, but it should be a good, safe,
>>> first approximation.
>>
>>
>> That's not good enough. I'll stop using .gitattributes. I
>> need to teach >40 devs how to use git on Windows. I only use
>> features that work flawlessly. .gitattributes doesn't. It bit
>> me twice now.
>
> why would checking everything out if .gitattributes has changed not
> work? I can see why _not_ doing so would cause problems, and I
> freely acknowledge that this approach imposes a performance hit by
> checking everything out twice, but I don't see how it would not be
> reliable.
What do you mean by "checking out everything"?
Which command do you propose?
Steffen
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 17:09 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <B61AE1A9-E983-4ACE-BF71-8FDC113A4F34@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>
>>> But this is really hard to solve. We would need to compare
>>> attributes before and after for _all_ files that have attributes
>>> in one of the two commits and check if they changed. If so, we
>>> need to do a fresh checkout according to the new attributes.
>>
>> if you know that you will get the new .gitattributes if it changes, setup a
>> post-checkout hook to checkout everything if it has changed. it's far from
>> ideal, but it should be a good, safe, first approximation.
>
>
> That's not good enough. I'll stop using .gitattributes. I
> need to teach >40 devs how to use git on Windows. I only use
> features that work flawlessly. .gitattributes doesn't. It bit
> me twice now.
why would checking everything out if .gitattributes has changed not work?
I can see why _not_ doing so would cause problems, and I freely
acknowledge that this approach imposes a performance hit by checking
everything out twice, but I don't see how it would not be reliable.
David Lang
> Luckily, core.autocrlf works if you set it before the first
> checkout and never change it. This seems sufficient for me if
> all files that have mixed line endings are fixed right away.
>
> Steffen
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Andreas Ericsson @ 2007-10-21 14:17 UTC (permalink / raw)
To: Jan Hudec
Cc: Wincent Colaiuta, Shawn O. Pearce, Johannes Schindelin,
Jari Aalto, git
In-Reply-To: <20071021131351.GE8887@efreet.light.src>
Jan Hudec wrote:
> On Sun, Oct 21, 2007 at 14:42:25 +0200, Andreas Ericsson wrote:
>> Wincent Colaiuta wrote:
>>> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>>>
>>>>>>>> - commented out call to list_common_cmds_help()
>>>>> Well, I'm almost sure of the opposite. One of the big results of the
>>>>> Git
>>>>> Survey was that git is still not user-friendly enough. Your patch would
>>>>> only make this issue worse.
>>>> Actually I think Jari's patch helps for the reason originally
>>>> stated in the message (less output when you make a small typo).
>>>> Though I agree that the commented out code should just be removed.
>>>>
>>>> I actually had to do `git config alias.upsh push` just to keep
>>>> myself from screaming every time I made a small typo and Git gave
>>>> me a screenful of "helpful reminders".
>>> If you want to go really user friendly, how about a check against the list
>>> of known commands using a shortest-edit distance algorithm?
>> http://en.wikipedia.org/wiki/Levenshtein_distance
>>
>> Implementing the algorithm doesn't seem terribly difficult.
>
> That's not the correct algorithm (you need to consider transpozitions, so you
> need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but
> I would not think that's the easier, or faster, way to do it. Though this
> would have to be benchmarked -- calculating the edit distance is quadratic,
> while generating the list of possibilities (and seeing whether they exist) is
> linear, but with large constant. So the question is, whether we have few
> enough commands that the quadratic calculation might be faster.
>
It's intended to be used for strings of length 3-14, run through once when the
user has given bogus input. We're not gonna index databases here. Simplicity
in the implementation almost certainly outweighs the performance penalty of
doing it the stupid way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jan Hudec @ 2007-10-21 13:13 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Shawn O. Pearce, Johannes Schindelin,
Jari Aalto, git
In-Reply-To: <471B4931.5040102@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
On Sun, Oct 21, 2007 at 14:42:25 +0200, Andreas Ericsson wrote:
> Wincent Colaiuta wrote:
>> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>>
>>>>>>> - commented out call to list_common_cmds_help()
>>>>
>>>> Well, I'm almost sure of the opposite. One of the big results of the
>>>> Git
>>>> Survey was that git is still not user-friendly enough. Your patch would
>>>> only make this issue worse.
>>>
>>> Actually I think Jari's patch helps for the reason originally
>>> stated in the message (less output when you make a small typo).
>>> Though I agree that the commented out code should just be removed.
>>>
>>> I actually had to do `git config alias.upsh push` just to keep
>>> myself from screaming every time I made a small typo and Git gave
>>> me a screenful of "helpful reminders".
>> If you want to go really user friendly, how about a check against the list
>> of known commands using a shortest-edit distance algorithm?
>
> http://en.wikipedia.org/wiki/Levenshtein_distance
>
> Implementing the algorithm doesn't seem terribly difficult.
That's not the correct algorithm (you need to consider transpozitions, so you
need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but
I would not think that's the easier, or faster, way to do it. Though this
would have to be benchmarked -- calculating the edit distance is quadratic,
while generating the list of possibilities (and seeing whether they exist) is
linear, but with large constant. So the question is, whether we have few
enough commands that the quadratic calculation might be faster.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* gitk still interested in translations?
From: Christian Stimming @ 2007-10-21 12:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
In-Reply-To: <18090.44123.905869.974967@cargo.ozlabs.ibm.com>
Hi Paul,
in July I submitted patches to add the necessary framework for UI
translations/i18n to the gitk tool [1] [2], and I'd also volunteer to provide
a full German translation. As you pointed out [3], this would require some
decisions on integration and installation places, which according to Junios
reply [4] didn't seem too difficult.
What is the progress on your i18n plans in gitk? None of the patches had been
applied to gitk, have they? If you say you *are* interested, I'd be happy to
provide an up-to-date patch against gitk.git @ kernel.org for #1 Makefile
rules, #2 msgcat integration, and most importantly #3 message markup.
Christian
[1] http://marc.info/?l=git&m=118554802809395&w=2
[2] http://marc.info/?l=git&m=118554865029767&w=2
[3] http://marc.info/?l=git&m=118559040716553&w=2
[4] http://marc.info/?l=git&m=118559853016496&w=2
Am Samstag, 28. Juli 2007 04:39 schrieb Paul Mackerras:
> Christian Stimming writes:
> > Similar to the discussion in git-gui, all user-visible strings are
> > passed through the [mc ...] procedure to have them translated by msgcat.
> >
> > Signed-off-by: Christian Stimming <stimming@tuhh.de>
> > ---
> > @Paul: Are you interested in applying this? If yes, I'd happily
>
> Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
> whitespace-damaged, though.
>
> > provide the Makefile rules for string extraction and translation
> > catalog updates, but I'd like to hear a proposal or decision on where
> > to place them. Should the po files for translation go into the po/
> > subdirectory? And then a proposal/decision of where to install the
> > compiled .msg catalogs will be necessary.
>
> Yes indeed. Junio?
>
> Is it possible to include the translations, or at least the more
> common translations, in the Tcl code itself? So far I have managed to
> have gitk be self-contained, in that it doesn't need any external data
> files, which simplifies installation and is a useful attribute in some
> situations.
>
> Also I would want to be sure that gitk wouldn't crash or fail to
> function if it can't find its message catalogs.
>
> Paul.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Andreas Ericsson @ 2007-10-21 12:42 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Shawn O. Pearce, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <ED3FFB7A-861F-47E4-97EA-D7A05552FC2C@wincent.com>
Wincent Colaiuta wrote:
> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>
>>>>>> - commented out call to list_common_cmds_help()
>>>
>>> Well, I'm almost sure of the opposite. One of the big results of the
>>> Git
>>> Survey was that git is still not user-friendly enough. Your patch would
>>> only make this issue worse.
>>
>> Actually I think Jari's patch helps for the reason originally
>> stated in the message (less output when you make a small typo).
>> Though I agree that the commented out code should just be removed.
>>
>> I actually had to do `git config alias.upsh push` just to keep
>> myself from screaming every time I made a small typo and Git gave
>> me a screenful of "helpful reminders".
>
> If you want to go really user friendly, how about a check against the
> list of known commands using a shortest-edit distance algorithm?
>
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Rocco Rutte @ 2007-10-21 12:12 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[ No need to Cc: me as I'm on the git list, too ]
Hi,
* Michele Ballabio [07-10-20 18:02:47 +0200] wrote:
>Uh-oh. I think I just found the issue. That's probably a bug
>somewhere in the import (either fast-export or fast-import or
>the original repo, I don't know), so I'm not sure if gitk
>should be patched, but since the resulting repo seems correct
>as far as git is concerned (i.e. git fsck --full --strict
>doesn't complain), I guess something should be done.
>Here is the culprit (or so I think). One of the guilty commits is:
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Oh. Yes, this is a bug in the python scripts that get merges quite
wrong. I didn't notice that earlier as git doesn't complain and the
contents of the repo turns out as identical.
I'll push fixes (e.g. packed refs support) to the fast-export repo in
Monday. With these changes, the mutt repo as well hg-crew (which has far
more merges than the mutt repo) seem to work correctly (no identical
parents and identical contents).
Thanks for tracking it down.
Still I think fast-import could warn or error out if its gets such
content which doesn't really make sense...
Rocco
^ permalink raw reply
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Pierre Habouzit @ 2007-10-21 10:31 UTC (permalink / raw)
To: René Scharfe; +Cc: Shawn O. Pearce, git
In-Reply-To: <471B1AA5.8070009@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Sun, Oct 21, 2007 at 09:23:49AM +0000, René Scharfe wrote:
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > builtin-apply.c | 2 +-
> > builtin-archive.c | 2 +-
> > diff.c | 4 ++--
> > entry.c | 2 +-
> > strbuf.h | 8 +++++++-
> > test-delta.c | 3 ++-
> > 6 files changed, 14 insertions(+), 7 deletions(-)
>
> I have a feeling this is going in then wrong direction. Shouldn't
> we rather use size_t everywhere? malloc() takes a size_t, and it's
> the basis of strbuf and also of the file content functions.
I agree, Junio was working on a patch that generalized use of size_t's
when unsigned long where used and size_t meant, I suppose he didn't had
the time to push it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 10:27 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710210204580.4818@asgard>
On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>> But this is really hard to solve. We would need to compare
>> attributes before and after for _all_ files that have attributes
>> in one of the two commits and check if they changed. If so, we
>> need to do a fresh checkout according to the new attributes.
>
> if you know that you will get the new .gitattributes if it changes,
> setup a post-checkout hook to checkout everything if it has
> changed. it's far from ideal, but it should be a good, safe, first
> approximation.
That's not good enough. I'll stop using .gitattributes. I
need to teach >40 devs how to use git on Windows. I only use
features that work flawlessly. .gitattributes doesn't. It bit
me twice now.
Luckily, core.autocrlf works if you set it before the first
checkout and never change it. This seems sufficient for me if
all files that have mixed line endings are fixed right away.
Steffen
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option
From: Jan Hudec @ 2007-10-21 10:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jari Aalto, git
In-Reply-To: <20071021033318.GD14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sat, Oct 20, 2007 at 23:33:18 -0400, Shawn O. Pearce wrote:
> Jari Aalto <jari.aalto@cante.net> wrote:
> > - Remove out call to list_common_cmds_help()
>
> Even if the list is against this change (which I'm in favor of)...
I didn't get the impression that the _whole_ list is against. I think that
the rather longish list should only be shown for 'git help' and when no
command was specified (but that is handled by implying help, so this change
does not apply to that case), so I am in favor of this.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Steffen Prohaska @ 2007-10-21 10:06 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Steven Walter, Johannes Schindelin, Ciprian Dorin Craciun,
Evan Carroll, git
In-Reply-To: <F430333B-B29B-4992-9474-0E87006CBA77@wincent.com>
On Oct 21, 2007, at 11:10 AM, Wincent Colaiuta wrote:
> El 21/10/2007, a las 5:09, Steven Walter escribió:
>
>> On Sat, Oct 20, 2007 at 10:34:34PM +0100, Johannes Schindelin wrote:
>>> I am torn. On one side I like the Wiki approach. On the other
>>> hand, the
>>> Wiki will get less review by git oldtimers, whereas the patches to
>>> user-manual are usually reviewed as thoroughly as the code patches.
>>
>> No offense, but review by old timers can be both a blessing and a
>> curse.
>> Well, it's not the "review" that is so much a problem as the
>> "editorial
>> control." In my opinion (and I believe this is what the original
>> poster
>> was saying), the official Git User Manual focuses more on technical
>> issues and less on introducing git to a new user.
>
> But it's not an "intro", it's a user manual. That means it's
> supposed to be a comprehensive, in-depth treatment of just about
> everything. The technical content is a good thing; it's supposed to
> be the document you turn to when you want to move beyond
> superficial use to genuine, in-depth understanding.
But it could also have introductory parts and parts decribing
specific workflows.
Something similar to svnbook or cvsbook would be perfect. I
believe a reasonable goal is that you'll get all need if you
search gitbook with google.
Steffen
^ permalink raw reply
* Re: [BUG] git-mv submodule failure
From: Johannes Schindelin @ 2007-10-21 10:02 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710202248v56af5cb0gcf7dacb32848eca3@mail.gmail.com>
Hi,
On Sun, 21 Oct 2007, Yin Ping wrote:
> > But of course .gitmodules is unaffected. But it should be changed, too.
>
> IMHO, changing .gitmodules is what the 'git-submodule mv' should do, and
> 'git-mv' should only rename the module directory
No. If you "git mv" a submodule, it makes absolutely no sense to leave
.gitmodules as is.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-21 9:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071020031917.GR14735@spearce.org>
Reword the first sentence of the description of -x, in order to
make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
* Shawn O. Pearce wrote on Sat, Oct 20, 2007 at 05:19:17AM CEST:
> Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote:
> > >
> > > Is that by design (because there were conflicts) or an omission?
> > > In case of the former, maybe the description of -x should mention this.
> >
> > git commit currently doesn't know that you commit a cherry-pick. The -c
> > only says to use the commit message of the original commit. So this is
> > currently by design.
>
> Ralf, can you submit an updated version of this patch that describes
> the current behavior better, given the "by design" remark above
> from Frank?
Here it goes. Still makes me wonder whether that is the ideal mode of
operation or not.
FWIW, I think the previous passive voice wording was correct English,
but here's a rewrite using mostly active voice (sound nicer anyway).
Cheers,
Ralf
Documentation/git-cherry-pick.txt | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 47b1e8c..76a2edf 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -27,11 +27,12 @@ OPTIONS
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
- information is useless to the recipient. If on the
+ When recording the commit, append to the original commit
+ message a note that indicates which commit this change
+ was cherry-picked from. Append the note only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: René Scharfe @ 2007-10-21 9:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071021052537.GB31927@spearce.org>
Fix size_t vs. unsigned long pointer mismatch warnings introduced
with the addition of strbuf_detach().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Shawn O. Pearce schrieb:
> On at least one system I've used recently sizeof(size_t) == 4
> and sizeof(unsigned long) == 8. Trying to pass a pointer to an 8
> byte value into strbuf_detach() causes problems as the function is
> expecting an address for a 4 byte result location. Writing only 4
> bytes here will leave the other 4 bytes unitialized and may cause
> problems when the caller evalutes the result.
>
> I am introducing strbuf_detach_ul() as a variant that takes its
> size as an unsigned long rather than as a size_t. This approach is
> shorter than fixing all of the callers to use their own temporary
> size_t value for the call.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-apply.c | 2 +-
> builtin-archive.c | 2 +-
> diff.c | 4 ++--
> entry.c | 2 +-
> strbuf.h | 8 +++++++-
> test-delta.c | 3 ++-
> 6 files changed, 14 insertions(+), 7 deletions(-)
I have a feeling this is going in then wrong direction. Shouldn't
we rather use size_t everywhere? malloc() takes a size_t, and it's
the basis of strbuf and also of the file content functions.
The following patch is shorter, though it adds one more line than
your's. The result is slightly uglier, but it's a good reminder to
use size_t in more places.
That said, I realize that converting read_sha1_file() et al. would
be quite painful. Maybe too painful?
builtin-apply.c | 2 +-
builtin-archive.c | 4 +++-
diff.c | 8 ++++++--
entry.c | 4 +++-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 047a60d..541a6f4 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -152,7 +152,7 @@ struct patch {
unsigned int is_rename:1;
struct fragment *fragments;
char *result;
- unsigned long resultsize;
+ size_t resultsize;
char old_sha1_prefix[41];
char new_sha1_prefix[41];
struct patch *next;
diff --git a/builtin-archive.c b/builtin-archive.c
index 04385de..6f29c2f 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -148,12 +148,14 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
buffer = read_sha1_file(sha1, type, sizep);
if (buffer && S_ISREG(mode)) {
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
convert_to_archive(path, buf.buf, buf.len, &buf, commit);
- buffer = strbuf_detach(&buf, sizep);
+ buffer = strbuf_detach(&buf, &size);
+ *sizep = size;
}
return buffer;
diff --git a/diff.c b/diff.c
index 0bd7e24..df82ed6 100644
--- a/diff.c
+++ b/diff.c
@@ -1512,6 +1512,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
static int populate_from_stdin(struct diff_filespec *s)
{
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
if (strbuf_read(&buf, 0, 0) < 0)
@@ -1519,7 +1520,8 @@ static int populate_from_stdin(struct diff_filespec *s)
strerror(errno));
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
return 0;
}
@@ -1609,9 +1611,11 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
*/
strbuf_init(&buf, 0);
if (convert_to_git(s->path, s->data, s->size, &buf)) {
+ size_t size = 0;
munmap(s->data, s->size);
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
}
}
diff --git a/entry.c b/entry.c
index 98f5f6d..cfadc6a 100644
--- a/entry.c
+++ b/entry.c
@@ -119,8 +119,10 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
*/
strbuf_init(&buf, 0);
if (convert_to_working_tree(ce->name, new, size, &buf)) {
+ size_t newsize = 0;
free(new);
- new = strbuf_detach(&buf, &size);
+ new = strbuf_detach(&buf, &newsize);
+ size = newsize;
}
if (to_tempfile) {
^ permalink raw reply related
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 9:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1192956535617-git-send-email-prohaska@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> If a .gitattributes is in the work tree and we checkout a
> different head, the .gitattributes of the head we are switching
> to must have precedence. Files are expected to be converted as
> configured in the .gitattributes that is available in the head
> we're switching to.
>
> This adds a test case revealing deficiencies of the current
> handling of .gitattributes.
>
> At a first glance, I saw two possible resolutions:
> 1) .gitattributes from the index has precedence. It's unclear
> how merging can be handled appropriately.
> 2) .gitattributes are handled as a special file. Checkout is a
> two pass process. In the first pass only the special file
> .gitattributes is checked out. In th second pass the remaining
> files are added. Maybe this gives a perspective how to handle
> merges.
>
> But actually the issue is much harder to solve.
>
> Here is what needs to be done: Whenever the attributes of a file
> change the file must be freshly checked out according to the
> attributes of the head we switch to.
this is the same problem that we would have with the extended file
attributes, in the discussion for those it was suggested that I refrence
the file from the index rather then from the file system to avoid needing
to do two passes.
> The file itself does not
> necessarily change between the two commits. A fresh checkout is
> already needed if only .gitattributes change.
>
> But this is really hard to solve. We would need to compare
> attributes before and after for _all_ files that have attributes
> in one of the two commits and check if they changed. If so, we
> need to do a fresh checkout according to the new attributes.
if you know that you will get the new .gitattributes if it changes, setup
a post-checkout hook to checkout everything if it has changed. it's far
from ideal, but it should be a good, safe, first approximation.
you shouldn't need to check all files of all attributes, only on any that
match the lines that get changed. the hook for this is exactly the type of
thing that I was talking about in the metastore thread.
> Maybe the gitattributes of a file should be part of the per-file
> flags in the index. Thus we could verify if the flags changed and
> if so, adjust the work tree accordig to the new flags. I'm
> lacking a deeper insight into the git internals. Therefore, I
> can't really say if the index is the right place. But it looks
> to me as if changing an attribute should be treated similar to a
> changing sha1, as far as the work tree is concerned.
the problem with this is that each attribute ends up needing it's own
flag, which severely limits extending things (see the discussions on file
permissions for examples). it's also much harder to manipulate them then
in a file.
David Lang
> So, I need some help.
> Steffen
>
> ---
> t/t0020-crlf.sh | 23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 62bc4bb..5d7e033 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
> }
> '
>
> +test_expect_success 'in-tree .gitattributes (5)' '
> +
> + git reset --hard master &&
> + echo >.gitattributes &&
> + git add .gitattributes &&
> + git commit -m "empty .gitattributes" &&
> + rm -rf tmp one dir .gitattributes patch.file three &&
> + git reset --hard master &&
> + git checkout master^ &&
> +
> + if remove_cr one >/dev/null
> + then
> + echo "Eh? one should not have CRLF"
> + false
> + else
> + : happy
> + fi &&
> + remove_cr three >/dev/null || {
> + echo "Eh? three should still have CRLF"
> + false
> + }
> +'
> +
> test_expect_success 'invalid .gitattributes (must not crash)' '
>
> echo "three +crlf" >>.gitattributes &&
>
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Wincent Colaiuta @ 2007-10-21 9:10 UTC (permalink / raw)
To: Steven Walter
Cc: Johannes Schindelin, Ciprian Dorin Craciun, Steffen Prohaska,
Evan Carroll, git
In-Reply-To: <20071021030927.GA19450@dervierte>
El 21/10/2007, a las 5:09, Steven Walter escribió:
> On Sat, Oct 20, 2007 at 10:34:34PM +0100, Johannes Schindelin wrote:
>> I am torn. On one side I like the Wiki approach. On the other
>> hand, the
>> Wiki will get less review by git oldtimers, whereas the patches to
>> user-manual are usually reviewed as thoroughly as the code patches.
>
> No offense, but review by old timers can be both a blessing and a
> curse.
> Well, it's not the "review" that is so much a problem as the
> "editorial
> control." In my opinion (and I believe this is what the original
> poster
> was saying), the official Git User Manual focuses more on technical
> issues and less on introducing git to a new user.
But it's not an "intro", it's a user manual. That means it's supposed
to be a comprehensive, in-depth treatment of just about everything.
The technical content is a good thing; it's supposed to be the
document you turn to when you want to move beyond superficial use to
genuine, in-depth understanding.
There are other documents with the goal of "introducing git to the
new user", grouped together here:
<http://git.or.cz/course/index.html>
And also under the "Documentation" heading on the Git home page:
<http://git.or.cz/>
Those are probably the articles that should be worked on and
augmented if you care about introducing things to a newbie.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Wincent Colaiuta @ 2007-10-21 8:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021020653.GA14735@spearce.org>
El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>
>>>>> - commented out call to list_common_cmds_help()
>>
>> Well, I'm almost sure of the opposite. One of the big results of
>> the Git
>> Survey was that git is still not user-friendly enough. Your patch
>> would
>> only make this issue worse.
>
> Actually I think Jari's patch helps for the reason originally
> stated in the message (less output when you make a small typo).
> Though I agree that the commented out code should just be removed.
>
> I actually had to do `git config alias.upsh push` just to keep
> myself from screaming every time I made a small typo and Git gave
> me a screenful of "helpful reminders".
If you want to go really user friendly, how about a check against the
list of known commands using a shortest-edit distance algorithm?
Unknown command: 'upsh': did you mean 'push'?
Type 'git help' for usage.
Here's just one of many articles introducing the shortest-edit idea,
as popularized by Google:
<http://norvig.com/spell-correct.html>
What do you think?
Cheers,
Wincent
^ permalink raw reply
* .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 8:48 UTC (permalink / raw)
Cc: git, Steffen Prohaska
If a .gitattributes is in the work tree and we checkout a
different head, the .gitattributes of the head we are switching
to must have precedence. Files are expected to be converted as
configured in the .gitattributes that is available in the head
we're switching to.
This adds a test case revealing deficiencies of the current
handling of .gitattributes.
At a first glance, I saw two possible resolutions:
1) .gitattributes from the index has precedence. It's unclear
how merging can be handled appropriately.
2) .gitattributes are handled as a special file. Checkout is a
two pass process. In the first pass only the special file
.gitattributes is checked out. In th second pass the remaining
files are added. Maybe this gives a perspective how to handle
merges.
But actually the issue is much harder to solve.
Here is what needs to be done: Whenever the attributes of a file
change the file must be freshly checked out according to the
attributes of the head we switch to. The file itself does not
necessarily change between the two commits. A fresh checkout is
already needed if only .gitattributes change.
But this is really hard to solve. We would need to compare
attributes before and after for _all_ files that have attributes
in one of the two commits and check if they changed. If so, we
need to do a fresh checkout according to the new attributes.
Maybe the gitattributes of a file should be part of the per-file
flags in the index. Thus we could verify if the flags changed and
if so, adjust the work tree accordig to the new flags. I'm
lacking a deeper insight into the git internals. Therefore, I
can't really say if the index is the right place. But it looks
to me as if changing an attribute should be treated similar to a
changing sha1, as far as the work tree is concerned.
So, I need some help.
Steffen
---
t/t0020-crlf.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 62bc4bb..5d7e033 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
}
'
+test_expect_success 'in-tree .gitattributes (5)' '
+
+ git reset --hard master &&
+ echo >.gitattributes &&
+ git add .gitattributes &&
+ git commit -m "empty .gitattributes" &&
+ rm -rf tmp one dir .gitattributes patch.file three &&
+ git reset --hard master &&
+ git checkout master^ &&
+
+ if remove_cr one >/dev/null
+ then
+ echo "Eh? one should not have CRLF"
+ false
+ else
+ : happy
+ fi &&
+ remove_cr three >/dev/null || {
+ echo "Eh? three should still have CRLF"
+ false
+ }
+'
+
test_expect_success 'invalid .gitattributes (must not crash)' '
echo "three +crlf" >>.gitattributes &&
--
1.5.3.mingw.1.138.g7bf9d
^ permalink raw reply related
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-21 7:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710210031130.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 21 Oct 2007, Jakub Narebski wrote:
>
>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>>> Maybe we could group commands into more categories?
>>>
>>> plumbing: should be hidden from the 'normal' user. Porcelain
>>> should be sufficient for every standard task.
>> The problem is division between what is porcelain and what is plumbing.
>> Some commands are right on border (git-fsck, git-update-index,
>> git-rev-parse comes to mind).
>
> Sorry, but my impression from the latest mails was that the commands are
> fine. What is lacking is a nice, _small_ collection of recommended
> workflows. And when we have agreed on such a set of workflows, we
> optimize the hell out of them. Only this time it is not performance, but
> user-friendliness.
>
http://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a
good starting point, I think.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-21 7:15 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <C65193EE-A45D-49ED-8831-1A006421A915@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 21, 2007, at 8:52 AM, Shawn O. Pearce wrote:
> >
> >I think that if you set LANG=en before you start git-gui it will
> >take on English, and so will all of the standard dialogs that we
> >"borrow" from wish.
>
> Do we have a chance before we source the real git-gui.tcl?
> Maybe we could "set env(LANG)" based on "git config gui.lang"?
> Or is it already too late because we needed to restart wish?
Hmm. Really quick testing here shows that we just need to make sure
env(LANG) is set before we do the msgcat::mcload call in git-gui.sh
line 104.
If we're going to use a `git config gui.lang` thing then we can
probably just make a msgcat::mclocale call on line 103 just before we
load our message file. Unfortunately this is before we have located
git so technically git-gui doesn't know how to run git-config and
thus cannot get to gui.lang. :-|
Hmm. Looking at this further we may be able to insert the mclocale
call at two locations; one at line 864 before we open the repository
wizard, and again at line 1802, just before we start to initialize
our UI. This does mean that for really serious errors (e.g. "No
git in PATH") we'll be using your native OS language.
--
Shawn.
^ 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