Re: [PATCH v3] gitk: Synchronize highlighting in file view when scrolling diff
On Wed, Sep 19, 2012 at 08:17:27PM +0200, Stefan Haller wrote: Here's one way how to address your concern. When pressing the search button it will highlight the file that contains the current search hit; if you then scroll from there though, the normal mechanism kicks in again and might highlight the previous file. The same happens now if you select the last file in the list, but it's diff is smaller than a screenful. In the previous patch versions it would select a different file than you clicked on, which is probably also confusing. Is this what you had in mind? Yes, it is, and I applied your patch. I wonder though if it might work better to highlight all the files that are visible? Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] gitk: Better highlighting of search results
On Sat, Sep 22, 2012 at 09:40:23AM +0200, Stefan Haller wrote: Here's something that has been bugging me for a long time: when using the incremental search feature, it's hard to tell what happens when clicking the Search button (or type Ctrl-S) repeatedly. It does have the concept of a current search hit, and Ctrl-S advances to the next one; however, you can't see it because all search hits are highlighted in the same way (yellow). So when there are multiple hits visible on the current page, it will at some point scroll down to reveal more hits, but it's impossible to predict when this will happen. To improve this, we highlight the current search in orange and the other ones in yellow (like Chrome does it when you search on a Web page). Nice, thanks - applied. Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: Work around empty back and forward images when buttons are disabled
On Sat, Sep 22, 2012 at 09:46:48AM +0200, Stefan Haller wrote: On Mac, the back and forward buttons show an empty rectange instead of a grayed-out arrow when they are disabled. The reason is a Tk bug on Mac that causes disabled images not to draw correctly (not to draw at all, that is); see https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.tcl/V-nW1JBq0eU. To work around this, we explicitly provide gray images for the disabled state; I think this looks better than the default stipple effect that you get on Windows as well, but that may be a matter of taste. Signed-off-by: Stefan Haller ste...@haller-berlin.de Thanks, applied. Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] commit: configure submodules
As reported on the mailing list[1], ignore submodule config is not respected on commit. [1] http://git.661346.n2.nabble.com/submodule-ignore-is-not-respected-on-commit-td7539238.html Signed-off-by: Orgad Shaneh org...@gmail.com --- builtin/commit.c |1 + 1 file changed, 1 insertion(+) diff --git a/builtin/commit.c b/builtin/commit.c index 62028e7..7a83cae 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1452,6 +1452,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix) usage_with_options(builtin_commit_usage, builtin_commit_options); wt_status_prepare(s); + gitmodules_config(); git_config(git_commit_config, s); determine_whence(s); s.colopts = 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/2] pretty: support right alignment
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: ... On the other hand, I don't really wish to turn pretty format machinery into a full feature text layout engine (by ripping of links/lynx?). That is very true. We should restrain ourselves and avoid going overboard piling shiny new toys on a not-so-useful foundation that is not expressive enough. One feature that is probably much more needed on the foundation side would be some form of conditional output, without which built-in output elements like --show-notes cannot be emulated with --format option. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: configure submodules
Orgad Shaneh org...@gmail.com writes: As reported on the mailing list[1], ignore submodule config is not respected on commit. [1] http://git.661346.n2.nabble.com/submodule-ignore-is-not-respected-on-commit-td7539238.html Signed-off-by: Orgad Shaneh org...@gmail.com --- Thanks. Please do not force people to go to external website like that while reading the git log output. You could have just said git status does not list a submodule with uncommitted working tree files as modified when submodule.$name.ignore configuration is set to dirty, but git commit forgets to take this configuration variable into account. or something. It would also be good to say I reported it earlier in this message with the URL _after_ the three-dash line. I see Jens added with 302ad7a (Submodules: Use ignore settings from .gitmodules too for diff and status, 2010-08-06) the call to gitmodules_config() to git status and git diff family, but I suspect that was a huge mistake. Once a submodule is initialized with submodule init, the default set of configuration should be copied to the user's $GIT_DIR/config and subsequent run-time invocation should read $GIT_DIR/config and $GIT_DIR/config alone, to honor user's customization. Instead, I think git_commit_config() and git_status_config() should call submodule_config() function to read submodule.$name.ignore not from .gitmodules file but from $GIT_DIR/config. Jens, what do you think? I see no reason for anybody other than submodule init to call gitmodules_config() that reads from the in-tree .gitmodules file. builtin/commit.c |1 + 1 file changed, 1 insertion(+) diff --git a/builtin/commit.c b/builtin/commit.c index 62028e7..7a83cae 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1452,6 +1452,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix) usage_with_options(builtin_commit_usage, builtin_commit_options); wt_status_prepare(s); + gitmodules_config(); git_config(git_commit_config, s); determine_whence(s); s.colopts = 0; -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] Advanced --oneline layout
The series is now feature complete from my usage pov. The syntax may change though. No tests yet until we agree on the syntax and semantics. Summary: - %C(auto) turns on coloring for the next placeholder - %C(auto,N) the same on the next N placeholders - %(W) makes sure the next placeholder takes W columns, left aligned - %(W) like % but right aligned - %(W) like % but centered - %|(W), %|(W), %|(W) are similar, except that W is calculated to reach the Nth column on screen. (We might want %| instead of %|) - %(W) like %(W) but it will try to steal trailing spaces if the placeholder uses more than W columns. Very useful in %% combination where the last placeholder may leave a lot of spaces unused - All the above may take trunc, ltrunc, mtrunc optios in the bracket to truncate the result string if exceeds the given width. It truncates on the right, left and middle respectively. - No support for $COLUMNS. If you want to fit your screen, bash's $(()) syntax is your friend to calculate columns. - We might want to support %direction(W,N), e.g. %(40,3), where the next N placeholders are grouped and aligned together as a single placeholder. Show off time: 6ab07c4 pretty: support % that steal trailing spaces (HEAD, lanh/prettier) Nguyễn..gọc Duy ee1c10e pretty: support truncating in %, % and % Nguyễn..gọc Duy 77aefae pretty: support padding placeholders, % % and % Nguyễn..gọc Duy 8f81f6b pretty: two phase conversion for non utf-8 commits Nguyễn..gọc Duy c3f1243 utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences Nguyễn..gọc Duy 1a4e9bb utf8.c: move display_mode_esc_sequence_len() for use by other functions Nguyễn..gọc Duy 99aa0c2 pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s) Nguyễn..gọc Duy 1feaab6 pretty: split parsing %C into a separate function Nguyễn..gọc Duy b2676ac pretty: share code between format_decoration and show_decorations Nguyễn..gọc Duy 6bdccbe graph: avoid infinite loop in graph_show_commit() Nguyễn..gọc Duy 16eed7c Merge branch 'mh/fetch-filter-refs' (origin/master) Junio C Hamano Produced with %C(auto,99)%h %|(80,trunc)%s%|(80)%d%(15,mtrunc)% an Nguyễn Thái Ngọc Duy (9): pretty: share code between format_decoration and show_decorations pretty: split parsing %C into a separate function pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s) utf8.c: move display_mode_esc_sequence_len() for use by other functions utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences pretty: two phase conversion for non utf-8 commits pretty: support padding placeholders, % % and % pretty: support truncating in %, % and % pretty: support % that steal trailing spaces Documentation/pretty-formats.txt | 7 + log-tree.c | 60 --- log-tree.h | 3 + pretty.c | 327 --- t/t4207-log-decoration-colors.sh | 8 +- t/t6006-rev-list-format.sh | 16 +- t/t6006/commit-msg.iso8859-1 | 5 + utf8.c | 94 --- utf8.h | 4 + 9 files changed, 412 insertions(+), 112 deletions(-) create mode 100644 t/t6006/commit-msg.iso8859-1 -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] pretty: share code between format_decoration and show_decorations
This also adds color support to format_decoration()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
log-tree.c | 60 +---
log-tree.h | 3 ++
pretty.c | 19 +
t/t4207-log-decoration-colors.sh | 8 +++---
4 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index c894930..528cab0 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -174,36 +174,50 @@ static void show_children(struct rev_info *opt, struct
commit *commit, int abbre
}
}
-void show_decorations(struct rev_info *opt, struct commit *commit)
+void format_decoration(struct strbuf *sb,
+ const struct commit *commit,
+ int use_color)
{
- const char *prefix;
- struct name_decoration *decoration;
+ const char *prefix = (;
+ struct name_decoration *d;
const char *color_commit =
- diff_get_color_opt(opt-diffopt, DIFF_COMMIT);
+ diff_get_color(use_color, DIFF_COMMIT);
const char *color_reset =
- decorate_get_color_opt(opt-diffopt, DECORATION_NONE);
+ decorate_get_color(use_color, DECORATION_NONE);
+
+ load_ref_decorations(DECORATE_SHORT_REFS);
+ d = lookup_decoration(name_decoration, commit-object);
+ if (!d)
+ return;
+ while (d) {
+ strbuf_addstr(sb, color_commit);
+ strbuf_addstr(sb, prefix);
+ strbuf_addstr(sb, decorate_get_color(use_color, d-type));
+ if (d-type == DECORATION_REF_TAG)
+ strbuf_addstr(sb, tag: );
+ strbuf_addstr(sb, d-name);
+ strbuf_addstr(sb, color_reset);
+ prefix = , ;
+ d = d-next;
+ }
+ if (prefix[0] == ',') {
+ strbuf_addstr(sb, color_commit);
+ strbuf_addch(sb, ')');
+ strbuf_addstr(sb, color_reset);
+ }
+}
+
+void show_decorations(struct rev_info *opt, struct commit *commit)
+{
+ struct strbuf sb = STRBUF_INIT;
if (opt-show_source commit-util)
printf(\t%s, (char *) commit-util);
if (!opt-show_decorations)
return;
- decoration = lookup_decoration(name_decoration, commit-object);
- if (!decoration)
- return;
- prefix = (;
- while (decoration) {
- printf(%s, prefix);
- fputs(decorate_get_color_opt(opt-diffopt, decoration-type),
- stdout);
- if (decoration-type == DECORATION_REF_TAG)
- fputs(tag: , stdout);
- printf(%s, decoration-name);
- fputs(color_reset, stdout);
- fputs(color_commit, stdout);
- prefix = , ;
- decoration = decoration-next;
- }
- putchar(')');
+ format_decoration(sb, commit, opt-diffopt.use_color);
+ fputs(sb.buf, stdout);
+ strbuf_release(sb);
}
/*
@@ -616,8 +630,8 @@ void show_log(struct rev_info *opt)
printf( (from %s),
find_unique_abbrev(parent-object.sha1,
abbrev_commit));
+ fputs(diff_get_color_opt(opt-diffopt, DIFF_RESET), stdout);
show_decorations(opt, commit);
- printf(%s, diff_get_color_opt(opt-diffopt, DIFF_RESET));
if (opt-commit_format == CMIT_FMT_ONELINE) {
putchar(' ');
} else {
diff --git a/log-tree.h b/log-tree.h
index f5ac238..10c2682 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -13,6 +13,9 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt);
+void format_decoration(struct strbuf *sb,
+ const struct commit *commit,
+ int use_color);
void show_decorations(struct rev_info *opt, struct commit *commit);
void log_write_email_headers(struct rev_info *opt, struct commit *commit,
const char **subject_p,
diff --git a/pretty.c b/pretty.c
index 8b1ea9f..e910679 100644
--- a/pretty.c
+++ b/pretty.c
@@ -764,23 +764,6 @@ static void parse_commit_message(struct
format_commit_context *c)
c-commit_message_parsed = 1;
}
-static void format_decoration(struct strbuf *sb, const struct commit *commit)
-{
- struct name_decoration *d;
- const char *prefix = (;
-
- load_ref_decorations(DECORATE_SHORT_REFS);
- d = lookup_decoration(name_decoration, commit-object);
- while (d) {
- strbuf_addstr(sb, prefix);
- prefix = , ;
- strbuf_addstr(sb, d-name);
- d = d-next;
- }
- if
[PATCH 2/9] pretty: split parsing %C into a separate function
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
pretty.c | 60 +++-
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/pretty.c b/pretty.c
index e910679..93c96c2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -863,6 +863,40 @@ static int format_reflog_person(struct strbuf *sb,
return format_person_part(sb, part, ident, strlen(ident), dmode);
}
+static size_t parse_color_placeholder(struct strbuf *sb,
+ const char *placeholder,
+ struct format_commit_context *c)
+{
+ if (placeholder[1] == '(') {
+ const char *end = strchr(placeholder + 2, ')');
+ char color[COLOR_MAXLEN];
+ if (!end)
+ return 0;
+ color_parse_mem(placeholder + 2,
+ end - (placeholder + 2),
+ --pretty format, color);
+ strbuf_addstr(sb, color);
+ return end - placeholder + 1;
+ }
+ if (!prefixcmp(placeholder + 1, red)) {
+ strbuf_addstr(sb, GIT_COLOR_RED);
+ return 4;
+ }
+ if (!prefixcmp(placeholder + 1, green)) {
+ strbuf_addstr(sb, GIT_COLOR_GREEN);
+ return 6;
+ }
+ if (!prefixcmp(placeholder + 1, blue)) {
+ strbuf_addstr(sb, GIT_COLOR_BLUE);
+ return 5;
+ }
+ if (!prefixcmp(placeholder + 1, reset)) {
+ strbuf_addstr(sb, GIT_COLOR_RESET);
+ return 6;
+ }
+ return 0;
+}
+
static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -875,31 +909,7 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
/* these are independent of the commit */
switch (placeholder[0]) {
case 'C':
- if (placeholder[1] == '(') {
- const char *end = strchr(placeholder + 2, ')');
- char color[COLOR_MAXLEN];
- if (!end)
- return 0;
- color_parse_mem(placeholder + 2,
- end - (placeholder + 2),
- --pretty format, color);
- strbuf_addstr(sb, color);
- return end - placeholder + 1;
- }
- if (!prefixcmp(placeholder + 1, red)) {
- strbuf_addstr(sb, GIT_COLOR_RED);
- return 4;
- } else if (!prefixcmp(placeholder + 1, green)) {
- strbuf_addstr(sb, GIT_COLOR_GREEN);
- return 6;
- } else if (!prefixcmp(placeholder + 1, blue)) {
- strbuf_addstr(sb, GIT_COLOR_BLUE);
- return 5;
- } else if (!prefixcmp(placeholder + 1, reset)) {
- strbuf_addstr(sb, GIT_COLOR_RESET);
- return 6;
- } else
- return 0;
+ return parse_color_placeholder(sb, placeholder, c);
case 'n': /* newline */
strbuf_addch(sb, '\n');
return 1;
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/pretty-formats.txt | 1 +
pretty.c | 28 +++-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index d9edded..c706556 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -145,6 +145,7 @@ The placeholders are:
- '%Cblue': switch color to blue
- '%Creset': reset color
- '%C(...)': color specification, as described in color.branch.* config option
+- '%C(auto[,N])': turn on coloring on the next placeholder (or the next N
placeholders) if supported
- '%m': left, right or boundary mark
- '%n': newline
- '%%': a raw '%'
diff --git a/pretty.c b/pretty.c
index 93c96c2..45fe878 100644
--- a/pretty.c
+++ b/pretty.c
@@ -630,6 +630,7 @@ struct format_commit_context {
} signature;
char *message;
size_t width, indent1, indent2;
+ unsigned use_color;
/* These offsets are relative to the start of the commit message. */
struct chunk author;
@@ -872,6 +873,24 @@ static size_t parse_color_placeholder(struct strbuf *sb,
char color[COLOR_MAXLEN];
if (!end)
return 0;
+ if (!prefixcmp(placeholder + 1, (auto)) {
+ /*
+* use_color decreased after every
+* format_commit_one() so we lose one right
+* after parsing %C. Which is why we add an
+* extra one to use_color here.
+*/
+ if (placeholder[6] == ',') {
+ char *next;
+ int v = strtoul(placeholder + 7, next, 10);
+ if (next == end)
+ c-use_color = v + 1;
+ else
+ return 0;
+ } else
+ c-use_color = 2;
+ return end - placeholder + 1;
+ }
color_parse_mem(placeholder + 2,
end - (placeholder + 2),
--pretty format, color);
@@ -955,13 +974,17 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
switch (placeholder[0]) {
case 'H': /* commit hash */
+ strbuf_addstr(sb, diff_get_color(c-use_color, DIFF_COMMIT));
strbuf_addstr(sb, sha1_to_hex(commit-object.sha1));
+ strbuf_addstr(sb, diff_get_color(c-use_color, DIFF_RESET));
return 1;
case 'h': /* abbreviated commit hash */
+ strbuf_addstr(sb, diff_get_color(c-use_color, DIFF_COMMIT));
if (add_again(sb, c-abbrev_commit_hash))
return 1;
strbuf_addstr(sb, find_unique_abbrev(commit-object.sha1,
c-pretty_ctx-abbrev));
+ strbuf_addstr(sb, diff_get_color(c-use_color, DIFF_RESET));
c-abbrev_commit_hash.len = sb-len - c-abbrev_commit_hash.off;
return 1;
case 'T': /* tree hash */
@@ -998,7 +1021,7 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
strbuf_addstr(sb, get_revision_mark(NULL, commit));
return 1;
case 'd':
- format_decoration(sb, commit, 0);
+ format_decoration(sb, commit, c-use_color);
return 1;
case 'g': /* reflog info */
switch(placeholder[1]) {
@@ -1101,6 +1124,7 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
+ struct format_commit_context *c = context;
int consumed;
size_t orig_len;
enum {
@@ -1128,6 +1152,8 @@ static size_t format_commit_item(struct strbuf *sb, const
char *placeholder,
orig_len = sb-len;
consumed = format_commit_one(sb, placeholder, context);
+ if (c-use_color)
+ c-use_color--;
if (magic == NO_MAGIC)
return consumed;
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] utf8.c: move display_mode_esc_sequence_len() for use by other functions
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
utf8.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/utf8.c b/utf8.c
index a544f15..18a4d9c 100644
--- a/utf8.c
+++ b/utf8.c
@@ -9,6 +9,20 @@ struct interval {
int last;
};
+static size_t display_mode_esc_sequence_len(const char *s)
+{
+ const char *p = s;
+ if (*p++ != '\033')
+ return 0;
+ if (*p++ != '[')
+ return 0;
+ while (isdigit(*p) || *p == ';')
+ p++;
+ if (*p++ != 'm')
+ return 0;
+ return p - s;
+}
+
/* auxiliary function for binary search in interval table */
static int bisearch(ucs_char_t ucs, const struct interval *table, int max)
{
@@ -303,20 +317,6 @@ static void strbuf_add_indented_text(struct strbuf *buf,
const char *text,
}
}
-static size_t display_mode_esc_sequence_len(const char *s)
-{
- const char *p = s;
- if (*p++ != '\033')
- return 0;
- if (*p++ != '[')
- return 0;
- while (isdigit(*p) || *p == ';')
- p++;
- if (*p++ != 'm')
- return 0;
- return p - s;
-}
-
/*
* Wrap the text, if necessary. The variable indent is the indent for the
* first line, indent2 is the indent for all other lines.
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
utf8.c | 20 ++--
utf8.h | 1 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/utf8.c b/utf8.c
index 18a4d9c..791499e 100644
--- a/utf8.c
+++ b/utf8.c
@@ -266,18 +266,26 @@ int utf8_width(const char **start, size_t *remainder_p)
* string, assuming that the string is utf8. Returns strlen() instead
* if the string does not look like a valid utf8 string.
*/
-int utf8_strwidth(const char *string)
+int utf8_strnwidth(const char *string, int len, int skip_ansi)
{
int width = 0;
const char *orig = string;
- while (1) {
- if (!string)
- return strlen(orig);
- if (!*string)
- return width;
+ if (len == -1)
+ len = strlen(string);
+ while (string string orig + len) {
+ int skip;
+ while (skip_ansi
+ (skip = display_mode_esc_sequence_len(string)))
+ string += skip;
width += utf8_width(string, NULL);
}
+ return string ? width : len;
+}
+
+int utf8_strwidth(const char *string)
+{
+ return utf8_strnwidth(string, -1, 0);
}
int is_utf8(const char *text)
diff --git a/utf8.h b/utf8.h
index 3c0ae76..58d5b6b 100644
--- a/utf8.h
+++ b/utf8.h
@@ -4,6 +4,7 @@
typedef unsigned int ucs_char_t; /* assuming 32bit int */
int utf8_width(const char **start, size_t *remainder_p);
+int utf8_strnwidth(const char *string, int len, int skip_ansi);
int utf8_strwidth(const char *string);
int is_utf8(const char *text);
int is_encoding_utf8(const char *name);
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] pretty: two phase conversion for non utf-8 commits
Always assume format_commit_item() takes an utf-8 string for
simplicity. If commit message is in non-utf8, or output encoding is
not, then the commit is first converted to utf-8, processed, then
output converted to output encoding.
This of course only works with encodings that are compatible with
Unicode.
This also fixes the iso8859-1 test. It's supposed to create an
iso8859-1 commit, but the commit content in t6006-rev-list-format.sh
is in UTF-8. Split the content out in a separate file (so its encoding
won't accidentally be converted) and convert it back to iso8859-1.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
pretty.c | 29 +++--
t/t6006-rev-list-format.sh | 16 +---
t/t6006/commit-msg.iso8859-1 | 5 +
3 files changed, 29 insertions(+), 21 deletions(-)
create mode 100644 t/t6006/commit-msg.iso8859-1
diff --git a/pretty.c b/pretty.c
index 45fe878..f3275a7 100644
--- a/pretty.c
+++ b/pretty.c
@@ -916,7 +916,8 @@ static size_t parse_color_placeholder(struct strbuf *sb,
return 0;
}
-static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
+static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
+ const char *placeholder,
void *context)
{
struct format_commit_context *c = context;
@@ -1121,7 +1122,8 @@ static size_t format_commit_one(struct strbuf *sb, const
char *placeholder,
return 0; /* unknown placeholder */
}
-static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
+static size_t format_commit_item(struct strbuf *sb, /* in UTF-8 */
+const char *placeholder,
void *context)
{
struct format_commit_context *c = context;
@@ -1205,25 +1207,32 @@ void format_commit_message(const struct commit *commit,
struct format_commit_context context;
static const char utf8[] = UTF-8;
const char *output_enc = pretty_ctx-output_encoding;
+ char *enc;
memset(context, 0, sizeof(context));
context.commit = commit;
context.pretty_ctx = pretty_ctx;
context.wrap_start = sb-len;
context.message = commit-buffer;
- if (output_enc) {
- char *enc = get_header(commit, encoding);
- if (strcmp(enc ? enc : utf8, output_enc)) {
- context.message = logmsg_reencode(commit, output_enc);
- if (!context.message)
- context.message = commit-buffer;
- }
- free(enc);
+ enc = get_header(commit, encoding);
+ if (enc strcmp(utf8, enc)) {
+ context.message = reencode_string(context.message, utf8, enc);
+ if (!context.message)
+ context.message = commit-buffer;
}
+ free(enc);
strbuf_expand(sb, format, format_commit_item, context);
rewrap_message_tail(sb, context, 0, 0, 0);
+ if (output_enc strcmp(utf8, output_enc)) {
+ char *out = reencode_string(sb-buf, output_enc, utf8);
+ if (out) {
+ int len = strlen(out);
+ strbuf_attach(sb, out, len, len + 1);
+ }
+ }
+
if (context.message != commit-buffer)
free(context.message);
free(context.signature.gpg_output);
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index f94f0c4..cd24839 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -124,27 +124,21 @@ commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
[1;31;43mfoo[m
EOF
-cat commit-msg 'EOF'
-Test printing of complex bodies
-
-This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
-EOF
+cat $TEST_DIRECTORY/t6006/commit-msg.iso8859-1 commit-msg
test_expect_success 'setup complex body' '
git config i18n.commitencoding iso8859-1
echo change2 foo git commit -a -F commit-msg
'
test_format complex-encoding %e 'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+commit 1ed88da4a5b5ed8c449114ac131efc62178734c3
iso8859-1
commit 131a310eb913d107dd3c09a65d1651175898735d
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
EOF
test_format complex-subject %s 'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+commit 1ed88da4a5b5ed8c449114ac131efc62178734c3
Test printing of complex bodies
commit 131a310eb913d107dd3c09a65d1651175898735d
changed foo
@@ -153,7 +147,7 @@ added foo
EOF
test_format complex-body %b 'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+commit 1ed88da4a5b5ed8c449114ac131efc62178734c3
This commit message is much longer than the others,
and it will be encoded in iso8859-1. We should therefore
include an iso8859 character: ¡bueno!
@@ -163,7 +157,7 @@
[PATCH 7/9] pretty: support padding placeholders, % % and %
Either %, % or % standing before a placeholder specifies how many
columns (at least as the placeholder can exceed it) it takes. Each
differs on how spaces are padded:
% pads on the right (aka left alignment)
% pads on the left (aka right alignment)
% pads both ways equally (aka centered)
The (N) follows them, e.g. `%(100)', to specify the number of
columns the next placeholder takes.
However, if '|' stands before (N), e.g. `%|(100)', then the number
of columns is calculated so that it reaches the Nth column on screen.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/pretty-formats.txt | 4 ++
pretty.c | 113 ++-
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index c706556..49d29ab 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -152,6 +152,10 @@ The placeholders are:
- '%x00': print a byte from a hex code
- '%w([w[,i1[,i2]]])': switch line wrapping, like the -w option of
linkgit:git-shortlog[1].
+- '%(N)': make the next placeholder take at least N columns, padding spaces
on the right if necessary
+- '%|(N)': make the next placeholder take at least until Nth columns,
padding spaces on the right if necessary
+- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding spaces on the left
+- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding both sides (i.e. the text is centered)
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index f3275a7..d169673 100644
--- a/pretty.c
+++ b/pretty.c
@@ -617,12 +617,20 @@ struct chunk {
size_t len;
};
+enum flush_type {
+ no_flush,
+ flush_right,
+ flush_left,
+ flush_both
+};
+
struct format_commit_context {
const struct commit *commit;
const struct pretty_print_context *pretty_ctx;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
unsigned commit_signature_parsed:1;
+ enum flush_type flush_type;
struct {
char *gpg_output;
char good_bad;
@@ -631,6 +639,7 @@ struct format_commit_context {
char *message;
size_t width, indent1, indent2;
unsigned use_color;
+ int padding;
/* These offsets are relative to the start of the commit message. */
struct chunk author;
@@ -916,6 +925,52 @@ static size_t parse_color_placeholder(struct strbuf *sb,
return 0;
}
+static size_t parse_padding_placeholder(struct strbuf *sb,
+ const char *placeholder,
+ struct format_commit_context *c)
+{
+ const char *ch = placeholder;
+ enum flush_type flush_type;
+ int to_column = 0;
+
+ switch (*ch++) {
+ case '':
+ flush_type = flush_right;
+ break;
+ case '':
+ if (*ch == '') {
+ flush_type = flush_both;
+ ch++;
+ } else
+ flush_type = flush_left;
+ break;
+ default:
+ return 0;
+ }
+
+ /* the next value means wide enough to that column */
+ if (*ch == '|') {
+ to_column = 1;
+ ch++;
+ }
+
+ if (*ch == '(') {
+ const char *start = ch + 1;
+ const char *end = strchr(start, ')');
+ char *next;
+ int width;
+ if (!end || end == start)
+ return 0;
+ width = strtoul(start, next, 10);
+ if (next == start || width == 0)
+ return 0;
+ c-padding = to_column ? -width : width;
+ c-flush_type = flush_type;
+ return end - placeholder + 1;
+ }
+ return 0;
+}
+
static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
const char *placeholder,
void *context)
@@ -967,6 +1022,10 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
return end - placeholder + 1;
} else
return 0;
+
+ case '':
+ case '':
+ return parse_padding_placeholder(sb, placeholder, c);
}
/* these depend on the commit */
@@ -1122,6 +1181,55 @@ static size_t format_commit_one(struct strbuf *sb, /* in
UTF-8 */
return 0; /* unknown placeholder */
}
+static size_t format_and_pad_commit(struct strbuf *sb, /* in UTF-8 */
+ const char *placeholder,
+ struct format_commit_context *c)
+{
+
[PATCH 8/9] pretty: support truncating in %, % and %
%(N,trunc) truncates the righ part after N columns and replace the
last two letters with ... ltrunc does the same on the left. mtrunc
cuts the middle out.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/pretty-formats.txt | 2 +-
pretty.c | 51 +---
utf8.c | 46
utf8.h | 2 ++
4 files changed, 97 insertions(+), 4 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 49d29ab..3f056dc 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -152,7 +152,7 @@ The placeholders are:
- '%x00': print a byte from a hex code
- '%w([w[,i1[,i2]]])': switch line wrapping, like the -w option of
linkgit:git-shortlog[1].
-- '%(N)': make the next placeholder take at least N columns, padding spaces
on the right if necessary
+- '%(N[,trunc|ltrunc|mtrunc])': make the next placeholder take at least N
columns, padding spaces on the right if necessary
- '%|(N)': make the next placeholder take at least until Nth columns,
padding spaces on the right if necessary
- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding spaces on the left
- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding both sides (i.e. the text is centered)
diff --git a/pretty.c b/pretty.c
index d169673..673193e 100644
--- a/pretty.c
+++ b/pretty.c
@@ -624,6 +624,13 @@ enum flush_type {
flush_both
};
+enum trunc_type {
+ trunc_none,
+ trunc_left,
+ trunc_middle,
+ trunc_right
+};
+
struct format_commit_context {
const struct commit *commit;
const struct pretty_print_context *pretty_ctx;
@@ -631,6 +638,7 @@ struct format_commit_context {
unsigned commit_message_parsed:1;
unsigned commit_signature_parsed:1;
enum flush_type flush_type;
+ enum trunc_type truncate;
struct {
char *gpg_output;
char good_bad;
@@ -956,7 +964,7 @@ static size_t parse_padding_placeholder(struct strbuf *sb,
if (*ch == '(') {
const char *start = ch + 1;
- const char *end = strchr(start, ')');
+ const char *end = start + strcspn(start, ,));
char *next;
int width;
if (!end || end == start)
@@ -966,6 +974,23 @@ static size_t parse_padding_placeholder(struct strbuf *sb,
return 0;
c-padding = to_column ? -width : width;
c-flush_type = flush_type;
+
+ if (*end == ',') {
+ start = end + 1;
+ end = strchr(start, ')');
+ if (!end || end == start)
+ return 0;
+ if (!prefixcmp(start, trunc)))
+ c-truncate = trunc_right;
+ else if (!prefixcmp(start, ltrunc)))
+ c-truncate = trunc_left;
+ else if (!prefixcmp(start, mtrunc)))
+ c-truncate = trunc_middle;
+ else
+ return 0;
+ } else
+ c-truncate = trunc_none;
+
return end - placeholder + 1;
}
return 0;
@@ -1197,9 +1222,29 @@ static size_t format_and_pad_commit(struct strbuf *sb,
/* in UTF-8 */
}
consumed = format_commit_one(local_sb, placeholder, c);
len = utf8_strnwidth(local_sb.buf, -1, 1);
- if (len padding)
+ if (len padding) {
+ switch (c-truncate) {
+ case trunc_left:
+ strbuf_utf8_replace(local_sb,
+ 0, len - (padding - 2),
+ ..);
+ break;
+ case trunc_middle:
+ strbuf_utf8_replace(local_sb,
+ padding / 2 - 1,
+ len - (padding - 2),
+ ..);
+ break;
+ case trunc_right:
+ strbuf_utf8_replace(local_sb,
+ padding - 2, len - (padding - 2),
+ ..);
+ break;
+ case trunc_none:
+ break;
+ }
strbuf_addstr(sb, local_sb.buf);
- else {
+ } else {
int sb_len = sb-len, offset;
switch (c-flush_type) {
case flush_left:
diff --git a/utf8.c b/utf8.c
index 791499e..095c5ff 100644
--- a/utf8.c
+++ b/utf8.c
@@ -422,6 +422,52 @@ int strbuf_add_wrapped_bytes(struct strbuf *buf, const
[PATCH 9/9] pretty: support % that steal trailing spaces
This is pretty useful in `%(100)%s%Cred%(20)% an' where %s does not
use up all 100 columns and %an needs more than 20 columns. By
replacing %(20) with %(20), %an can steal spaces from %s.
% understands escape sequences, so %Cred does not stop it from
stealing spaces in %(100).
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/pretty-formats.txt | 4 +++-
pretty.c | 35 +++
utf8.c | 2 +-
utf8.h | 1 +
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 3f056dc..e752da0 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -155,7 +155,9 @@ The placeholders are:
- '%(N[,trunc|ltrunc|mtrunc])': make the next placeholder take at least N
columns, padding spaces on the right if necessary
- '%|(N)': make the next placeholder take at least until Nth columns,
padding spaces on the right if necessary
- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding spaces on the left
-- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively, but
padding both sides (i.e. the text is centered)
+- '%(N)', '%|(N)': similar to '%(N)', '%|(N)' respectively,
except that if the next placeholder takes more spaces than given and there are
spaces on its left, use those spaces
+- '%(N)', '%|(N)': similar to '%
+(N)', '%|(N)' respectively, but padding both sides (i.e. the text is
centered)
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/pretty.c b/pretty.c
index 673193e..deeacf2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -621,6 +621,7 @@ enum flush_type {
no_flush,
flush_right,
flush_left,
+ flush_left_and_steal,
flush_both
};
@@ -949,6 +950,9 @@ static size_t parse_padding_placeholder(struct strbuf *sb,
if (*ch == '') {
flush_type = flush_both;
ch++;
+ } else if (*ch == '') {
+ flush_type = flush_left_and_steal;
+ ch++;
} else
flush_type = flush_left;
break;
@@ -1222,6 +1226,36 @@ static size_t format_and_pad_commit(struct strbuf *sb,
/* in UTF-8 */
}
consumed = format_commit_one(local_sb, placeholder, c);
len = utf8_strnwidth(local_sb.buf, -1, 1);
+
+ if (c-flush_type == flush_left_and_steal) {
+ const char *ch = sb-buf + sb-len - 1;
+ while (len padding ch sb-buf) {
+ const char *p;
+ if (*ch == ' ') {
+ ch--;
+ padding++;
+ continue;
+ }
+ /* check for trailing ansi sequences */
+ if (*ch != 'm')
+ break;
+ p = ch - 1;
+ while (ch - p 10 *p != '\033')
+ p--;
+ if (*p != '\033' ||
+ ch + 1 - p != display_mode_esc_sequence_len(p))
+ break;
+ /*
+* got a good ansi sequence, put it back to
+* local_sb as we're cutting sb
+*/
+ strbuf_insert(local_sb, 0, p, ch + 1 - p);
+ ch = p - 1;
+ }
+ strbuf_setlen(sb, ch + 1 - sb-buf);
+ c-flush_type = flush_left;
+ }
+
if (len padding) {
switch (c-truncate) {
case trunc_left:
@@ -1256,6 +1290,7 @@ static size_t format_and_pad_commit(struct strbuf *sb, /*
in UTF-8 */
case flush_both:
offset = (padding - len) / 2;
break;
+ case flush_left_and_steal:
case no_flush: /* to make gcc happy */
break;
}
diff --git a/utf8.c b/utf8.c
index 095c5ff..6af288d 100644
--- a/utf8.c
+++ b/utf8.c
@@ -9,7 +9,7 @@ struct interval {
int last;
};
-static size_t display_mode_esc_sequence_len(const char *s)
+size_t display_mode_esc_sequence_len(const char *s)
{
const char *p = s;
if (*p++ != '\033')
diff --git a/utf8.h b/utf8.h
index 0451a70..758a1ed 100644
--- a/utf8.h
+++ b/utf8.h
@@ -3,6 +3,7 @@
typedef unsigned int ucs_char_t; /* assuming 32bit int */
+size_t display_mode_esc_sequence_len(const char *s);
int utf8_width(const char **start, size_t *remainder_p);
int utf8_strnwidth(const char *string, int len, int skip_ansi);
int utf8_strwidth(const char *string);
--
1.7.12.1.406.g6ab07c4
--
To
Re: [RFC] Questions for Git User's Survey 2011
On Sun, Sep 23, 2012 at 10:09 AM, Junio C Hamano gits...@pobox.com wrote: Jakub Narębski jna...@gmail.com writes: I have created short (well, at least shorter than previous ones) Git User's Survey 2012 on Survs.com. The test channel is https://www.survs.com/survey/J87I3PDBU4 Note that all answers in this channel would be deleted. I was thinking about running this survey for about three weeks, from 24 September to 14 October 2012. The current premium unlimited plan, a gift from Survs.com admins, is valid till 26 October. I don't know if it would be prolonged; it usually was. As to what is involved in running survey: if we want and would be able to use Survs.com, one should register there, and I can add them to git account as a member with admin rights. Thanks for getting the ball rolling again this year. A few comments. #5. Given that 1.8.0 will ship on Oct 21st, this may want to include 1.8.0 as well. Thanks for an information. Done. #7. Stop backup, and leave that to 'other (please specify)'. Also, Frontend to other SCM feels somewhat out of place. It would be interesting to see how work vs personal and native vs foreign are correlated, for example, but this format does not let you measure it. I have split this question in two: #7. What kind of projects etc. do you use Git for? #8. I use Git for (check all that apply): where the first question is about work..private direction, and the second one is now reducted to code, documentation, etc. But now that I think of it, perhaps it might be interesting to put those in the matrix form, where one direction would be work vs personal, other code vs foreign. #12. I am not sure why EGit applies and Eclipse doesn't. Is it like saying vc.el applies but Emacs doesn't (the former is the interface, the latter is 'the other side' the interface connects git to)? If so it makes sense to me, but if EGit is the only interface used to connect to Eclipse, perhaps it does not help people who answer these questions to say this. I have reworked / rewritten the description to this question. What I wanted here is to not add editor/IDE which is used only to edit files and create commit messages via core.editor, but without any Git integration. #13. This list is intelligible, at least to me. git add but not git rm? What is incremental add / commit? git add -p? Is it worth asking about update-index? It may be simpler to condense the questionaire down to the following three questions: - Do you use command line tool to build commit? [Always/Often/Sometimes/Never] - When you do, do you build the next commit incrementally with git add [-p] and run git commit without the -a option? [Always/Often/Sometimes/Never] - What do you use if you do not commit with the command line? GUI? IDE/Editor? FileManager? Web? I have split this question in two: #14. What tool do you use to create new commits? #15. How do you create new commits? The latter is about incremental commits etc. I wonder if it would not make this survey too complicated to add the tool vs how (i.e. rows from 14th rows, columns from 15th rows) to complete 3rd dimension ;-) #21. (nit) Isn't ProGit one of the printed books (or ebooks)? I can add other than above. I think the questions are designed to gauge the individual users (proficiency, background, etc.), but I think it would be interesting to see what kind of projects they are using Git for, but not in vague terms like #7 does. Even within work projects - code, it would be enlightening to see a bit more details, e.g. Are they building phone app? Controlling nuclear reactors? Bioinformatics? This is something hard to ask for... well, we could always use free form question, but then the problem is with analyzing the data, even if we don't get 10k answers like in last year. How big is their team? Do any of you have a proposal for sensible ranges? For example - 1 - a few - several - 10-50 - 50-150 - more than 150 I think multiple choice would fit better here, with troubles analysing and explaining how to format free-form, and people participating in different projects. How is the project structured, e.g. a central repository where everybody pushes into? Workers push to submission branches that are reviewed, approved and merged by the official committers? Use of continuous integration? Issue tracker integration? Hmm... the question about workflows used could be interesting. BTW. I have added to :kinds of tools questions, e.g. about CI, so this topic is more covered... I think. -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to create the [PATCH 0/5] first email?
On Saturday 2012-09-15 19:08, Junio C Hamano wrote: If you plan to use git send-email to send the final results out, you should consider git send-email as your MUA in the quoted paragraph. And that will be very platform independent viewpoint to see things from. git format-patch -o my-series/ --cover-letter ... would treat my-series/ directory as MUA's drafts folder and prepares the messages you would want to send out, and you can proof-read and edit the files in there before telling your MUA to send them out, with git send-email ... my-series/*.patch or something. One can also send [0/n] with a normal MUA, and then use git send-email --in-reply-to 'messageid...@yourhost.no' commitrange It's not like 0/n has to be emitted at the same second 1/n is :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] graph: avoid infinite loop in graph_show_commit()
On Sun, Sep 23, 2012 at 6:55 PM, Michal Kiedrowicz michal.kiedrow...@gmail.com wrote: Nguyễn Thái Ngọc Duy pclouds at gmail.com writes: The loop can be triggered with git diff-tree --graph commit where the commit is a non-merge. It goes like this Isn't this the same issue as in http://article.gmane.org/gmane.comp.version-control.git/123979 ? (with slightly different fix) I don't know. I'm not familiar enough with graph.c to tell. Maybe Adam can have a look? The patch that is cut out is http://article.gmane.org/gmane.comp.version-control.git/206205 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] pretty: two phase conversion for non utf-8 commits
A few nitpicks
- Ursprungligt meddelande -
Always assume format_commit_item() takes an utf-8 string for
simplicity. If commit message is in non-utf8, or output encoding is
not, then the commit is first converted to utf-8, processed, then
output converted to output encoding.
This of course only works with encodings that are compatible with
Unicode.
Such as? Unicode was defined to encompass all knows encodings.
-static size_t format_commit_one(struct strbuf *sb, const char
*placeholder,
+static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
+ const char *placeholder,
void *context)
{
struct format_commit_context *c = context;
Which parameter does the comment apply to? I believe most conventions
nowadays include parameter documentation in the comment preceding
the function header.
[...]
b/t/t6006/commit-msg.iso8859-1
new file mode 100644
index 000..f8fe808
--- /dev/null
+++ b/t/t6006/commit-msg.iso8859-1
@@ -0,0 +1,5 @@
+Test printing of complex bodies
+
+This commit message is much longer than the others,
+and it will be encoded in iso8859-1. We should therefore
+include an iso8859 character: �bueno!
8859-1 to be exact. Only three 8859 encoding has the
character.
-- robin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz sascha...@babbelbox.org wrote: As I know how hard translations can be, esp. with that much technical terms inside, I'm usually expecting _not_ to yield the same result when translating a software's translation back to English. Yeah, I think the goal is not making translations which are looking nearly the same when somebody translates them back to English in the first place. However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, because it's very unusual in German messages of computer programs. Translators should have the freedom to reword terms a bit to make a more optimal translation, but the meaning must not be lost, and I can't say that this is the case. Translate the term in the middle of word-by-word would result in in der Mitte eines, which can be interpreted as a place somewhere or that an action is in progress. To avoid a possible confusion, we decided to translate this term as im Gange sein (be in progress) in the whole translation. I also think that in der Mitte einer Zusammenführung sein doesn't sound really good. It tends to mean a place, not an action. And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to I've been thinking about possible different translations, and the only one I have in mind is wertvoll. But translating valuable as wertvoll (bereits etwas Wertvolles vorhanden) sounds a bit like we've found a treasure, instead of something which has a value in the meaning of content. I think having a translation which is more like useful than valuable does also hit the point of the message, doesn't it? confuse me (even the original text) - and now I feel like I don't understand the meaning of the last sentence at all; neither in English nor in the German translation: After removing the directory with all rebase-information inside it, WHERE should something valuable still be left over? Is it referring to my working tree? Yeah, I think it means the working tree and/or the index which would make sense. Ralf -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Quickly searching for a note
Junio C Hamano venit, vidit, dixit 22.09.2012 22:23: Michael J Gruber g...@drmicha.warpmail.net writes: On my mental scratch pad (yeah, that's where the bald spots are) I have the following more general idea to enhance the revision parser: --limit-run=script:: --run=script::: These options run the script `script` on each revision that is walked. The script is run in an environment which has the variables `GIT_SPECIFIER` exported, where `SPECIFIER` is any of the specifiers for the `--format` option in the long format (the same as for 'git for-each-ref'). In the case of `--limit-run`, the return code of `script` decides whether the commit is processed further (i.e. shown using the format in effect) or ignored. You could argue that the above is not an inpractical solution as long as the user of --run, which spawns a new process every time we need to check if a commit is worth showing in the log/rev-list stream, knows what she is doing and promises not to complain that it is no more performant than an external script that reads from rev-list output and does the equivalent filtering. I personally am not very enthused. If we linked with an embeddable scripting language interpreter (e.g. lua, tcl, guile, ...), it may be a more practical enhancement, though. Yes, the idea is extend, don't embed the other way round, so to say. I still think extending git log so that it can call a script with commit info already in the environment gives a more convenient approach then embedding git rev-list into your own script. It's not more performant, of course. I just see many more requests of the type grep notes coming, i.e. limitting based on other commit info, or in a different way then already possible. Just image you want to find out who's responsible for those commits in git.git with subject lengths 100 ;) The point is also that when you pipe rev-list into your script you have to do all the output formatting yourself, or call git log -1/git show again to have git do the output formatting after your script decided about the limitting. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Sharing my thoughts on this one, … On Sun, Sep 23, 2012 at 5:04 PM, Ralf Thielow ralf.thie...@gmail.com wrote: On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz sascha...@babbelbox.org wrote: However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, because it's very unusual in German messages of computer programs. Translators should have the freedom to reword terms a bit to make a more optimal translation, but the meaning must not be lost, and I can't say that this is the case. Translate the term in the middle of word-by-word would result in in der Mitte eines, which can be interpreted as a place somewhere or that an action is in progress. To avoid a possible confusion, we decided to translate this term as im Gange sein (be in progress) in the whole translation. I also think that in der Mitte einer Zusammenführung sein doesn't sound really good. It tends to mean a place, not an action. What about a simple Eventuell wird bereits ein andere Neuaufbau/rebase ausgeführt? And, iirc, I wonder if translates to Ich frage mich, ob … And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to I've been thinking about possible different translations, and the only one I have in mind is wertvoll. But translating valuable as wertvoll (bereits etwas Wertvolles vorhanden) sounds a bit like we've found a treasure, instead of something which has a value in the meaning of content. I think having a translation which is more like useful than valuable does also hit the point of the message, doesn't it? What about wichtig? I think that transfers the meaning pretty well. Es wird angehalten, um den Verlust wichtiger Infos zu vermeiden maybe? I hope the above spends some inspiration :) Cheers, Daniel -- typed with http://neo-layout.org -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 17:04:15 schrieb Ralf Thielow: On Sat, Sep 22, 2012 at 11:57 PM, Sascha Cunz sascha...@babbelbox.org wrote: As I know how hard translations can be, esp. with that much technical terms inside, I'm usually expecting _not_ to yield the same result when translating a software's translation back to English. Yeah, I think the goal is not making translations which are looking nearly the same when somebody translates them back to English in the first place. Exactly. The meaning is more important then the exact wording. Please consider this: Es wurden Neuaufbau- / Zusammenführungs-Informationen gefunden. Falls ein Neuaufbau bereits im Gange ist, versuche bitte: git rebase (--continue | --abort | --skip) Sollte dies nicht der Fall sein, können die Informationen durch rm -fr $(GIT_DIR)/rebase-merge entfernt werden. Es wird angehalten, falls etwas Schützenswertes gefunden werden sollte. It sounds way cleaner (to me at least) and transports all of the meaning. Esp. for the last sentence, it's very hard to find something in German that doesn't sound 'destructive'. Btw: In the past I've seen quite a few topics on translation on this list - is this at all the right place for that kind of discussion? Sascha However, git-rebase just threw these two sentences at me (And though i know their meaning, i couldn't get the meaning from the message, it gave). Both are in context of starting a rebase while one is already in progress. first is: Original: ... and I wonder if you are in the middle of another rebase. German git translation: ... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist. And a re-translation back to English from my understanding as native German speaker: ... and it would be astonishing (=i'd be surprised), if a rebase was already in progress. We try to avoid translating terms like I wonder if.. and similar as ich wundere mich, because it's very unusual in German messages of computer programs. Translators should have the freedom to reword terms a bit to make a more optimal translation, but the meaning must not be lost, and I can't say that this is the case. Translate the term in the middle of word-by-word would result in in der Mitte eines, which can be interpreted as a place somewhere or that an action is in progress. To avoid a possible confusion, we decided to translate this term as im Gange sein (be in progress) in the whole translation. I also think that in der Mitte einer Zusammenführung sein doesn't sound really good. It tends to mean a place, not an action. And second: Original: I am stopping in case you still have something valuable there. German git translation: Es wird angehalten, falls bereits etwas Nützliches vorhanden ist. I wanted to point out that etwas Nützliches is more something useful that something valuable. But the more I thought about it, the more it started to I've been thinking about possible different translations, and the only one I have in mind is wertvoll. But translating valuable as wertvoll (bereits etwas Wertvolles vorhanden) sounds a bit like we've found a treasure, instead of something which has a value in the meaning of content. I think having a translation which is more like useful than valuable does also hit the point of the message, doesn't it? confuse me (even the original text) - and now I feel like I don't understand the meaning of the last sentence at all; neither in English nor in the German translation: After removing the directory with all rebase-information inside it, WHERE should something valuable still be left over? Is it referring to my working tree? Yeah, I think it means the working tree and/or the index which would make sense. Ralf -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 17:36:08 schrieb knittl: Sharing my thoughts on this one, … [...] What about wichtig? I think that transfers the meaning pretty well. Es wird angehalten, um den Verlust wichtiger Infos zu vermeiden maybe? I hope the above spends some inspiration :) Thanks, Daniel, _this_ translation now let me even understand the English wording: I somehow added an implicit second again in that line, thinking this information is associated with the words and run me again. But what it actually wants to say, is probably: I won't remove the rebase- merge directory on your behalf, because you might have something valuable left over _from a previous rebase / merge run_ Sascha -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone over http with basic auth bug?
On Sat, Sep 22, 2012 at 1:43 PM, Paul J R m...@pjr.cc wrote: It hadnt occured to me that git-http-backend behaves differently to the dumb http protocol on read (though that was from reading the git source so i obviously missed what was going on there). Ultimately im writing a little webapp that wraps around git-http-backend for some git repository management and on reads i've been just acting like webserver but on writes i throw off to git-http-backend. But seeing it do authenticated reads properly via git-http-backend im going to change how it functions, cause that does work with older clients. It works back as far as 1.6.6 as a client. Clients before 1.6.6 can't use git-http-backend. Fortunately 1.6.6 is pretty old, its nearly 3 years ago (Dec 23, 2009). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
On Sun, Sep 23, 2012 at 5:41 PM, Sascha Cunz sascha...@babbelbox.org wrote: Exactly. The meaning is more important then the exact wording. Please consider this: Es wurden Neuaufbau- / Zusammenführungs-Informationen gefunden. We can't change the ... Verzeichnis *rebase-merge* ... part of the message, because rebase-merge is a substitution and we have to use all of them. Falls ein Neuaufbau bereits im Gange ist, versuche bitte: git rebase (--continue | --abort | --skip) Sollte dies nicht der Fall sein, können die Informationen durch rm -fr $(GIT_DIR)/rebase-merge entfernt werden. Es wird angehalten, falls etwas Schützenswertes gefunden werden sollte. It sounds way cleaner (to me at least) and transports all of the meaning. Esp. for the last sentence, it's very hard to find something in German that doesn't sound 'destructive'. Not sure why you change vorhanden ist to gefunden werden sollte. Maybe we should use a combination? See below. Btw: In the past I've seen quite a few topics on translation on this list - is this at all the right place for that kind of discussion? Different translation teams use different places for discussions. The German uses this list. Like this, maybe. [PATCH] l10n: de.po: improve translation of a rebase message The word still was translated as bereits, change it to noch. valuable was translated as nützlich which is more like useful than valuable, change it to schützenswert. Noticed-by: Sascha Cunz sascha...@babbelbox.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com diff --git a/po/de.po b/po/de.po index 2739bc0..7fc0185 100644 --- a/po/de.po +++ b/po/de.po @@ -5756,8 +5756,8 @@ msgstr \t$cmd_live_rebase\n Wenn das nicht der Fall ist, probiere bitte\n \t$cmd_clear_stale_rebase\n -und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n -etwas Nützliches vorhanden ist. +und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n +etwas Schützenswertes vorhanden ist. #: git-rebase.sh:395 #, sh-format -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: submodule: if $command was not matched, don't parse other args
Am 22.09.2012 22:31, schrieb Junio C Hamano: Ramkumar Ramachandra artag...@gmail.com writes: diff --git a/git-submodule.sh b/git-submodule.sh index a7e933e..dfec45d 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1108,7 +1108,15 @@ do done # No command word defaults to status -test -n $command || command=status +if test -z $command +then +if test $# = 0 +then +command=status +else +usage +fi +fi I personally feel no command means this default is a mistake for git submodule, even if there is no pathspec or other arguments, but I am not a heavy user of submodules, so others should discuss this. The commit message of 97a5d8cce9 (git-submodule: re-enable 'status' as the default subcommand) back from 2007 indicates that Lars did back then think that status is a sane default. I agree with Junio that this is not optimal, but I'd rather tend to not change that behavior which has been there from day one for backward compatibility reasons. But if many others see that as an improvement too I won't object against changing it the way Ramkumar proposes (but he'd have to change the documentation too ;-). Since diff and status learned to display submodule status information (except for a submodule being uninitialized) I almost never use this option myself, so I'd be interested to hear what submodule users who do use git submodule [status] frequently think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Message from 'git-rebase'; German translation
Am Sonntag, 23. September 2012, 19:34:23 schrieb Ralf Thielow: On Sun, Sep 23, 2012 at 5:41 PM, Sascha Cunz sascha...@babbelbox.org wrote: Exactly. The meaning is more important then the exact wording. Please consider this: Es wurden Neuaufbau- / Zusammenführungs-Informationen gefunden. We can't change the ... Verzeichnis *rebase-merge* ... part of the message, because rebase-merge is a substitution and we have to use all of them. Falls ein Neuaufbau bereits im Gange ist, versuche bitte: git rebase (--continue | --abort | --skip) Sollte dies nicht der Fall sein, können die Informationen durch rm -fr $(GIT_DIR)/rebase-merge entfernt werden. Es wird angehalten, falls etwas Schützenswertes gefunden werden sollte. It sounds way cleaner (to me at least) and transports all of the meaning. Esp. for the last sentence, it's very hard to find something in German that doesn't sound 'destructive'. Not sure why you change vorhanden ist to gefunden werden sollte. Maybe we should use a combination? See below. Probably a result of my initial misunderstanding of the original text. As I pointed out in another mail on this thread, I think the real meaning is: Es wird [jetzt] angehalten, _weil_ dort [im Rebase-Merge Verzeichnis] noch etwas Schützenswertes vorhanden sein könnte. Btw: In the past I've seen quite a few topics on translation on this list - is this at all the right place for that kind of discussion? Different translation teams use different places for discussions. The German uses this list. Like this, maybe. Yes, that is already much better. [PATCH] l10n: de.po: improve translation of a rebase message The word still was translated as bereits, change it to noch. valuable was translated as nützlich which is more like useful than valuable, change it to schützenswert. Noticed-by: Sascha Cunz sascha...@babbelbox.org Signed-off-by: Ralf Thielow ralf.thie...@gmail.com diff --git a/po/de.po b/po/de.po index 2739bc0..7fc0185 100644 --- a/po/de.po +++ b/po/de.po @@ -5756,8 +5756,8 @@ msgstr \t$cmd_live_rebase\n Wenn das nicht der Fall ist, probiere bitte\n \t$cmd_clear_stale_rebase\n -und führe dieses Kommando nochmal aus. Es wird angehalten, falls bereits\n -etwas Nützliches vorhanden ist. +und führe dieses Kommando nochmal aus. Es wird angehalten, falls noch\n +etwas Schützenswertes vorhanden ist. #: git-rebase.sh:395 #, sh-format -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: configure submodules
Am 23.09.2012 10:37, schrieb Junio C Hamano: I see Jens added with 302ad7a (Submodules: Use ignore settings from .gitmodules too for diff and status, 2010-08-06) the call to gitmodules_config() to git status and git diff family, but I suspect that was a huge mistake. Once a submodule is initialized with submodule init, the default set of configuration should be copied to the user's $GIT_DIR/config and subsequent run-time invocation should read $GIT_DIR/config and $GIT_DIR/config alone, to honor user's customization. Not honoring the user's customization would be a big mistake, but this is not what happens here. A setting in $GIT_DIR/config always overrides the one in .gitmodules (that's why gitmodules_config() is called before git_config()). Instead, I think git_commit_config() and git_status_config() should call submodule_config() function to read submodule.$name.ignore not from .gitmodules file but from $GIT_DIR/config. Jens, what do you think? I see no reason for anybody other than submodule init to call gitmodules_config() that reads from the in-tree .gitmodules file. I think the copying on init is not what we should do here because it sets the user's customization to what ever happened to be in .gitmodules at the time he initialized the submodule. Later changes from upstream to such a setting would not be honored unless the user copies that new setting herself (which I think is The Right Thing for the URL, but not for the other work tree related settings like 'ignore'). Imagine you have a submodule containing a huge media file which is set to be ignored for performance reasons. When upstream later decides it should rather use .gitattributes to just disable diffing that file and removes the submodule ignore so the users see changes to other files of the submodule again, that will just work the way it is done now, but won't when we copy that setting on init. So it is either honor upstream unless the user decides otherwise or take what upstream configured at init time as the users choice (until he actively changes it). And I think the former is more flexible as it allows upstream to change settings without user intervention, which is why I did it that way. And as I understand that .gitattributes follow the same principle: Unless the user configured something different in his $GIT_DIR/info/attributes file, git will use the settings from the .gitattributes file of the currently checked out commit. So I think Orgad's change is sane and should go in. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] pretty: two phase conversion for non utf-8 commits
On Sun, Sep 23, 2012 at 8:54 PM, Robin Rosenberg
robin.rosenb...@dewire.com wrote:
This of course only works with encodings that are compatible with
Unicode.
Such as? Unicode was defined to encompass all knows encodings.
Just a precaution because I have never read Unicode standard (and it
keeps getting updated, hence incomplete)
-static size_t format_commit_one(struct strbuf *sb, const char
*placeholder,
+static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
+ const char *placeholder,
void *context)
{
struct format_commit_context *c = context;
Which parameter does the comment apply to? I believe most conventions
nowadays include parameter documentation in the comment preceding
the function header.
Yeah. I should have followed that.
b/t/t6006/commit-msg.iso8859-1
new file mode 100644
index 000..f8fe808
--- /dev/null
+++ b/t/t6006/commit-msg.iso8859-1
@@ -0,0 +1,5 @@
+Test printing of complex bodies
+
+This commit message is much longer than the others,
+and it will be encoded in iso8859-1. We should therefore
+include an iso8859 character: �bueno!
8859-1 to be exact. Only three 8859 encoding has the
character.
Yep. But i'll probably need a closer look at t6006. It seems there's a
few upside down exclamation (not sure what it's called) in UTF-8 in
that test. I'll fix the text too.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] silence git gc --auto --quiet output
When --quiet is requested, gc --auto should not display messages unless there is an error. Signed-off-by: Tobias Ulmer tobi...@tmux.org --- builtin/gc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/builtin/gc.c b/builtin/gc.c index 6d46608..6be6c8d 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -217,9 +217,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix) */ if (!need_to_gc()) return 0; - if (quiet) - fprintf(stderr, _(Auto packing the repository for optimum performance.\n)); - else + if (!quiet) fprintf(stderr, _(Auto packing the repository for optimum performance. You may also\n run \git gc\ manually. See -- 1.7.6 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] gitk: Synchronize highlighting in file view when scrolling diff
Paul Mackerras pau...@samba.org wrote: On Wed, Sep 19, 2012 at 08:17:27PM +0200, Stefan Haller wrote: Here's one way how to address your concern. When pressing the search button it will highlight the file that contains the current search hit; if you then scroll from there though, the normal mechanism kicks in again and might highlight the previous file. The same happens now if you select the last file in the list, but it's diff is smaller than a screenful. In the previous patch versions it would select a different file than you clicked on, which is probably also confusing. Is this what you had in mind? Yes, it is, and I applied your patch. I wonder though if it might work better to highlight all the files that are visible? Interesting idea. I tried it, but I don't like it much, it just looks and feels so odd. I can send a patch if you're interested in trying it yourself. But personally, I really only need the synchronization feature in the case where a file's diff is longer than fits on a screen; as long as a file header is visible on the left side, it's prominent enough that I don't need more guidance. -Stefan -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: configure submodules
Jens Lehmann jens.lehm...@web.de writes: Jens, what do you think? I see no reason for anybody other than submodule init to call gitmodules_config() that reads from the in-tree .gitmodules file. I think the copying on init is not what we should do here because it sets the user's customization to what ever happened to be in .gitmodules at the time he initialized the submodule. Hrm, why does the user have submodule.$name.$whatever customized before saying submodule init $whategver for that copying to be problematic? So I think Orgad's change is sane and should go in. Matching what cmd_commit() does to what cmd_status() does, i.e. grab submodule.$name.ignore from somewhere, is not something I questioned. The patch is a good change to make them consistent. What I was wondering was if that is a consistently wrong thing to do to read from .gitmodules not $GIT_DIR/config. In any case, the log message I suggested in the review needs to be updated in the reroll to make it clear that this is about reading from .gitmodules, not configuration. AFAICS, gitmodule_config() does not even read from $GIT_DIR/config, right? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
