* Re: Few Questions
From: Matthieu Moy @ 2009-01-20 11:04 UTC (permalink / raw)
To: m.arya; +Cc: git
In-Reply-To: <726600.29783.qm@web35708.mail.mud.yahoo.com>
"Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> Hi,
>
> I am new to Git. Earlier I have configured svn with LDAP auth and svnwebclient.
>
> I want to have following with Git
>
> - LDAP and ssh authentication.
AFAIK, there isn't any authentication mechanism built into Git.
Instead, Git relies on existing (proven, reliable, ...) mechanisms.
SSH authentication is what you get when accessing a repository with
e.g. git clone ssh://host.com/path/to/repo (either you have a full
ssh shell access on the server, or you can restrict the access with
git-shell to allow only basic git operations on the server).
There's probably a way to let your server use LDAP for authentication
when using SSH, but that's independant from Git (and I'm helpless
here).
> - checkin and checkout using web interface and ssh
Gitweb for the web interface. "checkin" and "checkout" have different
meanings depending on the tool, so I'm not sure I understand the
question correctly.
In Git, the equivalent of "checkout" for centralized VCS would be
"clone" (i.e. get a local working tree for a remote repository, but
Git also duplicates the history), see above, it works straigtforwardly
through SSH. I don't think you can do it from a web interface, but I
don't understand what would be the point in doing it.
> - when ever someone checkin something then a email should be send to
> a email address (a mailing list)
With a hook. You probably don't want to have this as the commit hook,
since the advantage of Git is to make "commit" a local, somehow
private operation, and to distinguish it from "push" (which somehow
means "publish", "show to the rest of the world"). So sending email
when some server receives the new revisions is sensible, this is the
post-receive hook.
These can help:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/hooks/post-receive-email;h=28a3c0e46ecf9951f3f42a025a288a65c70e0424;hb=HEAD
http://source.winehq.org/git/tools.git/?a=blob;f=git-notify;hb=HEAD
--
Matthieu
^ permalink raw reply
* [PATCH] tutorial-2: Update with the new "git commit" ouput
From: Santi Béjar @ 2009-01-20 11:29 UTC (permalink / raw)
To: git
Commit
c5ee71f (commit: more compact summary and without extra quotes, 2009-01-19)
changed the "git commit" output when creating a commit.
This patch updates the example session in the tutorial.
Signed-off-by: Santi Béjar <santi@agolina.net>
---
Documentation/gittutorial-2.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index a057b50..dc8fc3a 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -32,12 +32,12 @@ Initialized empty Git repository in .git/
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
-[master (root-commit)] created 54196cc: "initial commit"
+[master (root-commit) 54196cc] initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
-[master] created c4d59f3: "add emphasis"
+[master c4d59f3] add emphasis
1 files changed, 1 insertions(+), 1 deletions(-)
------------------------------------------------
--
1.6.1.258.g7ff14
^ permalink raw reply related
* Re: how to track multiple upstreams in one repository
From: Miklos Vajna @ 2009-01-20 12:03 UTC (permalink / raw)
To: Ciprian Dorin, Craciun; +Cc: Greg KH, david, Bryan Donlan, git
In-Reply-To: <8e04b5820901192329pf44431coce4423e6a8d43198@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Tue, Jan 20, 2009 at 09:29:13AM +0200, "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
> :) This is something that escaped me... Could you give me the
> exact git url for this repository? (on kernel.org I'm not able to find
> it, just the current one...)
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
Have you tried this one?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-20 13:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120044447.GF30714@sigill.intra.peff.net>
Hi,
On Mon, 19 Jan 2009, Jeff King wrote:
> One of the things I didn't like about it was that the valgrind wrapper
> directory was created in the Makefile.
I agree.
> I think creating it inside the trash directory for each test run that
> wants to use valgrind makes more sense (probably as .git/valgrind, which
> is unlikely to hurt anything but will stay out of the way of most of the
> tests).
Here I disagree. But I think that test-lib.sh should create it on-demand,
and it should traverse all executables in all paths listed in $PATH,
replacing the ones that start with "git-" ("git" itself should be the
first one) that are no scripts by symlinks to the valgrind script (which
should therefore live in t/), and those that _are_ scripts by symlinks to
$GIT_ROOT/$NAME.
I'll work on it.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 14:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <49758367.7040706@viscovery.net>
On Tue, Jan 20, 2009 at 08:55:19AM +0100, Johannes Sixt wrote:
> > - the test needs a few tweaks to be portable to Windows
>
> While this is true, the workaround I have in my tree is so ugly that its
> discussion would hold back this series unnecessarily. So, please don't
> wait for the fixup of the test.
My goal was to just accept multiple exit codes in the test. I'll cc you
when I send out the new one, and you can comment.
-Peff
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 14:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201447290.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 02:51:49PM +0100, Johannes Schindelin wrote:
> > I think creating it inside the trash directory for each test run that
> > wants to use valgrind makes more sense (probably as .git/valgrind, which
> > is unlikely to hurt anything but will stay out of the way of most of the
> > tests).
>
> Here I disagree. But I think that test-lib.sh should create it on-demand,
> and it should traverse all executables in all paths listed in $PATH,
> replacing the ones that start with "git-" ("git" itself should be the
> first one) that are no scripts by symlinks to the valgrind script (which
> should therefore live in t/), and those that _are_ scripts by symlinks to
> $GIT_ROOT/$NAME.
How will you deal with race conditions between two simultaneously
running scripts? I.e., where are you going to put it?
> I'll work on it.
Great.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Jeff King @ 2009-01-20 14:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <alpine.DEB.1.00.0901201133280.3586@pacific.mpi-cbg.de>
On Tue, Jan 20, 2009 at 11:36:08AM +0100, Johannes Schindelin wrote:
> > > Of course. But the problem is that rev-list is _already_ contaminated
> > > by --pretty=format:%Cred. Or do you mean, you really want rev-list to
> > > unconditionally output color in such a case?
> >
> > No, rev-list is not contaminated with UI color options. %Cred _always_
> > outputs the color, even when the user turned off color explicitely,
> > using --no-color.
>
> BTW I would find it very logical for rev-list not to output any color at
> all when %C(yellow) is specified, as your code respects the diff UI
> options, which are implicitly turned off for rev-list (as rev-list is no
> UI), just like the coloring of "commit <name>" is implicitly turned off
> for rev-list.
Now I'm confused. Should color in --pretty=format always be on, or
should it respect color settings? You seem to be advocating both sides
in the two paragraphs.
The behavior I would propose it along the lines of:
- plumbing _always_ has color off
- porcelain respects color.* config, --color, etc
-Peff
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Jakub Narebski @ 2009-01-20 14:38 UTC (permalink / raw)
To: git
In-Reply-To: <200901192145.21115.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. wrote:
> Nawiązania: 1 2 3
> When diff is invoked with --color-words (w/o =regex), use the regular
> expression the user has configured as diff.color-words.
>
> diff drivers configured via attributes take precedence over the
> diff.color-words setting. If the user wants to change them, they have
> their own configuration variables.
Just a nit: all other configuration variables use camelCase or runwords;
this would be first configuration variable with '-' as words separator,
I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-20 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120141932.GB10688@sigill.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 02:51:49PM +0100, Johannes Schindelin wrote:
>
> > > I think creating it inside the trash directory for each test run
> > > that wants to use valgrind makes more sense (probably as
> > > .git/valgrind, which is unlikely to hurt anything but will stay out
> > > of the way of most of the tests).
> >
> > Here I disagree. But I think that test-lib.sh should create it
> > on-demand, and it should traverse all executables in all paths listed
> > in $PATH, replacing the ones that start with "git-" ("git" itself
> > should be the first one) that are no scripts by symlinks to the
> > valgrind script (which should therefore live in t/), and those that
> > _are_ scripts by symlinks to $GIT_ROOT/$NAME.
>
> How will you deal with race conditions between two simultaneously
> running scripts? I.e., where are you going to put it?
There are no race conditions, as for every git executable, a symbolic link
is created, pointing to the valgrind.sh script [*1*].
Besides, what with valgrind being a memory hog, you'd be nuts to call
valgrinded scripts simultaneously.
Ciao,
Dscho
[*1*] Before anybody complains about symbolic links not being available on
Windows, or $GIT_SHELL not being heeded by the valgrind.sh script: get
valgrind to compile on those platforms, and _then_ we'll talk again.
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Johannes Schindelin @ 2009-01-20 14:58 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <20090120142301.GC10688@sigill.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 11:36:08AM +0100, Johannes Schindelin wrote:
>
> > > > Of course. But the problem is that rev-list is _already_ contaminated
> > > > by --pretty=format:%Cred. Or do you mean, you really want rev-list to
> > > > unconditionally output color in such a case?
> > >
> > > No, rev-list is not contaminated with UI color options. %Cred _always_
> > > outputs the color, even when the user turned off color explicitely,
> > > using --no-color.
> >
> > BTW I would find it very logical for rev-list not to output any color at
> > all when %C(yellow) is specified, as your code respects the diff UI
> > options, which are implicitly turned off for rev-list (as rev-list is no
> > UI), just like the coloring of "commit <name>" is implicitly turned off
> > for rev-list.
>
> Now I'm confused. Should color in --pretty=format always be on, or
> should it respect color settings? You seem to be advocating both sides
> in the two paragraphs.
No, I am just very bad at relating my thoughts.
What I tried to say is "plumbing does not, and should not, change behavior
depending on diff.color".
With %Cred, I was just lazy, and did not make a check if diff.color is
true, which I regret now.
But then, its behavior still does not depend on diff.color when using
plumbing.
It does not even depend on it when using porcelain :-)
> The behavior I would propose it along the lines of:
>
> - plumbing _always_ has color off
>
> - porcelain respects color.* config, --color, etc
Right, that'd be the sane behavior, even for %Cred.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-20 15:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201545570.5159@intel-tinevez-2-302>
This patch adds the ability to use valgrind's memcheck tool to
diagnose memory problems in git while running the test scripts. It
works by placing a "fake" git in the front of the test script's PATH;
this fake git runs the real git under valgrind. It also points the
exec-path such that any stand-alone dashed git programs are run using
the same script. In this way we avoid having to modify the actual git
code in any way.
To be certain that every call to any git executable is intercepted,
the PATH is searched for executables beginning with "git-"; Scripts
are excluded however.
Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the
make invocation. Any invocation of git that finds any errors under
valgrind will exit with failure code 126. Any valgrind output will go
to the usual stderr channel for tests (i.e., /dev/null, unless -v has
been specified).
If you need to pass options to valgrind -- you might want to run
another tool than memcheck, for example -- you can set the environment
variable GIT_VALGRIND_OPTIONS.
A few default suppressions are included, since libz seems to
trigger quite a few false positives. We'll assume that libz
works and that we can ignore any errors which are reported
there.
Initial patch and all the hard work by Jeff King.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
AFAIR libz reserves only aligned memory, and does all operations
in an aligned manner, but it is safe (even if it accesses
uninitialized memory, it does not use the results anyway).
t/test-lib.sh | 39 +++++++++++++++++++++++++++++++++++++--
t/valgrind/.gitignore | 2 ++
t/valgrind/default.supp | 21 +++++++++++++++++++++
t/valgrind/valgrind.sh | 12 ++++++++++++
4 files changed, 72 insertions(+), 2 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 41d5a59..1daae9b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -94,6 +94,8 @@ do
--no-python)
# noop now...
shift ;;
+ --va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
+ valgrind=t; shift ;;
*)
break ;;
esac
@@ -467,8 +469,41 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-PATH=$TEST_DIRECTORY/..:$PATH
-GIT_EXEC_PATH=$(pwd)/..
+if test -z "$valgrind"
+then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+else
+ # override all git executables in PATH and TEST_DIRECTORY/..
+ GIT_VALGRIND=$TEST_DIRECTORY/valgrind
+ mkdir -p "$GIT_VALGRIND"
+ OLDIFS=$IFS
+ IFS=:
+ for path in $PATH:$TEST_DIRECTORY/..
+ do
+ ls "$TEST_DIRECTORY"/../git "$path"/git-* 2> /dev/null |
+ while read file
+ do
+ # handle only executables
+ test -x "$file" || continue
+
+ base=$(basename "$file")
+ test ! -h "$GIT_VALGRIND"/"$base" || continue
+
+ if test "#!" = "$(head -c 2 < "$file")"
+ then
+ # do not override scripts
+ ln -s ../../"$base" "$GIT_VALGRIND"/"$base"
+ else
+ ln -s valgrind.sh "$GIT_VALGRIND"/"$base"
+ fi
+ done
+ done
+ IFS=$OLDIFS
+ PATH=$GIT_VALGRIND:$PATH
+ GIT_EXEC_PATH=$GIT_VALGRIND
+ export GIT_VALGRIND
+fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
GIT_CONFIG_NOSYSTEM=1
diff --git a/t/valgrind/.gitignore b/t/valgrind/.gitignore
new file mode 100644
index 0000000..d781a63
--- /dev/null
+++ b/t/valgrind/.gitignore
@@ -0,0 +1,2 @@
+/git
+/git-*
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
new file mode 100644
index 0000000..2482b3b
--- /dev/null
+++ b/t/valgrind/default.supp
@@ -0,0 +1,21 @@
+{
+ ignore-zlib-errors-cond
+ Memcheck:Cond
+ obj:*libz.so*
+}
+
+{
+ ignore-zlib-errors-value4
+ Memcheck:Value4
+ obj:*libz.so*
+}
+
+{
+ writing-data-from-zlib-triggers-errors
+ Memcheck:Param
+ write(buf)
+ obj:/lib/ld-*.so
+ fun:write_in_full
+ fun:write_buffer
+ fun:write_loose_object
+}
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
new file mode 100755
index 0000000..24f3a4e
--- /dev/null
+++ b/t/valgrind/valgrind.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+base=$(basename "$0")
+
+exec valgrind -q --error-exitcode=126 \
+ --leak-check=no \
+ --suppressions="$GIT_VALGRIND/default.supp" \
+ --gen-suppressions=all \
+ --log-fd=4 \
+ --input-fd=4 \
+ $GIT_VALGRIND_OPTIONS \
+ "$GIT_VALGRIND"/../../"$base" "$@"
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* [PATCH 2/2] valgrind: ignore ldso errors
From: Johannes Schindelin @ 2009-01-20 15:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201602410.5159@intel-tinevez-2-302>
From: Jeff King <peff@peff.net>
On some Linux systems, we get a host of Cond and Addr errors
from calls to dlopen that are caused by nss modules. We
should be able to safely ignore anything happening in
ld-*.so as "not our problem."
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
This is Peff's patch, unchanged.
t/valgrind/default.supp | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
index 2482b3b..1013847 100644
--- a/t/valgrind/default.supp
+++ b/t/valgrind/default.supp
@@ -11,6 +11,18 @@
}
{
+ ignore-ldso-cond
+ Memcheck:Cond
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr8
+ Memcheck:Addr8
+ obj:*ld-*.so
+}
+
+{
writing-data-from-zlib-triggers-errors
Memcheck:Param
write(buf)
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* Re: Few Questions
From: Jakub Narebski @ 2009-01-20 15:44 UTC (permalink / raw)
To: m.arya; +Cc: git
In-Reply-To: <726600.29783.qm@web35708.mail.mud.yahoo.com>
"Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> Hi,
>
> I am new to Git. Earlier I have configured svn with LDAP auth and
> svnwebclient.
>
> I want to have following with Git
>
> - LDAP and ssh authentication.
>
Instead of inventing (and failing) its own protocol and its own
authentication git uses established solutions for authentication: SSH
for "smart" server, and WebDAV for push via (currently only "dumb")
HTTPS protocol.
There exist solutions that help with setting up SSH for git:
git-shell, ssh_acl, and I think most commonly used Gitosis (see
seminal reference about Gitosis on http://git.or.cz/gitwiki/BlogPosts).
> - checkin and checkout using web interface and ssh
>
Git is distributed version control system: checkin (named 'commit' in
git) and checkout are _local_ operations. Fetch (getting new changes
from remote repository) and clone (creating new local repository
following or forking specified remote repository) can be done via
local filesystem, via git:// protocol, via "dumb" HTTP, and via SSH.
Push (sending changes to remote repository) needs autheticated
channel: most common used is SSH, but you can also use WebDAV with
HTTPS.
There are web interfaces for Git, something like SVN::Web or ViewVC,
like gitweb (in Perl, developed in git.git repository) and cgit (in C).
See also "Web interfaces" section on InterfacesFrontendsAndTools page
on git wiki.
> - when ever someone checkin something then a email should be send to
> a email address (a mailing list)
If by 'checkin' you mean publishing changes to a server (i.e. push in
git terminology), see for example contrib/hooks/post-receive-email
hook.
> please let me know how to do this with Git
Please learn that Git is _different_ from Subversion, and not try to
follow your SVN workflow and expectations blindly.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Rename detection: Avoid repeated filespec population
From: Björn Steinbrink @ 2009-01-20 15:59 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
In diffcore_rename, we assume that the blob contents in the filespec
aren't required anymore after estimate_similarity has been called and thus
we free it. But estimate_similarity might return early when the file sizes
differ too much. In that case, cnt_data is never set and the next call to
estimate_similarity will populate the filespec again, eventually rereading
the same blob over and over again.
To fix that, we first get the blob sizes and only when the blob contents
are actually required, and when cnt_data will be set, the full filespec is
populated, once.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
This actually affects the copy detection way more than the pure
rename detection, due to the larger number of candidates, but it's the
same code, and I only realized that when I reran the stuff to get some
numbers to show off. ;-)
Test with linux-2.6.git and hot caches:
git diff-tree -p db30c705758^2..db30c705758
| unpatched | patched
------------------------------
plain | 3s | 3s
-M | 4s | 3s
-C | 2m 25s | 9s
-C -C | 4m 30s | 24s
diffcore-rename.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 168a95b..0b0d6b8 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -153,9 +153,9 @@ static int estimate_similarity(struct diff_filespec *src,
* is a possible size - we really should have a flag to
* say whether the size is valid or not!)
*/
- if (!src->cnt_data && diff_populate_filespec(src, 0))
+ if (!src->cnt_data && diff_populate_filespec(src, 1))
return 0;
- if (!dst->cnt_data && diff_populate_filespec(dst, 0))
+ if (!dst->cnt_data && diff_populate_filespec(dst, 1))
return 0;
max_size = ((src->size > dst->size) ? src->size : dst->size);
@@ -173,6 +173,11 @@ static int estimate_similarity(struct diff_filespec *src,
if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
return 0;
+ if (!src->cnt_data && diff_populate_filespec(src, 0))
+ return 0;
+ if (!dst->cnt_data && diff_populate_filespec(dst, 0))
+ return 0;
+
delta_limit = (unsigned long)
(base_size * (MAX_SCORE-minimum_score) / MAX_SCORE);
if (diffcore_count_changes(src, dst,
--
1.6.1.135.g3cf3b
^ permalink raw reply related
* git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-20 15:46 UTC (permalink / raw)
To: git
Hello all,
Back in June I had done a test convert of our CVS repo using git 1.5.5.1
and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
week to finish!). Recently I wanted to try again with the latest
versions of git and cvs2svn.
When I get to the final stage (running git fast-import to build the
converted repo), I get the following output:
cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
fast-import
fatal: Unsupported command: '.
fast-import: dumping crash report to .git/fast_import_crash_19097
The crash is 18MB and I'd rather not post it, but the only bits that
seem somewhat interesting are:
fast-import crash report:
fast-import process: 19097
parent process : 19095
at Mon Jan 19 11:44:42 2009
fatal: Unsupported command: '.
Most Recent Commands Before Crash
---------------------------------
(...)
reset refs/tags/T_9772
from :1000007127
reset refs/heads/TAG.FIXUP
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
* '.
Has anyone got any ideas how to resolve this?
Thanks,
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere Learn more at
www.mqsoftware.com
^ permalink raw reply
* Re: Few Questions
From: Shawn O. Pearce @ 2009-01-20 16:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: m.arya, git
In-Reply-To: <m3r62yx9qi.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> >
> > I want to have following with Git
> >
> > - LDAP and ssh authentication.
> >
>
> Instead of inventing (and failing) its own protocol and its own
> authentication git uses established solutions for authentication: SSH
> for "smart" server, and WebDAV for push via (currently only "dumb")
> HTTPS protocol.
>
> There exist solutions that help with setting up SSH for git:
> git-shell, ssh_acl, and I think most commonly used Gitosis (see
> seminal reference about Gitosis on http://git.or.cz/gitwiki/BlogPosts).
Yup. Gitosis is very popular for this.
At my last job I rolled my own Gitosis-lite, but in Perl, because
they are a Perl based shop. It also uses the update-paranoid hook
for access controls, as its more flexible (and easier to confuse
the heck out of yourself) than Gitosis. But if you can get along
with Gitosis, its a good choice. Unfortunately its authentication
is limited to public keys registered in the authorized keys file
of the "git" user.
<plug type="not-quite-ready-but-will-be-soon">
Gerrit2 is also likely to enter this "market" soon. I'm trying to
get it production ready and live for one major project before the
end of this month. It embeds its own SSH daemon on a non-standard
port, completely disconnected from the OS authentication. This may
make it slightly more palatable in some enviroments then Gitosis,
as you don't need a huge authorized_keys file, and you don't have
to worry quite so much about attack vectors.
Unlike with Gitosis, public key management is placed on end-users
by using web authentication to identify the user, and letting the
user manage their own "authorized key list". It also has a full
blown web based code review system built in. Which right now a
project must use if it is hosted by Gerrit2. :-)
</plug>
--
Shawn.
^ permalink raw reply
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Kelly F. Hickel @ 2009-01-20 16:04 UTC (permalink / raw)
To: Kelly F. Hickel, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
> Back in June I had done a test convert of our CVS repo using git
> 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well
That's a typo. The June conversion used git 1.5.5.1 and cvs2svn 2.1.1
(not 2.2.0 as previously stated).
Sorry for the confusion.
-Kelly
^ permalink raw reply
* CR codes from git commands
From: Brent Goodrick @ 2009-01-20 16:26 UTC (permalink / raw)
To: git
Hi,
I am considering converting from CVS over to using git. I'm currently
using git version 1.5.6.5 on Debian Linux "testing". One of the first
things I ran into was having to set PAGER to "cat" to avoid the
problems when running git from anything other than a terminal. The
second thing is that "git pull" (and possibly other commands) are
emitting ^M (octal 013) codes on output, possibly caused by the same
assumption as causes the problem that is fixed by setting PAGER to
"cat". This is not a big deal on small repos, but on larger ones I
actually do want to see status line output (or be given some option to
see them), so that I can then run "tail -1lf" on the log file that is
written during a long "git pull" operation.
Is there some configuration option or some environment variable I can
set that tells git to stop treating every invocation as if it is
coming from a terminal?
You can reproduce this on Linux with the following script (look for
the CR codes on the final git pull at the end of the script):
-- cut below this line ---
#!/bin/sh
# I could have simply used "set -x" here but then I wouldn't see the
# redirection syntax like ">file1", so instead use a PrintRun
# function:
PrintRun ()
{
echo "COMMAND: $*"
eval "$*; exitcode=\$?"
if [ $exitcode != 0 ]
then
echo "ERROR: Command failed: $*"
exit 1
fi
}
# Failed attempt at hacking around git insisting on using ^M codes on stderr:
# cat >/tmp/git_pager <<EOF
# sed 's%^% >> %g'
# # This doesn't work either since the output I want to filter is on stderr
# # tr '\013' '\012'
# EOF
# chmod a+x /tmp/git_pager
# GIT_PAGER=/tmp/git_pager; export GIT_PAGER
# Clear out the scratch areas:
PrintRun rm -rf /tmp/git_area1
PrintRun rm -rf /tmp/git_area2
# Populate the initial area:
PrintRun mkdir -p /tmp/git_area1
PrintRun cd /tmp/git_area1
PrintRun git init
PrintRun "echo a new file 1 >file1"
PrintRun "echo a new file 2 >file2"
PrintRun git add file1
PrintRun git add file2
PrintRun git status
PrintRun "git commit -m \"first commit in git_area1\""
PrintRun find .
# Clone from the first area into a second area and add a file there:
PrintRun rm -rf /tmp/git_area2
PrintRun cd /tmp
PrintRun git clone /tmp/git_area1 git_area2
PrintRun cd /tmp/git_area2
PrintRun find .
PrintRun "echo a new file 3 >file3"
PrintRun git add file3
PrintRun git status
PrintRun "git commit -m \"second commit but in git_area2\""
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git status; true" # true means don't fail inside PrintRun
# Now attempt to somehow refresh (what is the "git" word for "cvs update"?) into the first area:
PrintRun cd /tmp/git_area1
PrintRun "git status; true" # true means don't fail inside PrintRun
PrintRun "git diff; true" # true means don't fail inside PrintRun
# PrintRun "git pull /tmp/git_area2 master 2>&1"
# PrintRun "git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012'"
PrintRun git pull /tmp/git_area2 master
-- cut above this line ---
Attempts at hacking around the problem: Redirecting stderr output from
git and then manually translating CR codes into LF codes yeilds the
following output (but I can't do this in practice and, no, I can't use
aliases in Bourne scripts (Bash/KSH yes, Bourne no)):
git> COMMAND: git pull /tmp/git_area2 master 2>&1
git> remote: Counting objects: 4, done.
git> remote: Compressing objects: 50% (1/2)
git> --> remote: Compressing objects: 100% (2/2)
git> --> remote: Compressing objects: 100% (2/2 )Unpacking objects: 33% (1/3)
git> --> Unpacking objects: 66% (2/3)
git> --> Unpacking objects: 100% (3/3)
git> --> Unpacking objects: 100% (3/3), done.
git> remote: , done.
git> remote: Total 3 (delta 0), reused 0 (delta 0)
git> From /tmp/git_area2
git> * branch master -> FETCH_HEAD
git> Updating b2f942d..4f9ba90
git> Fast forward
git> file3 | 1 +
git> 1 files changed, 1 insertions(+), 0 deletions(-)
git> create mode 100644 file3
Trying to automatically filter this with redirection and use of tr
fails to show the progress output completely which is a non-option
either:
git> COMMAND: git pull /tmp/git_area2 master 2>&1 | tr '\013' '\012'
git> From /tmp/git_area2
git> * branch master -> FETCH_HEAD
git> Updating 49b1897..bb5f57c
git> Fast forward
git> file3 | 1 +
git> 1 files changed, 1 insertions(+), 0 deletions(-)
git> create mode 100644 file3
Thanks,
bgoodr
^ permalink raw reply
* Re: [PATCH] Add tests for diff.color-words configuration option.
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901201057080.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Tuesday 2009 January 20 03:58:37 Johannes Schindelin wrote:
>On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> I'm not sure why the diff is crazy long.
>
>Because you changed things that need no changing, such as "cat > expect"
>-> "cat > expect.blabla",
I suppose I could have gotten away with doing this differently, but I did need
to save off some of those results to different files because I wanted to
resuse the results.
>and because you inserted your test instead of
>adding it at the end.
I put the tests in that order explicitly to test that .gitattributes overrides
the configuration option.
I'm going to be reworking both patches anyway, so I should be able to
rearrange things less, in this file.
Thanks for the feedback.
--
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
* feature request mergetool, skip, abort
From: Caleb Cushing @ 2009-01-20 16:39 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
firstly my patch sucks, and I know it. but hopefully it'll give some
idea of what I'm trying to do and someone can implement it properly.
basically there are some files, that I can't merge with git, but I
need to merge other files before I can fix those and I like to use
mergetool, so I want a way to skip the files I'm not going to be able
to merge.
--
Caleb Cushing
http://xenoterracide.blogspot.com
[-- Attachment #2: 0001-preliminary-merge-skip-abort-patch.patch --]
[-- Type: application/octet-stream, Size: 1223 bytes --]
From b43603bcd408cccea7ba55041a8356d0ca536989 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] preliminary merge/skip/abort patch
---
git-mergetool.sh | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..c0b27ed 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,11 +177,25 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
- fi
+ while true; do
+ printf "Use (m)erge file or (s)skip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*)
+ break
+ ;;
+ [sS]*)
+ return 0 #go to the next file, needs to clean up
+ ;;
+ [aA]*)
+ return 1 #should exit immediately, doesn't
+ ;;
+ esac
+ done
+ fi
- case "$merge_tool" in
+ case "$merge_tool" in
kdiff3)
if base_present ; then
("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
--
1.6.1
^ permalink raw reply related
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Johannes Schindelin @ 2009-01-20 16:41 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
Hi,
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
That is strange. The command "data 88" should read the next 88 bytes and
not stop at the line starting with '.
Just to test, I successfully imported this:
-- snip --
commit refs/heads/testing/test
mark :1
committer cvs2svn <cvs2svn> 1002043747 +0000
data 3
'.
-- snap --
So I guess the problem lies much earlier: I could imagine that there is
_another_ "data" command that has a bogus length and just happens to end
after the line "data 88".
Maybe that helps?
I could also imagine that the '. actually is the end of an example
inside a blob, that literally looks like a fast-import script, but
actually is not meant for _this_ fast-import run.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 16:51 UTC (permalink / raw)
To: Brian Foster; +Cc: Reece Dunn, git list
In-Reply-To: <200901200912.14432.brian.foster@innova-card.com>
On Tue, Jan 20, 2009 at 1:42 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
> On Monday 19 January 2009 15:37:06 Dilip M wrote:
>> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
>> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
>> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
>> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
>> >> not found'
>> >
>> > Who is the owner of the repository directory (and the .git directory)
>> > and what are the permissions on the directory? [ ... ]
>>
>> dm-laptop:~/repos/atria> id -a
>> uid=1000(dm) gid=1000(dm) [ ... ]
>> dm-laptop:~/repos/atria> ls -lh .git/
>>[... all looks Ok ...]
>
> repeating Reece's question, what is the permissions/owner
> _of_the_directory_which_contains_ the '.git/' directory?
> I can reproduce this behaviour (git 1.6.0.4) simply by
> denying myself search (née execute) permission on that
> directory, for entirely obvious reasons.
It's the same issue....Any ENV variable I can set to debug this...?
dm-laptop:~/repos/atria> id -a
uid=1000(dm) gid=1000(dm)
groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),109(lpadmin),115(admin),1000(dm)
dm-laptop:~/repos/atria> ls -ld .git
drwxr-xr-x 8 dm dm 4096 2009-01-19 22:34 .git
dm-laptop:~/repos/atria> ls -la .git
total 68
drwxr-xr-x 8 dm dm 4096 2009-01-19 22:34 .
drwxr-xr-x 6 dm dm 4096 2009-01-18 23:28 ..
drwxr-xr-x 2 dm dm 4096 2009-01-18 23:24 branches
-rw-r--r-- 1 dm dm 20 2009-01-19 22:28 COMMIT_EDITMSG
-rw-r--r-- 1 dm dm 256 2009-01-18 23:28 config
-rw-r--r-- 1 dm dm 58 2009-01-18 23:24 description
-rw-r--r-- 1 dm dm 89 2009-01-19 20:15 FETCH_HEAD
-rw-r--r-- 1 dm dm 23 2009-01-19 21:49 HEAD
drwxr-xr-x 2 dm dm 4096 2009-01-18 23:24 hooks
-rw-r--r-- 1 dm dm 5280 2009-01-19 22:28 index
drwxr-xr-x 2 dm dm 4096 2009-01-19 22:34 info
drwxr-xr-x 3 dm dm 4096 2009-01-19 22:34 logs
drwxr-xr-x 4 dm dm 4096 2009-01-19 22:34 objects
-rw-r--r-- 1 dm dm 41 2009-01-19 20:15 ORIG_HEAD
-rw-r--r-- 1 dm dm 153 2009-01-19 22:34 packed-refs
drwxr-xr-x 5 dm dm 4096 2009-01-18 23:28 refs
dm-laptop:~/repos/atria> umask
22
-- DM
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901201058520.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]
On Tuesday 2009 January 20 04:02:00 you wrote:
>On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> diff --git a/diff.c b/diff.c
>> index 9fcde96..c53e1d1 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -23,6 +23,7 @@ static int diff_detect_rename_default;
>> static int diff_rename_limit_default = 200;
>> static int diff_suppress_blank_empty;
>> int diff_use_color_default = -1;
>> +static const char *diff_color_words_cfg = NULL;
>> static const char *external_diff_cmd_cfg;
>
>Guess why external_diff_cmd_cfg is not set to NULL? All variables
>defined outside a function are set to all-zero anyway.
I suppose I just initialize variables by reflex, having been bitten with too
many sometimes-crashes due to variables that were usually-zero. Assuming C
does guarantee that it is zeroed, I'll drop the " = NULL" line noise in the
next version.
>> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char
>> *value, void *cb) }
>> if (!strcmp(var, "diff.external"))
>> return git_config_string(&external_diff_cmd_cfg, var, value);
>> + if (!strcmp(var, "diff.color-words"))
>
>I'd call it diff.wordregex, because that's what it is.
I don't like runtogetherwords because they are hard to read for me; I tend to
choose the wrong word breaks if it is ambiguous. There are other
configuration values that use camelCaseWords so I will convert over to using
that.
I thought "word regex" made more sense, but I wanted to match the command-line
option. Will change.
>> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
>> o->word_regex = userdiff_word_regex(one);
>> if (!o->word_regex)
>> o->word_regex = userdiff_word_regex(two);
>> + if (!o->word_regex)
>> + o->word_regex = diff_color_words_cfg;
>
>IMHO this is the wrong order. config should not override attributes,
>which are by definition more specific.
You are up too late Dscho. This ordering makes the config not override
attributes. If one of the files has a diff driver, o->word_regex will be set
to it (and become non-NULL). That will prevent execution of the body of the
added "if (!o->word_regex)" -- preventing the configuration option from being
used.
>> diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
>> index 6ebce9d..a207d9e 100755
>> --- a/t/t4034-diff-words.sh
>> +++ b/t/t4034-diff-words.sh
>> @@ -105,7 +105,7 @@ a = b + c<RESET>
>> EOF
>> cp expect.non-whitespace-is-word expect
>>
>> -test_expect_failure 'use default supplied by config' '
>> +test_expect_success 'use default supplied by config' '
>
>Let's squash the two, okay?
Will do. I expected the code changes to be larger than the test, and when I
finished it was completely the other way. My next patch will be all-in-one.
Thanks for your feedback.
--
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] Add tests for diff.color-words configuration option.
From: Johannes Schindelin @ 2009-01-20 16:54 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201034.22478.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> On Tuesday 2009 January 20 03:58:37 Johannes Schindelin wrote:
> >On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
> >> I'm not sure why the diff is crazy long.
> >
> >Because you changed things that need no changing, such as "cat > expect"
> >-> "cat > expect.blabla",
>
> I suppose I could have gotten away with doing this differently, but I
> did need to save off some of those results to different files because I
> wanted to resuse the results.
Why didn't you do that, then?
cp expect expect.for-later-use
> >and because you inserted your test instead of adding it at the end.
>
> I put the tests in that order explicitly to test that .gitattributes
> overrides the configuration option.
Why not just remove the .gitattributes for your second test?
It would be much clearer that you did not modify any existing tests, then.
Ciao,
Dscho
^ permalink raw reply
* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901201001.54979.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On Tuesday 2009 January 20 03:01:50 Thomas Rast wrote:
>It was really intended as a toy patch, but if people find it useful
>(Boyd?) I can add the rest of the options so that all searches can be
>chosen independently, and shape it as a "real" contrib patch.
I'll test it out later today and get back to you.
[OT]
I actually prefer Stephen; My father is Boyd.
--
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
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