* [PATCH v2] git-web--browse: don't add start as candidate on Ubuntu
From: Ramsay Jones @ 2009-01-12 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Petr Baudis, GIT Mailing-list
In-Reply-To: <7vljtr33sb.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>> Le jeudi 1 janvier 2009, Ramsay Jones a écrit :
>> ...
>>> Does anybody else see this issue and can someone test the patch?
>> Petr, as you added support for using /bin/start on MinGW, could you test?
>>
>> diff --git a/git-web--browse.sh b/git-web--browse.sh
>> index 78d236b..7ed0fad 100755
>> --- a/git-web--browse.sh
>> +++ b/git-web--browse.sh
>> @@ -115,7 +115,7 @@ if test -z "$browser" ; then
>> browser_candidates="open $browser_candidates"
>> fi
>> # /bin/start indicates MinGW
>> - if test -n /bin/start; then
>> + if test -x /bin/start; then
>> browser_candidates="start $browser_candidates"
>> fi
>
> In any case, the original test is simply bogus. 'test -n "$foo"' is to
> see if $foo is an empty string, and giving a constant /bin/start always
> yields true.
>
> As an old timer, I tend to prefer "test -f" in this context, as anybody
> sane can expect that the directory /bin will contain executables and
> nothing else. Another reason is purely stylistic. Historically "-f" has
> been much more portable than "-x" (which came from SVID), even though it
> wouldn't make much difference in practice in the real world these days.
Sorry for the late reply; if this has already been resolved, then sorry for
the noise.
I was expecting to be castigated for having /sbin in my $PATH. Indeed, I was
a bit surprised... So, I checked my initialization files and then the system
initialization files and could not find where it was being set...
$ strings /bin/bash | grep sbin
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ strings /bin/sh | grep sbin
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
So I don't think it's anything I'm doing...
Anyway, I've changed the patch as you suggested. It would still be good
if someone on MinGW could test it.
ATB,
Ramsay Jones
git-web--browse.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 78d236b..c5e62a6 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -115,7 +115,7 @@ if test -z "$browser" ; then
browser_candidates="open $browser_candidates"
fi
# /bin/start indicates MinGW
- if test -n /bin/start; then
+ if test -f /bin/start; then
browser_candidates="start $browser_candidates"
fi
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:11 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901121435.35547.bss@iguanasuicide.net>
>> if [ -z "${1-}" ]
>
> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
> the script?
As already discussed, because the script must be sourced, then the "set
+u" has global scope.
I suppose that the option could be tested and then reset as appropriate
at the end of the script.
(note: for some reason Mercurial's bash completion script does not have
this problem; they use $1 directly without bash complaining)
--
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
* Re: [JGIT] Blame functionality for jgit
From: Manuel Woelker @ 2009-01-12 21:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <20090112174232.GJ10179@spearce.org>
On Mon, Jan 12, 2009 at 6:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> I largely ported the cgit blame algorithm described here
>> https://kerneltrap.org/mailarchive/git/2006/10/12/224187 , the
>> relevant file is builtin-blame.c cf.
>> http://repo.or.cz/w/git.git?a=blob;f=builtin-blame.c;hb=HEAD
>
> OK. Fortunately Junio has largely given his blessing to this code
> being converted to Java under the BSD license.
Glad to hear that, Dscho already mentioned that a port like this might
raise license concerns. So I hope Junio would be okay with that.
> Unfortunately I can't reach incava.org to download java-diff, but
> its entry on sourceforge says it uses an LGPL license. Within JGit
> we do want to stick to BSD and BSD dependencies, so bringing in
> java-diff as a new dependency isn't something we really want to do.
>
> Fortunately Dscho has been working on a Java diff implementation for
> JGit, and is considering releasing it under a BSD license so we can
> include it.
>
> The interface is still to be decided, but in general we have
> found that running against a byte[] is much faster than running
> against String. We're probably going to want the diff library to
> take a byte[] and an IntList (as created by RawParseUtils.lineMap)
> and let it work against the byte array ranges directly, without any
> additional allocations, except where it needs to build up its hash
> of records.
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. We could adopt the interface to
allow for a "fast" implementation, and have existing diff
implementations adapted to that. I'd be very interested to see Dscho's
diff work, and maybe we can get something going on that front. A
patience diff implementation would be rather neat too, and all my
googling hasn't turned up anything.
> I think eventually we'll have a BSD licensed LCS that will come with
> JGit, which would eliminate the need for such a shim. I'd like
> to see that happen before blame gets added, but if blame is ready
> and the shim is reasonably well done, I'm inclined to bring blame
> in early.
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...
> - Don't use @author tags, we don't use them anywhere else.
>
> - Please include copyright headers on all new files.
>
> - I think the IDiff, IDifference should be in a ".diff" package so
> we can reuse them for other diff applications. Especially if we
> wind up using a shim to link to different LCS implementations.
>
> - I think the API for BlameEngine should be more like:
>
> public class BlameEngine {
> private final RevWalk rw;
>
> public BlameEngine(final Repository repo) {
> this(new RevWalk(repo));
> }
>
> public BlameEngine(final RevWalk walk) {
> rw = walk;
> }
>
> public RevWalk getRevWalk() {
> return rw;
> }
>
> public List<BlameEntry> blame(RevCommit c, String path);
> }
>
> One reason for this style of API is we can have the engine cache
> blame records. This can make a GUI navigator much more efficient
> as it jumps around between commits and asks for blames over the
> same data.
>
> - Internally you should *always* use RevCommit, not Commit.
> The RevCommit class can be orders of magnitude faster than Commit.
>
> - Internally you should always use RevTree and TreeWalk to locate
> blob IDs. Its orders of magnitude faster than Tree and TreeEntry.
>
> - Don't use new String(loader.getBytes()) (e.g. in Origin.getData)
> to get the data for a file. We want to do raw diffs, so that the
> character encoding is considered as part of the blame. E.g. if
> a file switches character encodings, the blame has to go to the
> commit that introduced the new encoding. This is a huge reason
> to use byte[] and IntList over an array of String.
>
> - RawParseUtils.lineMap will be faster than a Pattern of "^(.*)$".
>
Thanks for the comments. This first version was basically just a
proof-of-concept to see if and how it could work. I didn't want to
pour too much effort into, before knowing if this project was viable
at all. This input is very valuable and I will try to incorporate the
suggestions into future revisions.
I'll keep you posted on new developments
- Manuel
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:21 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <496BB204.2040109@tedpavlic.com>
> (note: for some reason Mercurial's bash completion script does not have
> this problem; they use $1 directly without bash complaining)
It appears like they use
complete -o bashdefault
whereas Git's uses
complete -o default
I think that's the difference.
--
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
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 21:25 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <496BB204.2040109@tedpavlic.com>
* Ted Pavlic [Mon, 12 Jan 2009 16:11:32 -0500]:
>> That looks ugly to me. Any reason we shouldn't just "set +u" at the top of
>> the script?
> As already discussed, because the script must be sourced, then the "set
> +u" has global scope.
> I suppose that the option could be tested and then reset as appropriate
> at the end of the script.
That does not help, because appart from being global, it of course takes
effect at run time. In other words, it doesn't matter if set -u is
active or not at function definition time, but at function invoation
time.
> (note: for some reason Mercurial's bash completion script does not have
> this problem; they use $1 directly without bash complaining)
Because (from a quick look) their completion script never expands a
variable which is not known to be set.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A hacker does for love what other would not do for money.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 21:27 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Ted Pavlic, git
In-Reply-To: <20090112204030.GA23327@chistera.yi.org>
[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]
On Monday 2009 January 12 14:40:30 Adeodato Simó wrote:
>* Boyd Stephen Smith Jr. [Mon, 12 Jan 2009 14:35:35 -0600]:
>> >The attached patch replaces things like
>> >
>> > if [ -z "$1" ]
>> >
>> >with
>> >
>> > if [ -z "${1-}" ]
>>
>> That looks ugly to me. Any reason we shouldn't just "set +u" at the top
>> of the script?
>
>`set +u` affects the shell globally, not just to the sourced file. If
>you do that, you must be aware that you'll be preventing people from
>running their shell in `set -u` mode. (Merely stating a fact here, not
>giving any opinion.)
I'm not familiar with bash completion exception as a user, I didn't realize
all these functions had to be sourced into the current shell.
Well, if the user want to run in "set -u" mode preventing it is bogus, IMO.
We could use subshells and unset at the top of _git and _gitk functions, that
would be only a +6/-4 patch. It would also not be something future
contributors have to think (much) about.
--
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
* [PATCH/RFC] Documentation/git-mailsplit.txt: Emphasize -o more
From: jidanni @ 2009-01-12 21:28 UTC (permalink / raw)
To: git
The need for -o cannot be overstated. Else the arguments get
interpreted differently. We also mention the output.
(By the way, "fatal: unknown option: -o" is seen if a space comes
after it.)
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-mailsplit.txt | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index 5cc94ec..5dc24c9 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -13,10 +13,18 @@ DESCRIPTION
-----------
Splits a mbox file or a Maildir into a list of files: "0001" "0002" .. in the
specified directory so you can process them further from there.
+The number of files produced is printed to the standard output.
IMPORTANT: Maildir splitting relies upon filenames being sorted to output
patches in the correct order.
+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.
+
OPTIONS
-------
<mbox>::
@@ -27,9 +35,6 @@ OPTIONS
Root of the Maildir to split. This directory should contain the cur, tmp
and new subdirectories.
--o<directory>::
- Directory in which to place the individual messages.
-
-b::
If any file doesn't begin with a From line, assume it is a
single mail message instead of signaling error.
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Shawn O. Pearce @ 2009-01-12 21:31 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Adeodato Simó, Ted Pavlic, git
In-Reply-To: <200901121527.21818.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
>
> Well, if the user want to run in "set -u" mode preventing it is bogus, IMO.
> We could use subshells and unset at the top of _git and _gitk functions, that
> would be only a +6/-4 patch. It would also not be something future
> contributors have to think (much) about.
Running in subshells is a bad idea. We'd likely lose access
to the completion word array, and it would take a lot longer per
completion because you need to spin-up and tear-down that subshell.
We have spent some time to make the current completion code use as
few forks as possible to get the results we want, because it runs
faster that way.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Shawn O. Pearce @ 2009-01-12 21:32 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Boyd Stephen Smith Jr., git
In-Reply-To: <496BB442.90107@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> wrote:
>> (note: for some reason Mercurial's bash completion script does not have
>> this problem; they use $1 directly without bash complaining)
>
> 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.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Ted Pavlic @ 2009-01-12 21:37 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <20090112212544.GA24941@chistera.yi.org>
> 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?
In fact, it's $1, $2, $3, and $4 that are causing the problemw ith the
git completions.
--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
* Re: [PATCH] Update bash completions to prevent unbound variable errors.
From: Boyd Stephen Smith Jr. @ 2009-01-12 21:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Adeodato Simó, Ted Pavlic, git
In-Reply-To: <20090112213149.GL10179@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]
On Monday 2009 January 12 15:31:49 Shawn O. Pearce wrote:
>"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
>> Well, if the user want to run in "set -u" mode preventing it is bogus,
>> IMO. We could use subshells and unset at the top of _git and _gitk
>> functions, that would be only a +6/-4 patch. It would also not be
>> something future contributors have to think (much) about.
>
>Running in subshells is a bad idea.
Yeah, not only for all the reasons you mention, but because it would require
refactoring to use -C instead of -F (so we a longer and uglier patch); our
changes to COMPREPLY in the subshell wouldn't be seen by bash.
Having tripped over my lack of experience twice in two messages in this
thread, I'm going to bow out of the rest of it. My ascetic opinion still
stands, but I'll take working code, warts and all, over broken code.
--
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: [PATCH] Update bash completions to prevent unbound variable errors.
From: Adeodato Simó @ 2009-01-12 21:40 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Shawn O. Pearce, git, gitster
In-Reply-To: <496BA0E4.2040607@tedpavlic.com>
* Ted Pavlic [Mon, 12 Jan 2009 14:58:28 -0500]:
I don't know if this patch will go forward or not, but there are several
instances of spurious ${x-}, eg.:
> __gitdir ()
> {
> - if [ -z "$1" ]; then
> + if [ -z "${1-}" ]; then
Given the above...
> - elif [ -d "$1/.git" ]; then
> - echo "$1/.git"
> + elif [ -d "${1-}/.git" ]; then
> + echo "${1-}/.git"
> else
> - echo "$1"
> + echo "${1-}"
... this other hunk is redundant, because if [ -z "${1-}" ] fails, then
$1 is surely set.
> __git_ps1 ()
> {
> local g="$(git rev-parse --git-dir 2>/dev/null)"
> - if [ -n "$g" ]; then
> + if [ -n "${g-}" ]; then
Spurious, $g is always set here.
> @@ -111,8 +111,8 @@ __git_ps1 ()
> - if [ -n "$1" ]; then
> + if [ -n "${1-}" ]; then
This one is okay...
> - printf "$1" "${b##refs/heads/}$r"
> + printf "${1-}" "${b##refs/heads/}$r"
But this one is unnecessary, if [ -n "${1-}" ] succeeds, then $1 is set.
And so on.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott
^ permalink raw reply
* 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
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