* John Ellson ([EMAIL PROTECTED]) wrote:
rpmbuild -ta cogito-0.12.tar.gz fails because cogito.spec.in refers to
.bz2 in its Source: line, instead of to .gz.
Just grab the .bz2, or the SRPM http://kernel.org/pub/software/scm/cogito/RPMS
(still mirroring, I just uploaded it a bit ago)
This is
* Petr Baudis ([EMAIL PROTECTED]) wrote:
I'm happy to announce the release of the 0.12 version of the Cogito
SCM-like layer over Linus' GIT tree history storage tool. Get it at
http://www.kernel.org/pub/software/scm/cogito/
RPMs uploading to:
Dear diary, on Wed, Jul 06, 2005 at 02:01:38PM CEST, I got a letter
where Brian Gerst [EMAIL PROTECTED] told me that...
Petr Baudis wrote:
Also, I've deprecated rsync, as I explained in another mail. Use
cg-branch-chg to change the branch URLs to some more sensible scheme -
most likely HTTP,
Dear diary, on Wed, Jul 06, 2005 at 08:40:00PM CEST, I got a letter
where John Ellson [EMAIL PROTECTED] told me that...
rpmbuild -ta cogito-0.12.tar.gz fails because cogito.spec.in refers to
.bz2 in its Source: line, instead of to .gz.
(FYI, cogito.spec.in is Chris' sole teritorry in Cogito, so
Chris Wright wrote:
* John Ellson ([EMAIL PROTECTED]) wrote:
rpmbuild -ta cogito-0.12.tar.gz fails because cogito.spec.in refers to
.bz2 in its Source: line, instead of to .gz.
Just grab the .bz2, or the SRPM http://kernel.org/pub/software/scm/cogito/RPMS
(still mirroring, I just
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
GHz [ MoBo: Intel E7520, intel 82801 ]
but kernel hangs on boot right after records:
Booting processor 2/1 rip
Chris Wright wrote:
* John Ellson ([EMAIL PROTECTED]) wrote:
But:
cd cogito
cg-update
make dist
rpmbuild -ta cogito-0.12.tar.gz
still doesn't work.Do you have a different process for generating
the initial cogito-0.12-1src.rpm ?
I start from the bz2 from kernel.org.
* John Ellson ([EMAIL PROTECTED]) wrote:
So now I have to ask, where does that come from if its not created by
make dist ?
It's automated by kernel.org mirroring (along with signature
generation). So .gz is built, uploaded, the rest is automatic.
Is what I'm asking to do in the above
I have two questions on rev-list --objects.
(1) Would it make sense to have an extra flag to rev-list
--objects to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
produced
Linus,
You'll find the necessary infrastructure for doing an rpm build here:
kernel.org/pub/scm/linux/kernel/git/chrisw/git.git
The diff is below:
diff-tree a9db297485a7b8c641d3cf686d03cb63b774e530 (from
dd7ba8b4949535c24e604a37709db0e3be9ccbbc)
Author: Chris Wright [EMAIL PROTECTED]
On Wed, 2005-07-06 at 21:48 -0700, Tony Luck wrote:
Groan ... as well you should.
My tree has re-appeared now. Thanks to whoever fixed it.
I noticed similar effects recently. Its related to the mirroring of
master.kernel.org to the public server. At some point you have only the
half of
On Thu, 7 Jul 2005, Junio C Hamano wrote:
(1) Would it make sense to have an extra flag to rev-list
--objects to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
The current error message does not make any sense.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
pack-check.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
c3818dc056d1a603e15fe3f862849eddaee2a7c3
diff --git a/pack-check.c b/pack-check.c
--- a/pack-check.c
+++
LT == Linus Torvalds [EMAIL PROTECTED] writes:
(2) When showing --objects, it lists the top-level tree node
with no name, which makes it indistinguishable from commit
objects by pack-objects, probably impacting the delta logic.
Would something like the following patch make sense, to name
Linus Torvalds [EMAIL PROTECTED] writes:
That said, I really think the dumb protocols are useless anyway. No other
system supports pure static object pulling anyway, and as far as I'm
concerned, I want rsync to kind of work (but it won't be optimal, since
re-packing will delete all the old
Hello,
I have problems with Cogito-0.12 when trying to clone a local tree:
My original tree is in /git/u-boot-denx (imported from CVS); /git
is a directory mounted over NFS; all this is under Fedora Core 4 in
case it matters:
- cd /git/u-boot-denx
- cg-tag-ls
This adds --self-sufficient flag to git-repack-script, and uses
it when preparing the dumb server material.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
*** This makes things easier for the dumb puller because
*** self-sufficient pack means less falling back on traditional
*** http-pull.
When --objects=self-sufficient is specified instead of usual
--objects, rev-list shows all objects reachable from trees
associated with the commits in its output. This can be used to
ensure that a single pack can be used to recreate the tree
associated with every commit in it.
Signed-off-by:
So, what _is_ then the way to pull now, actually? If we use rsync, won't
we end up with having the objects we previous had twice now?
Rsync works fine. You can either unpack the pack you get, or, if you
prefer, just run
git-prune-packed
cg-update from a local repo that contains
TL == Tony Luck [EMAIL PROTECTED] writes:
TL Also git-fsck-cache in a repo that is fully packed complains:
TLfatal: No default references
git-fsck-cache --full, perhaps?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More
On Thu, 7 Jul 2005, Junio C Hamano wrote:
- if (!strcmp(arg, --objects)) {
+ if (!strncmp(arg, --objects, 9)) {
+ if (!strcmp(arg+9, =self-sufficient))
+ objects_self_sufficient = 1;
This is nasty - if you mis-spell
On Thu, 7 Jul 2005, Tony Luck wrote:
So, what _is_ then the way to pull now, actually? If we use rsync, won't
we end up with having the objects we previous had twice now?
Rsync works fine. You can either unpack the pack you get, or, if you
prefer, just run
cg-update from a local repo that contains packs is broken though :-(
Is this with cg-0.12? The most recent release should be happy with packs.
Yes ... I pulled, built and installed the latest cogito this afternoon
before trying
to touch anything involving packs. cg-version says:
On Thu, 7 Jul 2005, Linus Torvalds wrote:
cg-update from a local repo that contains packs is broken though :-(
Is this with cg-0.12? The most recent release should be happy with packs.
Ahh, I see it. It's because it uses git-local-pull, and yes,
git-local-pull does the old filename
LT == Linus Torvalds [EMAIL PROTECTED] writes:
LT This is nasty - if you mis-spell self-sufficient (easy enough to do)
LT you'll never know the end result isn't what you expected. It won't warn
LT you in any way, it will just make a non-self-sufficient pack..
To match the change of flag name
Catalin Marinas [EMAIL PROTECTED] writes:
A new StGIT release is available from http://procode.org/stgit/
I think it would be good if it was possible to include diffstat output
in exported patches, something like this:
Added possibility to include diffstat output in exported patches.
PO == Peter Osterlund [EMAIL PROTECTED] writes:
PO I think it would be good if it was possible to include diffstat output
PO in exported patches, something like this:
PO Added possibility to include diffstat output in exported patches.
And you wuold want to do things similarly to what others
On Thu, 7 Jul 2005, Junio C Hamano wrote:
Again you are right. How about --full-objects instead?
I don't mind the --objects=xxx format per se, but it would need to
verify that the =xxx was either valid or wasn't there at all. So what I
objected to was not that it was easy to mis-spell,
Eric W. Biederman wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
That said, I really think the dumb protocols are useless anyway. No other
system supports pure static object pulling anyway, and as far as I'm
concerned, I want rsync to kind of work (but it won't be optimal, since
re-packing
Linus Torvalds [EMAIL PROTECTED] writes:
On Thu, 7 Jul 2005, Eric W. Biederman wrote:
For optimizing network bandwidth that sounds like the way to go. For
adhoc development I don't know. For a central sever you still need
an authenticated way to push content, which makes it another
On Thu, 7 Jul 2005, Junio C Hamano wrote:
However it does not automatically mean that the avenue I have
been pursuing would not work; the server side preparation needs
to be a bit more careful than what I sent, which unconditionally
runs prune-packed. It instead should leave the files
31 matches
Mail list logo
