Jakub Narebski | 1 Aug 01:07 2007
Picon

Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view

Gaah, I just find that I forgot in some places to preserve "-l"...
Please wait for amended patch.

--

-- 
Jakub Narebski

Denis Bueno | 1 Aug 01:45 2007
Picon

Git clone error

Hi all,

I'm a new git user (actually a darcs convert) and am running into a weird
problem on a small and simple repository.  The error I see is:

    git[14] > git clone /Volumes/work/scripts/
    Initialized empty Git repository in /tmp/git/scripts/.git/
    remote: Generating pack...
    Done counting 80 objects.
    remote: error: unable to unpack b28b949a1a3c8eb37ca6eefd024508fa8b253429
header
    fatal: unable to get type of object b28b949a1a3c8eb37ca6error:
git-upload-pack: git-pack-objects died with error.
    fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
    remote: aborting due to possible repository corruption on the remote
side.
    fatal: early EOF
    fatal: index-pack died with error code 128
    fetch-pack from '/Volumes/work/scripts/.git' failed.

I have many git repos on my system (one for configuration files, one for
scripts, various school projects, etc.) and this is the only one that has
been problematic thus far.  As you can see I am trying to clone a local repo
-- there should be no network problems here.  As I said, the repo is small:

    scripts[19] > find . -type f | wc -l
    118

(which of course includes all of git's files.)
(Continue reading)

Michael Haggerty | 1 Aug 02:09 2007
Picon

cvs2svn conversion directly to git ready for experimentation

I am the maintainer of cvs2svn[1], which is a program for one-time
conversions from CVS to Subversion.  cvs2svn is very robust against the
many peculiarities of CVS and can convert just about every CVS
repository we have ever seen.

I've been working on a cvs2svn output pass that writes the converted CVS
repository directly into git rather than Subversion.  The code runs now
with at least one repository from our test suite of nasty CVS repositories.

Unfortunately, I am a complete git newbie, so I would very much
appreciate help from the git community with feedback and checking
whether the conversion output is reasonable and gitlike.

The git output is very preliminary and virtually untested, and has the
following limitations (hopefully to be removed in the near future):

- It is rather slow.  Among other things, it still uses RCS or CVS to
extract the contents of the CVS revisions, which will soon be changed to
win a factor of 2 or so.

- CVS allows a branch to be created from arbitrary combinations of
source revisions and/or source branches.  cvs2svn tries to create a
branch from a single source, but if it can't figure out how to, it
creates the branch using "merge" from multiple sources.  In pathological
situations, the number of merge sources for a branch can be arbitrarily
large.

- It is not very intelligent about creating tags.  When asked to create
a tag, it unconditionally creates a "tag fixup branch"[2] with the same
name and contents as the tag, then tags this branch.  The tag fixup
(Continue reading)

Jakub Narebski | 1 Aug 02:16 2007
Picon

Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial

I have lately added new Git speed benchmark, from Bryan Murdock blog. 
The repository is bit untypical:

<quote>  
  By performance, I mean that I used the UNIX time command to see how
  long various basic operations took. Performing the various basic
  operations gave me some insight into the usability of each as well.
  For this test I used a directory with 266 MB of files, 258 KB of which
  were text files, with the rest being image files. I know, kind of
  weird to version all those binary files, but that was the project I
  was interested in testing this out on. Your mileage may vary and all
  that. Here’s a table summarizing the real times reported by time(1):
</quote>

If I remember correctly there were some patches to git which tried to 
better deal with large blobs. In this simple benchmark git was 
outperformed by Mercurial and even Bazaar-NG a bit.

http://git.or.cz/gitwiki/GitBenchmarks#head-5657b8361895b5a02c0de39337c410e4d8dcdbce
http://bryan-murdock.blogspot.com/2007/03/cutting-edge-revision-control.html
--

-- 
Jakub Narebski
Poland
Junio C Hamano | 1 Aug 02:22 2007
Picon
Picon

Re: Git clone error

"Denis Bueno" <denbuen <at> sandia.gov> writes:

> ...  The error I see is:
>
>     git[14] > git clone /Volumes/work/scripts/
>     Initialized empty Git repository in /tmp/git/scripts/.git/
>     remote: Generating pack...
>     Done counting 80 objects.
>     remote: error: unable to unpack b28b949a1a3c8eb37ca6eefd024508fa8b253429
> header
>     fatal: unable to get type of object b28b949a1a3c8eb37ca6error:
> git-upload-pack: git-pack-objects died with error.
>     fatal: git-upload-pack: aborting due to possible repository corruption
> on the remote side.
>     remote: aborting due to possible repository corruption on the remote
> side.

First thing to check would be...

>     fatal: early EOF
>     fatal: index-pack died with error code 128
>     fetch-pack from '/Volumes/work/scripts/.git' failed.

        $ cd /Volumes/work/scripts
        $ git fsck --full

Johannes Schindelin | 1 Aug 02:28 2007
Picon
Picon

Re: [PATCH 0/9] work-tree clean ups

Hi,

so this is yet another revision of the work-tree clean ups (sorry to all 
those who grow tired of it; I feel with you: I am tired of it, too).

Junio rightfully pointed out that the tests do not succeed after each 
single step of the series.

Alas, after thinking about it for quite some time, I do not think there is 
any way around squashing all the earlier steps 4,6--9 into one step.

There is not really much that can be done about step 6/9: if we are in a 
work tree: that does not mean that we are _not_ in the git_dir.  (And no, 
this does not break git-clean, as a work tree is a work tree is a work 
tree.  If the user was stupid enough to specify the same directory as 
GIT_DIR and GIT_WORK_TREE, then that is _her_ problem.  Git is a powerful 
tool, and you can harm yourself with it.  Tough.)

Patch 7/9 is needed, because the old logic in git-init was wrong, and only 
hidden by the fact that the work-tree logic was implemented wrongly to 
begin with.

Patches 8 and 9/9 only updated the tests to ensure a sane logic, instead 
of an unsane one.  So they are needed, too.

Note: if you are in a bare repository (a repository which either says 
"core.bare = false" in the config, or which is a direct ancestor 
directory, i.e. ../[...]/.. of the current working directory) there will 
_not_ be an automatic working directory assignment.  You will be operating 
_without_ any work tree, unless you specify one.
(Continue reading)

Johannes Schindelin | 1 Aug 02:28 2007
Picon
Picon

[PATCH 1/4] Add is_absolute_path() and make_absolute_path()


This patch adds convenience functions to work with absolute paths.
The function is_absolute_path() should help the efforts to integrate
the MinGW fork.

Note that make_absolute_path() returns a pointer to a static buffer.

Signed-off-by: Johannes Schindelin <johannes.schindelin <at> gmx.de>
---
 Makefile             |    2 +-
 cache.h              |    5 ++++
 path.c               |   65 ++++++++++++++++++++++++++++++++++++++++++++++++++
 t/t0000-basic.sh     |   16 ++++++++++++
 test-absolute-path.c |   11 ++++++++
 5 files changed, 98 insertions(+), 1 deletions(-)
 create mode 100644 test-absolute-path.c

diff --git a/Makefile b/Makefile
index 149df1b..41c4de0 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -937,7 +937,7  <at>  <at>  endif

 ### Testing rules

-TEST_PROGRAMS = test-chmtime$X test-genrandom$X test-date$X test-delta$X test-sha1$X test-match-trees$X
+TEST_PROGRAMS = test-chmtime$X test-genrandom$X test-date$X test-delta$X test-sha1$X
test-match-trees$X test-absolute-path$X

 all:: $(TEST_PROGRAMS)
(Continue reading)

Johannes Schindelin | 1 Aug 02:29 2007
Picon
Picon

[PATCH 2/4] Add functions get_relative_cwd() and is_inside_dir()


The function get_relative_cwd() works just as getcwd(), only that it
takes an absolute path as additional parameter, returning the prefix
of the current working directory relative to the given path.  If the
cwd is no subdirectory of the given path, it returns NULL.

is_inside_dir() is just a trivial wrapper over get_relative_cwd().

Signed-off-by: Johannes Schindelin <johannes.schindelin <at> gmx.de>
---
 dir.c |   32 ++++++++++++++++++++++++++++++++
 dir.h |    3 +++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/dir.c b/dir.c
index 8d8faf5..5ea269a 100644
--- a/dir.c
+++ b/dir.c
 <at>  <at>  -642,3 +642,35  <at>  <at>  file_exists(const char *f)
   struct stat sb;
   return stat(f, &sb) == 0;
 }
