* rebase-merge/done: No such file or directory
From: jidanni @ 2009-01-12 19:13 UTC (permalink / raw)
To: johannes.schindelin; +Cc: git
Bug at git-rebase--interactive.sh:107: count=$(grep -c '^[^#]' < "$DONE")
$DONE might not exist. Do test -f $DONE before you grep it.
This will happen if the user gave a wrong squash choice.
$ git rebase --interactive ...
Waiting for Emacs...
grep: .git/rebase-merge/done: No such file or directory
Cannot 'squash' without a previous commit
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 21:47 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <496BB810.30503@tedpavlic.com>
* Ted Pavlic [Mon, 12 Jan 2009 16:37:20 -0500]:
>> Because (from a quick look) their completion script never expands a
>> variable which is not known to be set.
> They use $1, $2, etc. In fact, they use $1, $2, and $3 in their _hg,
> which is their main completion function. Why would those be defined
> there?
From http://www.gnu.org/software/bash/manual/bashref.html#Programmable-Completion:
When the function or command is invoked, the first argument is the name
of the command whose arguments are being completed, the second argument
is the word being completed, and the third argument is the word
preceding the word being completed on the current command line.
> In fact, it's $1, $2, $3, and $4 that are causing the problemw ith the
> git completions.
They are causing problems in the functions that are called sometimes
with arguments, sometimes without, like __gitdir. If you know that
you'll always be calling a function with $1, you need not use ${1-};
that's what happens in the mercurial completion script AFAICS.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- F. Nietzsche
^ permalink raw reply
* Re: checking out by date
From: Robin Rosenberg @ 2009-01-12 21:24 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20090112193039.GO25823@eratosthenes.cryptobackpack.org>
David Bryson <david@statichacks.org> writes:
> Hi All,
>
> I have a very large repository that imported into git from CVS with
> about 5 years worth of history.
>
> Today I decided to checkout some code from the past:
>
> $ git checkout master@{"Mon Dec 31 2007"}
> warning: Log for 'master' only goes back to Tue, 2 Dec 2008 16:57:15
> -0800.
git checkout $(git rev-list -n1 --before="Mon Dec 31 2007 23:59:59")
-- robin
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <20090112213213.GM10179@spearce.org>
>> It appears like they use
>>
>> complete -o bashdefault
>>
>> whereas Git's uses
>>
>> complete -o default
>>
>> I think that's the difference.
>
> If that's all we need to do, that's a simple 1 line change... which
> I like.
That was a red herring. The problem is more fundamental than that.
The script needs to be more careful about its use. I'll submit a better
patch momentarily.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* git log, outputs something weird for colors
From: mark @ 2009-01-12 21:51 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* git/webdav is refusing to authenticate properly.
From: Peter Spierenburg @ 2009-01-12 21:54 UTC (permalink / raw)
To: git
Greetings,
I'm trying to push a local git repository to a remote site using
WebDAV, but it is eating my lunch.
My first attempt includes a username but no password in the url:
$ git-config remote.upload.url
http://peter@spierepf.dyndns.org/git/ToastMeister.git/
$ git push upload master
Fetching remote heads...
refs/
refs/tags/
refs/heads/
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to 0f5f3df5e289b5696d7319dcfabc2383192f306a
Unable to create branch path
http://peter@spierepf.dyndns.org/git/ToastMeister.git/refs
Unable to lock remote branch refs/heads/master
error: failed to push some refs to
'http://peter@spierepf.dyndns.org/git/ToastMeister.git/'
What surprises me here is that git never asks for a password, so
naturally, my apache webserver will refuse the request:
==> /var/log/apache2/access.log <==
208.38.1.1 - - [12/Jan/2009:11:52:07 -0700] "PROPFIND
/git/ToastMeister.git/ HTTP/1.1" 207 569 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:08 -0700] "HEAD
/git/ToastMeister.git/info/refs HTTP/1.1" 404 - "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:08 -0700] "HEAD
/git/ToastMeister.git/objects/info/packs HTTP/1.1" 404 - "-"
"git/1.5.6.3"
==> /var/log/apache2/error.log <==
[Mon Jan 12 11:52:08 2009] [error] [client 208.38.1.1] File does not
exist: /var/www/git/ToastMeister.git/info/refs
[Mon Jan 12 11:52:08 2009] [error] [client 208.38.1.1] File does not
exist: /var/www/git/ToastMeister.git/objects/info/packs
==> /var/log/apache2/access.log <==
208.38.1.1 - - [12/Jan/2009:11:52:08 -0700] "PROPFIND
/git/ToastMeister.git/refs/ HTTP/1.1" 207 2587 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:08 -0700] "PROPFIND
/git/ToastMeister.git/refs/tags/ HTTP/1.1" 207 933 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:08 -0700] "PROPFIND
/git/ToastMeister.git/refs/heads/ HTTP/1.1" 207 934 "-" "git/1.5.6.3"
208.38.1.1 - peter [12/Jan/2009:11:52:08 -0700] "MKCOL
/git/ToastMeister.git/refs HTTP/1.1" 401 598 "-" "git/1.5.6.3"
==> /var/log/apache2/error.log <==
[Mon Jan 12 11:52:08 2009] [warn] [client 208.38.1.1] [12697]
auth_ldap authenticate: user peter authentication failed; URI
/git/ToastMeister.git/refs [Empty password not allowed][Invalid
credentials]
[Mon Jan 12 11:52:08 2009] [error] [client 208.38.1.1] user peter:
authentication failure for "/git/ToastMeister.git/refs": Password
Mismatch
So next, I'll try adding a password to the URL:
$ git-config remote.upload.url
http://peter:<secret>@spierepf.dyndns.org/git/ToastMeister.git/
$ git push upload master
Fetching remote heads...
refs/
refs/tags/
refs/heads/
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to 0f5f3df5e289b5696d7319dcfabc2383192f306a
Unable to create branch path
http://peter:<secret>@spierepf.dyndns.org/git/ToastMeister.git/refs
Unable to lock remote branch refs/heads/master
error: failed to push some refs to
'http://peter:<secret>@spierepf.dyndns.org/git/ToastMeister.git/'
>From the client side, the result appears identical, but on the server:
==> /var/log/apache2/access.log <==
208.38.1.1 - - [12/Jan/2009:11:52:50 -0700] "PROPFIND
/git/ToastMeister.git/ HTTP/1.1" 207 581 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:50 -0700] "HEAD
/git/ToastMeister.git/info/refs HTTP/1.1" 404 - "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:51 -0700] "HEAD
/git/ToastMeister.git/objects/info/packs HTTP/1.1" 404 - "-"
"git/1.5.6.3"
==> /var/log/apache2/error.log <==
[Mon Jan 12 11:52:50 2009] [error] [client 208.38.1.1] File does not
exist: /var/www/git/ToastMeister.git/info/refs
[Mon Jan 12 11:52:51 2009] [error] [client 208.38.1.1] File does not
exist: /var/www/git/ToastMeister.git/objects/info/packs
==> /var/log/apache2/access.log <==
208.38.1.1 - - [12/Jan/2009:11:52:51 -0700] "PROPFIND
/git/ToastMeister.git/refs/ HTTP/1.1" 207 2587 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:51 -0700] "PROPFIND
/git/ToastMeister.git/refs/tags/ HTTP/1.1" 207 933 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:51 -0700] "PROPFIND
/git/ToastMeister.git/refs/heads/ HTTP/1.1" 207 934 "-" "git/1.5.6.3"
208.38.1.1 - peter [12/Jan/2009:11:52:51 -0700] "MKCOL
/git/ToastMeister.git/refs HTTP/1.1" 301 458 "-" "git/1.5.6.3"
208.38.1.1 - - [12/Jan/2009:11:52:51 -0700] "MKCOL
/git/ToastMeister.git/refs/ HTTP/1.1" 401 598 "-" "git/1.5.6.3"
It looks like the client is attempting to create a collection that
already exists, gets redirected (301 - Moved Permanently), forgets to
authenticate on the next request, gets denied (401 - Unauthorized),
and gives up.
Any idea why this is happening?
Peter-Frank Spierenburg.
^ permalink raw reply
* Re: [JGIT] Blame functionality for jgit
From: Shawn O. Pearce @ 2009-01-12 21:55 UTC (permalink / raw)
To: Manuel Woelker; +Cc: Robin Rosenberg, git
In-Reply-To: <3d045c7e0901121317j4ccd9515vbc7a44abc8ae5356@mail.gmail.com>
Manuel Woelker <manuel.woelker@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 6:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> That sounds like a good plan. For now I am not all that concerned
> about performance myself (premature optimization and all that), but in
> the long run - and especially with rename/copy detection that will
> definitely a factor for usability.
Yea, I know. Premature optimization is the root of all evil.
But we've also learned the hard way that Java is slow as snot
compared to C git. The only way we can even stay close is to
optimize the hell out of the tight inner sections, and very often
that means using byte[] and avoiding upconverting to String to as
late as we possibly can.
Performance *is* a feature in Git. Its not a "nice to have",
its a requirement. The old history view for example was too damn
slow using Commit, requiring minutes on one of my systems to render
egit.git history. Using RevCommit its subsecond response time.
I just wanted to point out that we care quite a bit about speed, and
that given our input (raw byte[] from the pack) we need to be able
to quickly make decisions without upconverting to String, otherwise
blame performance will be so bad that its completely unusable.
> > I think eventually we'll have a BSD licensed LCS [...]
>
> While trying to look up the Myers diff algorithm I found a diff
> implementation in Apache wicket (cf.
> http://wicket.sourceforge.net/apidocs/wicket/util/diff/myers/package-summary.html
> ). This one is under an Apache license, is that any better? It's truly
> kind of sad that you need a degree in law these days to get any work
> done in this license jungle. I just happen to strongly oppose the
> reinvention of circular transportation-enabling devices...
Yea, even the ASF has trouble deciding if the Apache License and
the GPL can get along:
"The Apache Software Foundation is still trying to determine if
this version of the Apache License is compatible with the GPL."
http://www.apache.org/licenses/
The Apache License doesn't play nice with GPLv2 apparently, but is
OK with GPLv2, at least according to the FSF.
Anyway. The Apache License is roughly the new style BSD, but with
patent protection clauses built in. I think we can consume code
under the Apache License and redistribute it without any trouble
for us, our any of our downstream consumers.
> I'll keep you posted on new developments
Looking forward to it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more
From: Junio C Hamano @ 2009-01-12 22:06 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <877i50jjs8.fsf@jidanni.org>
jidanni@jidanni.org writes:
> The need for -o cannot be overstated. Else the arguments get
> interpreted differently.
I do not think there is any ambiguity with the existing SYNOPSIS.
'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
> +REQUIRED OPTIONS
> +-------
> +-o<directory>::
> + Directory in which to place the individual messages.
> + -o is required or else arguments may be misinterpreted in a
> + backwards compatibility mode.
> +
I think you are being overly alarmist without being helpful.
You hint that there is a backwards compatible syntax but you do not say
what it is, and you hint that the backwards compatible syntax is bad in
some unspecified way by saying "misinterpreted", without substantiating
the claim in any way.
The worst part in the new description is "may be", which only injects FUD
("is my use trigger that pitfall? how do I decide? the manual page does
not say!") without being helpful at all to the readers.
Probably a better alternative would be to describe what the backward
compatible syntax is and what it does (which I won't do here), and mention
something like the attached patchlet, without moving where -o<dir> is
described, _if_ you want to talk about it.
diff --git i/Documentation/git-mailsplit.txt w/Documentation/git-mailsplit.txt
index 5cc94ec..1b12014 100644
--- i/Documentation/git-mailsplit.txt
+++ w/Documentation/git-mailsplit.txt
@@ -28,7 +28,10 @@ OPTIONS
and new subdirectories.
-o<directory>::
- Directory in which to place the individual messages.
+ Directory in which to place the individual messages. This option
+ is required in a modern usage of the command; when omitted, the
+ arguments are parsed differently and the command works in a
+ backward compatible mode (see below).
-b::
If any file doesn't begin with a From line, assume it is a
^ permalink raw reply related
* git-format-patch with -o ../ in subdir of working copy writes output in wrong place
From: Cesar Eduardo Barros @ 2009-01-12 22:04 UTC (permalink / raw)
To: git
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.
Testcase:
mkdir a
cd a
git init
mkdir b
touch b/c
git add b/c
git commit -m 'test'
cd b
echo 'test' > c
git commit -a -m 'test'
git format-patch -o ../ HEAD^..HEAD
Expected result: put the patch within the "a" directory
Result with v1.6.1: put the patch within the parent of the "a" directory
(This testcase uses ../ instead of ../../ to avoid putting the patch
file in an unexpected place, like in your home directory, which is what
would happen in practice.)
--
Cesar Eduardo Barros
cesarb@cesarb.net
cesar.barros@gmail.com
^ permalink raw reply
* Re: [kde] kde konsole color settings in terminal
From: Boyd Stephen Smith Jr. @ 2009-01-12 22:18 UTC (permalink / raw)
To: mark; +Cc: kde, git
In-Reply-To: <82fa9e310901121335p4bd1e223x8eea1881c0add364@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On Monday 2009 January 12 15:35:08 mark wrote:
>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
Looks like konsole isn't interpreting the color codes. However, it also looks
like git doesn't use termcap/terminfo/etc. to determine the correct way to
write colors for your terminal and just defaults to ANSI.
Do you get odd output from:
grep --color=always o <<< foo
or are the "o"s properly colored red?
>settings in my bash and git.
>
>export | grep -i term
>declare -x TERM="xterm-256color"
So you have a /usr/share/terminfo/k/konsole-256color file? If so, it might be
better to use TERM="konsole-256color".
I never use 256 color mode, so I'm not clear on how that works. However, what
git is outputting look more like ANSI 16-color codes.
Does this work as you expect in other terminal applications (like rxvt or
xterm or gnome-terminal) with the same settings for TERM?
Just to let you know, it works here (openSUSE 11.1) with Konsole 1.6.6 (KDE
3.5.10) running git 1.6.0.2 inside screen 4.00.02
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git log, outputs something weird for colors
From: Jacob Helwig @ 2009-01-12 22:28 UTC (permalink / raw)
To: mark; +Cc: git
In-Reply-To: <82fa9e310901121351y22feaf21rfb880bcd0d6cb1a3@mail.gmail.com>
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".
-Jacob
^ permalink raw reply
* Re: [kde] kde konsole color settings in terminal
From: mark @ 2009-01-12 22:30 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: kde, git
In-Reply-To: <200901121618.52636.bss@iguanasuicide.net>
On Mon, Jan 12, 2009 at 2:18 PM, Boyd Stephen Smith Jr.
<bss@iguanasuicide.net> wrote:
> On Monday 2009 January 12 15:35:08 mark wrote:
>>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
>
> Looks like konsole isn't interpreting the color codes. However, it also looks
> like git doesn't use termcap/terminfo/etc. to determine the correct way to
> write colors for your terminal and just defaults to ANSI.
>
> Do you get odd output from:
> grep --color=always o <<< foo
> or are the "o"s properly colored red?
[mark@localhost blue]$ grep --color=always o <<< foo
foo
yes the oo s are colored yellow.
>>settings in my bash and git.
>>
>>export | grep -i term
>>declare -x TERM="xterm-256color"
>
> So you have a /usr/share/terminfo/k/konsole-256color file? If so, it might be
> better to use TERM="konsole-256color".
i do not have that file you specify.
I have only these
ls /usr/share/terminfo/k/*
/usr/share/terminfo/k/kon /usr/share/terminfo/k/kon2
> I never use 256 color mode, so I'm not clear on how that works. However, what
> git is outputting look more like ANSI 16-color codes.
>
> Does this work as you expect in other terminal applications (like rxvt or
> xterm or gnome-terminal) with the same settings for TERM?
no, it is not working on gnome-terminal or xterm. i do not have rxvt.
i even tried with TERM=xterm.
still the same problem!!
i am running on kde 4.1.3, fedora 10 latest updates.
i am getting good colors on vim.
i like git colors, help me out!
thanks a lot!
^ permalink raw reply
* 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
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