* Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: greened @ 2013-01-16 3:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Techlive Zheng
In-Reply-To: <7vmwwjedei.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "David A. Greene" <greened@obbligato.org> writes:
>
>> From: Techlive Zheng <techlivezheng@gmail.com>
>>
>> Use %B to format the commit message and body to avoid an extra newline
>> if a commit only has a subject line.
>>
>> Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
>>
>> Signed-off-by: David A. Greene <greened@obbligato.org>
>> ---
>
> This time (only), I'll try to fix them up at my end, but please
> check your toolchain, find out where the extra blank line between
> S-o-b: lines we see above come from, and fix that, so that I won't
> have to do so again.
Will do.
>> contrib/subtree/git-subtree.sh | 6 +++++-
>> contrib/subtree/t/t7900-subtree.sh | 15 +++++++++++++++
>> 2 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index 920c664..5341b36 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -296,7 +296,11 @@ copy_commit()
>> # We're going to set some environment vars here, so
>> # do it in a subshell to get rid of them safely later
>> debug copy_commit "{$1}" "{$2}" "{$3}"
>> - git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
>> + # Use %B rather than %s%n%n%b to handle the special case of a
>> + # commit that only has a subject line. We don't want to
>> + # introduce a newline after the subject, causing generation of
>> + # a new hash.
>> + git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
>
> The new format template is fine, but I do not think the comment
> should be there. It does not give any useful information to people
> who are reading the end result of applying this patch and is useful
> only in the context of comparing the old and new templates, iow, it
> belongs to the commit log message.
I'll delete the comment.
-David
^ permalink raw reply
* Re: [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: greened @ 2013-01-16 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: 郑文辉(Techlive Zheng), git
In-Reply-To: <7vzk0j9oig.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David, how would you like to handle a reroll of this piece?
I'll just get the test fix from Techlive Zheng, apply it to my
branch and re-send.
Are you incorporating the other patches? Should I drop them
from my list?
-David
^ permalink raw reply
* Re: [PATCH 3/7] contrib/subtree: Add --unannotate
From: greened @ 2013-01-16 3:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, James Nylen
In-Reply-To: <7vehhvecoy.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "David A. Greene" <greened@obbligato.org> writes:
>
>> diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
>> index c5bce41..75aa690 100644
>> --- a/contrib/subtree/git-subtree.txt
>> +++ b/contrib/subtree/git-subtree.txt
>> @@ -198,6 +198,21 @@ OPTIONS FOR split
>> git subtree tries to make it work anyway, particularly
>> if you use --rejoin, but it may not always be effective.
>>
>> +--unannotate=<annotation>::
>> + This option is only valid for the split command.
>> +
>> + When generating synthetic history, try to remove the prefix
>> + <annotation> from each commit message (using bash's "strip
>> + shortest match from beginning" command, which supports
>> + globbing). This makes sense if you format library commits
>> + like "library: Change something or other" when you're working
>> + in your project's repository, but you want to remove this
>> + prefix when pushing back to the library's upstream repository.
>> + (In this case --unannotate='*: ' would work well.)
>> +
>> + Like --annotate, you need to use the same <annotation>
>> + whenever you split, or you may run into problems.
>
> I think this paragraph inherits existing breakage from the beginning
> of time, but I do not think the above will format the second and
> subsequent paragraphs correctly.
Ok, I'll take a look.
> I've applied all seven patches in the series with minor fix-ups, and
> will merge it to 'pu'.
Thanks!
-David
^ permalink raw reply
* Re: [PATCH 4/7] contrib/subtree: Better Error Handling for add
From: greened @ 2013-01-16 3:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7gnneco2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "David A. Greene" <greened@obbligato.org> writes:
>
>> From: "David A. Greene" <greened@obbligato.org>
>>
>> Check refspecs for validity before passing them on to other commands.
>> This lets us generate more helpful error messages.
>>
>> Signed-off-by: David A. Greene <greened@obbligato.org>
>> ---
>> contrib/subtree/git-subtree.sh | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
>> index cac0680..d53eaee 100755
>> --- a/contrib/subtree/git-subtree.sh
>> +++ b/contrib/subtree/git-subtree.sh
>> @@ -508,12 +508,18 @@ cmd_add()
>> ensure_clean
>>
>> if [ $# -eq 1 ]; then
>> - "cmd_add_commit" "$@"
>> + git rev-parse -q --verify "$1^{commit}" >/dev/null ||
>> + die "'$1' does not refer to a commit"
>
> Where do these uneven indentation come from? Is it mimicking
> existing breakage in the script?
Huh. I'm not sure how that happened. I'll fix it if you haven't got to
it already.
-David
^ permalink raw reply
* Re: [PATCH 0/7] guilt patches, including git 1.8 support
From: Theodore Ts'o @ 2013-01-16 3:26 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Josef 'Jeff' Sipek, git, Per Cederqvist, Iulian Udrea,
Axel Beckert
In-Reply-To: <20130116022606.GI12524@google.com>
On Tue, Jan 15, 2013 at 06:26:06PM -0800, Jonathan Nieder wrote:
> Hi Jeff and other guilty parties,
>
> I collected all the guilt patches I could find on-list and added one
> of my own. Completely untested, except for running the regression
> tests. These are also available via git protocol from
>
> git://repo.or.cz/guilt/mob.git mob
Jonathan, thanks for collecting all of the guilt patches! Your repro
was also very much really useful since I hadn't grabbed the latest
patches from jeffpc's repo before it disappeared after the kernel.org
security shutdown.
Jeff, do you need some help getting your repro on kernel.org
re-established?
- Ted
^ permalink raw reply
* Re: [PATCH 3/7] contrib/subtree: Add --unannotate
From: greened @ 2013-01-16 4:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, James Nylen
In-Reply-To: <87vcaxq0ez.fsf@waller.obbligato.org>
greened@obbligato.org writes:
>> I think this paragraph inherits existing breakage from the beginning
>> of time, but I do not think the above will format the second and
>> subsequent paragraphs correctly.
>
> Ok, I'll take a look.
I don't know what "correctly" is but it is at least formatted in a
similar manner to the other options.
-David
^ permalink raw reply
* Re: [PATCH 3/7] contrib/subtree: Add --unannotate
From: Junio C Hamano @ 2013-01-16 4:31 UTC (permalink / raw)
To: greened; +Cc: git, James Nylen
In-Reply-To: <87y5ftojoj.fsf@waller.obbligato.org>
greened@obbligato.org writes:
> greened@obbligato.org writes:
>
>>> I think this paragraph inherits existing breakage from the beginning
>>> of time, but I do not think the above will format the second and
>>> subsequent paragraphs correctly.
>>
>> Ok, I'll take a look.
>
> I don't know what "correctly" is but it is at least formatted in a
> similar manner to the other options.
That is what "inherits existing breakage" means ;-)
The first paragraph is typeset as body text, while the rest are
typeset in monospaced font, no?
It should be more like this, I think:
--option::
First paragraph
+
Second paragraph
+
And third paragraph
^ permalink raw reply
* Re: [PATCH] attr: fix off-by-one directory component length calculation
From: Junio C Hamano @ 2013-01-16 5:35 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Jean-Noël AVILA, git
In-Reply-To: <CACsJy8C2uEgwozpWBfowYJea3XRB72rhzjsSFuG9Ud0afuQy6w@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Jan 16, 2013 at 9:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> On Wed, Jan 16, 2013 at 08:08:03AM +0700, Duy Nguyen wrote:
>>>> Actually I'd like to remove that function.
>>>
>>> This is what I had in mind:
>>
>> I think the replacement logic to find the basename is moderately
>> inferiour to the original. For one thing (this may be somewhat
>> subjective), it is less readable now.
>
> Yeah, maybe it's micro optimization.
Your change is micro unoptimization (and making the result less
readable). I wouldn't worry too much about micro-optimizing an
existing piece of code, but making an efficient code into a worse
one without a good reason is a different story.
>> Also the original only
>> scanned the string from the beginning once (instead of letting
>> strlen() to scan once and go back).
>
> But we do need to strlen() anyway in collect_all_attrs().
That is exactly my point, isn't it?
The loop to find the basename has to run to the end of the string at
least once, as it cannot not stop at the last slash---it goes from
front to back and it won't know which one is the last slash until it
sees the end of the string. After the loop exits, you know the
length of the string without running a separate strlen() to assign
to "pathlen".
> So we scan
> the string 3 times (strlen + 2 * find_basename) in the original. Now
> we do it twice.
I already said that overall restructure of the code may be a good
idea to reduce the calls to the function. I was only comparing the
implementations of the loop that finds the basename, so I do not
understand what you mean by that "2 *" in that comparison. It does
not make sense to me.
^ permalink raw reply
* git fetch without --recurse-submodules option
From: 乙酸鋰 @ 2013-01-16 5:45 UTC (permalink / raw)
To: git
Hi,
With git pull or git fetch without specifying --recurse-submodules,
what is the default action?
It seems git fetches submodules wtihout specifying --recurse-submodules.
If this is not clear, please update documentation.
In git pull document --recurse-submodules option, it tells users to
see git-config(1) and gitmodules(5), but does not tell users to refer
to git fetch --recurse-submodules for the meaning of the switches.
In git fetch document --recurse-submodules option, it does not tell
users to see git-config(1) or gitmodules(5).
^ permalink raw reply
* Re: [PATCH] attr: fix off-by-one directory component length calculation
From: Duy Nguyen @ 2013-01-16 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jean-Noël AVILA, git
In-Reply-To: <7vtxqhzo4m.fsf@alter.siamese.dyndns.org>
On Tue, Jan 15, 2013 at 09:35:21PM -0800, Junio C Hamano wrote:
> >> Also the original only
> >> scanned the string from the beginning once (instead of letting
> >> strlen() to scan once and go back).
> >
> > But we do need to strlen() anyway in collect_all_attrs().
>
> That is exactly my point, isn't it?
OK I get your point now. Something like this?
-- 8< --
Subject: [PATCH] attr: avoid calling find_basename() twice per path
find_basename() is only used inside collect_all_attrs(), called once
in prepare_attr_stack, then again after prepare_attr_stack()
returns. Both calls return exact same value. Reorder the code to do
the same task once. Also avoid strlen() because we knows the length
after finding basename.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
attr.c | 45 ++++++++++++++++++---------------------------
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/attr.c b/attr.c
index cfc6748..880f862 100644
--- a/attr.c
+++ b/attr.c
@@ -564,32 +564,12 @@ static void bootstrap_attr_stack(void)
attr_stack = elem;
}
-static const char *find_basename(const char *path)
-{
- const char *cp, *last_slash = NULL;
-
- for (cp = path; *cp; cp++) {
- if (*cp == '/' && cp[1])
- last_slash = cp;
- }
- return last_slash ? last_slash + 1 : path;
-}
-
-static void prepare_attr_stack(const char *path)
+static void prepare_attr_stack(const char *path, int dirlen)
{
struct attr_stack *elem, *info;
- int dirlen, len;
+ int len;
const char *cp;
- dirlen = find_basename(path) - path;
-
- /*
- * find_basename() includes the trailing slash, but we do
- * _not_ want it.
- */
- if (dirlen)
- dirlen--;
-
/*
* At the bottom of the attribute stack is the built-in
* set of attribute definitions, followed by the contents
@@ -769,15 +749,26 @@ static int macroexpand_one(int attr_nr, int rem)
static void collect_all_attrs(const char *path)
{
struct attr_stack *stk;
- int i, pathlen, rem;
- const char *basename;
+ int i, pathlen, rem, dirlen;
+ const char *basename, *cp, *last_slash = NULL;
+
+ for (cp = path; *cp; cp++) {
+ if (*cp == '/' && cp[1])
+ last_slash = cp;
+ }
+ pathlen = cp - path;
+ if (last_slash) {
+ basename = last_slash + 1;
+ dirlen = last_slash - path;
+ } else {
+ basename = path;
+ dirlen = 0;
+ }
- prepare_attr_stack(path);
+ prepare_attr_stack(path, dirlen);
for (i = 0; i < attr_nr; i++)
check_all_attr[i].value = ATTR__UNKNOWN;
- basename = find_basename(path);
- pathlen = strlen(path);
rem = attr_nr;
for (stk = attr_stack; 0 < rem && stk; stk = stk->prev)
rem = fill(path, pathlen, basename, stk, rem);
--
1.8.0.rc3.18.g0d9b108
-- 8< --
^ permalink raw reply related
* Re: t9902 fails (Was: [PATCH] attr: fix off-by-one directory component length calculation)
From: Torsten Bögershausen @ 2013-01-16 6:15 UTC (permalink / raw)
To: Jeff King
Cc: Jean-Noël AVILA, Junio C Hamano, git,
Nguyễn Thái Ngọc Duy, Torsten Bögershausen
In-Reply-To: <20130115232400.GA16147@sigill.intra.peff.net>
On 01/16/2013 12:24 AM, Jeff King wrote:
> On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
>
>> "Jean-Noël AVILA"<avila.jn@gmail.com> writes:
>>
>>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known
>>> issue?
>>
>> Which branch?
>
> t9902.10 is overly sensitive to extra git commands in your PATH, as well
> as cruft in your build dir (especially if you have been building 'pu',
> which has git-check-ignore). Try "make clean&& make test".
>
> -Peff
This may help, or it may not.
If there are other binaries like
"git-check-email" or "git-check-ignore" in the PATH
.....
When you switch to a branch generating a file like
git-check-ignore then "make clean" will know about it
and will remove it.
If you switch to master, then "make clean" will not remove it.
What does "git status" say?
We had a discussion about this some weeks ago, but never concluded.
How about this:
http://comments.gmane.org/gmane.comp.version-control.git/211907
^ permalink raw reply
* Re: [PATCH] Allow custom "comment char"
From: Junio C Hamano @ 2013-01-16 6:23 UTC (permalink / raw)
To: Ralf Thielow; +Cc: jrnieder, git
In-Reply-To: <7v622y45wy.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
> ...
> Looks like a good progress overall, except for nits here and there.
>
>> diff --git a/builtin/notes.c b/builtin/notes.c
>> index 453457a..5e84e35 100644
>> --- a/builtin/notes.c
>> +++ b/builtin/notes.c
>> @@ -92,10 +92,7 @@ static const char * const git_notes_get_ref_usage[] = {
>> };
>>
>> static const char note_template[] =
>> - "\n"
>> - "#\n"
>> - "# Write/edit the notes for the following object:\n"
>> - "#\n";
>> + "Write/edit the notes for the following object:";
>
> I think this (and its use site that manually adds "\n#\n") is a
> symptom of strbuf_commented_add*() function not designed right.
> When it iterates over lines and adds each of them in a commented out
> form, it could check if the line is an empty one and refrain from
> adding a trailing SP if that is the case. Then this can become
>
> "\nWrite/edit the notes...\n\n";
>
> You have to create the "\n" blank line at the beginning manually,
> but that is logically outside the commented out block, so it is not
> a problem.
>> diff --git a/git-submodule.sh b/git-submodule.sh
>> index 22ec5b6..1b8d95f 100755
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -975,13 +975,19 @@ cmd_summary() {
>> echo
>> done |
>> if test -n "$for_status"; then
>> + comment_char=`git config core.commentchar`
>> + if [ ! -n "$comment_char" ]; then
>> + comment_char='#'
>> + elif [ ${#comment_char} -gt 1 ]; then
>
> Not portable, I think.
>
>> + echo "$comment_char"
>> + sed -e "s|^|$comment_char |" -e "s|^$comment_char $|$comment_char|"
>
> Can $comment_char be a '|'?
I think it may be the easiest to teach one of the pure-helper
commands, e.g. "git stripspace", to do this kind of thing for you
with a new option.
To summarize, along the lines of the attached patch (on top of
jc/custom-comment-char topic).
builtin/branch.c | 20 +++++++++-----------
builtin/stripspace.c | 35 +++++++++++++++++++++++++++++------
strbuf.c | 42 +++++++++++++++++++++++++++++++++++++++++-
strbuf.h | 4 ++++
4 files changed, 83 insertions(+), 18 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7f8865a..42de4c5 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -707,18 +707,16 @@ static int edit_branch_description(const char *branch_name)
if (!buf.len || buf.buf[buf.len-1] != '\n')
strbuf_addch(&buf, '\n');
/*
- * NEEDSWORK: introduce a strbuf_commented_addf(), possibly
- * sharing code with status_vprintf(), that makes each line
- * commented with comment_line_char, and use it here and from
- * other places (e.g. write_commented_object() and create_note()
- * in builtin/notes.c and create_tag() in builtin/tag.c).
+ * NEEDSWORK: convert more code to use this:
+ * (e.g. write_commented_object() and create_note() in
+ * builtin/notes.c and create_tag() in builtin/tag.c).
*/
- strbuf_addf(&buf,
- "%c Please edit the description for the branch\n"
- "%c %s\n"
- "%c Lines starting with '%c' will be stripped.\n",
- comment_line_char, comment_line_char,
- branch_name, comment_line_char, comment_line_char);
+ strbuf_commented_addf(&buf,
+ "Please edit the description for the branch\n"
+ " %s\n"
+ "Lines starting with '%c' will be stripped.\n",
+ branch_name, comment_line_char);
+
fp = fopen(git_path(edit_description), "w");
if ((fwrite(buf.buf, 1, buf.len, fp) < buf.len) || fclose(fp)) {
strbuf_release(&buf);
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index 600ca66..790b500 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -66,21 +66,44 @@ void stripspace(struct strbuf *sb, int skip_comments)
strbuf_setlen(sb, j);
}
+static void comment_lines(struct strbuf *buf)
+{
+ char *msg;
+ size_t len;
+
+ msg = strbuf_detach(buf, &len);
+ strbuf_add_commented_lines(buf, msg, len);
+}
+
int cmd_stripspace(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
int strip_comments = 0;
+ enum { INVAL = 0, STRIP_SPACE = 1, COMMENT_LINES = 2 } mode = STRIP_SPACE;
+
+ if (argc == 2) {
+ if (!strcmp(argv[1], "-s") ||
+ !strcmp(argv[1], "--strip-comments")) {
+ strip_comments = 1;
+ } else if (!strcmp(argv[1], "-c")) {
+ mode = COMMENT_LINES;
+ git_config(git_default_config, NULL);
+ } else {
+ mode = INVAL;
+ }
+ } else if (argc > 1)
+ mode = INVAL;
- if (argc == 2 && (!strcmp(argv[1], "-s") ||
- !strcmp(argv[1], "--strip-comments")))
- strip_comments = 1;
- else if (argc > 1)
- usage("git stripspace [-s | --strip-comments] < input");
+ if (mode == INVAL)
+ usage("git stripspace [-s|-c] <input");
if (strbuf_read(&buf, 0, 1024) < 0)
die_errno("could not read the input");
- stripspace(&buf, strip_comments);
+ if (mode == STRIP_SPACE)
+ stripspace(&buf, strip_comments);
+ else /* i.e. COMMENT_LINES */
+ comment_lines(&buf);
write_or_die(1, buf.buf, buf.len);
strbuf_release(&buf);
diff --git a/strbuf.c b/strbuf.c
index 9a373be..d0525c8 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -411,12 +411,17 @@ int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
return len;
}
-void strbuf_add_lines(struct strbuf *out, const char *prefix,
+static void add_lines(struct strbuf *out,
+ const char *prefix1,
+ const char *prefix2,
const char *buf, size_t size)
{
while (size) {
+ const char *prefix;
const char *next = memchr(buf, '\n', size);
next = next ? (next + 1) : (buf + size);
+
+ prefix = (prefix2 && buf[0] == '\n') ? prefix2 : prefix1;
strbuf_addstr(out, prefix);
strbuf_add(out, buf, next - buf);
size -= next - buf;
@@ -425,6 +430,41 @@ void strbuf_add_lines(struct strbuf *out, const char *prefix,
strbuf_complete_line(out);
}
+void strbuf_add_lines(struct strbuf *out, const char *prefix,
+ const char *buf, size_t size)
+{
+ add_lines(out, prefix, NULL, buf, size);
+}
+
+void strbuf_add_commented_lines(struct strbuf *out,
+ const char *buf, size_t size)
+{
+ static char prefix1[3];
+ static char prefix2[2];
+
+ if (prefix1[0] != comment_line_char) {
+ sprintf(prefix1, "%c ", comment_line_char);
+ sprintf(prefix2, "%c", comment_line_char);
+ }
+ add_lines(out, prefix1, prefix2, buf, size);
+}
+
+void strbuf_commented_addf(struct strbuf *sb, const char *fmt, ...)
+{
+ va_list params;
+ struct strbuf buf = STRBUF_INIT;
+ int incomplete_line = sb->len && sb->buf[sb->len - 1] != '\n';
+
+ va_start(params, fmt);
+ strbuf_vaddf(&buf, fmt, params);
+ va_end(params);
+
+ strbuf_add_commented_lines(sb, buf.buf, buf.len);
+ if (incomplete_line)
+ sb->buf[--sb->len] = '\0';
+ strbuf_release(&buf);
+}
+
void strbuf_addstr_xml_quoted(struct strbuf *buf, const char *s)
{
while (*s) {
diff --git a/strbuf.h b/strbuf.h
index ecae4e2..1eb0c75 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -131,10 +131,14 @@ extern void strbuf_addbuf_percentquote(struct strbuf *dst, const struct strbuf *
__attribute__((format (printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
+__attribute__((format (printf,2,3)))
+extern void strbuf_commented_addf(struct strbuf *sb, const char *fmt, ...);
__attribute__((format (printf,2,0)))
extern void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap);
extern void strbuf_add_lines(struct strbuf *sb, const char *prefix, const char *buf, size_t size);
+extern void strbuf_add_commented_lines(struct strbuf *out, const char *buf, size_t size);
+
/*
* Append s to sb, with the characters '<', '>', '&' and '"' converted
^ permalink raw reply related
* [PATCH v3 3/3] diff: Introduce --diff-algorithm command line option
From: Michal Privoznik @ 2013-01-16 7:51 UTC (permalink / raw)
To: git; +Cc: gitster, trast, peff
In-Reply-To: <cover.1358322212.git.mprivozn@redhat.com>
Since command line options have higher priority than config file
variables and taking previous commit into account, we need a way
how to specify myers algorithm on command line. However,
inventing `--myers` is not the right answer. We need far more
general option, and that is `--diff-algorithm`.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
Documentation/diff-options.txt | 21 +++++++++++++++++++++
contrib/completion/git-completion.bash | 11 +++++++++++
diff.c | 12 +++++++++++-
diff.h | 2 ++
merge-recursive.c | 9 +++++++++
5 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 39f2c50..6f11c34 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -55,6 +55,27 @@ endif::git-format-patch[]
--histogram::
Generate a diff using the "histogram diff" algorithm.
+--diff-algorithm={patience|minimal|histogram|myers}::
+ Choose a diff algorithm. The variants are as follows:
++
+--
+`default`, `myers`;;
+ The basic greedy diff algorithm. Currently, this happens to be
+ the default algorithm as well.
+`minimal`;;
+ Spend extra time to make sure the smallest possible diff is
+ produced.
+`patience`;;
+ Use "patience diff" algorithm when generating patches.
+`histogram`;;
+ This algorithm extends the patience algorithm to "support
+ low-occurrence common elements".
+--
++
+For instance, if you configured diff.algorithm variable to a
+non-default value and want to use the default one, then you
+have to use `--diff-algorithm=default` option.
+
--stat[=<width>[,<name-width>[,<count>]]]::
Generate a diffstat. By default, as much space as necessary
will be used for the filename part, and the rest for the graph
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 33e25dc..d592cf9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1021,6 +1021,8 @@ _git_describe ()
__gitcomp_nl "$(__git_refs)"
}
+__git_diff_algorithms="myers minimal patience histogram"
+
__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
@@ -1035,6 +1037,7 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--raw
--dirstat --dirstat= --dirstat-by-file
--dirstat-by-file= --cumulative
+ --diff-algorithm=
"
_git_diff ()
@@ -1042,6 +1045,10 @@ _git_diff ()
__git_has_doubledash && return
case "$cur" in
+ --diff-algorithm=*)
+ __gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
+ return
+ ;;
--*)
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
--base --ours --theirs --no-index
@@ -2114,6 +2121,10 @@ _git_show ()
" "" "${cur#*=}"
return
;;
+ --diff-algorithm=*)
+ __gitcomp "$__git_diff_algorithms" "" "${cur##--diff-algorithm=}"
+ return
+ ;;
--*)
__gitcomp "--pretty= --format= --abbrev-commit --oneline
$__git_diff_common_options
diff --git a/diff.c b/diff.c
index 7d6cc4c..5fa40e9 100644
--- a/diff.c
+++ b/diff.c
@@ -144,7 +144,7 @@ static int git_config_rename(const char *var, const char *value)
return git_config_bool(var,value) ? DIFF_DETECT_RENAME : 0;
}
-static long parse_algorithm_value(const char *value)
+long parse_algorithm_value(const char *value)
{
if (!value)
return -1;
@@ -3634,6 +3634,16 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
else if (!strcmp(arg, "--histogram"))
options->xdl_opts = DIFF_WITH_ALG(options, HISTOGRAM_DIFF);
+ else if (!prefixcmp(arg, "--diff-algorithm=")) {
+ long value = parse_algorithm_value(arg+17);
+ if (value < 0)
+ return error("option diff-algorithm accepts \"myers\", "
+ "\"minimal\", \"patience\" and \"histogram\"");
+ /* clear out previous settings */
+ DIFF_XDL_CLR(options, NEED_MINIMAL);
+ options->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK;
+ options->xdl_opts |= value;
+ }
/* flags options */
else if (!strcmp(arg, "--binary")) {
diff --git a/diff.h b/diff.h
index a47bae4..54c2590 100644
--- a/diff.h
+++ b/diff.h
@@ -333,6 +333,8 @@ extern struct userdiff_driver *get_textconv(struct diff_filespec *one);
extern int parse_rename_score(const char **cp_p);
+extern long parse_algorithm_value(const char *value);
+
extern int print_stat_summary(FILE *fp, int files,
int insertions, int deletions);
extern void setup_diff_pager(struct diff_options *);
diff --git a/merge-recursive.c b/merge-recursive.c
index 33ba5dc..ea9dbd3 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2068,6 +2068,15 @@ int parse_merge_opt(struct merge_options *o, const char *s)
o->xdl_opts = DIFF_WITH_ALG(o, PATIENCE_DIFF);
else if (!strcmp(s, "histogram"))
o->xdl_opts = DIFF_WITH_ALG(o, HISTOGRAM_DIFF);
+ else if (!strcmp(s, "diff-algorithm=")) {
+ long value = parse_algorithm_value(s+15);
+ if (value < 0)
+ return -1;
+ /* clear out previous settings */
+ DIFF_XDL_CLR(o, NEED_MINIMAL);
+ o->xdl_opts &= ~XDF_DIFF_ALGORITHM_MASK;
+ o->xdl_opts |= value;
+ }
else if (!strcmp(s, "ignore-space-change"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
else if (!strcmp(s, "ignore-all-space"))
--
1.8.0.2
^ permalink raw reply related
* [PATCH v3 1/3] git-completion.bash: Autocomplete --minimal and --histogram for git-diff
From: Michal Privoznik @ 2013-01-16 7:51 UTC (permalink / raw)
To: git; +Cc: gitster, trast, peff
In-Reply-To: <cover.1358322212.git.mprivozn@redhat.com>
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..383518c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1031,7 +1031,7 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
--inter-hunk-context=
- --patience
+ --patience --histogram --minimal
--raw
--dirstat --dirstat= --dirstat-by-file
--dirstat-by-file= --cumulative
--
1.8.0.2
^ permalink raw reply related
* [PATCH v3 0/3] Rework git-diff algorithm selection
From: Michal Privoznik @ 2013-01-16 7:51 UTC (permalink / raw)
To: git; +Cc: gitster, trast, peff
It's been a while I was trying to get this in. Recently, I realized how
important this is.
Please keep me CC'ed as I am not subscribed to the list.
diff to v1:
-Junio's suggestions worked in
diff to v2:
-yet more Junio's suggestions included
Michal Privoznik (3):
git-completion.bash: Autocomplete --minimal and --histogram for
git-diff
config: Introduce diff.algorithm variable
diff: Introduce --diff-algorithm command line option
Documentation/diff-config.txt | 18 ++++++++++++++++++
Documentation/diff-options.txt | 21 +++++++++++++++++++++
contrib/completion/git-completion.bash | 14 +++++++++++++-
diff.c | 34 ++++++++++++++++++++++++++++++++++
diff.h | 2 ++
merge-recursive.c | 9 +++++++++
6 files changed, 97 insertions(+), 1 deletion(-)
--
1.8.0.2
^ permalink raw reply
* [PATCH v3 2/3] config: Introduce diff.algorithm variable
From: Michal Privoznik @ 2013-01-16 7:51 UTC (permalink / raw)
To: git; +Cc: gitster, trast, peff
In-Reply-To: <cover.1358322212.git.mprivozn@redhat.com>
Some users or projects prefer different algorithms over others, e.g.
patience over myers or similar. However, specifying appropriate
argument every time diff is to be used is impractical. Moreover,
creating an alias doesn't play nicely with other tools based on diff
(git-show for instance). Hence, a configuration variable which is able
to set specific algorithm is needed. For now, these four values are
accepted: 'myers' (which has the same effect as not setting the config
variable at all), 'minimal', 'patience' and 'histogram'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
Documentation/diff-config.txt | 18 ++++++++++++++++++
contrib/completion/git-completion.bash | 1 +
diff.c | 24 ++++++++++++++++++++++++
3 files changed, 43 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 4314ad0..3a62ace 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -155,3 +155,21 @@ diff.tool::
"kompare". Any other value is treated as a custom diff tool,
and there must be a corresponding `difftool.<tool>.cmd`
option.
+
+diff.algorithm::
+ Choose a diff algorithm. The variants are as follows:
++
+--
+`default`, `myers`;;
+ The basic greedy diff algorithm. Currently, this happens to be
+ the default algorithm as well.
+`minimal`;;
+ Spend extra time to make sure the smallest possible diff is
+ produced.
+`patience`;;
+ Use "patience diff" algorithm when generating patches.
+`histogram`;;
+ This algorithm extends the patience algorithm to "support
+ low-occurrence common elements".
+--
++
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 383518c..33e25dc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1839,6 +1839,7 @@ _git_config ()
diff.suppressBlankEmpty
diff.tool
diff.wordRegex
+ diff.algorithm
difftool.
difftool.prompt
fetch.recurseSubmodules
diff --git a/diff.c b/diff.c
index 348f71b..7d6cc4c 100644
--- a/diff.c
+++ b/diff.c
@@ -36,6 +36,7 @@ static int diff_no_prefix;
static int diff_stat_graph_width;
static int diff_dirstat_permille_default = 30;
static struct diff_options default_diff_options;
+static long diff_algorithm;
static char diff_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RESET,
@@ -143,6 +144,21 @@ static int git_config_rename(const char *var, const char *value)
return git_config_bool(var,value) ? DIFF_DETECT_RENAME : 0;
}
+static long parse_algorithm_value(const char *value)
+{
+ if (!value)
+ return -1;
+ else if (!strcasecmp(value, "myers") || !strcasecmp(value, "default"))
+ return 0;
+ else if (!strcasecmp(value, "minimal"))
+ return XDF_NEED_MINIMAL;
+ else if (!strcasecmp(value, "patience"))
+ return XDF_PATIENCE_DIFF;
+ else if (!strcasecmp(value, "histogram"))
+ return XDF_HISTOGRAM_DIFF;
+ return -1;
+}
+
/*
* These are to give UI layer defaults.
* The core-level commands such as git-diff-files should
@@ -196,6 +212,13 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "diff.algorithm")) {
+ diff_algorithm = parse_algorithm_value(value);
+ if (diff_algorithm < 0)
+ return -1;
+ return 0;
+ }
+
if (git_color_config(var, value, cb) < 0)
return -1;
@@ -3213,6 +3236,7 @@ void diff_setup(struct diff_options *options)
options->add_remove = diff_addremove;
options->use_color = diff_use_color_default;
options->detect_rename = diff_detect_rename_default;
+ options->xdl_opts |= diff_algorithm;
if (diff_no_prefix) {
options->a_prefix = options->b_prefix = "";
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH] Allow custom "comment char"
From: Ralf Thielow @ 2013-01-16 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jrnieder, git
In-Reply-To: <7vmww9zlwj.fsf@alter.siamese.dyndns.org>
2013/1/16 Junio C Hamano <gitster@pobox.com>:
>>> diff --git a/git-submodule.sh b/git-submodule.sh
>>> index 22ec5b6..1b8d95f 100755
>>> --- a/git-submodule.sh
>>> +++ b/git-submodule.sh
>>> @@ -975,13 +975,19 @@ cmd_summary() {
>>> echo
>>> done |
>>> if test -n "$for_status"; then
>>> + comment_char=`git config core.commentchar`
>>> + if [ ! -n "$comment_char" ]; then
>>> + comment_char='#'
>>> + elif [ ${#comment_char} -gt 1 ]; then
>>
>> Not portable, I think.
>>
>>> + echo "$comment_char"
>>> + sed -e "s|^|$comment_char |" -e "s|^$comment_char $|$comment_char|"
>>
>> Can $comment_char be a '|'?
>
> I think it may be the easiest to teach one of the pure-helper
> commands, e.g. "git stripspace", to do this kind of thing for you
> with a new option.
>
> To summarize, along the lines of the attached patch (on top of
> jc/custom-comment-char topic).
Very good idea. I'll integrate.
Thanks
^ permalink raw reply
* Re: [PATCH v2 06/14] imap-send.c: remove some unused fields from struct store
From: Michael Haggerty @ 2013-01-16 8:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20130115203204.GA12524@google.com>
On 01/15/2013 09:32 PM, Jonathan Nieder wrote:
> Michael Haggerty wrote:
>
>> - else if ((arg1 = next_arg(&cmd))) {
>> - if (!strcmp("EXISTS", arg1))
>> - ctx->gen.count = atoi(arg);
>> - else if (!strcmp("RECENT", arg1))
>> - ctx->gen.recent = atoi(arg);
>> + } else if ((arg1 = next_arg(&cmd))) {
>> + /* unused */
>
> The above is just the right thing to do to ensure no behavior change.
> Let's take a look at the resulting code, though:
>
> if (... various reasonable things ...) {
> ...
> } else if ((arg1 = next_arg(&cmd))) {
> /* unused */
> } else {
> fprintf(stderr, "IMAP error: unable to parse untagged response\n");
> return RESP_BAD;
>
> Anyone forced by some bug to examine this "/* unused */" case is going
> to have no clue what's going on. In that respect, the old code was
> much better, since it at least made it clear that one case where this
> code gets hit is handling "<num> EXISTS" and "<num> RECENT" untagged
> responses.
>
> I suspect that original code did not have an implicit and intended
> missing
>
> else
> ; /* negligible response; ignore it */
>
> but the intent was rather
>
> else {
> fprintf(stderr, "IMAP error: I can't parse this\n");
> return RESP_BAD;
> }
>
> Since actually fixing that is probably too aggressive for this patch,
> how about a FIXME comment like the following?
>
> /*
> * Unhandled response-data with at least two words.
> * Ignore it.
> *
> * NEEDSWORK: Previously this case handled '<num> EXISTS'
> * and '<num> RECENT' but as a probably-unintended side
> * effect it ignores other unrecognized two-word
> * responses. imap-send doesn't ever try to read
> * messages or mailboxes these days, so consider
> * eliminating this case.
> */
Yes, this sounds reasonable to me. Thanks for the improvement.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2 07/14] imap-send.c: inline imap_parse_list() in imap_list()
From: Michael Haggerty @ 2013-01-16 8:26 UTC (permalink / raw)
To: Matt Kraai; +Cc: Junio C Hamano, git
In-Reply-To: <20130115185147.GB14552@ftbfs.org>
On 01/15/2013 07:51 PM, Matt Kraai wrote:
> On Tue, Jan 15, 2013 at 09:06:25AM +0100, Michael Haggerty wrote:
>> -static struct imap_list *parse_imap_list(struct imap *imap, char **sp)
>> +static struct imap_list *parse_list(char **sp)
>
> The commit subject refers to imap_parse_list and imap_list whereas the
> code refers to parse_imap_list and parse_list.
Yes, you're right. Thanks.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [BUG] Possible bug in `remote set-url --add --push`
From: Michael J Gruber @ 2013-01-16 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jardel Weyrich, Sascha Cunz, git@vger.kernel.org
In-Reply-To: <7v4nii5tp2.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Also there is a conceptual confusion: pushurl is meant to push to the
>> same repo using a different url, e.g. something authenticated
>> (https/ssh) for push and something faster/easier for fetch.
>
> That is not necessarily true, depending on the definition of your
> "same". Having multiple URLs/PushURLs that refer to physically
> different locations, as long as "git push there" immediately
> followed by "git fetch here" should work with the repositories that
> are conceptually equivalent, is a supported mode of operation. In
That is my definition of "same", in the sense of "object-and-ref-same"
when "in-sync" (at least regarding all pushed refs; there may be more
there).
> fact, they being physically different _was_ the original motivation
> of the feature. See 755225d (git builtin "push", 2006-04-29).
I thought it was about unauthenticated git-protocol vs. git+ssh but was
wrong.
> The definition of the "immediate" above also depends on your use; it
> could be tens of minutes (you may be fetching from git.k.org that
> can be reached from the general public, which may be a cname for
> multiple machines mirroring a single master.k.org that k.org account
> holders push to, and there may be propagation delays). In such a
> scenario, your URL may point at the public git.k.org, pushURL may
> point at master.k.org, and you may have other pushURLs that point at
> other places you use as back-up locations (e.g. git.or.cz or
> github.com).
Yes. That is also why we fetch from one fetch URL only, because we
assume they point at the "same" repo and don't need to check.
> As long as you _mean_ to maintain their contents the same, you can
> call them conceptually "the same repo" and your statement becomes
> true.
>
>> It never was meant to push to several repos.
>
> This is false. It _was_ designed to be used that way from day one.
It is very true with me definition of "same" ;)
> (I am not saying using it in other ways is an abuse---I am merely
> saying that pushing to multiple physically different repositories is
> within its scope).
>
>> That being said, I don't mind changing the behaviour of set-url.
>
> I do not think we want to change the behaviour of set-url. What
> needs to be fixed is the output from "remote -v". It should:
>
> * When there is no pushURL but there is a URL, then show it as
> (fetch/push), and you are done;
>
> * When there is one or more pushURLs and a URL, then show the URL
> as (fetch), and show pushURLs as (push), and you are done;
>
> * When there are more than one URLs, and there is no pushURL, then
> show the first URL as (fetch/push), and the remainder in a
> notation that says it is used only for push, but it shouldn't be
> the same "(push)"; the user has to be able to distinguish it from
> the pushURLs in a repository that also has URLs.
Maybe "(fetch fallback/push)" if we do use it as a fallback? If we don't
we probably should?
> * When there are more than one URLs, and there are one or more
> pushURLs, then show the first URL as (fetch), the other URLs
> as (unused), and the pushURLs as (push).
>
> Strictly speaking, the last one could be a misconfiguration. If you
> have:
>
> [remote "origin"]
> url = one
> url = two
> pushurl = three
> pushurl = four
>
> then your "git fetch" will go to one, and "git push" will go to
> three and four, and two is never used.
Do we fall back to two if one is unavailable? In any case, people may
use a configuration like that to keep track of mirrors and shuffle
around the fetch lines (rather than commenting/uncommenting) when one
goes offline.
> It should also be stressed that the third one a supported
> configuration. With
>
> [remote "origin"]
> url = one
> url = two
>
> your "git fetch" goes to one, and your "git push" will go to one and
> two. This is the originally intended use case of 755225d. It is to
> push to and fetch from master.k.org (think of "one" above) and in
> addition to push to backup.github.com ("two").
Michael
^ permalink raw reply
* Re: [RFC/PATCH 2/8 v3] git_remote_helpers: fix input when running under Python 3
From: John Keeping @ 2013-01-16 9:45 UTC (permalink / raw)
To: Pete Wyckoff
Cc: Junio C Hamano, Michael Haggerty, git, Eric S. Raymond,
Felipe Contreras, Sverre Rabbelier
In-Reply-To: <20130116000316.GA26999@padd.com>
On Tue, Jan 15, 2013 at 07:03:16PM -0500, Pete Wyckoff wrote:
> john@keeping.me.uk wrote on Tue, 15 Jan 2013 22:40 +0000:
>> This is what keeping the refs as byte strings looks like.
>
> As John knows, it is not possible to interpret text from a byte
> string without talking about the character encoding.
>
> Git is (largely) a C program and uses the character set defined
> in the C standard, which is a subset of ASCII. But git does
> "math" on strings, like this snippet that takes something from
> argv[] and prepends "refs/heads/":
>
> strcpy(refname, "refs/heads/");
> strcpy(refname + strlen("refs/heads/"), ret->name);
>
> The result doesn't talk about what character set it is using,
> but because it combines a prefix from ASCII with its input,
> git makes the assumption that the input is ASCII-compatible.
>
> If you feed a UTF-16 string in argv, e.g.
>
> $ echo master | iconv -f ascii -t utf16 | xargs git branch
> xargs: Warning: a NUL character occurred in the input. It cannot be passed through in the argument list. Did you mean to use the --null option?
> fatal: Not a valid object name: ''.
>
> you get an error about NUL, and not the branch you hoped for.
> Git assumes that the input character set contains roughly ASCII
> in byte positions 0..127.
>
> That's one small reason why the useful character encodings put
> ASCII in the 0..127 range, including utf-8, big5 and shift-jis.
> ASCII is indeed special due to its legacy, and both C and Python
> recognize this.
>
>> diff --git a/git_remote_helpers/git/importer.py b/git_remote_helpers/git/importer.py
>> @@ -18,13 +18,16 @@ class GitImporter(object):
>>
>> def get_refs(self, gitdir):
>> """Returns a dictionary with refs.
>> +
>> + Note that the keys in the returned dictionary are byte strings as
>> + read from git.
>> """
>> args = ["git", "--git-dir=" + gitdir, "for-each-ref", "refs/heads"]
>> - lines = check_output(args).strip().split('\n')
>> + lines = check_output(args).strip().split('\n'.encode('utf-8'))
>> refs = {}
>> for line in lines:
>> - value, name = line.split(' ')
>> - name = name.strip('commit\t')
>> + value, name = line.split(' '.encode('utf-8'))
>> + name = name.strip('commit\t'.encode('utf-8'))
>> refs[name] = value
>> return refs
>
> I'd suggest for this Python conundrum using byte-string literals, e.g.:
>
> lines = check_output(args).strip().split(b'\n')
> value, name = line.split(b' ')
> name = name.strip(b'commit\t')
>
> Essentially identical to what you have, but avoids naming "utf-8" as
> the encoding. It instead relies on Python's interpretation of
> ASCII characters in string context, which is exactly what C does.
The problem is that AFAICT the byte-string prefix is only available in
Python 2.7 and later (compare [1] and [2]). I think we need this more
convoluted code if we want to keep supporting Python 2.6 (although
perhaps 'ascii' would be a better choice than 'utf-8').
[1] http://docs.python.org/2.6/reference/lexical_analysis.html#literals
[2] http://docs.python.org/2.7/reference/lexical_analysis.html#literals
John
^ permalink raw reply
* [PATCH] git-remote: distinguish between default and configured URLs
From: Michael J Gruber @ 2013-01-16 10:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jardel Weyrich, Sascha Cunz
In-Reply-To: <7v4nii5tp2.fsf@alter.siamese.dyndns.org>
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Maybe something like this? It even seems to make the code in get_one_entry
clearer.
I yet have to look at the tests, doc and other git-remote invocations.
builtin/remote.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 937484d..ec07109 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1509,25 +1509,28 @@ static int get_one_entry(struct remote *remote, void *priv)
{
struct string_list *list = priv;
struct strbuf url_buf = STRBUF_INIT;
- const char **url;
- int i, url_nr;
+ char *fetchurl0, *fetchurl1;
+ int i;
+
+ if (remote->pushurl_nr > 0) {
+ fetchurl0 = "fetch";
+ fetchurl1 = "fetch fallback";
+ } else {
+ fetchurl0 = "fetch/push";
+ fetchurl1 = "fetch fallback/push";
+ }
- if (remote->url_nr > 0) {
- strbuf_addf(&url_buf, "%s (fetch)", remote->url[0]);
+ for (i = 0; i < remote->url_nr; i++) {
+ strbuf_addf(&url_buf, "%s (%s)", remote->url[0], i ? fetchurl1 : fetchurl0);
string_list_append(list, remote->name)->util =
strbuf_detach(&url_buf, NULL);
- } else
+ } /* else */
+ if (remote->url_nr == 0)
string_list_append(list, remote->name)->util = NULL;
- if (remote->pushurl_nr) {
- url = remote->pushurl;
- url_nr = remote->pushurl_nr;
- } else {
- url = remote->url;
- url_nr = remote->url_nr;
- }
- for (i = 0; i < url_nr; i++)
+
+ for (i = 0; i < remote->pushurl_nr; i++)
{
- strbuf_addf(&url_buf, "%s (push)", url[i]);
+ strbuf_addf(&url_buf, "%s (push)", remote->pushurl[i]);
string_list_append(list, remote->name)->util =
strbuf_detach(&url_buf, NULL);
}
--
1.8.1.1.456.g93e7b0a
^ permalink raw reply related
* [PATCH v3] test-lib.sh: unfilter GIT_PERF_*
From: Nguyễn Thái Ngọc Duy @ 2013-01-16 10:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1358257856-3274-1-git-send-email-pclouds@gmail.com>
These variables are user parameters to control how to run the perf
tests. Allow users to do so.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
PERF -> PERF_
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..bf4cf71 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -85,7 +85,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $("$PERL_PATH" -e '
.*_TEST
PROVE
VALGRIND
- PERF_AGGREGATING_LATER
+ PERF_
));
my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
print join("\n", @vars);
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH] git-remote: distinguish between default and configured URLs
From: Michael J Gruber @ 2013-01-16 10:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, Jardel Weyrich, Sascha Cunz
In-Reply-To: <a5bf3511b3ecf4e9243d550d11ab977f95ecea30.1358331096.git.git@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 16.01.2013 11:14:
> The current output of "git remote -v" does not distinguish between
> explicitly configured push URLs and those coming from fetch lines.
>
> Revise the output so so that URLs are distinguished by their labels:
>
> (fetch): fetch config used for fetching only
> (fetch/push): fetch config used for fetching and pushing
> (fetch fallback/push): fetch config used for pushing only
> (fetch fallback): fetch config which is unused
> (push): push config used for pushing
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> Maybe something like this? It even seems to make the code in get_one_entry
> clearer.
>
> I yet have to look at the tests, doc and other git-remote invocations.
Okay, so "git remote show remotename" copied the logic from "git remote
-v" but neither reused the code nor the output format. I guess we'd have
to implement the new logic and keep the old format? Refactoring would
require settling on a common format. Both outputs should be
ui-as-ui-can, but I'm afraid people are still grepping the output in
their scripts :(
Michael
^ permalink raw reply
* Re: [PATCH 3/3] Avoid non-portable strftime format specifiers in git-cvsimport
From: Ben Walton @ 2013-01-16 10:38 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Junio C Hamano, esr, git
In-Reply-To: <CAEUsAPZakGKUmQWrsTaF1cpbQm0Y4C3sDxCWD_i1gkQxeC-bRQ@mail.gmail.com>
On Wed, Jan 16, 2013 at 1:53 AM, Chris Rorvick <chris@rorvick.com> wrote:
> On Tue, Jan 15, 2013 at 5:10 PM, Ben Walton <bdwalton@gmail.com> wrote:
>> Neither %s or %z are portable strftime format specifiers. There is no
>> need for %s in git-cvsimport as the supplied time is already in
>> seconds since the epoch. For %z, use the function get_tz_offset
>> provided by Git.pm instead.
>
> Out of curiosity, which platforms are affected? Assuming DST is a 1
> hour shift (patch 2/3) is not necessarily portable either, though this
> currently appears to only affect a small island off of the coast of
> Australia. :-)
My primary motivation on this change was for solaris. %s isn't
supported in 10 (not sure about 11) and %z was only added in 10. The
issue affects other older platforms as well.
Good point about the 1 hour assumption. Is it worth hacking in
additional logic to handle Lord Howe Island? I think it's likely a
case of "in for a penny, in for a pound" but that could lead to
madness when it comes to time zones. Either way, the function behaves
better now than before.
(I wasn't aware of the half hour oddball wrt to DST, so I learned
something new here too!)
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself. Much more happiness,
truth, beauty and wisdom will come to you that way.
-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
^ 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