qgit-0.7
Here is qgit-0.7, a GUI git viewer. you can download from: http://prdownloads.sourceforge.net/qgit/qgit-0.7.tar.gz?download This time a small changelog, but a lot of work ;-) - rewrite of graph drawing - start-up loading: switch to use git-rev-list --topo-order - final fixes to annotation - cache of file lists to speed-up loading of file names - added color background on heads Graph now uses connected lines and should be better to follow, also the switch from home grown to legacy git-rev-list --topo-order helps in clarify revs history. Annotation now works for me in all cases with the limitation that does not follow renames. When you run qgit for the first time it takes some time to git-rev-list and git-diff-tree the repo. Following runs are faster because a persistent cache of file names is used, so the speed is the same of just running git-rev-list. Note: because of the use of --topo-order option in git-rev-list you need a very recent copy of git. For people who missed previous releases, a brief feature list: - revisions log with diff and file viewer windows - graph of development lines - automatic update of all open views when navigating through lists - filter by a substring (with wildcards support) in SHA, short log, author or paths - colored file list window: green new file, red removed one - patch viewer of diffs against parent, head or a mouse selected (CTRL + PRESS) rev - file viewer with automatic annotation of content and file history - file viewer with substring find function and jump to diff with double-click in annotate line - command line arguments support using git-rev-parse - highlight on tags and heads As usual, to try qgit: -unpack files -make -cd bin -copy qgit in the path -run qgit from a git working directory Please refer to README for more information. Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Stacked GIT 0.4
Stacked GIT 0.4 release is available from http://procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
Note that StGIT is not an SCM interface on top of GIT and it expects a
previously initialised GIT repository. For standard SCM operations,
either use plain GIT commands or the Cogito tool.
For more information, see the README file in the archive.
What's new in this release:
* Support for configuration files (/etc/stgitrc,
~/.stgitrc, .git/stgitrc)
* Configurable merge tool ('diff3' by default)
* Empty patches are marked with a '0' when listed with
'series' (useful for tracking upstream merges)
* Support for patch description templates (with variables like
author details and diffstats)
* 'files' command to show the files modified by a patch (either a
simple list or with diffstats)
* 'push --undo' option to cancel a push operation
* 'push/pop --to' option to perform the operation on a range of
patches between the given names
* 'push --reverse' option to push patches in reverse order
* 'diff --stat' option to show the diffstats instead of the diff
* Faster 'pop' - it now switches directly to the bottom of the
last patch to be popped
* The three files involved in a three-way merge are left in the
working tree in case of a conflict for further analysis (can be
overwritten with the 'keeporig' option)
* Many bug fixes
--
Catalin
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
tag referring to a commit but not directly?
I was playing with a tag that refers to another tag which refers
to a commit, and found out that some things did not work as I
expected.
Is it a PEBCAK on my part to expect tag-to-tag-to-commit to
behave the same way as a bare commit (or a tag to commit), or is
this just a bug? I think the following two would fix what I
found, but I am not sure if I am using the struct object and
friends the way they are expected to be used. I am uncertain
about what the expected behaviour should be either for that
matter; I admit that tags are new to me.
---
*** To find whom to ask about the thing I am butchering, I
*** used the following pickaxe:
git-rev-list linus |
git-diff-tree --stdin -v -s \
-S' if (obj-type == tag_type)
obj = ((struct tag *)obj)-tagged;'
git-rev-list linus |
git-diff-tree --stdin -v -s \
-S' /*
* Tag object? Look what it points to..
*/
if (object-type == tag_type) {'
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff 0:5
# - master: format-patch: fix skipping of blank-lines (take 2)
# + 5: tag deref until we get non tag
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
if (!obj)
return NULL;
- if (obj-type == tag_type)
- obj = ((struct tag *)obj)-tagged;
+ while (obj-type == tag_type)
+ obj = parse_object(((struct tag *)obj)-tagged-sha1);
+
return check_commit(obj, sha1);
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -354,12 +354,12 @@ static struct commit *get_commit_referen
/*
* Tag object? Look what it points to..
*/
- if (object-type == tag_type) {
+ while (object-type == tag_type) {
struct tag *tag = (struct tag *) object;
object-flags |= flags;
if (tag_objects !(object-flags UNINTERESTING))
add_pending_object(object, tag-tag);
- object = tag-tagged;
+ object = parse_object(tag-tagged-sha1);
}
/*
Compilation finished at Sat Jul 9 02:37:16
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] add -N option to cg-add (resent)
(resending cogito patches)
Add the -N option to cg-add.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-add | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -13,20 +13,35 @@
# is that 'Cogito' manages content and empty directories have no content.
# Instead, directories are added automatically when adding files inside
# them.
+#
+# OPTIONS
+# ---
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE=cg-add FILE...
+USAGE=cg-add [-N] FILE...
. ${COGITO_LIB}cg-Xlib
[ $1 ] || usage
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=--info-only
+ else
+ optfail
+ fi
+done
+
TMPFILE=$(mktemp -t gitadd.XX) || exit 1
-find $@ -type f -print0 $TMPFILE || {
+find [EMAIL PROTECTED] -type f -print0 $TMPFILE || {
die not all files exist, nothing added
rm $TMPFILE
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add --
+cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] add -N option to cg-init (resent)
(resending cogito patches)
Add the -N option to cg-add.
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-add | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -13,20 +13,35 @@
# is that 'Cogito' manages content and empty directories have no content.
# Instead, directories are added automatically when adding files inside
# them.
+#
+# OPTIONS
+# ---
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE=cg-add FILE...
+USAGE=cg-add [-N] FILE...
. ${COGITO_LIB}cg-Xlib
[ $1 ] || usage
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=--info-only
+ else
+ optfail
+ fi
+done
+
TMPFILE=$(mktemp -t gitadd.XX) || exit 1
-find $@ -type f -print0 $TMPFILE || {
+find [EMAIL PROTECTED] -type f -print0 $TMPFILE || {
die not all files exist, nothing added
rm $TMPFILE
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add --
+cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linus kernel tree corrupt?
On Fri, Jul 08, 2005 at 10:06:09AM -0700, Tony Luck wrote: On 7/8/05, Jon Smirl [EMAIL PROTECTED] wrote: What happened in this session... Linus has packed his GIT tree ... and now http-pull doesn't work. rsync still does (provided you have a new enough cogito). So does that mean we should ignore cogito's whinging about rsync being deprecated? -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] add -N option to cg-init (resent again)
(resending cogito patches)
add the -N option to cg-init
Signed-off-by: Bryan Larsen [EMAIL PROTECTED]
---
cg-init | 22 +++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -10,13 +10,29 @@
#
# If `cg-init` is run in a non-empty directory files in the top and
# sub directory will automatically be added.
+#
+# OPTIONS
+# ---
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE=cg-init
+USAGE=cg-init [-N]
_git_repo_unneeded=1
. ${COGITO_LIB}cg-Xlib
-uri=$1
+
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=-N
+ else
+ optfail
+ fi
+done
+
+uri=$ARGV
[ -e $_git ] die $_git already exists
@@ -38,7 +54,7 @@ if [ $uri ]; then
echo Cloned (origin $uri available as branch \origin\)
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add
+ find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
cg-commit -C -mInitial commit -E
fi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
What broke snapshots now?
Does git on master.kernel.org need to be updated to handle packed objects? See attached. Linus, please could you add the snapshot script to your regression testing? http://david.woodhou.se/git-snapshot.sh It'd be good to keep that working without too much manual intervention. -- dwmw2 ---BeginMessage--- + case `hostname` in ++ hostname + export PATH=/home/dwmw2/cogito:/usr/bin:/bin + PATH=/home/dwmw2/cogito:/usr/bin:/bin + export BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + STAGINGLOCK=/staging/upload.lock + FINAL=/pub/linux/kernel/v2.6/snapshots + '[' '!' -d /pub/scm/linux/kernel/git/torvalds/linux-2.6.git ']' + export WORK_DIRECTORY=/home/dwmw2/snapshots/2.6 + WORK_DIRECTORY=/home/dwmw2/snapshots/2.6 + export SNAP_TAG_DIRECTORY=/home/dwmw2/snapshots/2.6/tags + SNAP_TAG_DIRECTORY=/home/dwmw2/snapshots/2.6/tags + export STAGE=/home/dwmw2/snapshots/2.6/stage + STAGE=/home/dwmw2/snapshots/2.6/stage + export SHA1_FILE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects + SHA1_FILE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects ++ ls -rt /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.11 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.11-tree /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc2 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc3 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc4 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc5 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc6 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc1 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc2 ++ tail -n1 ++ sed s:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v:: + RELNAME=2.6.13-rc2 ++ cat /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc2 + RELOBJ=c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19 ++ tail -n1 ++ sed s:/home/dwmw2/snapshots/2.6/tags/v:: ++ ls -rt /home/dwmw2/snapshots/2.6/tags/v2.6.13-rc2-git1 + SNAPNAME=2.6.13-rc2-git1 + '[' 2.6.13-rc2-git1 == '' ']' ++ cat /home/dwmw2/snapshots/2.6/tags/v2.6.13-rc2-git1 + LASTOBJ=c101f3136cc98a003d0d16be6fab7d0d950581a6 ++ echo 2.6.13-rc2-git1 ++ sed 's/^.*-git//' + OLDGITNUM=1 ++ expr 1 + 1 + NEWGITNUM=2 + CURNAME=2.6.13-rc2-git2 ++ tree-id c101f3136cc98a003d0d16be6fab7d0d950581a6 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c1/01f3136cc98a003d0d16be6fab7d0d950581a6: No such file or directory fatal: git-cat-file c101f3136cc98a003d0d16be6fab7d0d950581a6: bad file Invalid id: c101f3136cc98a003d0d16be6fab7d0d950581a6 usage: git-cat-file [-t | tagname] sha1 usage: git-cat-file [-t | tagname] sha1 Invalid id: + LASTTREE= ++ cat /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD + CURCOMM=a92b7b80579fe68fe229892815c750f6652eb6a9 ++ tree-id a92b7b80579fe68fe229892815c750f6652eb6a9 + CURTREE=7fd73e9f39bf6003cc3188a10426b62d8c47ab40 ++ tree-id c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c5/21cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: No such file or directory fatal: git-cat-file c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: bad file Invalid id: c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19 usage: git-cat-file [-t | tagname] sha1 usage: git-cat-file [-t | tagname] sha1 Invalid id: + RELTREE= + echo release 2.6.13-rc2 commit tree release 2.6.13-rc2 commit tree ++ git-cat-file -t c101f3136cc98a003d0d16be6fab7d0d950581a6 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c1/01f3136cc98a003d0d16be6fab7d0d950581a6: No such file or directory fatal: git-cat-file c101f3136cc98a003d0d16be6fab7d0d950581a6: bad file + echo last c101f3136cc98a003d0d16be6fab7d0d950581a6 tree last c101f3136cc98a003d0d16be6fab7d0d950581a6 tree + echo head a92b7b80579fe68fe229892815c750f6652eb6a9 tree 7fd73e9f39bf6003cc3188a10426b62d8c47ab40 head a92b7b80579fe68fe229892815c750f6652eb6a9 tree 7fd73e9f39bf6003cc3188a10426b62d8c47ab40 + '[' '' == 7fd73e9f39bf6003cc3188a10426b62d8c47ab40 ']' ++ echo 2.6.13-rc2-git2 ++ cut -f2- -d- + EXTRAVERSION=-rc2-git2 + cd /home/dwmw2/snapshots/2.6/stage + rm -rf tmp-empty-tree + mkdir -p tmp-empty-tree/.git + cd tmp-empty-tree + git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/f8/640c306db2d583b9a30f2e52f8fb0a4cf624e0: No such file or directory fatal: failed to unpack tree object a92b7b80579fe68fe229892815c750f6652eb6a9 + git-checkout-cache Makefile checkout-cache: Makefile is not in the cache. + perl -pi -e 's/EXTRAVERSION =.*/EXTRAVERSION = -rc2-git2/' Makefile Can't open Makefile: No such file or directory. + git-diff-cache -m -p + gzip -9 usage: diff-cache [-r] [-z] [-p] [-i] [--cached] tree sha1 + echo
Re: arch 2.0 first source available (git related)
On Sat, 2005-07-09 at 13:39 +0200, Petr Baudis wrote: Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter where Thomas Lord [EMAIL PROTECTED] told me that... 2.0 is very much git influenced but it brings some (imo significant) improvements to the table. Could you list some of the things interesting for us? What is the benefit of a prereq graph compared to just having a single shared object database? From the documentation, that's the only interesting thing I noticed which is different from git (and things like artificially limiting filename length to 256 characters). Well, partly the statement about improvements was a hint to look beyond the docs to the code but... The prereq graph is, indeed, an improvement. It: * speeds up and simplifies blob-db GC * vastly improves the possibilities for archive integrity checking * can be used for smart, streamy network mirroring of revisions * allows people to commit the same tree multiple ways: e.g., once optimizing access for users who frequently read incremental updates and a second time for users who only update at named releases * helps make the system securable (current code isn't yet) against the possibility of multiple files with identical fingerprints but different contents in the same or related trees * helps in a variety of ways when it comes time to make `revc' operable over a network -- committing to a remote archive. Other advantageous (imo) changes from `git' not mentioned in the original message: * blobs do not have header lines Git blobs all begin with a line of text declaring the type and size of the blob. That doesn't increase database verifiability significantly and I found no use for the headers. Having the headers makes it needlessly complicated to translate a file to or from a blob. `revc' does not have blob headers. * `revc' uses portable file formats In working dirs, `git' stores binary files which are endian, word-size, and compiler-environment specific. `revc' stores some binary files too (for performance and simplicity reasons) but uses only portable formats. * `revc' is shaping up into much cleaner and more portable code (at least compared to the last version of `git' I saw -- which was extremely *lucid* code but not terribly clean and not even attempting to be portable.) The list goes on and I don't promise to be picking the most interesting items from it according to anybody's particular metric of interesting. revc -- probably strange yet familiar to git hackers, -t - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qgit-0.7
Wolfgang Denk ha scritto:
Dear Marco,
in message [EMAIL PROTECTED] you wrote:
Here is qgit-0.7, a GUI git viewer.
Sorry, but I cannot compile it on a Fedora Core 4 system:
- ./configure
+scons was found, that's excellent+
scons: Reading SConscript files ...
- make
scons -Q
g++ -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/lib64/qt-3.3/include -c -o
src/annotate.o
src/annotate.cpp
src/annotate.cpp: In member function `QStringList Annotate::processDiff(const
QString, QStringList, const QString)':
src/annotate.cpp:378: error: jump to case label
src/annotate.cpp:373: error: crosses initialization of `int num'
src/annotate.cpp:387: error: jump to case label
src/annotate.cpp:373: error: crosses initialization of `int num'
src/annotate.cpp:401: error: jump to case label
src/annotate.cpp:373: error: crosses initialization of `int num'
scons: *** [src/annotate.o] Error 1
make: *** [all] Error 2
The following patch solves this problem:
--- src/annotate.cpp.ORIG 2005-07-09 07:10:23.0 +0200
+++ src/annotate.cpp 2005-07-09 16:05:09.556653902 +0200
@@ -370,10 +370,12 @@
char firstChar = line[0].latin1();
switch (firstChar) {
case '@':
+ {
int num = line.section(',', 1, 1). section('+', 1,
1).toInt();
// diff lines start from 1, 0 is empty file,
// instead QValueList::at() starts from 0
cur = (num 0) ? newAnn.at(num - 1) : newAnn.end();
+ }
break;
case '+':
if (cur != newAnn.end()) {
Thanks for your patch, applied.
What version og gcc you have?
Mine is gcc version 4.0.1 and I don't have this compile error (of course ;-) ).
I have cc'ed to git@vger.kernel.org in case someone else have the same problem.
With this patch, I get a lot of build errors:
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
QSettings: error creating /.qt
QSettings::sync: filename is null/empty
...
It links and seems to run, though.
It's a known issue, probably due to scons setup, but I am not so familiar with
scons
to find a fix, in any case should be absolutely painless.
Marco
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What broke snapshots now?
On Sat, 9 Jul 2005, David Woodhouse wrote: Does git on master.kernel.org need to be updated to handle packed objects? See attached. Yes, looks that way. Except it's not git on master.kernel.org, it's git in your home directory, I suspect. I expressly held off packing the kernel repo until git had been updated on kernel.org. So while the regular git on kernel.org should already be up-to-date, you have PATH=/home/dwmw2/cogito:/usr/bin:/bin in your script ;) Linus, please could you add the snapshot script to your regression testing? http://david.woodhou.se/git-snapshot.sh None of the git-specific parts should have broken - you don't even do anything strange there, I think we already have regression tests in git for everything you use. But the fact that you had an old version is not something I can do much about ;) Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito Mac OS X compatibility
On Fri, Jul 08, 2005 at 07:34:55PM -0400, Bryan Larsen wrote: This appears to be some sort of weird shell thing. I've got bash 3.0 compiling in the background to see if that fixes the problem. Sounds like you're missing stat from coreutils. skimo - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linus kernel tree corrupt?
Petr Baudis wrote: Yes, please do. I deprecated rsync a day before Linus broke http-pull. It's un-deprecated again for now in the latest Cogito. Presumably for packed repos you want to drop the --ignore-existing --whole-file options I assume? Also, pulling with cogito-0.12: cg-clone -s rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ I still get: receiving file list ... done master sent 147 bytes received 863 bytes 2020.00 bytes/sec total size is 41 speedup is 0.04 receiving file list ... done progress: 1929 objects, 5796451 bytes, 100% done pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.idx pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack sent 42599 bytes received 73373124 bytes 451789.06 bytes/sec total size is 73178114 speedup is 1.00 receiving file list ... done v2.6.11 v2.6.11-tree v2.6.12 v2.6.12-rc2 v2.6.12-rc3 v2.6.12-rc4 v2.6.12-rc5 v2.6.12-rc6 v2.6.13-rc1 v2.6.13-rc2 sent 339 bytes received 1802 bytes 4282.00 bytes/sec total size is 410 speedup is 0.19 Missing object of tag v2.6.11... different source (obsolete tag?) Missing object of tag v2.6.11-tree... different source (obsolete tag?) Missing object of tag v2.6.12... different source (obsolete tag?) Missing object of tag v2.6.12-rc2... different source (obsolete tag?) Missing object of tag v2.6.12-rc3... different source (obsolete tag?) Missing object of tag v2.6.12-rc4... different source (obsolete tag?) Missing object of tag v2.6.12-rc5... different source (obsolete tag?) Missing object of tag v2.6.12-rc6... different source (obsolete tag?) Missing object of tag v2.6.13-rc1... different source (obsolete tag?) Missing object of tag v2.6.13-rc2... different source (obsolete tag?) New branch: 0109fd37046de64e8459f8c4f4706df9ac7cc82c Cloned (origin rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git available as branch origin) Cloned to ./ (origin rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git available as branch origin) Is the missing objects thing spurious? -hpa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cogito Mac OS X compatibility
Sounds like you're missing stat from coreutils. skimo Thanks. I've got it working to the point where it passes make test now. All I had to do was install coreutils and findutils from darwinports, and then make gcp, gstat and gnuxargs available under their standard names. Do the BSD's or Solaris have the same problem? Last time I used them they didn't have the gnu options available on their standard utils, but that was ages ago. If current BSD's have the problem, it might be worth expending some effort to make cogito more portable. If it's only OS X... Bryan - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Cogito-0.12
On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote: On Thu, Jul 07, 2005 at 05:23:26PM -0700, Linus Torvalds wrote: On Thu, 7 Jul 2005, Tony Luck wrote: This is what happens (linus is a local branch just pulled from kernel.org, so it just contains one pack file and its index). $ cg-update linus `/home/aegl/GIT/linus/.git/refs/heads/master' - `.git/refs/heads/linus' does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69 798458e067 Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067 while processing commit . cg-pull: objects pull failed Ok. The immediate fix is to just unpack the pack: mv .git/objects/pack/* .git/ for i in .git/*.pack; do git-unpack-objects $i; done (or similar - the above is untested, but I think it should be obvious enough what I'm trying to do). This is evil on the bandwidth, since you'll keep refetching the packed object (64MB of it) over and over. However, I've tried the above, and I get: $ mv .git/objects/pack/* .git/ $ for i in .git/*.pack; do git-unpack-objects $i; done Unpacking 55435 objects fatal: inflate returned -3 so it seems that the pack is corrupt... or something. $ md5sum .git/*.pack 2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack and git-fsck-cache produces lots and lots of: dangling tree fae688b62db0b553aae0bf17f0f70e93819dec2b broken link fromtree faed7d798b84f107dbb9ff8fa97fb909c9ea5347 toblob 008e19210e66f01fbaef1aba30243850766b8b12 broken link fromtree faed7d798b84f107dbb9ff8fa97fb909c9ea5347 toblob edae09a4b021e353ab4fbba756e31492fbb8fd2e broken link fromtree faed7d798b84f107dbb9ff8fa97fb909c9ea5347 toblob d098b3ba35384fb912989348fd6da59820711ca4 ... etc ... Additional information: x86 box, running FC2, cogito 0.12 built from the src.rpm on kernel.org. Lots of disk space (blocks + inodes) remaining. Pretty please can we stop breaking rmk's git/cogito/repos/scripts ? -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What broke snapshots now?
On Sat, 2005-07-09 at 09:15 -0700, Linus Torvalds wrote: Yes, looks that way. Except it's not git on master.kernel.org, it's git in your home directory, I suspect. I expressly held off packing the kernel repo until git had been updated on kernel.org. Doh. I thought I'd already done that, but in fact that was for the scripts which feed the mailing list, while the snapshot script kept using my copy. I've moved it out of the way now; sorry for the noise. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