+
+/*
+ * get_relative_cwd() gets the prefix of the current working directory
+ * relative to 'dir'.  If we are not inside 'dir', it returns NULL.
+ * As a convenience, it also returns NULL if 'dir' is already NULL.
+ */
+char *get_relative_cwd(char *buffer, int size, const char *dir)
+{
(Continue reading)

Johannes Schindelin | 1 Aug 02:29 2007
Picon
Picon

[PATCH 3/4] Add set_git_dir() function


With the function set_git_dir() you can reset the path that will
be used for git_path(), git_dir() and friends.

The responsibility to close files and throw away information from the
old git_dir lies with the caller.

Signed-off-by: Johannes Schindelin <johannes.schindelin <at> gmx.de>
---
 cache.h       |    1 +
 environment.c |    8 ++++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 98af530..e1f94cb 100644
--- a/cache.h
+++ b/cache.h
 <at>  <at>  -214,6 +214,7  <at>  <at>  extern char *get_object_directory(void);
 extern char *get_refs_directory(void);
 extern char *get_index_file(void);
 extern char *get_graft_file(void);
+extern int set_git_dir(const char *path);

 #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"

diff --git a/environment.c b/environment.c
index f83fb9e..a571fae 100644
--- a/environment.c
+++ b/environment.c
 <at>  <at>  -107,3 +107,11  <at>  <at>  char *get_graft_file(void)
(Continue reading)

Johannes Schindelin | 1 Aug 02:30 2007
Picon
Picon

[PATCH 4/4] Clean up work-tree handling


The old version of work-tree support was an unholy mess, barely readable,
and not to the point.

For example, why do you have to provide a worktree, when it is not used?
As in "git status".  Now it works.

Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?

IOW it is allowed to call

	$ git --git-dir=../ --work-tree=. bla

when you really want to.  In this case, you are both in the git directory
and in the working tree.  So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.

Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.

The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:

--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.

(Continue reading)


Gmane