Johannes Schindelin <[EMAIL PROTECTED]> writes:
> But maybe I just cried "wolf"...
I do not think you are crying wolf. I shared the same concern
from the beginning and that was partly why I was pushing for
the dumb server approach.
-
To unsubscribe from this list: send the line "unsubscribe gi
Petr Baudis <[EMAIL PROTECTED]> writes:
> Actually, HTTP should be working again now; but it's rather fresh yet so
> we should keep it rsync anyway for a while yet for the users of older
> GIT/Cogito versions.
My point being rsync://rsync.kernel.org/ vs http://www.kernel.org/.
-
To unsubscribe f
* Petr Baudis ([EMAIL PROTECTED]) wrote:
> * Cogito is now alone!
> GIT is no longer part of Cogito distribution.
> That means you need to get and install it separately.
> It is recommended to use at least 0.99.3. The newer
> the better
Dear diary, on Fri, Aug 05, 2005 at 04:00:03AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > http://git.or.cz/
>
> Wonderful.
>
> Once the page contents stabilizes, it would be a good idea to
> get it added in th
Hi,
I'm happy to announce release 0.13 of the Cogito SCMish layer over the
GIT Tree History Storage tool. As usual, get it at:
http://www.kernel.org/pub/software/scm/cogito
Highlights:
* Cogito is now alone!
GIT is no longer part of Cogito distribution.
Petr Baudis <[EMAIL PROTECTED]> writes:
> http://git.or.cz/
Wonderful.
Once the page contents stabilizes, it would be a good idea to
get it added in the page top links of http://www.kernel.org/git
page. Sorry, I do not know who is in charge of configuring the
gitweb there.
BTW, it may be
Hello,
as I promised some time ago, I finally put together a simple GIT
homepage proposal now available at:
http://git.or.cz/
Basically, I took r3 of Ryan Anderson's synopsis, pruned and rewrote
it a bit, added some hypertext and tried to very briefly cover the
porcelain as well. P
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
Oh, I see. Then the "templates/Makefile building into
templates/blt and then installing if you say make install"
approach I described earlier would hopefully work perfectly well
for you. Just like you tack the $src to your $PATH, you can
define GI
[EMAIL PROTECTED] writes:
> ... I seem to recall a patch to create subdirectories of
> .git/refs on demand (needed for tags/v99/1). I'd say just
> .git/objects/(everything), .git/refs, and .git/info.
Having thought about this a bit more, I am inclined to drop
this. I see the template mechanism t
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Junio, maybe there should be some test-case for this:
>
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
> commit
> error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local
> ref 'refs/tags/v2.6.11'.
Dear diary, on Mon, Aug 01, 2005 at 04:49:37AM CEST, I got a letter
where Martin Langhoff <[EMAIL PROTECTED]> told me that...
> On a new machine, trying to boostrap into latest cogito, I download
> and make cogito 0.12.1, and then...
>
> $ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git c
Dear diary, on Fri, Aug 05, 2005 at 02:06:13AM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> yes, sorry about this. Packs got there through rsyncs all the way from
> git-core, and my immediate naive git-unpack-objects didn't actually do
> anything since all the object
Dear diary, on Sun, Jul 31, 2005 at 02:42:28PM CEST, I got a letter
where Sergey Vlasov <[EMAIL PROTECTED]> told me that...
> Hello!
Hi,
> Today's pull from rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> downloaded more than 10 MB. It seems that the cogito.git repository
> currently contai
Junio, maybe there should be some test-case for this:
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
commit
error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local
ref 'refs/tags/v2.6.11'.
error: Object 5dc01c595e6c6ec9ccda4f6f69c13
$DESTDIR is more usual during the build than $dest and is what is usually
used in the makefiles, so let's use it too.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
This updates the subdirectory Makefiles as well.
commit aef274d1fc04d848c7355a68c3e48c0b2b5400cb
tree 546c10ded595cf48
Dear diary, on Thu, Aug 04, 2005 at 10:47:19PM CEST, I got a letter
where Wolfgang Denk <[EMAIL PROTECTED]> told me that...
> Building of RPM's from the current cogito tree fails:
>
> -> rpmbuild -ba cogito.spec
> ...
> make -C tools install
> make[1]: Entering directory `/usr/local/BUILD/cogito-
Hi,
the following snippet adds git_mkstemp() to libgit (path.c).
/holger
add git_mkstemp() to libgit
---
commit 1a1f2cb5c27ed26e6ef8dd34209e561bdf256c22
tree 868b67b55978394d288ac4f2ca8edcbbad4355bd
parent 10833f5e7d0da63ca976607864282d41b5faff1b
author Holger Eitzenberger <[EMAIL PROTECTED]> T
Building of RPM's from the current cogito tree fails:
-> rpmbuild -ba cogito.spec
...
make -C tools install
make[1]: Entering directory `/usr/local/BUILD/cogito-0.12.1/tools'
gcc -g -O2 -Wall -o git-mailsplit mailsplit.c
gcc -g -O2 -Wall -o git-mailinfo mailinfo.c
install -m755 -d /usr/bin
instal
prep_temp_blob: use git_mkstemp() instead of mkstemp()
/holger
prep_temp_blob: use git_mkstemp() instead of mkstemp()
---
commit 43bac92063c8dd8d88b33cb838530d4bb3dcad25
tree aeb8bdc2aa285df1fc4888e66fe88b4a8a5e2b3b
parent 1a1f2cb5c27ed26e6ef8dd34209e561bdf256c22
author Holger Eitzenberger <[EMA
Dear diary, on Mon, Aug 01, 2005 at 10:44:02PM CEST, I got a letter
where Holger Eitzenberger <[EMAIL PROTECTED]> told me that...
> Hi,
Hi,
> please see the notes of my first email, thx.
I don't know. Is this really a good idea? The names are lowercase and
may be whatever mess some build scripts
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Sorry, I am so used to not installing in my home because of small quotas
> :-(
>
> Anyway, my usual setup is that I check git out from my private branch, add
> that directory to my path, and every once in a while do a "git pull origin
> && make
Use instead of two spaces uniformly in the Makefile, even in the
ifdefs. Gives it a nice consistent look.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit aa6f095b0cd57ab424f02695ccfc8168f5c3b981
tree 046906d724925998ec7f47efc26bab7e84052014
parent ccf4810a5187b6f13b809e659870101e66d198
$DESTDIR is more usual during the build than $dest and is what is usually
used in the makefiles, so let's use it too.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit ffc29a11e9be157e2349d431adadf1b6e91a2251
tree fbd1076ed78c609777f81094cb8989b5b32973da
parent aa6f095b0cd57ab424f02695ccf
As proposed on the mailing list previously, remove the seemingly obscure
$COPTS usage in favour of a default $CFLAGS value, which is a more usual
usage.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 3e90b732f2c1c5d6b3b460be0c17cd24f3932ced
tree 51f9664dbc8e3b72b9941e5ccf8de867c3fb35b1
On Thu, 4 Aug 2005, Johannes Schindelin wrote:
> > * Make git-init-db create an absolute minimum $GIT_DIR
> > structure itself, if the template directory is not available,
> > possibly with a warning.
>
> This would be exactly what I'd like. Let git-init-db create
> .git/objects/[0-9a-f]{2}/, .gi
I'm totally stupid and got it backwards, sorry about that.
git-merge-cache -q would mean it's noisy and quiet without any
parameters.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 1d86b5cb68dd47b4fced8343945c8860946df5d2
tree 25c4f9cabd6db8c92ab1b0313093d898c03b2b7a
parent 04c23173a81
Dear diary, on Wed, Aug 03, 2005 at 12:40:35AM CEST, I got a letter
where Sebastian Kuzminsky <[EMAIL PROTECTED]> told me that...
> Or am I missing something?
>
> The most recent commit to cogito makes the documentation depend on
> asciidoc.conf, but it looks like the actual config file was not ad
Dear diary, on Sat, Jul 30, 2005 at 04:11:48AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> By the way, do people mind my posting my own patches to the
> list? I keep the same in the "pu" (proposed updates) branch, so
> if the list readers think I am just adding
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
I will keep git-rev-list; used in Jeff's git-changes-script and
some parts of Cogito as well.
According to my grep's, these files use git-rev-list:
git-bisect-script
git-cherry
git-format-patch-script
git-log-script
git-repack-script
git-whatchan
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin <[EMAIL PROTECTED]> writes:
I'd like to not being forced to install git. Scenario: I have an SSH
account on a remote machine. I am not root there, but I'd like to
synchronize my work with git. I can not install git.
Sorry, bu
Hi,
I just tried to clone a relatively big repository from a slow machine to a
slow machine. I'm talking about a 1.2 gigabyte repository, packed down to
120 megabyte, containing more than 21000 commits. When git-clone-script
did not show anything for over 15 minutes, I decided to find out what
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 2 Aug 2005, Junio C Hamano wrote:
>>
>> How about git-rev-tree? Does anybody care?
>
> Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
> did.
I will keep git-rev-list; used in Jeff's git-changes-script and
some part
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> I'd like to not being forced to install git. Scenario: I have an SSH
> account on a remote machine. I am not root there, but I'd like to
> synchronize my work with git. I can not install git.
Sorry, but now you completely lost me. You want git,
Petr Baudis wrote:
-> cg-diff
fatal: unable to create new cachefile
fatal: unable to create temp-file
It would be nice if there was at least a way to specify some TMPDIR
instead of the current directory in such a situation.
This is a bug in git-diff-* (producing the second error message;
On Thu, 4 Aug 2005, Petr Baudis wrote:
> Dear diary, on Wed, Aug 03, 2005 at 07:11:00PM CEST, I got a letter
> where [EMAIL PROTECTED] told me that...
> > IIRC, git-local-pull still doesn't work for a packed source repository,
> > because it doesn't include the possibility of copying a pack (or
Dear diary, on Wed, Aug 03, 2005 at 08:20:01AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> I am not sure if this is the right fix, and I have not received
> an answer from the original author of the patch. I would
> appreciate help from the folks on the list who
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
Johannes Schindelin <[EMAIL PROTECTED]> writes:
This may be controversial from the robustness standpoint, so I
am placing it in the proposed update queue first. Discussions
on the list very welcomed.
I'd vote against it: As of now, I can perfec
Dear diary, on Wed, Aug 03, 2005 at 07:11:00PM CEST, I got a letter
where [EMAIL PROTECTED] told me that...
> IIRC, git-local-pull still doesn't work for a packed source repository,
> because it doesn't include the possibility of copying a pack (or
> extracting an object) if the requested object
Dear diary, on Wed, Aug 03, 2005 at 09:42:41AM CEST, I got a letter
where Wolfgang Denk <[EMAIL PROTECTED]> told me that...
> Hello,
>
> sometimes I have to work in trees for which I have only read
> permissions; cogito has problems then - for example:
>
> -> cg-diff
> fatal: unable to
Johannes Schindelin <[EMAIL PROTECTED]> writes:
>> This may be controversial from the robustness standpoint, so I
>> am placing it in the proposed update queue first. Discussions
>> on the list very welcomed.
>
> I'd vote against it: As of now, I can perfectly do
>
> export PATH=$PATH:/whereever/
I use the attached patch here and its helped me quite a bit. Thought
I'd send it out for others to use as well. Prior to 0.12 I could do
this in my own scripts after a cg-merge exited with conflicts. Resently
it seems 'git-ls-files --unmerged' will no longer list any files that
had conflicts dur
>
> 1. The kernel Makefiles ar do not understand every subtle dependency.
>So they might get confused by updating to different tree states (as
>the bisect progresses) because those updates change Makefiles and
>include files. In other words, I should have done 'make clean' or
>'ma
Dave Jones <[EMAIL PROTECTED]> writes:
> Em, if you don't compile/test those intermediate versions,
> how do you know whether to tag it good/bad ?
I think Sanjoy is saying that they _were_ tested, and suspects
that bisect didn't leave the right versions of the files in the
work tree, so what
Hi,
On Tue, 2 Aug 2005, Junio C Hamano wrote:
This may be controversial from the robustness standpoint, so I
am placing it in the proposed update queue first. Discussions
on the list very welcomed.
I'd vote against it: As of now, I can perfectly do
export PATH=$PATH:/whereever/my/git/is
git
> Em, if you don't compile/test those intermediate versions,
> how do you know whether to tag it good/bad ?
Sorry, I wrote this part carelessly: "If I had checked out and
compiled those intermediate versions from scratch..."
I meant to emphasize the 'from scratch'. I did check out and compil
On Thu, Aug 04, 2005 at 06:41:41PM +0100, Sanjoy Mahajan wrote:
> > By any chance, is this patch causing you problems?
>
> No, sadly. But I had hopes! As I think about it more, there's no way
> it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG
> would not change anything
> By any chance, is this patch causing you problems?
No, sadly. But I had hopes! As I think about it more, there's no way
it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG
would not change anything (for those who don't know the patch, it is
appended below).
My latest theor
On Thu, Aug 04, 2005 at 03:23:28AM -0400, Sanjoy Mahajan wrote:
> > Could you try this please?
>
> Thanks, it now finishes with the diff that I expected:
>
> 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
> diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from
> a18bcb7450840f07
The King Penguin says:
Now, for extra bonus points, maybe you should make "git-rev-list" also
understand the "rev..rev" format (which you can't do with just the
get_sha1() interface, since it expands into more).
The faithful servant makes it so.
Signed-off-by: Junio C Hamano <[EMAIL
On Thu, Aug 04, 2005 at 10:39:16AM +0200, Sven Verdoolaege wrote:
> On Wed, Aug 03, 2005 at 08:49:16PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > My apologies if this has already been found and reported; I'm not
> > tracking the list closely.
> >
> > It seems that newly introduced files are not
On Wed, Aug 03, 2005 at 08:49:16PM -0500, Olof Johansson wrote:
> Hi,
>
> My apologies if this has already been found and reported; I'm not
> tracking the list closely.
>
> It seems that newly introduced files are not shown in gitweb.
> For example, see the following commit:
>
> http://kernel.or
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Now, for extra bonus points, maybe you should make "git-rev-list" also
> understand the "rev..rev" format (which you can't do with just the
> get_sha1() interface, since it expands into more).
Hmph. That makes sense.
What I set out to do when I sta
> Could you try this please?
Thanks, it now finishes with the diff that I expected:
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit
diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from
a18bcb7450840f07a772a45229de4811d930f461)
Author: Greg KH <[EMAIL PROTECTED]>
Date: Wed Jul
53 matches
Mail list logo