* [PATCH] t9500: skip gitweb tests if perl version is too old
From: Sven Verdoolaege @ 2007-06-22 15:49 UTC (permalink / raw)
To: git, Junio C Hamano
gitweb calls Encode::decode_utf8 with two arguments,
but old versions of perl only allow this function to be called
with one argument. Even older versions of perl do not even
have an Encode module.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
t/t9500-gitweb-standalone-no-errors.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 44ae503..d948724 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -60,6 +60,12 @@ gitweb_run () {
. ./test-lib.sh
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+ test_expect_success 'skipping gitweb tests, perl version is too old' :
+ test_done
+ exit
+}
+
gitweb_init
# ----------------------------------------------------------------------
--
1.5.2.2.249.g45fd
^ permalink raw reply related
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-22 15:28 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Linus Torvalds, Jeff King, Shawn O. Pearce, govindsalinas,
gitster
In-Reply-To: <200706221619.30521.andyparkins@gmail.com>
Hi,
On Fri, 22 Jun 2007, Andy Parkins wrote:
> What if two files with different filenames and content converge at some
> point in history, then diverge again? If git is tracking renames merely
> by content and picks the wrong one, then the history of fileA suddenly
> becomes the history of fileB.
This is becoming highly ethereal. Like "I could imagine that some day in
future, some person could devise a device, that might allow you to do
something that I can not explain, because I have not even thought of it".
IOW show me a reasonable example, and we'll talk business.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Andy Parkins @ 2007-06-22 15:19 UTC (permalink / raw)
To: git
Cc: Linus Torvalds, Jeff King, Johannes Schindelin, Shawn O. Pearce,
govindsalinas, gitster
In-Reply-To: <alpine.LFD.0.98.0706210910390.3593@woody.linux-foundation.org>
On Thursday 2007 June 21, Linus Torvalds wrote:
> The files are *identical* for christ sake! Following their history, it
> doesn't matter *which* base you follow, since regardless, they've come to
> the same point!
>
> So in that sense, the current git behaviour is actually perfectly fine.
Perhaps not. (Please don't read this as meaning I disagree with your
favour-the-identical-filename patch at all - in fact I think that would
address the case I give below).
What if two files with different filenames and content converge at some point
in history, then diverge again? If git is tracking renames merely by content
and picks the wrong one, then the history of fileA suddenly becomes the
history of fileB.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Failure in t5516, tests 15 and 16
From: Brian Gernhardt @ 2007-06-22 14:50 UTC (permalink / raw)
To: Git Mailing List
Tests 15 and 16 in script "t5516-fetch-push.sh" fails with "notice:
HEAD points to an unborn branch (master)". Is this just bad tests or
an actual failure? This is with current master
(45fd8bd32dd68ce6b14a406d0abbd6f56490131c) on OS X.
Detailed test results follow.
~~ Brian
----- 8< -----
* expecting success:
mk_test &&
if git show-ref --verify -q refs/tags/frotz
then
git tag -d frotz
fi &&
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
Initialized empty Git repository in .git/
notice: HEAD points to an unborn branch (master)
notice: No default references
Deleted tag frotz.
updating 'refs/heads/frotz'
from 0000000000000000000000000000000000000000
to 9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
Generating pack...
Done counting 5 objects.
Deltifying 5 objects...
100% (5/5) done
Writing 5 objects...
100% (5/5) done
Total 5 (delta 0), reused 0 (delta 0)
Unpacking 5 objects...
100% (5/5) done
refs/heads/frotz: 0000000000000000000000000000000000000000 ->
9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
notice: HEAD points to an unborn branch (master)
* FAIL 15: push with colon-less refspec (3)
mk_test &&
if git show-ref --verify -q refs/tags/frotz
then
git tag -d frotz
fi &&
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
* expecting success:
mk_test &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
Initialized empty Git repository in .git/
notice: HEAD points to an unborn branch (master)
notice: No default references
Deleted branch frotz.
updating 'refs/tags/frotz'
from 0000000000000000000000000000000000000000
to 9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
Generating pack...
Done counting 5 objects.
Deltifying 5 objects...
100% (5/5) done
Writing 5 objects...
100% (5/5) done
Total 5 (delta 0), reused 0 (delta 0)
Unpacking 5 objects...
100% (5/5) done
refs/tags/frotz: 0000000000000000000000000000000000000000 ->
9ad36e1e54b2130a20d55abb4f0f3ca8494ead3f
notice: HEAD points to an unborn branch (master)
* FAIL 16: push with colon-less refspec (4)
mk_test &&
if git show-ref --verify -q refs/heads/frotz
then
git branch -D frotz
fi &&
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
test "$( cd testrepo && git show-ref | wc -l )" = 1
* failed 2 among 16 test(s)
^ permalink raw reply
* Re: problem pushing repository
From: Adam Mercer @ 2007-06-22 14:32 UTC (permalink / raw)
To: Raimund Bauer; +Cc: git
In-Reply-To: <1182521850.6207.42.camel@localhost>
On 22/06/07, Raimund Bauer <ray007@gmx.net> wrote:
> In my config it looks like this:
>
> [remote "slcom"]
> uploadpack = /usr/local/bin/git-upload-pack
> receivepack = /usr/local/bin/git-receive-pack
putting
[remote "glue"]
uploadpack = /home/ram/opt/git/bin/git-upload-pack
receivepack = /home/ram/opt/git/bin/git-receive-pack
in my .gitconfig I still get the error saying that git-receive-pack
can't be found. If I specify the path on the git push command line
using the --exec option then git-receive-pack is found, so it appears
that my config file isn't being read.
Cheers
Adam
^ permalink raw reply
* Re: problem pushing repository
From: Raimund Bauer @ 2007-06-22 14:17 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <799406d60706220636q4f7a3c17v6833d2eda25e8f0d@mail.gmail.com>
On Fri, 2007-06-22 at 09:36 -0400, Adam Mercer wrote:
> This seems like the best way to fix this issue, however it isn't clear
> >from the man page what I need to put in my ~/.gitconfig. With the
> following in .gitconfig
>
> [remote]
> glue.receivepack = /home/ram/opt/git/bin/git-receive-pack
In my config it looks like this:
[remote "slcom"]
uploadpack = /usr/local/bin/git-upload-pack
receivepack = /usr/local/bin/git-receive-pack
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Catalin Marinas @ 2007-06-22 14:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <20070622032502.GA17393@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Here's the problem though: `git-blame -w` will be supported
> in Git 1.5.3 and later, we all know this. But Git doesn't.
> Ask git-describe what version `master` and `next` are; its
> v1.5.2.2-249 and v1.5.2.2-1050.
[...]
> Maybe I should ask the StGIT folks how they deal with this, or if
> they just don't worry about it. I'm suspecting its the latter...
We don't worry much about it. We actually try to be compatible with
some older versions and not use much of the new features in GIT (StGIT
uses a small subset anyway - see stgit/git.py).
--
Catalin
^ permalink raw reply
* Re: problem pushing repository
From: Raimund Bauer @ 2007-06-22 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andrew Ruder, git
In-Reply-To: <Pine.LNX.4.64.0706221224310.4059@racer.site>
Hi,
On Fri, 2007-06-22 at 12:26 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 22 Jun 2007, Raimund Bauer wrote:
>
> > $ git push slcom test:test
> > error: dst refspec test does not match any existing ref on the remote
> > and does not start with refs/.
> > fatal: The remote end hung up unexpectedly
> > error: failed to push to
> > 'ray@softwarelandschaft.com:/home/ray/repos/drupal/multirate'
>
> This is a completely unrelated problem!
>
> It says that there is no branch named "test" on the remote side, and since
> you could also want to push a tag, you have to say
>
> test:refs/heads/test
>
> here. However, I do not understand why you bother to use the :dst syntax
> here, since your target name is _exactly_ the same as the source name. Why
> not just
>
> git push slcom test
because I had gotten the command line from bash-completion and since it
worked with existing branches I saw no reason why it shouldn't work with
new ones.
will read the documentation next time ;-)
> Ciao,
> Dscho
--
best regards
Ray
^ permalink raw reply
* Re: problem pushing repository
From: Adam Mercer @ 2007-06-22 13:36 UTC (permalink / raw)
To: git
In-Reply-To: <20070622022426.GA2961@bowser.ruder>
On 21/06/07, Andrew Ruder <andy@aeruder.net> wrote:
> On Thu, Jun 21, 2007 at 07:00:18PM -0700, Junio C Hamano wrote:
> > $ ssh newberry.ihepa.ufl.edu sh -c 'echo $PATH'
> >
> > may be a good starting point to test this, and the first step
> > to fix it would be
> >
> > $ man ssh
> > $ man sshd
>
> While I wholeheartedly agree with Junio here, you may also find
>
> remote.<name>.receivepack
>
> useful, see git-push(1) and git-config(1) for more information.
This seems like the best way to fix this issue, however it isn't clear
from the man page what I need to put in my ~/.gitconfig. With the
following in .gitconfig
[remote]
glue.receivepack = /home/ram/opt/git/bin/git-receive-pack
I get the following error when trying to push
[ram@skymoo glue]$ git push
ssh://newberry.ihepa.ufl.edu/~/public_html/git/glue.git
fatal: bad config file line 6 in /Users/ram/.gitconfig
so this is clearly not the right entry. Can someone please give me a
push in the right direction?
Cheers
Adam
^ permalink raw reply
* Re: problem pushing repository
From: Adam Mercer @ 2007-06-22 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xacbvf1.fsf@assigned-by-dhcp.pobox.com>
On 21/06/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Adam Mercer" <ramercer@gmail.com> writes:
>
> > [ram@skymoo glue]$ git push
> > ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git
> > bash: line 1: git-receive-pack: command not found
> > fatal: The remote end hung up unexpectedly
> > error: failed to push to
> > 'ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git'
> > [ram@skymoo glue]$ which git-receive-pack
> > /Users/ram/opt/git/bin/git-receive-pack
> > [ram@skymoo glue]$
> >
> > git-receive-pack is in my $PATH so why can't it be found when trying to push?
>
> Check your ssh and ssh server settings. Often the process
> invoked from non-interactive ssh connection (such as the attempt
> to invoke receive-pack) would not get the PATH you set up in ~/.login
> or ~/.bash_profile.
>
> $ ssh newberry.ihepa.ufl.edu sh -c 'echo $PATH'
>
> may be a good starting point to test this, and the first step
> to fix it would be
>
> $ man ssh
> $ man sshd
Thanks Junio thats the problem my path isn't being set correctly on newberry
[ram@skymoo ram]$ ssh newberry sh -c 'echo $PATH'
[ram@skymoo ram]$ ssh newberry
[ram@newberry ram]$ which git-receive-pack
~/opt/git/bin/git-receive-pack
[ram@newberry ram]$
Cheers
Adam
^ permalink raw reply
* Re: 100% (was: [PATCH] diffcore-rename: favour identical basenames)
From: Johannes Schindelin @ 2007-06-22 12:49 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ps3oi7ma.fsf_-_@lola.quinscape.zz>
Hi,
On Fri, 22 Jun 2007, David Kastrup wrote:
> As a note aside: would it be possible to always round downwards when
> computing similarities or converting between them?
I'd rather not. This would be counterintuitive. People expect rounded
values.
> I very much would like to see the 100% figure reserved for identity.
> This is particularly relevant when interpreting the output of git-diff
> --name-status with regard to R100, C100 and similar flags.
You should never depend on the output of --name-status if you're
interested in identifying identical files, but on the object names.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] config: Add --null/-z option for null-delimted output
From: Frank Lichtenheld @ 2007-06-22 12:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <200706220156.01175.jnareb@gmail.com>
On Fri, Jun 22, 2007 at 01:56:00AM +0200, Jakub Narebski wrote:
> On Mon, 18 Jun 2007, Frank Lichtenheld wrote:
> > Note the FIXME. Does anyone remember the reason why --get-regexp
> > and --list use different output format?
>
> I don't know, but at least two scripts use --get-regexp, namely
> git-remote and git-submodule. So we would have to be careful about
> changing that.
>
>
> I would be enough to add the following to your patch:
Yeah, I found this a but ugly though so I left it out of the first
patch in case someone had a better idea. Will include that in the
second version (which will also include documentation).
> By the way, I have tried to use git-config --null to redo config
> file parsing in gitweb, so one git-config call would be needed for
> all the config. I have noticed that --bool option description does
> not describe the observed behavior fully. For example it returns
> 'true' not only for '1', but for any integer != 0, including 0xdeadbeef.
Yeah, the description of --bool is very incomplete. Note that empty
values are false, and keys without values are true. I think this all
are valid choices, but they are indeed not documented.
Gruesse.
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* RE: [PATCH] git-svn: allow dcommit to retain local merge information
From: Joakim Tjernlund @ 2007-06-22 11:55 UTC (permalink / raw)
To: 'Steven Grimm', 'Eric Wong'; +Cc: 'Junio C Hamano', git
In-Reply-To: <4670E0A2.9060103@midwinter.com>
> -----Original Message-----
> From: Steven Grimm [mailto:koreth@midwinter.com]
> Sent: den 14 juni 2007 08:31
> To: Eric Wong
> Cc: Junio C Hamano; Joakim Tjernlund; git@vger.kernel.org
> Subject: Re: [PATCH] git-svn: allow dcommit to retain local
> merge information
>
> Eric Wong wrote:
> > Joakim/Steven:
> > Any further testing and test cases would be appreciated. Be very
> > careful with real-world repositories, and run dcommit with the
> > '-n' flag before actually committing to verify the diffs
> are sane.
> >
>
> I poked at this some tonight with an eye toward the use case of using
> git to merge svn branches. I ran into one inconvenience and one bug.
> I'll try playing with the "use lots of git branches to develop on one
> svn branch" use case some too, but for now, here are the
> notes I took,
> along with the commands if anyone wants to reproduce what I did.
> Hopefully this won't be too annoying to read. The bug is near
> the bottom.
>
> svn repo with a trunk and a branch, each with changes (no
> conflicts at
> first, keep it simple to start)
>
> $ svnadmin create svnrepo
> $ svn co file://`pwd`/svnrepo svnclient
> $ cd svnclient
> $ mkdir trunk tags branches
> $ echo test file number 1 > trunk/testfile1
> $ echo test file number 2 > trunk/testfile2
> $ svn add *
> $ svn commit -m "initial commit"
> $ echo trunk change 1 >> trunk/testfile1
> $ svn commit -m "trunk change 1"
> $ echo trunk change 2 >> trunk/testfile2
> $ svn commit -m "trunk change 2"
> $ svn cp trunk branches/mybranch
> $ svn commit -m "make a branch"
> $ echo trunk change 3 >> trunk/testfile1
> $ svn commit -m "post-branch change in trunk"
> $ echo branch change 1 >> branches/mybranch/testfile2
> $ svn commit -m "change in branch"
>
> git-svn clone of this dinky repo
>
> $ cd ..
> $ git-svn clone --trunk=trunk --branches=branches --tags=tags
> file://`pwd`/svnrepo gitclone
> $ cd gitclone
>
> Try to merge trunk change into branch using git
>
> $ git reset --hard mybranch
> $ git merge trunk
>
> Conflicts! what's going on?
>
> $ gitk --all
>
> Aha, looks like git-svn guessed wrong about where I made the
> branch; it
> thinks the branch comes from the initial rev. Easy enough to hack
> around, but might be nice to be able to do this using
> git-svn's history
> rewriting rather than a grafts file.
Yes, that would be nice indeed.
>
> $ echo `git-svn find-rev r4` `git-svn find-rev r3 trunk` >
> .git/info/grafts
> $ git reset --hard mybranch
> $ git merge trunk
>
> No conflicts now. Let's see what git-svn thinks it should do
>
> $ git-svn dcommit -n
>
> Looks like the right diff
>
> $ git-svn dcommit
>
> Refresh gitk display. Looks good, the new revision is a merge
> with the
> right parents. Let's check it out in svn land
>
> $ cd ../svnclient
> $ svn up
> $ cat branches/mybranch/testfile1
>
> Yep, the trunk change is there, nice! Now for a couple more
> revs with a
> conflict.
>
> $ echo post-merge trunk change >> trunk/testfile1
> $ svn commit -m "trunk change after merge"
> $ echo post-merge conflicting change >> trunk/testfile2
> $ svn commit -m "trunk change with conflict"
> $ cd ../gitclone
> $ git-svn fetch
> $ git merge -m "change with conflict" trunk
>
> Conflict, as expected
>
> $ vi testfile2
> $ git add testfile2
> $ git commit
> $ git-svn dcommit
> Transaction is out of date: Out of date: '/trunk/testfile1' in
> transaction '9-1' at /Users/koreth/git/git-svn line 398
Maybe this can help?
http://svn.haxx.se/subusers/archive-2005-02/0096.shtml
http://subclipse.tigris.org/faq.html#out-of-date
>
> Hmm, this merge was in mybranch, not in trunk
>
> $ git log --first-parent
>
> Yes, the most recent commit with a git-svn-id line has a
> mybranch URL.
> So why is it complaining about a trunk file being out of date?
>
> My experimentation pretty much ended there (I tried a few things to
> clear the error up, but none of them helped.)
>
> This machine is an OS X laptop. Subversion is 1.4.3 (r23084) from
> MacPorts. I used the git-svn from the "pu" branch since it had this
> patch and all the recent fixes.
>
> Let me know if you need more details. Hope this is helpful.
>
> -Steve
>
>
^ permalink raw reply
* 100% (was: [PATCH] diffcore-rename: favour identical basenames)
From: David Kastrup @ 2007-06-22 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706221122200.4059@racer.site>
> Footnote:
>
> *1* Actually, it is not _that_ bad. The score is not a value between 0 and
> 100, IOW it is _not_ what you see in the output of "diff -M". It is an
> unsigned short between 0 and MAX_SCORE, which is defined in
> diffcore.h as 60000.0.
>
> The Levenshtein distance between two filenames cannot be larger than
> the sum of their lengths, so it should be relatively safe. That is, if
> you don't have such insanely long paths as e.g. egit. But even there,
> the paths share most of their directories, and therefore the distances
> should be much, much smaller in real life.
As a note aside: would it be possible to always round downwards when
computing similarities or converting between them?
I very much would like to see the 100% figure reserved for identity.
This is particularly relevant when interpreting the output of git-diff
--name-status with regard to R100, C100 and similar flags.
--
David Kastrup
^ permalink raw reply
* parsecvs fails even on simple input
From: Roman Kagan @ 2007-06-22 11:36 UTC (permalink / raw)
To: Keith Packard, Al Viro; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]
One of the patches recently merged into parsecvs master, namely
commit f5b3cb849517adfd7790c1bfa84bbb84220e3e7b
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Tue Jan 16 04:15:35 2007 -0500
[PATCH] generate tree objects just as we calculate changesets
... and don't store the fsckloads of rev_file in ExportGit mode; they
are only needed (for now) in ExportGraph one.
Tree generation is done directly, without hitting on-disk index. Very fast
now.
broke parsecvs entirely. The reproducer (attached) is very simple:
initial commit of a just added file. parsecvs now barfs on it:
# parsecvs a,v
Initialized empty shared Git repository in .git/
Load: a,v ....................* 1 of 1
Pack pack-6b955e2d966143fc957ccd272e9dd822ceaccf25 created
Removing unused objects 81%...
Removing unused objects 100%...
Done.
error: invalid object d0141680ee5324d51a558a0a48c8a867cbc6a47c
error: writing tree
Authors: No such file or directory
Save: master ....................* 1 of 1
The problem is the following: after that commit parsecvs tries to add
objects to the git tree on its own via calls to libgit; however, in
between it runs git-pack-objects. Thus objects move to pack files
without libgit being aware of it; this results in 'ivalid object'
errors.
However, the object with that hash exists but is stored on the pack
file; if parsecvs is run in the same directory for the second time it
finds it there and happily completes.
I haven't yet had the time to dig deeper into this problem and code a
patch; however, the whole idea of doing part of the job through the
(unpublished) libgit API and the rest via callouts to git utilities
looks like calling for trouble. Wouldn't it be better to teach parsecvs
to speak git-fast-import language instead?
Roman.
[-- Attachment #2: a,v --]
[-- Type: text/plain, Size: 188 bytes --]
head 1.1;
access;
symbols;
locks; strict;
comment @# @;
1.1
date 2007.06.21.12.11.32; author tstuser; state Exp;
branches;
next ;
desc
@@
1.1
log
@test commit
@
text
@this is test
@
^ permalink raw reply
* Re: problem pushing repository
From: Johannes Schindelin @ 2007-06-22 11:26 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Andrew Ruder, git
In-Reply-To: <1182496916.6207.11.camel@localhost>
Hi,
On Fri, 22 Jun 2007, Raimund Bauer wrote:
> $ git push slcom test:test
> error: dst refspec test does not match any existing ref on the remote
> and does not start with refs/.
> fatal: The remote end hung up unexpectedly
> error: failed to push to
> 'ray@softwarelandschaft.com:/home/ray/repos/drupal/multirate'
This is a completely unrelated problem!
It says that there is no branch named "test" on the remote side, and since
you could also want to push a tag, you have to say
test:refs/heads/test
here. However, I do not understand why you bother to use the :dst syntax
here, since your target name is _exactly_ the same as the source name. Why
not just
git push slcom test
Hm??
> git-remote also has a problem:
> $ git remote show slcom
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
> ls-remote --heads
> ray@softwarelandschaft.com:/home/ray/repos/drupal/multirate: command
> returned error: 1
That's apparently a bug in git-remote.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC][PATCH] Fix assumption that git is installed in a standard place on the remote end ssh
From: Johannes Schindelin @ 2007-06-22 10:47 UTC (permalink / raw)
To: Kevin Green; +Cc: git
In-Reply-To: <20070622013026.GY14298@menevado.ms.com>
Hi,
On Thu, 21 Jun 2007, Kevin Green wrote:
> On 06/18/07 20:16:47, Johannes Schindelin wrote:
> > Hi,
> >
> > On Fri, 15 Jun 2007, Kevin Green wrote:
> >
> > > I'm thinking I like the env var idea much more though. I can just
> > > export it in my shell and it works in both cases.
> >
> > And it completely breaks down when you have more than one remotes. Or when
> > you cd to another project with another remote. Or etc. IOW it is fragile.
> >
> > Clearly, the config approach is the only one which makes sense. This
> > information is so closely coupled to a specific remote that you should
> > store it right where you store all the other remote information, too.
> >
>
> You're absolutely right. I agree, except that in _my_ environment git
> will be in a non-standard path but *always* consistently in the same
> place. I'm being greedy here. :)
Note that this "solution" will _only_ work for you.
> The config approach is clearly the most versatile. The question I have
> is, is there a good reason not to provide the third option of setting
> env var? I suppose that in the more likely case this could cause more
> harm than good, i.e. maybe this is too specific for my use case.
Since it will _only_ work for you, I think there is more harm done than
good, by including that in mainline git. Just think of somebody seeing
this mentioned in the docs, not reading further properly, and just getting
confused, blaming it on Git.
Instead, we have that wonderful config solution, which is the proper one
anyway, and which does not confuse people, once they found it.
However, Git is all about the freedom to fork and merge. So do the same as
me: keep those changes in your local repo, and do not use mainline Git.
For example, I have this option "-t" to Git, which automatically tries to
give human-readable names to all the 40-character object names, and does
not change colouring. Thus, I can say
git -t log -p whatever.c
to find exactly which commit introduced a certain feature (which I find by
searching the diffs). Then, I only have to copy&paste the nice commit name
into the mail/IRC where I am responding to, and be done.
This feature was not liked on the list, so it remains in my local fork
forever (though it is also stored in the mail archives).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-22 10:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <467B777D.C47BFE0E@eudaptics.com>
Hi,
On Fri, 22 Jun 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > The dangerous thing is that the score can get negative now.
> > ...
> > + score = (int)(src_copied * MAX_SCORE / max_size)
> > + - levenshtein(src->path, dst->path);
>
> Does that also mean that you can't ever have a rename with a score of
> 100%?
>
> (I haven't studied the algorithms and assume that levenshtein(a,b) == 0
> only if a==b, and that without the -levenshtein(...) the score can grow
> to 100%.)
There is a different code path for identical contents. So yes, you can
still hit 100%, but it is now much, much harder to hit a score close to
100% [*1*].
The obviously correct way to do this is to have a subscore, and use it
_strictly_ only when the score is identical.
I see two ways to do this properly:
- introduce a name_distance struct member, just below the score. This
means that estimate_similarity has to "return" two values instead of
one, and score_compare gets a bit more complex, too. Or
- change the score to unsigned long, and shift the score to higher bits,
adding a constant minus the Levenshtein distance. It is safe to assume
that the filenames are shorter than 16384 bytes (PATH_MAX is actually
much smaller than that), and even if two filenames of that length are
completely different, the distance can not be larger than twice that
number, i.e. 16384 deletions + 16384 insertions. Therefore, you could
pick 32768 as that constant.
However, I find both solutions ugly. Besides, I am not interested in the
feature myself, only the implementation of Levenshtein was interesting,
and I thought I just post the code here. So I did only the minimal stuff
on top of the interesting one to make it sort of work.
If somebody wants to pick up the ball, be my guest, because I am out of
that game.
Ciao,
Dscho
Footnote:
*1* Actually, it is not _that_ bad. The score is not a value between 0 and
100, IOW it is _not_ what you see in the output of "diff -M". It is an
unsigned short between 0 and MAX_SCORE, which is defined in
diffcore.h as 60000.0.
The Levenshtein distance between two filenames cannot be larger than
the sum of their lengths, so it should be relatively safe. That is, if
you don't have such insanely long paths as e.g. egit. But even there,
the paths share most of their directories, and therefore the distances
should be much, much smaller in real life.
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Schindelin @ 2007-06-22 10:22 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <20070622054142.GA7699@coredump.intra.peff.net>
Hi,
On Fri, 22 Jun 2007, Jeff King wrote:
> On Fri, Jun 22, 2007 at 02:14:43AM +0100, Johannes Schindelin wrote:
>
> > @@ -313,20 +297,24 @@ void diffcore_rename(struct diff_options *options)
> > if (rename_dst[i].pair)
> > continue; /* dealt with an earlier round */
> > for (j = 0; j < rename_src_nr; j++) {
> > - int k;
> > + int k, distance;
> > struct diff_filespec *one = rename_src[j].one;
> > if (!is_exact_match(one, two, contents_too))
> > continue;
> >
> > + distance = levenshtein(one->path, two->path);
> > /* see if there is a basename match, too */
> > for (k = j; k < rename_src_nr; k++) {
>
> This loop can start at k = j+1, since otherwise we are just checking
> rename_src[j] against itself.
Right.
> > +int levenshtein(const char *string1, const char *string2)
> > +{
> > + int len1 = strlen(string1), len2 = strlen(string2);
> > + int *row1 = xmalloc(sizeof(int) * (len2 + 1));
> > + int *row2 = xmalloc(sizeof(int) * (len2 + 1));
> > + int i, j;
> > +
> > + for (j = 1; j <= len2; j++)
> > + row1[j] = j;
>
> This loop must start at j=0, not j=1; otherwise you have an undefined
> value in row1[0], which gets read when setting row2[1], and you get
> a totally meaningless distance (I got -1209667248 on my test case!).
Sorry for that. I originally had an xcalloc in there, and did not look at
that loop afterwards.
And I completely forgot that on my laptop (on which I did this patch), I
had forgotten to add
ALL_CFLAGS += -DXMALLOC_POISON=1
to config.mak.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make list of features auto-managed.
From: Josef Weidendorfer @ 2007-06-22 9:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20070622043329.GE17393@spearce.org>
On Friday 22 June 2007, Shawn O. Pearce wrote:
> > Now you say that you don't want to wait for the release to happen before
> > using this cool new feature. Well, I'd reply that life is tough.
>
> In comparsion to other things we all must deal with in life, this
> is a cakewalk. ;-) But yes, your point is well made.
Hmm... Perhaps I am missing something.
IMHO this discussion is about how to cope with different versions of two
programs depending on each other, but being released in a loosely coupled way
(this is a problem Xorg now has with their independent releases of Xorg modules).
However, git-gui is released together with git (also in the foreseeable
future, even if we use submodules some day).
And therefore, a git user always will get installations of matching versions
of git and git-gui; this is even true for developers who run "make install"
in git source.
So IMHO there is no version check needed at all in this case. Anybody who
is installing git in strange partial ways should expect to be screwed.
Josef
^ permalink raw reply
* [RESEND][PATCH] git-svn: honor ~/.subversion/ client cert file settings.
From: Michael Krelin @ 2007-06-22 9:15 UTC (permalink / raw)
To: git; +Cc: Michael Krelin
Currently, whenever svn repository http server requests client
certificate, prompt provider is invoked, ignoring any
ssl-client-cert-file settings in ~/.subversion/servers. Moreover, it
happens more than once per session, which is quite irritating.
Signed-off-by: Michael Krelin <hacker@klever.net>
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..9dfea97 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2925,6 +2925,7 @@ sub new {
SVN::Client::get_ssl_server_trust_file_provider(),
SVN::Client::get_simple_prompt_provider(
\&Git::SVN::Prompt::simple, 2),
+ SVN::Client::get_ssl_client_cert_file_provider(),
SVN::Client::get_ssl_client_cert_prompt_provider(
\&Git::SVN::Prompt::ssl_client_cert, 2),
SVN::Client::get_ssl_client_cert_pw_prompt_provider(
--
1.5.2.2
^ permalink raw reply related
* Re: [RFC PATCH 2/2] Teach git-blame --gui how to start git-gui blame
From: Johannes Sixt @ 2007-06-22 8:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vps3oa7kf.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano wrote:
>
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> This is only minor nuisance, but can we do something about this?
> >>
> >> $ git gui --version
> >> Application initialization failed: no display name and no $DISPLAY environment variable
> >>
> >> I know it is from wish, not you, so I wouldn't insist, though.
> >
> > Actually that should be fixable.
> >
> > Should be as simple as using a Bourne shell script up front to
> > check for "z$1" = zversion || "z$1" = z--version, and if so dump
> > back the version, otherwise exec wish. This is actually quite easy
> > and won't change things for existing users. I'll put a patch into
> > maint tonight for it.
>
> If this makes life any harder to people on Windows, especially
> minGW, I would suggest against it.
The MinGW port's exec wrapper looks at the shbang line and runs the
shell. Hence, invocation as
git gui --version
will work even from CMD.EXE. But
git-gui --version
will only work from MSYS's rxvt.
-- Hannes
^ permalink raw reply
* Re: problem pushing repository
From: Johannes Sixt @ 2007-06-22 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <799406d60706211849h6e4fd1dbn487beab03fe1d79c@mail.gmail.com>
Adam Mercer wrote:
> [ram@skymoo glue]$ git push
> ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git
> bash: line 1: git-receive-pack: command not found
> fatal: The remote end hung up unexpectedly
> error: failed to push to
> 'ssh://ram@newberry.ihepa.ufl.edu/~ram/public_html/git/glue.git'
> [ram@skymoo glue]$ which git-receive-pack
> /Users/ram/opt/git/bin/git-receive-pack
> [ram@skymoo glue]$
>
> git-receive-pack is in my $PATH so why can't it be found when trying to push?
You must have git installed on the remote end, too.
-- Hannes
^ permalink raw reply
* Re: problem pushing repository
From: Raimund Bauer @ 2007-06-22 7:21 UTC (permalink / raw)
To: Andrew Ruder; +Cc: git
In-Reply-To: <20070622022426.GA2961@bowser.ruder>
On Thu, 2007-06-21 at 21:24 -0500, Andrew Ruder wrote:
> On Thu, Jun 21, 2007 at 07:00:18PM -0700, Junio C Hamano wrote:
> > $ ssh newberry.ihepa.ufl.edu sh -c 'echo $PATH'
> >
> > may be a good starting point to test this, and the first step
> > to fix it would be
> >
> > $ man ssh
> > $ man sshd
>
> While I wholeheartedly agree with Junio here, you may also find
>
> remote.<name>.receivepack
Yes, but it doesn't always work.
I have a server with several repositories, and git is installed
in /usr/local/bin.
All my local repostories know this server as a remote named 'slcom' and
I have a 2 global options
remote.slcom.uploadpack=/usr/local/bin/git-upload-pack
remote.slcom.receivepack=/usr/local/bin/git-receive-pack
Fetching, pulling and normal pushing works.
Pushing a new branch to the remote doesn't work:
$ git branch test
$ git push slcom test:test
error: dst refspec test does not match any existing ref on the remote
and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to
'ray@softwarelandschaft.com:/home/ray/repos/drupal/multirate'
git-remote also has a problem:
$ git remote show slcom
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
ls-remote --heads
ray@softwarelandschaft.com:/home/ray/repos/drupal/multirate: command
returned error: 1
All this with git from yesterday (next).
> - Andy
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Johannes Sixt @ 2007-06-22 7:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706220214250.4059@racer.site>
Johannes Schindelin wrote:
> The dangerous thing is that the score can get negative now.
> ...
> + score = (int)(src_copied * MAX_SCORE / max_size)
> + - levenshtein(src->path, dst->path);
Does that also mean that you can't ever have a rename with a score of
100%?
(I haven't studied the algorithms and assume that levenshtein(a,b) == 0
only if a==b, and that without the -levenshtein(...) the score can grow
to 100%.)
-- Hannes
^ 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