* Re: git-svn removes merge
From: Joakim Tjernlund @ 2007-06-08 13:52 UTC (permalink / raw)
To: git
In-Reply-To: <1181236096.30670.66.camel@gentoo-jocke.transmode.se>
On Thu, 2007-06-07 at 19:08 +0200, Joakim Tjernlund wrote:
> If I do this:
>
> git checkout --track -b svn remotes/trunk
> git checkout -b merge
> git-am ../mbox
> git checkout svn
> #edit Makefile and commit
> git-svn dcommit #Note 1
> git pull . merge
> git-svn dcommit
>
> then git-svn dcommit removes the merge beteen svn and merge.
> git log svn..merge shows all the commits that git-am ../mbox added.
>
> How do I avoid this?
>
> Jocke
>
> Note 1:
> If I skip this step then the last git-svn dcommit fails, why is that?
Forgot to mention the error msg I get here:
Transaction is out of date: Out of date: '/trunk/board/tmcu/of-tmtu.dts'
in transaction '101-1' at /usr/bin/git-svn line 405
Jocke
^ permalink raw reply
* Re: interaction between cvsimport and cvsexportcommit
From: Robin Rosenberg @ 2007-06-08 15:11 UTC (permalink / raw)
To: picca; +Cc: git
In-Reply-To: <20070608154222.56870830@localhost.localdomain>
fredag 08 juni 2007 skrev picca:
> Hello
>
> In the institut where I am working www.synchrotron-soleil.fr, the
> "computing department" use CVS for all their projects. As I am not from
> this department (I am a scientist), I can use my own tools and git is
> one of them.
> Nevertheless I need to interact with them (I am writting a C++
> library to control diffractometers) so I use cvsimport and
> cvsexportcommit.
>
> The point is that I find this over complicate compare to my git
> day-to-day experience.
>
> I do not understand why cvsimport and cvsexportcommit do not
> interact nicelly to ease git <-> cvs.
git-cvsexportcommit was written (I assume, since I did not actually write the
original version) to solve a problem and not to be a perfect solution.
Later I found it didn't do what I needed so I made improvements (to solve /my/
problems, mainly in reliability and completeness (binaries, add remove, all
or nothing). The rest was just inconvenience and I did not consider my
solution to that universally viable so I didn't include it in in
cvsexportcommit.
> For example as a neeby I expect this to work out of the box
> after the first cvsimport
>
> git cvsimport
> do some work
> git commit -a
> git cvsexportcommit
This assume you really want to export all. I don't, but I agree that it should
in principle be this simple. Patches anyone?
> and that's all
>
> Instead of this we have this:
>
> $ export GIT_DIR=~/project/.git
> $ cd ~/project_cvs_checkout
> $ git-cvsexportcommit -v <commit-sha1>
> $ cvs commit -F .mgs <files>
>
> or even worse
>
> $ export GIT_DIR=~/project/.git
> $ cd ~/project_cvs_checkout
> $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1
> git-cvsexportcommit -c -p -v
>
> what is missing in cvsexportcommit and cvsimport to lower the git <->
> cvs barrier.
Here is my script that I use to export. It takes as arguments a number of
commits or stgit patches. Note that hardcoded path to the CVS checkout...
Here's an exercise to the reader: Modify git-cvsexportcommit so it takes the
path to the CVS checkout from 1) a parameter (e.g. -w /checkout) or 2) a git
config variable. That will get get us a small step closer. It will be fairly
easy.
Cheers
-- robin
--------------------------8<-------------------------
#!/bin/bash -ex
if [ "$1" = "-p" ]
then
P="-p $2"
shift 2
fi
export GIT_DIR=$(git-rev-parse --git-dir)
GIT_DIR=$(cd $GIT_DIR;pwd)
cd ../Iris.CVSsynconly
for patch in "$@"
do
if commit=$(git-rev-parse $patch 2>/dev/null); then
git-cvsexportcommit-u $(echo $P) -c $commit
else
head=$(git-symbolic-ref HEAD)
br=${head#refs/heads/}
if commit=$(git-rev-parse refs/patches/$br/$patch); then
git-cvsexportcommit -u $(echo $P) -c $commit
fi
fi
done
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Thomas Glanzmann @ 2007-06-08 15:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: GIT
In-Reply-To: <20070608135054.GK2335@cip.informatik.uni-erlangen.de>
Hello,
> I give it a try and come back to you. I am off the net for 1 hour.
(tomcat-05) [/usr/src] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /usr/src/linux-2.6/.git/
remote: Generating pack...
remote: Done counting 496911 objects.
remote: Deltifying 496911 objects...
remote: 100% (496911/496911) done
Indexing 496911 objects...
remote: Total 496911 (delta 401539), reused 493712 (delta 398653)
100% (496911/496911) done
Resolving 401539 deltas...
fatal: serious inflate inconsistency
fatal: index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
yes, it is reproducable. Again I am off the net for an hour.
Thomas
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Thomas Glanzmann @ 2007-06-08 15:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: GIT, Michael Gernoth
In-Reply-To: <20070608153722.GL2335@cip.informatik.uni-erlangen.de>
Hello again,
> yes, it is reproducable. Again I am off the net for an hour.
I used the debian packages that built a friend of mine:
deb http://rmdir.de/~michael/git/ ./
If you want to reproduce it by yourself.
Thomas
^ permalink raw reply
* RE: clarify git clone --local --shared --reference
From: Loeliger Jon-LOELIGER @ 2007-06-08 15:57 UTC (permalink / raw)
To: Shawn O. Pearce, Brandon Casey; +Cc: git
In-Reply-To: <20070608053750.GB18521@spearce.org>
Shawn O. Pearce wrote:
>
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
> > ok. I just want to make sure this is not really about prune'ing.
> >
> > In the following, source and --shared repos are identical except...
> > 1) Source repo contains loose objects which are new commits.
> > --shared repo does git-pull.
> > we fast-forward, copying very little.
> > success.
>
> Copying nothing actually. All of the objects required are in the
> source repository, so --shared needs nothing additional.
So the thing I find myself wanting to do is
A "crib from local copy". That is, the network
Cost is large, so when cloning point to a local
(ie, already on same Filesystem) clone that is
Similar, use it as a reference, but, in the end,
Create a complete copy into the new repository.
I don't want it hard linked with --local.
I don't want it shared with --shared.
I don't want it as an altrnate source with --reference.
What I want is a new, clean, complete, unshared repository.
But for efficiency reasons, I want to grab objects
From a different, filesystem-local clone if possible.
Does that work?
jdl
^ permalink raw reply
* Re: [PATCH] Fix failed tag parsing when tag object has no body/message (and thus ends with a single '\n')
From: Junio C Hamano @ 2007-06-08 16:06 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Johannes Schindelin
In-Reply-To: <200706081018.34207.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I can:
>
> 1. Provide a new patch series to totally replace the previous 6-part patch
> series (plus bugfixes). The new patch series will make smaller steps and
> end up (hopefully) in a better place, with less overzealous
> checking/parsing, and more "traditional" whitespacing.
>
> OR
>
> 2. Provide the babystep-series ending up exactly where we are today (i.e.
> after the patch series, plus bug fixes). Then, provide patches on top of
> the existing series to get it into shape, both scope-wise (i.e. not trying
> to do too much) and whitespace-wise.
>
> Which do you prefer?
I am not sure if there is any practical difference between the
two ;-). But in either case, it appears that we should first
revert d9fa4a8 from 'next' and start from clean slate. It
really seems that the patch series did upset too many people;
personally I found the first patch still was follow-able, but I
do agree that it should have been much smaller and not mixing
too many things into one).
So, let's do 1.
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Nicolas Pitre @ 2007-06-08 16:15 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070608153722.GL2335@cip.informatik.uni-erlangen.de>
On Fri, 8 Jun 2007, Thomas Glanzmann wrote:
> Hello,
>
> > I give it a try and come back to you. I am off the net for 1 hour.
>
> (tomcat-05) [/usr/src] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Initialized empty Git repository in /usr/src/linux-2.6/.git/
> remote: Generating pack...
> remote: Done counting 496911 objects.
> remote: Deltifying 496911 objects...
> remote: 100% (496911/496911) done
> Indexing 496911 objects...
> remote: Total 496911 (delta 401539), reused 493712 (delta 398653)
> 100% (496911/496911) done
> Resolving 401539 deltas...
> fatal: serious inflate inconsistency
> fatal: index-pack died with error code 128
> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
>
> yes, it is reproducable. Again I am off the net for an hour.
I can't reproduce that.
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/nico/git/tst/linux-2.6/.git/
remote: Generating pack...
remote: Done counting 496911 objects.
remote: Deltifying 496911 objects...
remote: 100% (496911/496911) done
Indexing 496911 objects...
remote: Total 496911 (delta 401539), reused 493712 (delta 398653)
100% (496911/496911) done
Resolving 401539 deltas...
100% (401539/401539) done
Checking 22413 files out...
100% (22413/22413) done
$ git version
git version 1.5.2.1
> I used the debian packages that built a friend of mine:
>
> deb http://rmdir.de/~michael/git/ ./
>
> If you want to reproduce it by yourself.
I don't use Debian, sorry.
Nicolas
^ permalink raw reply
* git-p4 fails when cloning a p4 depo.
From: Benjamin Sergeant @ 2007-06-08 16:41 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
I attached a lame patch to die without showing the Python Traceback,
but I'd rather succeed :)
Maybe there is a different mailing list for git-p4. If there is tell
me and I'll post there.
Benjamin.
[bsergean@flanders sandbox]$ rm -rf dev ; git-p4 clone
//Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev
Importing from //Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev into dev
Initialized empty Git repository in .git/
Doing initial import of
//Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev/ from revision #head
[{'p4ExitCode': 32512}]
Traceback (most recent call last):
File "/home/bsergean/src/fast-export/git-p4", line 1489, in <module>
main()
File "/home/bsergean/src/fast-export/git-p4", line 1484, in main
if not cmd.run(args):
File "/home/bsergean/src/fast-export/git-p4", line 1395, in run
if not P4Sync.run(self, depotPaths):
File "/home/bsergean/src/fast-export/git-p4", line 1203, in run
self.commit(details, self.extractFilesFromCommit(details),
self.branch, self.depotPaths)
File "/home/bsergean/src/fast-export/git-p4", line 744, in commit
self.readP4Files(files)
File "/home/bsergean/src/fast-export/git-p4", line 722, in readP4Files
contents[stat['depotFile']] = text
KeyError: 'depotFile'
[-- Attachment #2: git-p4.diff --]
[-- Type: text/x-patch, Size: 429 bytes --]
diff --git a/git-p4 b/git-p4
index 36fe69a..3e1a878 100755
--- a/git-p4
+++ b/git-p4
@@ -707,6 +707,9 @@ class P4Sync(Command):
f['rev'])
for f in files]))
+ if "p4ExitCode" in filedata[0]:
+ die("Problems executing p4");
+
j = 0;
contents = {}
while j < len(filedata):
^ permalink raw reply related
* [PATCH] Additional white space fixes
From: Marco Costalba @ 2007-06-08 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Some white space breakage survived after "git-apply --whitespace=strip".
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
builtin-pack-objects.c | 2 +-
builtin-tar-tree.c | 2 +-
diff.h | 2 +-
git-clean.sh | 2 +-
git-svn.perl | 2 +-
git.c | 2 +-
gitweb/gitweb.perl | 6 +++---
read-cache.c | 4 ++--
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3d396ca..5601ac3 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -28,7 +28,7 @@ struct object_entry {
unsigned int hash; /* name hint hash */
unsigned int depth; /* delta depth */
- struct packed_git *in_pack; /* already in pack */
+ struct packed_git *in_pack; /* already in pack */
off_t in_pack_offset;
struct object_entry *delta; /* delta base object */
struct object_entry *delta_child; /* deltified objects who bases me */
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index b04719e..8861a29 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -21,7 +21,7 @@ int cmd_tar_tree(int argc, const char **
* $0 tree-ish ==>
* git-archive --format=tar tree-ish
* $0 tree-ish basedir ==>
- * git-archive --format-tar --prefix=basedir tree-ish
+ * git-archive --format-tar --prefix=basedir tree-ish
*/
int i;
const char **nargv = xcalloc(sizeof(*nargv), argc + 2);
diff --git a/diff.h b/diff.h
index a7ee6d8..0e8b84f 100644
--- a/diff.h
+++ b/diff.h
@@ -155,7 +155,7 @@ extern void diff_unmerge(struct diff
unsigned mode,
const unsigned char *sha1);
-#define DIFF_SETUP_REVERSE 1
+#define DIFF_SETUP_REVERSE 1
#define DIFF_SETUP_USE_CACHE 2
#define DIFF_SETUP_USE_SIZE_CACHE 4
diff --git a/git-clean.sh b/git-clean.sh
index 299309d..538d2f6 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -7,7 +7,7 @@ USAGE="[-d] [-f] [-n] [-q] [-x | -X] [--]
LONG_USAGE='Clean untracked files from the working directory
-d remove directories as well
-f override clean.requireForce and clean anyway
- -n don'\''t remove anything, just show what would be done
+ -n don'\''t remove anything, just show what would be done
-q be quiet, only report errors
-x remove ignored files as well
-X remove only ignored files
diff --git a/git-svn.perl b/git-svn.perl
index e350061..29b762b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4012,7 +4012,7 @@ diff-index line ($m hash)
$l_map = {
# repository root url
'https://svn.musicpd.org' => {
- # repository path # GIT_SVN_ID
+ # repository path # GIT_SVN_ID
'mpd/trunk' => 'trunk',
'mpd/tags/0.11.5' => 'tags/0.11.5',
},
diff --git a/git.c b/git.c
index 29b55a1..99be8c5 100644
--- a/git.c
+++ b/git.c
@@ -214,7 +214,7 @@ const char git_version_string[]
* require working tree to be present -- anything uses this needs
* RUN_SETUP for reading from the configuration file.
*/
-#define NOT_BARE (1<<2)
+#define NOT_BARE (1<<2)
static void handle_internal_command(int argc, const char **argv, char **envp)
{
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e92596c..82af59d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -105,9 +105,9 @@ our $fallback_encoding = 'latin1';
# $GITWEB_CONFIG as necessary.
our %feature = (
# feature => {
- # 'sub' => feature-sub (subroutine),
- # 'override' => allow-override (boolean),
- # 'default' => [ default options...] (array reference)}
+ # 'sub' => feature-sub (subroutine),
+ # 'override' => allow-override (boolean),
+ # 'default' => [ default options...] (array reference)}
#
# if feature is overridable (it means that allow-override has true value),
# then feature-sub will be called with default options as parameters;
diff --git a/read-cache.c b/read-cache.c
index 4362b11..6009293 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -208,9 +208,9 @@ int ie_match_stat(struct index_state *istate,
/*
* Within 1 second of this sequence:
- * echo xyzzy >file && git-update-index --add file
+ * echo xyzzy >file && git-update-index --add file
* running this command:
- * echo frotz >file
+ * echo frotz >file
* would give a falsely clean cache entry. The mtime and
* length match the cache, and other stat fields do not change.
*
--
1.5.2.GIT
^ permalink raw reply related
* Re: fatal: serious inflate inconsistency
From: Linus Torvalds @ 2007-06-08 17:01 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Nicolas Pitre, GIT
In-Reply-To: <20070608153722.GL2335@cip.informatik.uni-erlangen.de>
On Fri, 8 Jun 2007, Thomas Glanzmann wrote:
>
> yes, it is reproducable. Again I am off the net for an hour.
Could you compile your own git? If so, please try this patch on top of
current git, to make the error message a bit more informative.
It does sound like a corrupt stream, but maybe debian has some strange
zlib version that git doesn't like.
Linus
---
index-pack.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 82c8da3..542687b 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -277,9 +277,13 @@ static void *get_data_from_pack(struct object_entry *obj)
stream.avail_in = len;
inflateInit(&stream);
while ((st = inflate(&stream, Z_FINISH)) == Z_OK);
+ if (st != Z_STREAM_END)
+ die("serious inflate inconsistency: %d (%s)",
+ st, stream.msg ? stream.msg : "no message");
+ if (stream.total_out != obj->size)
+ die("serious inflate inconsistency: got %lu bytes, expected %lu",
+ stream.total_out, obj->size);
inflateEnd(&stream);
- if (st != Z_STREAM_END || stream.total_out != obj->size)
- die("serious inflate inconsistency");
free(src);
return data;
}
^ permalink raw reply related
* Re: [PATCH] gitweb: change filename/directory name of snapshots
From: Petr Baudis @ 2007-06-08 17:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7v4pliltuv.fsf@assigned-by-dhcp.cox.net>
On Fri, Jun 08, 2007 at 10:43:04AM CEST, Junio C Hamano wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > /.git or .git is removed from the project name and the
> > basename of the remaining path is used as the beginning of
> > the filename and as the directory in the archive.
> >
> > The regexp will actually not strip off /.git or .git if there
> > wouldn't be anything left after removing it.
> >
> > Currently the full project name is used as directory in the
> > archive and the basename is used as filename. For example a
> > repository named foo/bar/.git will have a archive named
> > .git-<version>.* and extract to foo/bar/.git. With this patch
> > the file is named bar-<version>.* and extracts to bar.
>
> Makes sense to me for "foo/bar/.git", but I am not sure if we
> would want to do this to "foo/bar.git". Opinions?
I wouldn't personally really mind getting rid of the .git suffix in both
cases. Yes, we are used to seeing the ".git" in the name, but I can't
think of any other reasons not to chop it off.
Having the .git in the archive name might be even more confusing since
there is a pseudo-convention (that I'm not sure anyone except me
follows, so maybe not :) that repositories have .git in the name while
working trees don't, and that tarball contains a working tree.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-08 17:25 UTC (permalink / raw)
To: git
trying to do git-svn set-tree remotes/trunk..svn
in my new git-svn repo I get:
config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1
git version 1.5.2.1
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Benjamin Sergeant @ 2007-06-08 18:13 UTC (permalink / raw)
To: git
In-Reply-To: <1621f9fa0706080941k67d2878dud8cf06436c67aea0@mail.gmail.com>
A perforce command with all the files in the repo is generated to get
all the file content.
Here is a patch to break it into multiple successive perforce command
who uses 4K of parameter max, and collect the output for later.
It works, but not for big depos, because the whole perforce depo
content is stored in memory in P4Sync.run(), and it looks like mine is
bigger than 2 Gigs, so I had to kill the process.
diff --git a/git-p4 b/git-p4
index 36fe69a..906b193 100755
--- a/git-p4
+++ b/git-p4
@@ -703,9 +703,22 @@ class P4Sync(Command):
if not files:
return
- filedata = p4CmdList('print %s' % ' '.join(['"%s#%s"' % (f['path'],
- f['rev'])
- for f in files]))
+ # We cannot put all the files on the command line
+ # OS have limitations on the max lenght of arguments
+ # POSIX says it's 4096 bytes, default for Linux seems to be 130 K.
+ # and all OS from the table below seems to be higher than POSIX.
+ # See http://www.in-ulm.de/~mascheck/various/argmax/
+ chunk = ''
+ filedata = []
+ for i in xrange(len(files)):
+ f = files[i]
+ chunk += '"%s#%s" ' % (f['path'], f['rev'])
+ if len(chunk) > 4000 or i == len(files)-1:
+ data = p4CmdList('print %s' % chunk)
+ if "p4ExitCode" in data[0]:
+ die("Problems executing p4. Error: [%d]." %
(data[0]['p4ExitCode']));
+ filedata.extend(data)
+ chunk = ''
j = 0;
contents = {}
@@ -1486,3 +1499,5 @@ def main():
if __name__ == '__main__':
main()
+
+# vim: set filetype=python sts=4 sw=4 et si :
On 6/8/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> I attached a lame patch to die without showing the Python Traceback,
> but I'd rather succeed :)
> Maybe there is a different mailing list for git-p4. If there is tell
> me and I'll post there.
>
> Benjamin.
>
> [bsergean@flanders sandbox]$ rm -rf dev ; git-p4 clone
> //Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev
> Importing from //Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev into dev
> Initialized empty Git repository in .git/
> Doing initial import of
> //Work/Users/Capture3D/A3D810/pdfl/Common/a3d/dev/ from revision #head
> [{'p4ExitCode': 32512}]
> Traceback (most recent call last):
> File "/home/bsergean/src/fast-export/git-p4", line 1489, in <module>
> main()
> File "/home/bsergean/src/fast-export/git-p4", line 1484, in main
> if not cmd.run(args):
> File "/home/bsergean/src/fast-export/git-p4", line 1395, in run
> if not P4Sync.run(self, depotPaths):
> File "/home/bsergean/src/fast-export/git-p4", line 1203, in run
> self.commit(details, self.extractFilesFromCommit(details),
> self.branch, self.depotPaths)
> File "/home/bsergean/src/fast-export/git-p4", line 744, in commit
> self.readP4Files(files)
> File "/home/bsergean/src/fast-export/git-p4", line 722, in readP4Files
> contents[stat['depotFile']] = text
> KeyError: 'depotFile'
>
>
^ permalink raw reply related
* Re: fatal: serious inflate inconsistency
From: Thomas Glanzmann @ 2007-06-08 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, GIT, Michael Gernoth
In-Reply-To: <alpine.LFD.0.98.0706080959570.4205@woody.linux-foundation.org>
Hello Linus,
> Could you compile your own git? If so, please try this patch on top of
> current git, to make the error message a bit more informative.
(tomcat-05) [/usr/src] scp 131.188.30.102:/var/tmp/sithglan/git-core-1.5.2.1/../git-core_1.5.2.1-1_i386.deb .
Warning: Permanently added '131.188.30.102' (RSA) to the list of known hosts.
git-core_1.5.2.1-1_i386.deb 100% 3511KB 1.7MB/s 00:02
(tomcat-05) [/usr/src] / dpkg -i git-core_1.5.2.1-1_i386.deb
(Reading database ... 13273 files and directories currently installed.)
Preparing to replace git-core 1:1.5.2.1-1 (using git-core_1.5.2.1-1_i386.deb) ...
Unpacking replacement git-core ...
Setting up git-core (1.5.2.1-1) ...
(tomcat-05) [/usr/src] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /usr/src/linux-2.6/.git/
remote: Generating pack...
remote: Done counting 496911 objects.
remote: Deltifying 496911 objects...
remote: 100% (496911/496911) done
Indexing 496911 objects...
remote: Total 496911 (delta 401539), reused 493712 (delta 398653)
100% (496911/496911) done
Resolving 401539 deltas...
fatal: serious inflate inconsistency: -3 (invalid distance too far back)
fatal: index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
I talked to Michael and he is certain that the machine has a memory
corruption the next thing I am going to do is compiling a kernel in an
endless loop. Again if somone needs shell access just send me your ssh
key.
The complete build log is on (well not the complete log the first line is
missing because my screen backlog has _only_ 10000 lines (a memory issue)):
The first line is:
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1-1.dsc
The rest is here:
http://wwwcip.informatik.uni-erlangen.de/~sithglan/screen-exchange.bz2 (32k)
Thanks,
Thomas
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-08 18:35 UTC (permalink / raw)
To: Loeliger Jon-LOELIGER; +Cc: Shawn O. Pearce, git
In-Reply-To: <AF0367BA48C55940A43CCF08DF35553C013C76BF@az33exm24.fsl.freescale.net>
Loeliger Jon-LOELIGER wrote:
> Shawn O. Pearce wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>>> ok. I just want to make sure this is not really about prune'ing.
>>>
>>> In the following, source and --shared repos are identical except...
>>> 1) Source repo contains loose objects which are new commits.
>>> --shared repo does git-pull.
>>> we fast-forward, copying very little.
>>> success.
>> Copying nothing actually. All of the objects required are in the
>> source repository, so --shared needs nothing additional.
>
> So the thing I find myself wanting to do is
> A "crib from local copy". That is, the network
> Cost is large, so when cloning point to a local
> (ie, already on same Filesystem) clone that is
> Similar, use it as a reference, but, in the end,
> Create a complete copy into the new repository.
>
> I don't want it hard linked with --local.
> I don't want it shared with --shared.
> I don't want it as an altrnate source with --reference.
>
> What I want is a new, clean, complete, unshared repository.
>
> But for efficiency reasons, I want to grab objects
> From a different, filesystem-local clone if possible.
>
> Does that work?
I don't think that exact behavior is implemented yet, but...
If the filesystem-local repo is pure subset version of the source repo
you could do this:
(assuming the filesystem-local repo is on branch master, and that is
what you want)
git clone -l <filesystem-local repo> <my_new_repo>
cd <my_new_repo>
git pull <source-repo>
No reason not to use -l on clone in this case IMO.
Otherwise...
If the filesystem-local repo has changes past the master HEAD on source
repo that you are not necessarily interested in...
1) git clone -l -n <filesystem-local repo> <my_new_repo>
2) cd <my_new_repo>
3) git fetch <source_repo> master:tmp
4) git branch -M tmp master
5) git checkout master
1) Here we use -l to encourage hard linking (no reason not to IMO),
and tell clone not (-n) to checkout the active branch.
3) Now fetch the master branch from the source_repo and store into
a new branch named tmp.
4) Rename tmp to master.
5) Checkout the files.
- Now the HEAD of master branch is at the same commit as the
source_repo.
One drawback is that origin is now tracking the filesystem-local repo,
so a git pull without supplying a repo will pull from filesystem-local repo.
-brandon
^ permalink raw reply
* Re: git-send-pack: broken handling of ref specs with wildcards
From: Daniel Barkalow @ 2007-06-08 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Alex Riesen, git
In-Reply-To: <7v8xavlzu0.fsf@assigned-by-dhcp.cox.net>
On Thu, 7 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 8 Jun 2007, Alex Riesen wrote:
> >
> >> Try something like this:
> >>
> >> git-send-pack --remote=origin --thin /some/other/repo \
> >> 'refs/heads/*:refs/remotes/child/*'
> >>
> >> The result looks broken: the sent reference are created not in
> >> refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
> >
> > I had the impression that it was git-push, a porcelain, which handles
> > refspec wildcards, not send-pack, which is plumbing.
>
> Well, I do not think it is wrong per-se if plumbing send-pack
> starts understanding 'a/*:b/*'. Earlier it only understood
> concrete refspecs, and such a refspec that has asterisks cannot
> be concrete, as '*' is an invalid char in a refname. So there
> is no risk of confusion.
>
> That is, as long as it is done right, which was not true in this
> case.
Good catch; all of my configurations have a {foo}/*:{foo}/* pattern for
the push, and I hadn't figured out a way to write tests for push and
fetch.
The code looks like it should do the right thing... now that somebody's
fixed it before I got to it. You people are far too efficient.
I'll probably break out a function for applying a pattern, since there are
multiple places that need to do it, but that can go into a series I'm
working on now.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Linus Torvalds @ 2007-06-08 18:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Nicolas Pitre, GIT, Michael Gernoth
In-Reply-To: <20070608182412.GQ2335@cip.informatik.uni-erlangen.de>
On Fri, 8 Jun 2007, Thomas Glanzmann wrote:
>
> fatal: serious inflate inconsistency: -3 (invalid distance too far back)
Whee. That's Z_DATA_ERROR, and yeah, I think the only thing that causes it
is a corrupt zlib input stream.
> I talked to Michael and he is certain that the machine has a memory
> corruption the next thing I am going to do is compiling a kernel in an
> endless loop. Again if somone needs shell access just send me your ssh
> key.
I'd not expect memory corruption to be that *repeatable*. But the message
certainly implies zlib data stream corruption _somewhere_, although the
fact that it seems to be so repeatable does make me suspect program error.
Of course, it could be a hard bit-error in memory, but even then it would
kind of have to hit the same page allocation history each time to be
repeatable. And the page cache is the only thing that is that sticky under
Linux, so it would have to be something like the zlib static data or code
that had hit the memory corruption.
Sounds strange. I wonder if we might have finally hit a case of different
versions of zlib acting differently?
But it _could_ just be a git bug too.
I don't think it's on the kernel.org side (or we would have had more
reports of this), but maybe there is some wild pointer thing inside git,
and nobody else noticed because it depends on some specific memory
allocation pattern (which in turn depends on things like kernel memory
layout choices, and on libc 'malloc()' implementation etc).
I'll build with ElectricFence, and see if it says anything for me. It
passes all the tests, but fetching the kernel is almost certainly going to
do things that we don't test for..
Linus
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Linus Torvalds @ 2007-06-08 19:06 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Nicolas Pitre, GIT, Michael Gernoth
In-Reply-To: <alpine.LFD.0.98.0706081136480.4205@woody.linux-foundation.org>
On Fri, 8 Jun 2007, Linus Torvalds wrote:
>
> I'll build with ElectricFence, and see if it says anything for me. It
> passes all the tests, but fetching the kernel is almost certainly going to
> do things that we don't test for..
It passes smaller clones fine with ElectricFence (and bigger ones fail
because EF uses *so* much memory for its checking that you cannot actually
complete them), so I don't think this is a git bug. Sounds like either the
hw problems are real, or there is some zlib (or other library) issue..
Linus
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Thomas Glanzmann @ 2007-06-08 19:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, GIT, Michael Gernoth
In-Reply-To: <alpine.LFD.0.98.0706081202580.4205@woody.linux-foundation.org>
Hello Linus,
> It passes smaller clones fine with ElectricFence (and bigger ones fail
> because EF uses *so* much memory for its checking that you cannot actually
> complete them), so I don't think this is a git bug. Sounds like either the
> hw problems are real, or there is some zlib (or other library) issue..
(mailrelay) [/var/tmp] git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /var/tmp/linux-2.6/.git/
remote: Generating pack...
remote: Done counting 496911 objects.
remote: Deltifying 496911 objects...
remote: 100% (496911/496911) done
Indexing 496911 objects...
remote: Total 496911 (delta 401539), reused 493712 (delta 398653)
100% (496911/496911) done
Resolving 401539 deltas...
100% (401539/401539) done
Checking 22413 files out...
100% (22413/22413) done
I have a very similar machine. For this one it works. It has 32 bit kernel and
userland. Debian etch again. v2.6.20.
Does someone know a command for debian that checks the checksums for every
installed packages and the file that are included in that package?
I know there is one for rpm so there must be one for debian, too.
Thomas
^ permalink raw reply
* how to properly import perforce history...
From: Kevin Green @ 2007-06-08 20:22 UTC (permalink / raw)
To: git
Very new to git. Was hoping this would be much more straightforward and I'm
assuming I'm just missing something fundamentally easy.
I'm using git-p4import.py which came with my release of git.
I have a small project I'd like to move from perforce to git ( 111 files, 165
revisions ).
I've used a number of different approaches to do this, all of them resulting
in my files being deleted.
1)
$ git init
$ git-p4import //depot/path master
bombs out with missing .git/index
2)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import --stitch //depot/path
This imports all the comment history, but deletes all of my files!!
3)
$ p4 sync ...
$ git init
$ git add .
$ git commit
$ git-p4import //depot/path new
### new branch with no files, but all my files in master
$ git checkout master
$ git merge new
### Now I see it deleting all of my files, but it pulls in all of the history.
NOTE: All of the commits pulled in have no file information associated with
them...
What am I missing?
Thanks
--Kevin
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Jan Hudec @ 2007-06-08 20:41 UTC (permalink / raw)
To: linux; +Cc: godeater, git
In-Reply-To: <20070607165150.27434.qmail@science.horizon.com>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Thu, Jun 07, 2007 at 12:51:50 -0400, linux@horizon.com wrote:
> 3) Branches are your friend. CVS users think branches are a big
> deal and require careful thought and planning. Git users branch
> almost as often as CVS users commit. A typical "big change"
> that might be a single commit in CVS would be a branch of
> several commits in git.
>
> In fact, a good piece of advice is to NEVER commit directly
> to your trunk ("master"). Do ALL development on branches, and
> merge them into the trunk.
>
> I cheat on that a lot, but I also know how to fix things if I get
> caught becauee a quick hack is proving not so quick: add a branch
> reference to the tip I'm developing on and then back up the master
> branch to where I should have left it when I started this project.
There is a big difference between the cvs and subversion notion of branches
and the git one, which make branches so much more friendly in git.
In cvs and subversion, branch name is part of the commit identity, so you
have to create it before you commit and it will stay with you forever. That
means you have to plan the branch, because there's no going back.
On the other hand git branch (head) names are just pointers to revisions you
base your work on. You can add branch name after you commit, you can rename
the branch anytime and you can delete branches that are no longer
interesting, either because they are already merged, or because they didn't
work out. That means you don't have to think twice whether you need a branch
before you commit, since you can always change your mind later.
This makes it possible to use heaps of short-lived branches for
experimenting and to give them silly names, because noone cares if you don't
publish them, which you don't need to do and ususally won't do until you are
confident that you are working in the right direction (at which point you
have much better idea about what name to publish them under).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: fatal: serious inflate inconsistency
From: Marco Roeland @ 2007-06-08 20:45 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Linus Torvalds, Nicolas Pitre, GIT, Michael Gernoth
In-Reply-To: <20070608193319.GS2335@cip.informatik.uni-erlangen.de>
On Friday June 8th 2007 at 21:33 Thomas Glanzmann wrote:
> Does someone know a command for debian that checks the checksums for every
> installed packages and the file that are included in that package?
Try debsums. Without arguments it checks all installed packages and
their files, but you can also check individual packages.
--
Marco Roeland
^ permalink raw reply
* [PATCH] make git barf when an alias changes environment variables
From: Matthias Lederhofer @ 2007-06-08 20:57 UTC (permalink / raw)
To: git
Aliases changing environment variables (GIT_DIR or
GIT_WORK_TREE) can cause problems:
git has to use GIT_DIR to read the aliases from the config.
After running handle_options for the alias the options of the
alias may have changed environment variables. Depending on
the implementation of setenv the memory location obtained
through getenv earlier may contain the old value or the new
value (or even be used for something else?). To avoid these
problems git errors out if an alias uses any option which
changes environment variables.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
This is on top of ml/worktree even though the problem is also present in
master. It could also be split into one patch which can be applied to
master directly and another one adding the missing parts in the
ml/worktree branch.
Another option instead of dying would be to execute git again. I
decided not to because of
(1) It causes problems with aliases starting the pager: After the exec
git wouldn't know that the pager is running and colors would be
missing.
(2) Up to now aliases not starting with '!' have recursion detection
and are only evaluated as aliases once. Executing git again would
break this.
Example:
Here is an example how to break git aliases, it works with libc of
FreeBSD but not with glibc. libc of FreeBSD reuses the old location
for the environment variable if the new value is smaller than the old
one.
There is a repository in a/.git and a repository in b/.git. Both have
valid HEADs:
% git --git-dir a/.git rev-list --pretty=oneline HEAD
496a0d181f6878ddda8926103a7cf28a668c46ef a
% git --git-dir b/.git rev-list --pretty=oneline HEAD
3c2858eded8ae7ff964549f85f479808d185283c b
Set up some aliases using --git-dir:
% git --git-dir a/.git config alias.works \
'--git-dir a/.git rev-list --pretty=oneline HEAD'
% git --git-dir a/.git config alias.breaks \
'--git-dir b/.git rev-list --pretty=oneline HEAD'
% git --git-dir a/.git config alias.good
'!git --git-dir b/.git rev-list --pretty=oneline HEAD'
The first one works because the value of the environment variable does
not change, the second one does not work because git reads the ref
HEAD from b/.git but searches the object in a/.git. The third one
always works.
% git --git-dir a/.git works
496a0d181f6878ddda8926103a7cf28a668c46ef a
% git --git-dir a/.git breaks
fatal: bad object HEAD
[1] 15643 exit 128 git --git-dir a/.git breaks
% git --git-dir a/.git good
3c2858eded8ae7ff964549f85f479808d185283c b
With the patch:
% git --git-dir a/.git breaks
fatal: alias 'breaks' changes environment variables
You can use '!git' in the alias to do this.
[1] 17295 exit 128 git --git-dir a/.git breaks
---
git.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index cd3910a..33edd62 100644
--- a/git.c
+++ b/git.c
@@ -28,7 +28,7 @@ static void prepend_to_path(const char *dir, int len)
free(path);
}
-static int handle_options(const char*** argv, int* argc)
+static int handle_options(const char*** argv, int* argc, int* envchanged)
{
int handled = 0;
@@ -64,24 +64,34 @@ static int handle_options(const char*** argv, int* argc)
usage(git_usage_string);
}
setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
+ if (envchanged)
+ *envchanged = 1;
(*argv)++;
(*argc)--;
handled++;
} else if (!prefixcmp(cmd, "--git-dir=")) {
setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --work-tree.\n" );
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
+ if (envchanged)
+ *envchanged = 1;
(*argv)++;
(*argc)--;
} else if (!prefixcmp(cmd, "--work-tree=")) {
setenv(GIT_WORK_TREE_ENVIRONMENT, cmd + 12, 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--bare")) {
static char git_dir[PATH_MAX+1];
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 1);
+ if (envchanged)
+ *envchanged = 1;
} else {
fprintf(stderr, "Unknown option: %s\n", cmd);
usage(git_usage_string);
@@ -160,7 +170,7 @@ static int split_cmdline(char *cmdline, const char ***argv)
static int handle_alias(int *argcp, const char ***argv)
{
- int nongit = 0, ret = 0, saved_errno = errno;
+ int nongit = 0, envchanged = 0, ret = 0, saved_errno = errno;
const char *subdir;
int count, option_count;
const char** new_argv;
@@ -181,7 +191,11 @@ static int handle_alias(int *argcp, const char ***argv)
alias_string + 1, alias_command);
}
count = split_cmdline(alias_string, &new_argv);
- option_count = handle_options(&new_argv, &count);
+ option_count = handle_options(&new_argv, &count, &envchanged);
+ if (envchanged)
+ die("alias '%s' changes environment variables\n"
+ "You can use '!git' in the alias to do this.",
+ alias_command);
memmove(new_argv - option_count, new_argv,
count * sizeof(char *));
new_argv -= option_count;
@@ -375,7 +389,7 @@ int main(int argc, const char **argv, char **envp)
/* Look for flags.. */
argv++;
argc--;
- handle_options(&argv, &argc);
+ handle_options(&argv, &argc, NULL);
if (argc > 0) {
if (!prefixcmp(argv[0], "--"))
argv[0] += 2;
--
1.5.2.1.888.gd5e4e
^ permalink raw reply related
* Re: [PATCH] Teach filter-branch about subdirectory filtering
From: Alex Riesen @ 2007-06-08 21:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0706080130000.4046@racer.site>
Johannes Schindelin, Fri, Jun 08, 2007 02:30:35 +0200:
>
> With git-filter-branch --subdirectory-filter <subdirectory> you can
> get at the history, as seen by a certain subdirectory. The history
> of the rewritten branch will only contain commits that touched that
> subdirectory, and the subdirectory will be rewritten to be the new
> project root.
>
Maybe it could be made more general
--subdirectory-filter <from> [--subdirectory-filter-to <to>]
<to> meaning root by default, and allow multiple filters to be set?
You would have to deal with file name conflicts in case some filters
refer to the same target directory, though.
It has already been asked how to split a project into many projects
based on directory boundaries. That'd help...
^ permalink raw reply
* Re: gitk highlighting commits
From: Jan Hudec @ 2007-06-08 21:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: picca, git
In-Reply-To: <20070608065739.GC18521@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Fri, Jun 08, 2007 at 02:57:39 -0400, Shawn O. Pearce wrote:
> picca <picca@synchrotron-soleil.Fr> wrote:
> > I am using git to follow the wine development. And I wondering if it
> > is possible to highlight all the commit since my last git pull ?
>
> If you do it *right after* the pull, you can see those commits that
> are new to you with:
>
> gitk ORIG_HEAD..
>
> ORIG_HEAD is a special name for the commit that you had just before
> you pulled. So you are asking gitk to show you all commits that
> are now in your current branch (implied by nothing to the right of
> the ..) that were not in your branch before the pull (ORIG_HEAD).
> That is the stuff you just pullled.
>
> If its many days later that you want to look at this and you have
> done some things that overwrite ORIG_HEAD (git reset; git rebase;
> etc.) then this becomes more difficult. But you can also do by
> time:
>
> gitk HEAD@{2.days.ago}..
There is actually one ref which only changes in pulls (and fetches) -- the
tracking brach. Therefore:
gitk origin/master@{1}..
(or whatever you pull) is what you want.
> This shows you everything that is new *to you* in the past two days.
> Even if the changes were created months ago and just recently were
> pulled by you yesterday, they will appear in gitk, because you asked
> for *your* history over the past two days, not the project history.
>
> These same tricks also work with git-log of course:
>
> git log ORIG_HEAD...
> git log HEAD@{2.days.ago}..
>
> You could also take a look at the manual page for git-rev-parse,
> there are some more details covered there I think.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 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