* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Johannes Schindelin @ 2005-08-04 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll3hxykj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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/my/git/is
>> git-init-db
>>
>> which would not work with this patch.
>
> I take it to mean that you do not mind building but would want
> to try it out before installing.
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.
> * 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}/, .git/refs/heads/, .git/refs/tags and .git/HEAD.
Everything else is taken from the templates directory, if that exists. I
would not warn if it does not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] daemon.c: squelch error message from EINTR
From: Petr Baudis @ 2005-08-04 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe8fk0dq.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Aug 03, 2005 at 08:20:01AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> 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 are familiar with
> the networking.
I think it's fine. EINTR means it got a signal while waiting, it might
be worthwhile checking by strace what signal it actually was - one thing
coming on my mind is SIGPIPE or so, but I barely saw the code. Anyway,
just sticking your hand in sand if you see this is probably fine.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git-local-pull?
From: barkalow @ 2005-08-04 20:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050804201230.GC24479@pasky.ji.cz>
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 barkalow@iabervon.org 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 is in a pack.
> >
> > I can probably fix it if anyone cares, but it's not something I use
> > personally, so I don't know if it's worthwhile. It should probably be
> > removed if we don't fix it, since it will fail on any popular repository
> > at this point.
>
> I want to use it in Cogito again, since copying everything obviously
> sucks and I want to hardlink, so repacking is not a solution either.
> Didn't you post some patches to fix this long time ago, actually?
Not for local-pull; I only did the other two. local-pull is special,
because it's actually dealing with files on disk, and it also has to look
at a repository that isn't what you're using.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git: problems in read-only trees
From: Holger Eitzenberger @ 2005-08-04 20:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wolfgang Denk, git
In-Reply-To: <20050804201125.GB24479@pasky.ji.cz>
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; the first
> error message means failed git-update-cache --refresh but that isn't
> fatal). Any reason why prep_temp_blob() works in . instead of $TMPDIR?
I do not know about the first message (cachefile), but the 2nd one is
trivial to fix. I implemented a function called git_mkstemp() (path.c
and so in libgit) which places the tmpfiles in $TMPDIR and if it's not
set in /tmp. The is close to what other programs do.
There are other references to mkstemp() in git where one or two of them
may use git_mkstemp() instead, but not in sha1_file.c, since it
hardlinks it later on.
/holger
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Junio C Hamano @ 2005-08-04 20:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508042215430.24657@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> 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, you are
not root, you cannot install git system wide, so you run git
installed in your $HOME/bin somewhere instead. I think I am
following you correctly up to this point.
But if that is the case, I do not see where your objections to
the template directory installed somewhere under $HOME/etc comes
from, which is what the default Makefile does, or at least
attempts to.
^ permalink raw reply
* Re: Users of git-check-files?
From: Junio C Hamano @ 2005-08-04 20:59 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0508030808530.3341@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> 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 parts of Cogito as well.
^ permalink raw reply
* Experiences with git-clone-pack and rsync
From: Johannes Schindelin @ 2005-08-04 21:06 UTC (permalink / raw)
To: git
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's
happening. The server sat, partly swapping, partly git-rev-list'ing,
git-pack-objects dozing.
Now, I know some internals of git, so I went in and did an rsync, which is
perfectly reasonable, given that I do not need the server to unpack the
objects, pack them again, and then - after a while - sending them as they
were: packed. It took 60 seconds with -- evidently -- almost no load for
the server.
BTW, I am not quite sure why the machine started swapping. Maybe it was
some other process on that server, but it could have been git-rev-list
also, keeping those 21000 commits in memory in order to sort them. Or, it
could have been something worse: git holding lots and lots of objects in
memory.
So, I don't know if git-daemon, which basically does the same thing as
git-clone-pack on the server side, would not be a pretty good way to bring
git.kernel.org (once it exists) to a halt.
Maybe there should be some kind of heuristics in git-daemon, i.e.
git-count-objects in reverse, to decide if it is not better to (at least
optionally) just send the pack as is, even if it contains more objects
than the user actually asked for. Or, for big projects like the kernel,
just send the pack if at least one needed object is contained in it. Hey,
git-http-pull already does that :-)
But maybe I just cried "wolf"...
Ciao,
Dscho
P.S.: There is a serious flaw in git-fetch-pack, though, which probably
persists when using git-daemon as server: If interrupted, it does not kill
the remote git-rev-list and git-pack-objects. I can bring down my poor
server pretty easily by issuing "git pull", interrupting that,
and repeating that several times. Not sure how to fix that.
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Johannes Schindelin @ 2005-08-04 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jf1xw90.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 4 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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, you are
> not root, you cannot install git system wide, so you run git
> installed in your $HOME/bin somewhere instead. I think I am
> following you correctly up to this point.
>
> But if that is the case, I do not see where your objections to
> the template directory installed somewhere under $HOME/etc comes
> from, which is what the default Makefile does, or at least
> attempts to.
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 test". Right now, it works.
Ciao,
Dscho
^ permalink raw reply
* Re: Users of git-check-files?
From: Johannes Schindelin @ 2005-08-04 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vwtn1wh8u.fsf@assigned-by-dhcp.cox.net>
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-whatchanged
gitk
send-pack.c
upload-pack.c
So better keep it :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Status of git.git repository
From: Petr Baudis @ 2005-08-04 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhded6o0r.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jul 30, 2005 at 04:11:48AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> 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 noise to the list
> traffic, I would stop doing so, and instead just invite
> interested people to browse the "pu" branch.
Browsing the "pu" branch may be bothersome and you won't ensure that the
related discussion stays in a single thread, and posting the patches
here makes them generally more visible, so I think it's a good idea to
keep doing so.
Cogito (and Git itself as well, I guess) does not handle those
"volatile" branches well at all - following them is difficult since
Cogito will think that you did some local commits and want to do a tree
merge. Would anyone consider doing
if ref(updatebranch) == ref(master) then
merge: always_fastforward
else
merge: perhaps_treemerge
a Bad Thing (tm)? It seems to me that it should do the right thing and
never get it wrong.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: cogito missing asciidoc.conf?
From: Petr Baudis @ 2005-08-04 22:29 UTC (permalink / raw)
To: Sebastian Kuzminsky; +Cc: git
In-Reply-To: <E1E05R5-0005Pz-J9@highlab.com>
Dear diary, on Wed, Aug 03, 2005 at 12:40:35AM CEST, I got a letter
where Sebastian Kuzminsky <seb@highlab.com> 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 added.
Hm, cg-patch was broken again. Thanks, fixed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH] Fix git-merge-cache -q
From: Petr Baudis @ 2005-08-04 22:31 UTC (permalink / raw)
To: git
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 <pasky@ucw.cz>
---
commit 1d86b5cb68dd47b4fced8343945c8860946df5d2
tree 25c4f9cabd6db8c92ab1b0313093d898c03b2b7a
parent 04c23173a8120f3bd2ae8af545e7e4f62c505ef0
author Petr Baudis <pasky@suse.cz> Sat, 30 Jul 2005 13:07:03 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Sat, 30 Jul 2005 13:07:03 +0200
merge-cache.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/merge-cache.c b/merge-cache.c
--- a/merge-cache.c
+++ b/merge-cache.c
@@ -30,7 +30,7 @@ static void run_program(void)
if (one_shot) {
err++;
} else {
- if (quiet)
+ if (!quiet)
die("merge program failed");
exit(1);
}
@@ -129,7 +129,7 @@ int main(int argc, char **argv)
}
merge_file(arg);
}
- if (err && quiet)
+ if (err && !quiet)
die("merge program failed");
return err;
}
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: barkalow @ 2005-08-04 22:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508042215430.24657@wgmdd8.biozentrum.uni-wuerzburg.de>
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}/, .git/refs/heads/, .git/refs/tags and .git/HEAD.
> Everything else is taken from the templates directory, if that exists. I would
> not warn if it does not.
Are .git/refs/heads and .git/refs/tags still needed? 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.
(Plus template, if available, of course)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Kill $COPTS in favour of $CFLAGS
From: Petr Baudis @ 2005-08-04 22:52 UTC (permalink / raw)
To: git
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 <pasky@ucw.cz>
---
commit 3e90b732f2c1c5d6b3b460be0c17cd24f3932ced
tree 51f9664dbc8e3b72b9941e5ccf8de867c3fb35b1
parent f0487fa4109c37dc67439c40ad894ec73433f471
author Petr Baudis <pasky@suse.cz> Fri, 05 Aug 2005 00:47:34 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 05 Aug 2005 00:47:34 +0200
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,8 @@
GIT_VERSION=0.99.3
-COPTS?=-g -O2
-CFLAGS+=$(COPTS) -Wall $(DEFINES)
+CFLAGS?=-g -O2
+CFLAGS+=-Wall $(DEFINES)
prefix=$(HOME)
bindir=$(prefix)/bin
^ permalink raw reply
* [PATCH] Use $DESTDIR instead of $dest
From: Petr Baudis @ 2005-08-04 22:55 UTC (permalink / raw)
To: git
$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 <pasky@ucw.cz>
---
commit ffc29a11e9be157e2349d431adadf1b6e91a2251
tree fbd1076ed78c609777f81094cb8989b5b32973da
parent aa6f095b0cd57ab424f02695ccfc8168f5c3b981
author Petr Baudis <pasky@suse.cz> Fri, 05 Aug 2005 00:54:52 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 05 Aug 2005 00:54:52 +0200
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -41,7 +41,7 @@ prefix=$(HOME)
bindir=$(prefix)/bin
etcdir=$(prefix)/etc
etcgitdir=$(etcdir)/git-core
-# dest=
+# DESTDIR=
CC?=gcc
AR?=ar
@@ -197,8 +197,8 @@ check:
### Installation rules
install: $(PROG) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
- $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bindir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
+ $(INSTALL) $(PROG) $(SCRIPTS) $(DESTDIR)$(bindir)
$(MAKE) -C templates install
install-tools:
^ permalink raw reply
* [PATCH] Unify Makefile indentation
From: Petr Baudis @ 2005-08-04 22:52 UTC (permalink / raw)
To: git
Use <tab> instead of two spaces uniformly in the Makefile, even in the
ifdefs. Gives it a nice consistent look.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
---
commit aa6f095b0cd57ab424f02695ccfc8168f5c3b981
tree 046906d724925998ec7f47efc26bab7e84052014
parent ccf4810a5187b6f13b809e659870101e66d19807
author Petr Baudis <pasky@suse.cz> Fri, 05 Aug 2005 00:51:06 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 05 Aug 2005 00:51:06 +0200
Makefile | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -87,7 +87,7 @@ PROG= git-update-cache git-diff-files
git-update-server-info git-show-rev-cache git-build-rev-cache
ifndef NO_CURL
-PROG+= git-http-pull
+ PROG += git-http-pull
endif
LIB_FILE=libgit.a
@@ -129,18 +129,18 @@ else
OPENSSL_LIBSSL=
endif
ifdef MOZILLA_SHA1
- SHA1_HEADER="mozilla-sha1/sha1.h"
- LIB_OBJS += mozilla-sha1/sha1.o
+ SHA1_HEADER="mozilla-sha1/sha1.h"
+ LIB_OBJS += mozilla-sha1/sha1.o
else
ifdef PPC_SHA1
- SHA1_HEADER="ppc/sha1.h"
- LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
+ SHA1_HEADER="ppc/sha1.h"
+ LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
- SHA1_HEADER=<openssl/sha.h>
+ SHA1_HEADER=<openssl/sha.h>
ifeq ($(shell uname -s),Darwin)
- LIBS += -lcrypto -lssl
+ LIBS += -lcrypto -lssl
else
- LIBS += -lcrypto
+ LIBS += -lcrypto
endif
endif
endif
^ permalink raw reply
* Re: [PATCH] Use the template mechanism to set up refs/ hierarchy as well.
From: Junio C Hamano @ 2005-08-04 21:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508042311370.24861@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 test". Right now, it works.
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 GIT_TEMPLATE_DIRECTORY to $src/templates/blt. Problem
solved.
^ permalink raw reply
* Re: [PATCH 2/3] conditional makefile vars
From: Petr Baudis @ 2005-08-04 23:07 UTC (permalink / raw)
To: Holger Eitzenberger; +Cc: git
In-Reply-To: <42EE8992.5070204@my-eitzenberger.de>
Dear diary, on Mon, Aug 01, 2005 at 10:44:02PM CEST, I got a letter
where Holger Eitzenberger <holger@my-eitzenberger.de> 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 or whatever may set, or junk the
user has set inadvertently. And automake-generated Makefiles don't have
them conditional either.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH 1/1] git: use git_mkstemp() instead of mkstemp()
From: Holger Eitzenberger @ 2005-08-04 20:49 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
prep_temp_blob: use git_mkstemp() instead of mkstemp()
/holger
[-- Attachment #2: git_use_git_mkstemp.patch --]
[-- Type: text/x-patch, Size: 1201 bytes --]
prep_temp_blob: use git_mkstemp() instead of mkstemp()
---
commit 43bac92063c8dd8d88b33cb838530d4bb3dcad25
tree aeb8bdc2aa285df1fc4888e66fe88b4a8a5e2b3b
parent 1a1f2cb5c27ed26e6ef8dd34209e561bdf256c22
author Holger Eitzenberger <holger@my-eitzenberger.de> Thu, 04 Aug 2005 22:30:43 +0200
committer Holger Eitzenberger <holger@elmo.intranet.astaro.de> Thu, 04 Aug 2005 22:30:43 +0200
diff.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -41,11 +41,13 @@ static const char *external_diff(void)
return external_diff_cmd;
}
+#define TEMPFILE_PATH_LEN 50
+
static struct diff_tempfile {
const char *name; /* filename external diff should read from */
char hex[41];
char mode[10];
- char tmp_path[50];
+ char tmp_path[TEMPFILE_PATH_LEN];
} diff_temp[2];
static int count_lines(const char *filename)
@@ -421,8 +423,7 @@ static void prep_temp_blob(struct diff_t
{
int fd;
- strcpy(temp->tmp_path, ".diff_XXXXXX");
- fd = mkstemp(temp->tmp_path);
+ fd = git_mkstemp(temp->tmp_path, TEMPFILE_PATH_LEN, ".diff_XXXXXX");
if (fd < 0)
die("unable to create temp-file");
if (write(fd, blob, size) != size)
^ permalink raw reply
* [PATCH 1/1] git: add git_mkstemp()
From: Holger Eitzenberger @ 2005-08-04 20:43 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Hi,
the following snippet adds git_mkstemp() to libgit (path.c).
/holger
[-- Attachment #2: git_add_git_mkstemp.patch --]
[-- Type: text/x-patch, Size: 1720 bytes --]
add git_mkstemp() to libgit
---
commit 1a1f2cb5c27ed26e6ef8dd34209e561bdf256c22
tree 868b67b55978394d288ac4f2ca8edcbbad4355bd
parent 10833f5e7d0da63ca976607864282d41b5faff1b
author Holger Eitzenberger <holger@my-eitzenberger.de> Thu, 04 Aug 2005 22:28:32 +0200
committer Holger Eitzenberger <holger@elmo.intranet.astaro.de> Thu, 04 Aug 2005 22:28:32 +0200
cache.h | 3 +++
path.c | 26 ++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -174,7 +174,10 @@ extern char *mkpath(const char *fmt, ...
extern char *git_path(const char *fmt, ...);
extern char *sha1_file_name(const unsigned char *sha1);
+int git_mkstemp(char *path, size_t n, const char *template);
+
int safe_create_leading_directories(char *path);
+char *safe_strncpy(char *, const char *, size_t);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int unpack_sha1_header(z_stream *stream, void *map, unsigned long mapsize, void *buffer, unsigned long size);
diff --git a/path.c b/path.c
--- a/path.c
+++ b/path.c
@@ -58,3 +58,29 @@ char *git_path(const char *fmt, ...)
return bad_path;
return cleanup_path(pathname);
}
+
+
+/* git_mkstemp() - create tmp file honoring TMPDIR variable */
+int git_mkstemp(char *path, size_t len, const char *template)
+{
+ char *env, *pch = path;
+
+ if ((env = getenv("TMPDIR")) == NULL) {
+ strcpy(pch, "/tmp/");
+ len -= 5;
+ } else
+ len -= snprintf(pch, len, "%s/", env);
+
+ safe_strncpy(pch, template, len);
+
+ return mkstemp(path);
+}
+
+
+char *safe_strncpy(char *dest, const char *src, size_t n)
+{
+ strncpy(dest, src, n);
+ dest[n - 1] = '\0';
+
+ return dest;
+}
^ permalink raw reply
* Can't build RPM's from current cogito tree
From: Wolfgang Denk @ 2005-08-04 20:47 UTC (permalink / raw)
To: git, Petr Baudis
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
install: cannot change permissions of `/usr/bin': Operation not permitted
make[1]: *** [install] Error 1
make[1]: Leaving directory `/usr/local/BUILD/cogito-0.12.1/tools'
make: *** [install-tools] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.6363 (%install)
This fixes it:
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -245,10 +245,10 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
done
install-tools:
- $(MAKE) -C tools install
+ $(MAKE) -C tools dest=$(DESTDIR) install
install-doc:
- $(MAKE) -C Documentation install
+ $(MAKE) -C Documentation dest=$(DESTDIR) install
uninstall:
cd $(DESTDIR)$(bindir) && rm -f $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT)
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by at least
one instruction -- from which, by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* [PATCH] Use $DESTDIR instead of $dest
From: Petr Baudis @ 2005-08-04 23:56 UTC (permalink / raw)
To: git
In-Reply-To: <20050804225529.GJ24479@pasky.ji.cz>
$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 <pasky@ucw.cz>
---
This updates the subdirectory Makefiles as well.
commit aef274d1fc04d848c7355a68c3e48c0b2b5400cb
tree 546c10ded595cf48473ce216b594607fd922836d
parent aa6f095b0cd57ab424f02695ccfc8168f5c3b981
author Petr Baudis <pasky@suse.cz> Fri, 05 Aug 2005 01:55:36 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 05 Aug 2005 01:55:36 +0200
Documentation/Makefile | 6 +++---
Makefile | 6 +++---
templates/Makefile | 10 +++++-----
tools/Makefile | 6 +++---
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -33,9 +33,9 @@ man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
install:
- $(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7)
- $(INSTALL) $(DOC_MAN1) $(dest)/$(man1)
- $(INSTALL) $(DOC_MAN7) $(dest)/$(man7)
+ $(INSTALL) -m755 -d $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
+ $(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
+ $(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
# 'include' dependencies
git-diff-%.txt: diff-format.txt diff-options.txt
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -41,7 +41,7 @@ prefix=$(HOME)
bindir=$(prefix)/bin
etcdir=$(prefix)/etc
etcgitdir=$(etcdir)/git-core
-# dest=
+# DESTDIR=
CC?=gcc
AR?=ar
@@ -197,8 +197,8 @@ check:
### Installation rules
install: $(PROG) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
- $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bindir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
+ $(INSTALL) $(PROG) $(SCRIPTS) $(DESTDIR)$(bindir)
$(MAKE) -C templates install
install-tools:
diff --git a/templates/Makefile b/templates/Makefile
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -5,15 +5,15 @@ prefix=$(HOME)
etcdir=$(prefix)/etc
etcgitdir=$(etcdir)/git-core
templatedir=$(etcgitdir)/templates
-# dest=
+# DESTDIR=
all:
clean:
install:
- $(INSTALL) -d -m755 $(dest)$(templatedir)/hooks/
+ $(INSTALL) -d -m755 $(DESTDIR)$(templatedir)/hooks/
$(foreach s,$(wildcard hooks--*),\
$(INSTALL) -m644 $s \
- $(dest)$(templatedir)/hooks/$(patsubst hooks--%,%,$s);)
- $(INSTALL) -d -m755 $(dest)$(templatedir)/info
- $(INSTALL) -d -m755 $(dest)$(templatedir)/branches
+ $(DESTDIR)$(templatedir)/hooks/$(patsubst hooks--%,%,$s);)
+ $(INSTALL) -d -m755 $(DESTDIR)$(templatedir)/info
+ $(INSTALL) -d -m755 $(DESTDIR)$(templatedir)/branches
diff --git a/tools/Makefile b/tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -8,7 +8,7 @@ INSTALL=install
HOME=$(shell echo $$HOME)
prefix=$(HOME)
bindir=$(prefix)/bin
-# dest=
+# DESTDIR=
PROGRAMS=git-mailsplit git-mailinfo
SCRIPTS=git-applymbox git-applypatch
@@ -19,8 +19,8 @@ git-%: %.c
all: $(PROGRAMS)
install: $(PROGRAMS) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
- $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(dest)$(bindir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
+ $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
clean:
rm -f $(PROGRAMS) *.o
^ permalink raw reply
* Re: Can't build RPM's from current cogito tree
From: Petr Baudis @ 2005-08-04 23:54 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050804204719.23F9D353C13@atlas.denx.de>
Dear diary, on Thu, Aug 04, 2005 at 10:47:19PM CEST, I got a letter
where Wolfgang Denk <wd@denx.de> 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-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
> install: cannot change permissions of `/usr/bin': Operation not permitted
> make[1]: *** [install] Error 1
> make[1]: Leaving directory `/usr/local/BUILD/cogito-0.12.1/tools'
> make: *** [install-tools] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.6363 (%install)
>
>
> This fixes it:
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -245,10 +245,10 @@ install-cogito: $(SCRIPT) $(LIB_SCRIPT)
> done
>
> install-tools:
> - $(MAKE) -C tools install
> + $(MAKE) -C tools dest=$(DESTDIR) install
>
> install-doc:
> - $(MAKE) -C Documentation install
> + $(MAKE) -C Documentation dest=$(DESTDIR) install
>
> uninstall:
> cd $(DESTDIR)$(bindir) && rm -f $(PROG) $(SCRIPTS) $(SCRIPT) $(GEN_SCRIPT)
Thanks, I fixed it the other way around, changing Documentation/Makefile
to use $DESTDIR. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Tree tags again..
From: Linus Torvalds @ 2005-08-05 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
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 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
error: remote ref 'refs/tags/v2.6.11-tree' is not a strict subset of local ref 'refs/tags/v2.6.11-tree'.
Hmm?
Linus
^ permalink raw reply
* Re: garbage in the cogito.git repository
From: Petr Baudis @ 2005-08-05 0:06 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20050731124228.GB11570@procyon.home>
Dear diary, on Sun, Jul 31, 2005 at 02:42:28PM CEST, I got a letter
where Sergey Vlasov <vsu@altlinux.ru> 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 contains all objects in unpacked form, even though most of
> that objects are already in pack files.
>
> Also there are two mysterious files:
>
> objects/base.idx
> objects/base.pack
>
> Could this be fixed?
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 objects were, well, in
.git/objects/pack/thatpackfile. Obviously, this behaviour is reasonable
when you think about it, but rather pitfallous, I would say. At least
documenting it might be worthwhile.
BTW, if you pull now, be prepared to get git-core from elsewhere, since
it will disappear from under your hands as I just unbundled it from
Cogito. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ 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