* Re: git log, outputs something weird for colors
From: mark @ 2009-01-12 22:33 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git, kde
In-Reply-To: <8c9a060901121428j37ff6699g7af264f79829b6de@mail.gmail.com>
On Mon, Jan 12, 2009 at 2:28 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 13:51, mark <markkicks@gmail.com> wrote:
>> hi
>> i am using kde konsole, and i am getting weird output for colors, for
>> example for git log i get the following output
>>
>>
>> git log
>> ESC[33mcommit 8b918256d944221f741e5d7300873810e31466a6ESC[m
>>
>>
>> settings in my bash and git.
>>
>> export | grep -i term
>> declare -x TERM="xterm-256color"
>>
>>
>> ~/.gitconfig
>> [color]
>> branch = auto
>> diff = auto
>> status = auto
>>
>> do you know what is wrong?
>> thanks
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> I don't have any problems with Konsole and git's coloring, but my TERM
> is set to "xterm", not "xterm-256color".
even xterm does not work for me!
but git status, and git branch give the correct color. the problem is
only with git log!
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-12 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Potashev, git
In-Reply-To: <7veizatxo9.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 10, 2009 at 05:54:14PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > [but I'm not sure whether testresult with Nathaniel Borenstein
> > (םולש ןב ילטפנ) is correct -- see rfc2047-info-0004]
> > ...
> > diff --git a/t/t5100/rfc2047-info-0004 b/t/t5100/rfc2047-info-0004
> > new file mode 100644
> > index 0000000..850f831
> > --- /dev/null
> > +++ b/t/t5100/rfc2047-info-0004
> > @@ -0,0 +1,5 @@
> > +Author: Nathaniel Borenstein
> > + ([somethig that could be detected as spam])
> > +Email: nsb@thumper.bellcore.com
> > +Subject: Test of new header generator
> > +
>
> That does look wrong. If you can fix this, please do so; otherwise please
> mark the test that deals with this entry with test_expect_failure, until
> somebody else does.
Yes, I think I've dealt with it -- we weren't unfolding 'From' header,
and we were not skipping comments in rfc822 headers, so:
From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Subject: [PATCH] mailinfo: 'From:' header should be unfold as well
At present we do headers unfolding (see RFC822 3.1.1. LONG HEADER FIELDS) for
all fields except 'From' (always) and 'Subject' (when keep_subject is set)
Not unfolding 'From' is a bug -- see above-mentioned RFC link.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
builtin-mailinfo.c | 1 +
t/t5100/sample.mbox | 5 ++++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index f7c8c08..6d72c1b 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -860,6 +860,7 @@ static void handle_info(void)
}
output_header_lines(fout, "Subject", hdr);
} else if (!memcmp(header[i], "From", 4)) {
+ cleanup_space(hdr);
handle_from(hdr);
fprintf(fout, "Author: %s\n", name.buf);
fprintf(fout, "Email: %s\n", email.buf);
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 4bf7947..d465685 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,7 +2,10 @@
From nobody Mon Sep 17 00:00:00 2001
-From: A U Thor <a.u.thor@example.com>
+From: A
+ U
+ Thor
+ <a.u.thor@example.com>
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a commit.
--
tg: (1562445..) t/mail-from-unfold (depends on: master)
From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Subject: [PATCH] mailinfo: more smarter removal of rfc822 comments from 'From'
As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
John (zzz) Doe <john.doe@xz> (Comment)
should "NOT [be] included in the destination mailbox"
We need this functionality to pass all RFC2047 based tests in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
builtin-mailinfo.c | 30 ++++++++++++++++++++++++++++++
t/t5100/sample.mbox | 4 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 6d72c1b..c0b1ab4 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
+static void cleanup_space(struct strbuf *sb);
+
+
static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)
{
struct strbuf *src = name;
@@ -120,6 +123,33 @@ static void handle_from(const struct strbuf *from)
strbuf_setlen(&f, f.len - 1);
}
+ /* This still could not be finished for emails like
+ *
+ * "John (zzz) Doe <john.doe@xz> (Comment)"
+ *
+ * The email part had already been removed, so let's kill comments as
+ * well -- RFC822 says comments should not be present in destination
+ * mailbox (3.4.3. Comments and A.1.4.)
+ */
+ while (1) {
+ char *ta;
+
+ at = strchr(f.buf, '(');
+ if (!at)
+ break;
+ ta = strchr(at, ')');
+ if (!ta)
+ break;
+
+ strbuf_remove(&f, at - f.buf, ta-at + (*ta ? 1 : 0));
+ }
+
+ /* and let's finally cleanup spaces that were around (possibly
+ * internal) comments
+ */
+ cleanup_space(&f);
+ strbuf_trim(&f);
+
get_sane_name(&name, &f, &email);
strbuf_release(&f);
}
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index d465685..42e02f3 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,10 +2,10 @@
From nobody Mon Sep 17 00:00:00 2001
-From: A
+From: A (zzz)
U
Thor
- <a.u.thor@example.com>
+ <a.u.thor@example.com> (Comment)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a commit.
--
tg: (b798ad9..) t/mail-from-comments (depends on: t/mail-from-unfold)
All these patches + original one (trivially adapted) could be pulled from
git://repo.or.cz/git/kirr.git for-junio
Kirill Smelkov (3):
mailinfo: 'From:' header should be unfold as well
mailinfo: more smarter removal of rfc822 comments from 'From'
mailinfo: correctly handle multiline 'Subject:' header
builtin-mailinfo.c | 58 ++++++++++++++++++++++++++++++++++++------
t/t5100-mailinfo.sh | 24 ++++++++++++++++-
t/t5100/info0012 | 5 +++
t/t5100/msg0012 | 7 +++++
t/t5100/patch0012 | 30 +++++++++++++++++++++
t/t5100/rfc2047-info-0001 | 4 +++
t/t5100/rfc2047-info-0002 | 4 +++
t/t5100/rfc2047-info-0003 | 4 +++
t/t5100/rfc2047-info-0004 | 4 +++
t/t5100/rfc2047-info-0005 | 2 +
t/t5100/rfc2047-info-0006 | 2 +
t/t5100/rfc2047-info-0007 | 2 +
t/t5100/rfc2047-info-0008 | 2 +
t/t5100/rfc2047-info-0009 | 2 +
t/t5100/rfc2047-info-0010 | 2 +
t/t5100/rfc2047-info-0011 | 2 +
t/t5100/rfc2047-samples.mbox | 48 ++++++++++++++++++++++++++++++++++
t/t5100/sample.mbox | 57 ++++++++++++++++++++++++++++++++++++++++-
18 files changed, 249 insertions(+), 10 deletions(-)
Thanks,
Kirill
^ permalink raw reply related
* Re: git log, outputs something weird for colors
From: mark @ 2009-01-12 22:38 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git, kde
In-Reply-To: <82fa9e310901121433p67f7bb3ai330439bf3c00df26@mail.gmail.com>
On Mon, Jan 12, 2009 at 2:33 PM, mark <markkicks@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 2:28 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 13:51, mark <markkicks@gmail.com> wrote:
>>> hi
>>> i am using kde konsole, and i am getting weird output for colors, for
>>> example for git log i get the following output
>>>
>>>
>>> git log
>>> ESC[33mcommit 8b918256d944221f741e5d7300873810e31466a6ESC[m
>>>
>>>
>>> settings in my bash and git.
>>>
>>> export | grep -i term
>>> declare -x TERM="xterm-256color"
>>>
>>>
>>> ~/.gitconfig
>>> [color]
>>> branch = auto
>>> diff = auto
>>> status = auto
>>>
>>> do you know what is wrong?
>>> thanks
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> I don't have any problems with Konsole and git's coloring, but my TERM
>> is set to "xterm", not "xterm-256color".
>
> even xterm does not work for me!
> but git status, and git branch give the correct color. the problem is
> only with git log!
>
this helped!
http://git.or.cz/gitwiki/GitFaq#head-678310c22f3e4a233d348bdde55a3e4cb7368ee9
i had LESS=-Q set on my .bashrc, commenting that out produces nice
colors for git log!
thanks all!
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
^ permalink raw reply
* Re: rebase-merge/done: No such file or directory
From: Johannes Schindelin @ 2009-01-12 22:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87ocycjq29.fsf@jidanni.org>
Hi,
On Tue, 13 Jan 2009, jidanni@jidanni.org wrote:
> Bug at git-rebase--interactive.sh:107: count=$(grep -c '^[^#]' < "$DONE")
Woohoo. Buuuug.
> $DONE might not exist. Do test -f $DONE before you grep it.
I cannot reproduce here. Since all the files in .git/rebase-merge/ are
internal files to rebase--interactive, I think we do not have to guard
against any possible user action rendering assumptions about internals
invalid.
Wasting a minute, I seem to understand why I cannot reproduce. Just
looking all of _two_ lines above the line you mentioned:
sed -e 1q < "$TODO" >> "$DONE"
Hrmpf. You're right. The user could have removed "$DONE"e between the
two lines ;-)
Hth,
Dscho
^ permalink raw reply
* [PATCH] Teach format-patch to handle output directory relative to cwd
From: Junio C Hamano @ 2009-01-12 22:49 UTC (permalink / raw)
To: Cesar Eduardo Barros; +Cc: git
In-Reply-To: <496BBE70.9060405@cesarb.net>
Without any explicit -o parameter, we correctly avoided putting the
resulting patch output to the toplevel. We should do the same when
the user gave a relative pathname to be consistent with this case and also
with how other commands handle relative pathnames.
Noticed by Cesar Eduardo Barros.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Cesar Eduardo Barros <cesarb@cesarb.net> writes:
> If you are in a subdirectory of your working copy (for instance,
> linux-2.6/drivers/net) and use git-format-patch with -o to a sequence
> of ../ (for instance, -o ../../../) to write to the working copy's
> parent directory, it instead interprets the directory passed to -o as
> relative to the root of the working copy, instead of the expected
> current directory.
builtin-log.c | 13 ++++++++++-
t/t4014-format-patch.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git c/builtin-log.c w/builtin-log.c
index 4a02ee9..3e404ae 100644
--- c/builtin-log.c
+++ w/builtin-log.c
@@ -731,6 +731,15 @@ static const char *clean_message_id(const char *msg_id)
return xmemdupz(a, z - a);
}
+static const char *set_outdir(const char *prefix, const char *output_directory)
+{
+ if (!output_directory)
+ output_directory = ".";
+ if (prefix)
+ output_directory = xstrdup(prefix_filename(prefix, strlen(prefix), output_directory));
+ return output_directory;
+}
+
int cmd_format_patch(int argc, const char **argv, const char *prefix)
{
struct commit *commit;
@@ -908,8 +917,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)
DIFF_OPT_SET(&rev.diffopt, BINARY);
- if (!output_directory && !use_stdout)
- output_directory = prefix;
+ if (!use_stdout)
+ output_directory = set_outdir(prefix, output_directory);
if (output_directory) {
if (use_stdout)
diff --git c/t/t4014-format-patch.sh w/t/t4014-format-patch.sh
index 9d99dc2..5a9a63d 100755
--- c/t/t4014-format-patch.sh
+++ w/t/t4014-format-patch.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2006 Junio C Hamano
#
-test_description='Format-patch skipping already incorporated patches'
+test_description='various format-patch tests'
. ./test-lib.sh
@@ -255,4 +255,54 @@ test_expect_success 'format-patch respects -U' '
'
+test_expect_success 'format-patch from a subdirectory (1)' '
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1
+ ) &&
+ case "$filename" in
+ sub/dir/*)
+ ;; # ok
+ *)
+ echo "Oops? $filename"
+ false
+ ;;
+ esac &&
+ test -f "$filename"
+'
+
+test_expect_success 'format-patch from a subdirectory (2)' '
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1 -o ..
+ ) &&
+ case "$filename" in
+ sub/dir/../0*)
+ ;; # ok
+ *)
+ echo "Oops? $filename"
+ false
+ ;;
+ esac &&
+ basename=$(expr "$filename" : ".*/\(.*\)") &&
+ test -f "sub/$basename"
+'
+
+test_expect_success 'format-patch from a subdirectory (3)' '
+ here="$TEST_DIRECTORY/$test" &&
+ rm -f 0* &&
+ filename=$(
+ rm -rf sub &&
+ mkdir -p sub/dir &&
+ cd sub/dir &&
+ git format-patch -1 -o "$here"
+ ) &&
+ basename=$(expr "$filename" : ".*/\(.*\)") &&
+ test -f "$basename"
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH EGIT Allow for git config to not error when lines have '/r' in them.]
From: Robin Rosenberg @ 2009-01-12 22:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ryan Alberts, git
In-Reply-To: <20090112171045.GI10179@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > torsdag 08 januari 2009 04:10:05 skrev Ryan Alberts:
> > > I have attached a small fix for when a git config has /r lines in the file.
> > > I have to admit that I do not usually submit patches to the open source
> > > community and I am not very familiar with the process :-) Please, please,
> > > let me know if I can do something different next time!
> >
> > Back to the patch. I think we should only ignore \r (not /r, but could say CR in
> > a comment) before an LF.
>
> I disagree; ignoring CR anyplace in the file should be fine, unless
> it is within a double quoted value, in which case it should use
> the same rule that \n would use within the same region.
>
> ' ', \n, \t all act the same with regards to being (mostly) ignored
> whitespace. \r is no different. Especially for anyone crazy enough
> to still be using a Mac style formatted file, with only CRs in it.
Those are copied from in to out in the repo config parser today. Why
should ' \r' be treated differently? Just CR (FF, Ctrl-G etc) is garbage,
but CRLF is a well established line terminator.
-- robin
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more
From: jidanni @ 2009-01-12 22:55 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vhc44gowr.fsf@gitster.siamese.dyndns.org>
All I know is the user had better not forget -o<directory> or else his
precious mailbox will be interpreted as something else... Actually the
problem is with builtin-mailsplit.c,
$ git mailsplit -o
fatal: unknown option: -o
One big tangle. So I would just say
+ certain backward compatibility mode (that we won't detail here).
^ permalink raw reply
* Re: rebase-merge/done: No such file or directory
From: Adeodato Simó @ 2009-01-12 23:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jidanni, git
In-Reply-To: <alpine.DEB.1.00.0901122342420.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Mon, 12 Jan 2009 23:47:47 +0100]:
> > $DONE might not exist. Do test -f $DONE before you grep it.
> I cannot reproduce here. Since all the files in .git/rebase-merge/ are
> internal files to rebase--interactive, I think we do not have to guard
> against any possible user action rendering assumptions about internals
> invalid.
> Wasting a minute, I seem to understand why I cannot reproduce. Just
> looking all of _two_ lines above the line you mentioned:
> sed -e 1q < "$TODO" >> "$DONE"
> Hrmpf. You're right. The user could have removed "$DONE"e between the
> two lines ;-)
No, not really. Start a rebase -i. Change the *first* "pick" to a
"squash". Save and exit the editor. You'll see the output jidanni
mentioned:
grep: .git/rebase-merge/done: No such file or directory
Cannot 'squash' without a previous commit
The second line tells the user what happened (what their error was), but
I guess we could do without the first one.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it.
-- Brian W. Kernighan
^ permalink raw reply
* Re: git/webdav is refusing to authenticate properly.
From: Johannes Schindelin @ 2009-01-12 23:04 UTC (permalink / raw)
To: Peter Spierenburg; +Cc: git
In-Reply-To: <137c54e10901121354l284f11ag675abb003fc83e93@mail.gmail.com>
Hi,
On Mon, 12 Jan 2009, Peter Spierenburg wrote:
> I'm trying to push a local git repository to a remote site using WebDAV,
> but it is eating my lunch.
Please see Documentation/howto/setup-git-server-over-http.txt.
In short, http-push does not ask for a password interactively, but you
have to use .netrc.
Hth,
Dscho
^ permalink raw reply
* [PATCH] Avoid spurious error messages on error mistakes.
From: Pierre Habouzit @ 2009-01-12 23:09 UTC (permalink / raw)
To: git, git; +Cc: Pierre Habouzit
In-Reply-To: <20090112230228.GA28545@chistera.yi.org>
Prior to that, if the user chose "squash" as a first action, the stderr
looked like:
grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory
Cannot 'squash' without a previous commit
Now the first line is gone.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c8b0861..8ed2244 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -349,7 +349,7 @@ do_next () {
squash|s)
comment_for_reflog squash
- has_action "$DONE" ||
+ test -f "$DONE" && has_action "$DONE" ||
die "Cannot 'squash' without a previous commit"
mark_action_done
--
1.6.1.161.g5e07b.dirty
^ permalink raw reply related
* Re: [PATCH] Teach format-patch to handle output directory relative to cwd
From: Cesar Eduardo Barros @ 2009-01-12 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9wgmwe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano escreveu:
> Without any explicit -o parameter, we correctly avoided putting the
> resulting patch output to the toplevel. We should do the same when
> the user gave a relative pathname to be consistent with this case and also
> with how other commands handle relative pathnames.
Works great, only the resulting output to the screen is a bit
ugly/confusing:
drivers/net/../../../0001-sc92031-more-useful-banner-in-kernel-log.patch
drivers/net/../../../0002-sc92031-remove-meaningless-version-string.patch
drivers/net/../../../0003-sc92031-inline-SC92031_DESCRIPTION.patch
drivers/net/../../../0004-sc92031-use-device-id-directly-instead-of-made-up-n.patch
drivers/net/../../../0005-sc92031-add-a-link-to-the-datasheet.patch
I would expect:
../../../0001-sc92031-more-useful-banner-in-kernel-log.patch
../../../0002-sc92031-remove-meaningless-version-string.patch
../../../0003-sc92031-inline-SC92031_DESCRIPTION.patch
../../../0004-sc92031-use-device-id-directly-instead-of-made-up-n.patch
../../../0005-sc92031-add-a-link-to-the-datasheet.patch
(after all, I am still inside the drivers/net directory)
--
Cesar Eduardo Barros
cesarb@cesarb.net
cesar.barros@gmail.com
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Junio C Hamano @ 2009-01-12 23:27 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Alexander Potashev, git
In-Reply-To: <20090112223447.GA5948@roro3.zxlink>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index f7c8c08..6d72c1b 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -860,6 +860,7 @@ static void handle_info(void)
> }
> output_header_lines(fout, "Subject", hdr);
> } else if (!memcmp(header[i], "From", 4)) {
> + cleanup_space(hdr);
> handle_from(hdr);
> fprintf(fout, "Author: %s\n", name.buf);
> fprintf(fout, "Email: %s\n", email.buf);
> diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
> index 4bf7947..d465685 100644
> --- a/t/t5100/sample.mbox
> +++ b/t/t5100/sample.mbox
> @@ -2,7 +2,10 @@
>
>
> From nobody Mon Sep 17 00:00:00 2001
> -From: A U Thor <a.u.thor@example.com>
> +From: A
> + U
> + Thor
> + <a.u.thor@example.com>
> Date: Fri, 9 Jun 2006 00:44:16 -0700
> Subject: [PATCH] a commit.
I think this is a reasonable change.
But doesn't this
> From nobody Mon Sep 17 00:00:00 2001
> -From: A
> +From: A (zzz)
> U
> Thor
> - <a.u.thor@example.com>
> + <a.u.thor@example.com> (Comment)
regress for people who spell their names like this?
From: john.doe@email.xz (John Doe)
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 23:39 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Alex Riesen, git
In-Reply-To: <alpine.DEB.2.00.0901120324490.18989@vellum.laroia.net>
Asheesh Laroia wrote:
> On Mon, 12 Jan 2009, Jakub Narebski wrote:
>
> > But I have to run
> >
> > $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
> >
> > first. Is there any way to automate this?
>
> Check out 'gstm' or 'autossh'.
I don't know about gSTM (Gnome SSH Tunnel Manager), but autossh
does only provide reconnect in the case the gateway host closes
connection. I still have to run it, perhaps from startup script.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Jakub Narebski @ 2009-01-12 23:43 UTC (permalink / raw)
To: Mike Hommey; +Cc: Alex Riesen, git
In-Reply-To: <20090112122337.GA7262@glandium.org>
On Mon, 12 January 2009, Mike Hommey wrote:
> On Mon, Jan 12, 2009 at 12:13:44PM +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>> Currently I have the folowing in my ~/.ssh/config:
>>
>> # TP S.A. blocks repo.or.cz
>> Host repo.or.cz
>> NoHostAuthenticationForLocalhost yes
>> HostName localhost
>> Port 2222
>>
>> and I can simply use "git push repo" without any changes.
>> But I have to run
>>
>> $ ssh -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>>
>> first. Is there any way to automate this?
>
> Something like the following should do the trick:
> Host repo.or.cz
> ProxyCommand ssh jnareb@host.example.com nc %h %p
>
> You will need nc (netcat) installed on the host.example.com server, though.
I assume that is both in place of above ~/.ssh/config configuration,
and making unnecessary port forwarding (ssh -L) invocation, isn't it?
P.S. What should I put in core.gitProxy to make it possible to fetch
via git:// protocol from repo.or.cz?
--
Jakub Narebski
Poland
^ permalink raw reply
* git-patches list?
From: Akira Kitada @ 2009-01-12 23:43 UTC (permalink / raw)
To: git
Hi,
Can I propose having another mailing list for posting patches to avoid
daily mail flood to this list?
Yes, I can filter out the emails but still...
Thanks,
^ permalink raw reply
* Re: git-patches list?
From: Junio C Hamano @ 2009-01-12 23:54 UTC (permalink / raw)
To: Akira Kitada; +Cc: git
In-Reply-To: <90bb445a0901121543q29d30d49yaa723b4b913a4b31@mail.gmail.com>
Akira Kitada <akitada@gmail.com> writes:
> Can I propose having another mailing list for posting patches to avoid
> daily mail flood to this list?
>
> Yes, I can filter out the emails but still...
This list has always been the only place where git development happens.
It would make the development very awkward to set up another list only for
patches, forbid patches to be sent to anywhere but that new list, but
still discuss the patches on this list.
It does not make much sense to me.
Consider what you would do when you see a problem somebody is having on
this list, and wanted to respond with a quick "this may fix it" patch?
Should you be sending that to the patches list, and sending a separate
message to this list saying that you have a potential fix in mind you
would want to discuss here, but the patches list rule mandated that you
had to send the patch to the other list, asking people who are reading
this list to look at the other list as well?
And no, having a separate "user list" won't solve the above problem either
and that is not what I am suggesting.
Not that I am seeing any problem right now; I am saying that the split
list as you suggest _will_ create problems.
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Jakub Narebski @ 2009-01-12 23:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Davide Libenzi, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901101507590.30769@pacific.mpi-cbg.de>
Hello!
On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
>>> On Sat, 10 Jan 2009, Jakub Narebski wrote:
>>>> Thomas Rast wrote:
>>>>
>>>>> --color-words works (and always worked) by splitting words onto one
>>>>> line each, and using the normal line-diff machinery to get a word
>>>>> diff.
>>>>
>>>> Cannot we generalize diff machinery / use underlying LCS diff engine
>>>> instead of going through line diff?
>>>
>>> What do you think we're doing? libxdiff is pretty hardcoded to newlines.
>>> That's why we're substituting non-word characters with newlines.
>>
>> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
>> subsequence, and doesn't it generate from the mathematical point of
>> view "diff" between two sequences (two arrays) which just happen to
>> be lines? It is a bit strange that libxdiff doesn't export its low
>> level algorithm...
>
> Umm.
>
> It _is_ Myers' algorithm. It just so happens that libxdiff hardcodes
> newline to be the separator.
So amd I to understand that _exported_ functions hardcode separator
to be newline (most probably for performance), and there is no function
in libxdiff which calculates LCS, or returns diff for arrays
(sequences)?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Anders Melchiorsen @ 2009-01-13 0:04 UTC (permalink / raw)
To: git; +Cc: jnareb, gitster
This lets gitweb hightlight abbreviated hashes as produced by
git rev-parse --short.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
It seems like seven digit hashes are in vogue now. So, did I miss some
reason for keeping it at eight in this spot?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ac84d1..1a7d448 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1337,7 +1337,7 @@ sub format_log_line_html {
my $line = shift;
$line = esc_html($line, -nbsp=>1);
- if ($line =~ m/([0-9a-fA-F]{8,40})/) {
+ if ($line =~ m/([0-9a-fA-F]{7,40})/) {
my $hash_text = $1;
my $link =
$cgi->a({-href => href(action=>"object", hash=>$hash_text),
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Re: [PATCH] gitweb: recognize six digit abbreviated SHA1
From: Anders Melchiorsen @ 2009-01-13 0:08 UTC (permalink / raw)
To: git; +Cc: jnareb, gitster
In-Reply-To: <87mydw2hrb.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> + if ($line =~ m/([0-9a-fA-F]{7,40})/) {
I could not make up my mind between the seven digits from "git
rev-parse --short" and the six digits currently used by gitk.
So I put one option in the patch, and the other one in the subject.
Cheers,
Anders.
^ permalink raw reply
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Jakub Narebski @ 2009-01-13 0:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0901111859q3a166d92k5176b27af2c4d256@mail.gmail.com>
On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
> > shortlogs) turned ref markers for tags and heads into links to
> > appropriate views for the ref name.
> >
> > Unfortunately the code didn't take into account the fact that nesting
> > links (A elements) is illegal in (X)HTML:
> >
> > 12.2.2 Nested links are illegal
> >
> > Links and anchors defined by the A element must not be nested;
> > an A element must not contain any other A elements.
[...]
> > What is more complicated is the issue of ref marker from
> > git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
> > view. There link is made into block element using "display: block;"
> > CSS rule (div.title, a.title), so that you can click _anywhere_ on the
> > header block. This breaks layout even worse, making hyperlinked ref
> > marker text appear *below* header div:
> >
> > -----------------------------------------------------------
> > |_Merge branch into maint_ [] |
> > -----------------------------------------------------------
> > _maint_
> >
> > To preserve current layout and behavior it would be needed to do some
> > deep HTML + CSS positioning hackery, perhaps with additional link block
> > without any text... But I don't know exactly how to do this; all [few]
> > experiments I did failed.
> >
> > I see possible the following alternate solutions:
> > * Ignore this issue (e.g. if it does not affect modern browsers)
>
> That would be my current choice until we find a better solution.
By the way, how common this error is? Could you check if _your_ web
browser (Firefox, Internet Explorer, Opera, Konqueror, Safari, Chrome)
does show this bug or not, please?
> > * Revert 4afbaef (we lose feature, but how often used is it?)
> > * Always use quirks mode, or check browser and use quirks mode if it
> > would break layout
> > * Use extra divs and links and CSS positioning to make layout which
> > looks like current one, and behaves as current one, but is more
> > complicated.
>
> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
I have found _a_ solution. Perhaps not the best one, but it works.
And IMHO gives / can give even better visual.
Current version (line wrapped for better visibility):
<div class="header">
<a class="title" href="...">GIT 1.6.1
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</a>
</div>
Current CSS (relevant part):
a.title {
display: block;
padding: 6px 8px;
}
Current rendering:
-----------------------------------------------------------
|_GIT 1.6.1_ [] |
-----------------------------------------------------------
__v1.6.1__
Proposed code (line wrapped for better visibility, with CSS embedded,
which would change in final version of course). Only parts of style
related to positioning are shown.
<div class="header">
<a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
<div style="float: left; margin: 6px 1px;">
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</div>
<a href="..." style="display: block; padding: 6px 8px;"> </a>
</div>
Rendering with proposed code:
-----------------------------------------------------------
_|_GIT 1.6.1_ [_v1.6.1_] |_
-----------------------------------------------------------
I guess that instead of additional DIV element, we could use DIV for
.refs, or use "float: right" style with SPAN element. I have not
checked if other variations works: this one does.
What do you think?
--
Jakub Narebski
Poland
^ permalink raw reply
* the meaning of keephardlinks
From: Geoff Russell @ 2009-01-13 0:17 UTC (permalink / raw)
To: git
I'm curious about what keephardlinks means.
If I do: "ln X Y ; git add Y ; git commit" in my origin and then
"git pull" in my cloned repository,
should I get a hard linked file in the clone
when core.keephardlinks is set to true?
Cheers,
Geoff Russell
^ permalink raw reply
* Re: [PATCH] Fix Dcoumentation typos surrounding the word 'handful'.
From: Markus Heidelberg @ 2009-01-13 0:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1231790527-7515-1-git-send-email-jdl@freescale.com>
Jon Loeliger, 12.01.2009:
> +++ b/Documentation/git-ls-tree.txt
> @@ -59,7 +59,7 @@ OPTIONS
>
> --abbrev[=<n>]::
> Instead of showing the full 40-byte hexadecimal object
> - lines, show only handful hexdigits prefix.
> + lines, show only a partal prefix.
partial :)
Markus
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Johannes Schindelin @ 2009-01-13 0:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Davide Libenzi, Thomas Rast
In-Reply-To: <200901130059.19511.jnareb@gmail.com>
Hi,
On Tue, 13 Jan 2009, Jakub Narebski wrote:
> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> > On Sat, 10 Jan 2009, Jakub Narebski wrote:
> >> On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> >>> On Sat, 10 Jan 2009, Jakub Narebski wrote:
> >>>> Thomas Rast wrote:
> >>>>
> >>>>> --color-words works (and always worked) by splitting words onto one
> >>>>> line each, and using the normal line-diff machinery to get a word
> >>>>> diff.
> >>>>
> >>>> Cannot we generalize diff machinery / use underlying LCS diff engine
> >>>> instead of going through line diff?
> >>>
> >>> What do you think we're doing? libxdiff is pretty hardcoded to newlines.
> >>> That's why we're substituting non-word characters with newlines.
> >>
> >> Isn't Meyers algorithm used by libxdiff based on LCS, largest common
> >> subsequence, and doesn't it generate from the mathematical point of
> >> view "diff" between two sequences (two arrays) which just happen to
> >> be lines? It is a bit strange that libxdiff doesn't export its low
> >> level algorithm...
> >
> > Umm.
> >
> > It _is_ Myers' algorithm. It just so happens that libxdiff hardcodes
> > newline to be the separator.
>
> So amd I to understand that _exported_ functions hardcode separator
> to be newline (most probably for performance), and there is no function
> in libxdiff which calculates LCS, or returns diff for arrays
> (sequences)?
That is my understanding, yes.
Ciao,
Dscho
^ permalink raw reply
* Re: the meaning of keephardlinks
From: Johannes Schindelin @ 2009-01-13 0:42 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0901121617m43af82a7te946b1607fbf3f77@mail.gmail.com>
Hi,
On Tue, 13 Jan 2009, Geoff Russell wrote:
> I'm curious about what keephardlinks means.
>
> If I do: "ln X Y ; git add Y ; git commit" in my origin and then
> "git pull" in my cloned repository,
> should I get a hard linked file in the clone
> when core.keephardlinks is set to true?
Nope.
It means that if you have a hard link locally, it will stay a hard link
(and if it is modified, the other linked files will obviously change,
too).
Note that this feature is not even in 'next'.
Ciao,
Dscho
^ permalink raw reply
* [PATCH/RFC] contrib/examples/README: warn of obsolescence
From: jidanni @ 2009-01-13 0:45 UTC (permalink / raw)
To: git
We attempt to give an explanation of the status of the files in this
directory.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
contrib/examples/README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 contrib/examples/README
diff --git a/contrib/examples/README b/contrib/examples/README
new file mode 100644
index 0000000..b10910c
--- /dev/null
+++ b/contrib/examples/README
@@ -0,0 +1 @@
+Note that these are obsolete versions of programs now replaced by C code.
--
1.6.0.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox