* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 9:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510094538.GE8176@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi,
Jan-Benedict Glaw:
> > Please don't change that without talking to Linus.
>
> I won't. You haven't seen a patch from me "fixing" this, too. *I*
> consider this as a defect, but that doesn't mean that I'll force others
> to take this view, too. But maybe I'll talk Linus into this when he's
> back from his trip.
That would be a good idea; I do support dropping (or at least relaxing)
that rule. For excluding unwanted files, I'd suggest using a .git/ignore
file with nice shiny patterns (*.a *.o *.swp ...) inside -- git already
supports that anyway.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: David Greaves @ 2005-05-10 9:47 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Matthias Urlichs, Brian Gerst, git
In-Reply-To: <20050510085626.GC8176@lug-owl.de>
Jan-Benedict Glaw wrote:
>On Tue, 2005-05-10 10:36:09 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
>
>
>>Jan-Benedict Glaw:
>>
>>
>>>> find * \( -type f -o tyle l \) -print0 | ...
>>>>
>>>>
>>>Btw, this won't find dot files, so using "." as the path list (instead
>>>of "*") might be wise...
>>>
>>>
>>>
>>git doesn't want to handle dot files anyway.
>>
>>
>
>...which I actually consider to be a bug. Why should git care about the
>filename, as long as it doesn't clash with ".git"? After all, it's just
>a plumbing mechanism designed to locate file contents by SHA-1 hashes.
>It shouldn't deal with file names at all, really:-)
>
>
I tend to agree that a generic 'content tracking system' shouldn't
impose this kind of rule.
Requiring well formed filenames (eg no //, no trailing /s) is fine - but
dot-file-discrimination?
When I first saw it, I expected this kind of rule to (eventually) be
lifted from the plumbing to the porcelain. The minor problem is that
Linus seems to like getting his hands dirty and keeps using the plumbing ;)
(eek - these analogies...)
David
--
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 9:45 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510093924.GH11221@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Tue, 2005-05-10 11:39:24 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Jan-Benedict Glaw:
> > Ever thought about keeping some important files (of your $HOME) in some
> > SCM? For sure, some of those are dot files:-)
>
> Yeah, but so are various local temporary files.
>
> Please don't change that without talking to Linus.
I won't. You haven't seen a patch from me "fixing" this, too. *I*
consider this as a defect, but that doesn't mean that I'll force others
to take this view, too. But maybe I'll talk Linus into this when he's
back from his trip.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 9:39 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Junio C Hamano, Brian Gerst, git
In-Reply-To: <20050510093212.GD8176@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi,
Jan-Benedict Glaw:
> Ever thought about keeping some important files (of your $HOME) in some
> SCM? For sure, some of those are dot files:-)
>
Yeah, but so are various local temporary files.
Please don't change that without talking to Linus.
FWIW, I keep important files backed up (backuppc is your friend).
No need to bother with an SCM for that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gerst, Matthias Urlichs, git
In-Reply-To: <7vis1rpi8a.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Tue, 2005-05-10 02:01:41 -0700, Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "JBG" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>
> >> find * \( -type f -o tyle l \) -print0 | ...
>
> JBG> Btw, this won't find dot files, so using "." as the path list (instead
> JBG> of "*") might be wise...
>
> Huh? Since when GIT started managing paths whose _any_ of their
> path component starts with a dot?
The Catholic Church never ever had female priests, so how could this
be a good thing?
Ever thought about keeping some important files (of your $HOME) in some
SCM? For sure, some of those are dot files:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Junio C Hamano @ 2005-05-10 9:01 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Brian Gerst, Matthias Urlichs, git
In-Reply-To: <20050510080445.GB8176@lug-owl.de>
>>>>> "JBG" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>> find * \( -type f -o tyle l \) -print0 | ...
JBG> Btw, this won't find dot files, so using "." as the path list (instead
JBG> of "*") might be wise...
Huh? Since when GIT started managing paths whose _any_ of their
path component starts with a dot?
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 8:56 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Brian Gerst, git
In-Reply-To: <20050510083609.GF11221@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Tue, 2005-05-10 10:36:09 +0200, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Jan-Benedict Glaw:
> > > find * \( -type f -o tyle l \) -print0 | ...
> >
> > Btw, this won't find dot files, so using "." as the path list (instead
> > of "*") might be wise...
> >
> git doesn't want to handle dot files anyway.
...which I actually consider to be a bug. Why should git care about the
filename, as long as it doesn't clash with ".git"? After all, it's just
a plumbing mechanism designed to locate file contents by SHA-1 hashes.
It shouldn't deal with file names at all, really:-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Martin Waitz @ 2005-05-10 8:56 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Jan-Benedict Glaw, Brian Gerst, git
In-Reply-To: <20050510083609.GF11221@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
hoi :)
On Tue, May 10, 2005 at 10:36:09AM +0200, Matthias Urlichs wrote:
> Jan-Benedict Glaw:
> > > find * \( -type f -o tyle l \) -print0 | ...
> >
> > Btw, this won't find dot files, so using "." as the path list (instead
> > of "*") might be wise...
> >
> git doesn't want to handle dot files anyway.
but find will output dotfiles in subdirectories.
So you have to prune the list anyway.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: David Greaves @ 2005-05-10 8:42 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Brian Gerst, Matthias Urlichs, git
In-Reply-To: <20050510080445.GB8176@lug-owl.de>
Jan-Benedict Glaw wrote:
>On Tue, 2005-05-10 09:52:27 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
>
>>On Tue, 2005-05-10 01:17:31 -0400, Brian Gerst <bgerst@didntduck.org> wrote:
>>
>>
>>>But it can handle symlinks:
>>>
>>> find * -type f -o -type l -print0 | xargs -0r cg-add
>>>
>>>
>>This won't work because the explicit OR (-o) lower precedence compared
>>to the implicit AND between "-type l" and "-print0", thus this find
>>command will do print0 IFF the matched entry is a symlink. Use something
>>like this instead:
>>
>> find * \( -type f -o tyle l \) -print0 | ...
>>
>>
>
>Btw, this won't find dot files, so using "." as the path list (instead
>of "*") might be wise...
>
>
This is a good thing - git ignores dot-files. see:
http://www.dgreaves.com/git/git-update-cache.html
*
<file> *
Files to act on. Note that files begining with *.* are discarded.
This includes ./file and dir/./file. If you don't want this, then
use cleaner names. The same applies to directories ending */* and
paths with *//*
Cogito should eventually spot and remove these since find * will
obviously find files beginning with a dot in subdirectories.
David
--
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 8:36 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Brian Gerst, git
In-Reply-To: <20050510080445.GB8176@lug-owl.de>
Hi,
Jan-Benedict Glaw:
> > find * \( -type f -o tyle l \) -print0 | ...
>
> Btw, this won't find dot files, so using "." as the path list (instead
> of "*") might be wise...
>
git doesn't want to handle dot files anyway.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 8:04 UTC (permalink / raw)
To: Brian Gerst; +Cc: Matthias Urlichs, git
In-Reply-To: <20050510075227.GA8176@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
On Tue, 2005-05-10 09:52:27 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Tue, 2005-05-10 01:17:31 -0400, Brian Gerst <bgerst@didntduck.org> wrote:
> > But it can handle symlinks:
> >
> > find * -type f -o -type l -print0 | xargs -0r cg-add
>
> This won't work because the explicit OR (-o) lower precedence compared
> to the implicit AND between "-type l" and "-print0", thus this find
> command will do print0 IFF the matched entry is a symlink. Use something
> like this instead:
>
> find * \( -type f -o tyle l \) -print0 | ...
Btw, this won't find dot files, so using "." as the path list (instead
of "*") might be wise...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Jan-Benedict Glaw @ 2005-05-10 7:52 UTC (permalink / raw)
To: Brian Gerst; +Cc: Matthias Urlichs, git
In-Reply-To: <428043EB.7010004@didntduck.org>
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
On Tue, 2005-05-10 01:17:31 -0400, Brian Gerst <bgerst@didntduck.org> wrote:
> But it can handle symlinks:
>
> find * -type f -o -type l -print0 | xargs -0r cg-add
This won't work because the explicit OR (-o) lower precedence compared
to the implicit AND between "-type l" and "-print0", thus this find
command will do print0 IFF the matched entry is a symlink. Use something
like this instead:
find * \( -type f -o tyle l \) -print0 | ...
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Junio C Hamano @ 2005-05-10 6:44 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Mark Allen, git
In-Reply-To: <428038D0.5000706@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> This is just plain WRONG. st.st_size is longer than long on many
HPA> architectures, including Linux/i386.
HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
HPA> and cast it to (intmax_t). That is, however, a C99-ism.
Actually the easiest way is to stop reporting the size. Nobody
else in core GIT reports st.st_size in their error messages.
Although I agree with you that what you say about the size of
st.st_size is correct, in GIT world view, apparently "unsigned
long" is big enough to hold st.st_size all over the code. Would
you recommend tackling that assumption as well?
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Junio C Hamano @ 2005-05-10 6:37 UTC (permalink / raw)
To: git; +Cc: Mark Allen, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.21.0505100019350.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> Actually, the relevant openssl functionality is always in libcrypto, not
DB> libssl...
Ok, could people try the following single liner, and if it
breaks yell loudly at me (or Daniel ;-)? It worked for me but I
just want to make sure before I put it in git-jc repository
which I will ask Linus to pull from later.
$ jit-diff 0:7
# - HEAD: Introduce GIT_DIR environment variable.
# + 7: Link with -lcrypto not -lssl
--- a/Makefile
+++ b/Makefile
@@ -60,7 +60,7 @@ ifdef PPC_SHA1
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
SHA1_HEADER=<openssl/sha.h>
- LIBS += -lssl
+ LIBS += -lcrypto
endif
endif
^ permalink raw reply
* Introducing GIT_DIR environment variable.
From: Junio C Hamano @ 2005-05-10 6:25 UTC (permalink / raw)
To: Petr Baudis, Daniel Barkalow; +Cc: git
In-Reply-To: <7voebjr5vd.fsf@assigned-by-dhcp.cox.net>
Ok, following the mailing list discussion, I've done GIT_DIR and
pushed it out to the usual git-jc repository, at:
http://members.cox.net/junkio/git-jc.git/
Author: Junio C Hamano <junkio@cox.net>
Date: Mon May 9 22:57:58 2005 -0700
Introduce GIT_DIR environment variable.
During the mailing list discussion on renaming GIT_ environment
variables, people felt that having one environment that lets the
user (or Porcelain) specify both SHA1_FILE_DIRECTORY (now
GIT_OBJECT_DIRECTORY) and GIT_INDEX_FILE for the default layout
would be handy. This change introduces GIT_DIR environment
variable, from which the defaults for GIT_INDEX_FILE and
GIT_OBJECT_DIRECTORY are derived. When GIT_DIR is not defined,
it defaults to ".git". GIT_INDEX_FILE defaults to
"$GIT_DIR/index" and GIT_OBJECT_DIRECTORY defaults to
"$GIT_DIR/objects".
Special thanks for ideas and discussions go to Petr Baudis and
Daniel Barkalow. Bugs are mine ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
--- a/cache.h
+++ b/cache.h
@@ -106,16 +106,15 @@ static inline unsigned int create_ce_mod
struct cache_entry **active_cache;
unsigned int active_nr, active_alloc, active_cache_changed;
+#define GIT_DIR_ENVIRONMENT "GIT_DIR"
+#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
-#define DEFAULT_DB_ENVIRONMENT ".git/objects"
-#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
-
-#define get_object_directory() (gitenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT)
-
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
-#define DEFAULT_INDEX_ENVIRONMENT ".git/index"
-#define get_index_file() (gitenv(INDEX_ENVIRONMENT) ? : DEFAULT_INDEX_ENVIRONMENT)
+extern char *get_object_directory(void);
+extern char *get_index_file(void);
+
+#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
#define alloc_nr(x) (((x)+16)*3/2)
--- a/git-prune-script
+++ b/git-prune-script
@@ -11,6 +11,9 @@ do
shift;
done
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
# Defaulting to include .git/refs/*/* may be debatable from the
# purist POV but power users can always give explicit parameters
# to the script anyway.
@@ -19,7 +22,8 @@ case "$#" in
0)
x_40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
x_40="$x_40$x_40$x_40$x_40$x_40$x_40$x_40$x_40"
- set x $(sed -ne "/^$x_40\$/p" .git/HEAD .git/refs/*/* 2>/dev/null)
+ set x $(sed -ne "/^$x_40\$/p" \
+ "$GIT_DIR"/HEAD "$GIT_DIR"/refs/*/* /dev/null 2>/dev/null)
shift ;;
esac
@@ -28,13 +32,7 @@ sed -ne '/unreachable /{
s/unreachable [^ ][^ ]* //
s|\(..\)|\1/|p
}' | {
- for d in "$GIT_OBJECT_DIRECTORY" "$SHA1_FILE_DIRECTORY" ''
- do
- test "$d" != "" && test -d "$d" && break
- done
- case "$d" in
- '') cd .git/objects/ ;;
- *) cd "$d" ;;
- esac || exit
+ cd "$GIT_OBJECT_DIRECTORY" || exit
xargs -r $dryrun rm -f
}
+
--- a/git-pull-script
+++ b/git-pull-script
@@ -3,6 +3,9 @@
merge_repo=$1
merge_name=${2:-HEAD}
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
download_one () {
# remote_path="$1" local_file="$2"
case "$1" in
@@ -25,16 +28,19 @@ download_objects () {
git-local-pull -l -a "$2" "$1/"
;;
*)
- rsync -avz --ignore-existing "$1/objects/." \
- ${SHA_FILE_DIRECTORY:-.git/objects}/.
+ rsync -avz --ignore-existing \
+ "$1/objects/." "$GIT_OBJECT_DIRECTORY"/.
;;
esac
}
echo "Getting remote $merge_name"
-download_one "$merge_repo/$merge_name" .git/MERGE_HEAD
+download_one "$merge_repo/$merge_name" "$GIT_DIR"/MERGE_HEAD
echo "Getting object database"
-download_objects "$merge_repo" "$(cat .git/MERGE_HEAD)"
+download_objects "$merge_repo" "$(cat "$GIT_DIR"/MERGE_HEAD)"
-git-resolve-script "$(cat .git/HEAD)" "$(cat .git/MERGE_HEAD)" "$merge_repo"
+git-resolve-script \
+ "$(cat "$GIT_DIR"/HEAD)" \
+ "$(cat "$GIT_DIR"/MERGE_HEAD)" \
+ "$merge_repo"
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -1,14 +1,19 @@
#!/bin/sh
#
+# Copyright (c) 2005 Linus Torvalds
+#
# Resolve two trees.
#
head="$1"
merge="$2"
merge_repo="$3"
-rm -f .git/MERGE_HEAD .git/ORIG_HEAD
-echo $head > .git/ORIG_HEAD
-echo $merge > .git/MERGE_HEAD
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
+
+rm -f "$GIT_DIR"/MERGE_HEAD "$GIT_DIR"/ORIG_HEAD
+echo $head > "$GIT_DIR"/ORIG_HEAD
+echo $merge > "$GIT_DIR"/MERGE_HEAD
#
# The remote name is just used for the message,
@@ -35,7 +40,7 @@ if [ "$common" == "$head" ]; then
echo "Kill me within 3 seconds.."
sleep 3
git-read-tree -m $merge && git-checkout-cache -f -a && git-update-cache --refresh
- echo $merge > .git/HEAD
+ echo $merge > "$GIT_DIR"/HEAD
git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
exit 0
fi
@@ -51,6 +56,6 @@ if [ $? -ne 0 ]; then
fi
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
echo "Committed merge $result_commit"
-echo $result_commit > .git/HEAD
+echo $result_commit > "$GIT_DIR"/HEAD
git-checkout-cache -f -a && git-update-cache --refresh
git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
--- a/git-tag-script
+++ b/git-tag-script
@@ -1,5 +1,9 @@
#!/bin/sh
-object=${2:-$(cat .git/HEAD)}
+# Copyright (c) 2005 Linus Torvalds
+
+: ${GIT_DIR=.git}
+
+object=${2:-$(cat "$GIT_DIR"/HEAD)}
type=$(git-cat-file -t $object) || exit 1
( echo -e "object $object\ntype $type\ntag $1\n"; cat ) > .tmp-tag
rm -f .tmp-tag.asc
--- a/init-db.c
+++ b/init-db.c
@@ -27,11 +27,12 @@ int main(int argc, char **argv)
char *path;
int len, i;
- safe_create_dir(".git");
-
- sha1_dir = gitenv(DB_ENVIRONMENT);
- if (!sha1_dir) {
- sha1_dir = DEFAULT_DB_ENVIRONMENT;
+ sha1_dir = get_object_directory();
+ if (!gitenv(DB_ENVIRONMENT) && !gitenv(GIT_DIR_ENVIRONMENT)) {
+ /* We create leading paths only when we fall back
+ * to local .git/objects, at least for now.
+ */
+ safe_create_dir(DEFAULT_GIT_DIR_ENVIRONMENT);
fprintf(stderr, "defaulting to local storage area\n");
}
len = strlen(sha1_dir);
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -59,6 +59,38 @@ int get_sha1_file(const char *path, unsi
return get_sha1_hex(buffer, result);
}
+static char *git_dir, *git_object_dir, *git_index_file;
+static void setup_git_env(void)
+{
+ git_dir = gitenv(GIT_DIR_ENVIRONMENT);
+ if (!git_dir)
+ git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
+ git_object_dir = gitenv(DB_ENVIRONMENT);
+ if (!git_object_dir) {
+ git_object_dir = xmalloc(strlen(git_dir) + 9);
+ sprintf(git_object_dir, "%s/objects", git_dir);
+ }
+ git_index_file = gitenv(INDEX_ENVIRONMENT);
+ if (!git_index_file) {
+ git_index_file = xmalloc(strlen(git_dir) + 7);
+ sprintf(git_index_file, "%s/index", git_dir);
+ }
+}
+
+char *get_object_directory(void)
+{
+ if (!git_object_dir)
+ setup_git_env();
+ return git_object_dir;
+}
+
+char *get_index_file(void)
+{
+ if (!git_index_file)
+ setup_git_env();
+ return git_index_file;
+}
+
int get_sha1(const char *str, unsigned char *sha1)
{
static char pathname[PATH_MAX];
@@ -70,15 +102,16 @@ int get_sha1(const char *str, unsigned c
"refs/snap",
NULL
};
- const char *gitdir;
const char **p;
if (!get_sha1_hex(str, sha1))
return 0;
- gitdir = ".git";
+ if (!git_dir)
+ setup_git_env();
for (p = prefix; *p; p++) {
- snprintf(pathname, sizeof(pathname), "%s/%s/%s", gitdir, *p, str);
+ snprintf(pathname, sizeof(pathname), "%s/%s/%s",
+ git_dir, *p, str);
if (!get_sha1_file(pathname, sha1))
return 0;
}
^ permalink raw reply
* Re: [RFD] Overlapping projects
From: Junio C Hamano @ 2005-05-10 6:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0505100135110.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>> ...
>> with an instruction like:
>>
>> ... Theoretically they can be independently updated to
>> the latest but preferred combination is to use at least this
>> release of core GIT to use this version of Cogito ...
DB> But when Petr adds something to the core, intended for eventual inclusion
DB> in the mainline, and uses it in cogito, this breaks everything, because
DB> then people have to know to pull both the latest cogito and the latest git
DB> from him. If the new git isn't backwards-compatible, then someone building
DB> an old cogito would have to somehow find the matching old git.
I think we are in agreement and saying the same thing. Yes, if
people wants to do mix and match, they should know what they are
doing.
Also I do not see any reason not to have GIT that comes from
Cogito additional stuff while Linus tree lags behind, which in a
sense already has been the case for some commands. Separating
directories would make things easier to manage, not harder.
Anyhow let's wait and see what Petr does. He said he has been
preparing core backports earlier. No point arguing about his
tree without helping him.
^ permalink raw reply
* Re: [RFD] Overlapping projects
From: Daniel Barkalow @ 2005-05-10 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y2nsl38.fsf@assigned-by-dhcp.cox.net>
On Mon, 9 May 2005, Junio C Hamano wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> DB> It seems to me like projects like cogito which are based on a core which
> DB> is itself a project and which is also part of other projects would benefit
> DB> from some sort of support.
>
> I personally feel supporting that kind of development directory
> structure is backwards, and Cogito is a very bad example for it.
The directory structure is definitely awkward. I'd personally put cogito
stuff in a separate directory. But that's a matter of which paths belong
to which commit.
> Things could have been structured in such a way to have Cogito
> and core GIT in separate directories hanging from the top level,
> and Cogito can borrow pieces of GIT from the neighboring
> directory if it needed to build specialized binary using
> libgit.a. Unless Petr makes changes to core GIT that is _too_
> specific for general use (read: does not meet Linus' taste), we
> should be able to port the nicer changes made to the core GIT
> for Cogito's use (like git-ls-files "-t" flag) back to core GIT
> and there would not be a reason for Cogito to keep carrying its
> own copy of modified core GIT.
>
> DB> In particular, it would be nice if Linus could pull the
> DB> changes to the core without getting the wrapper programs at
> DB> all.
>
> Yes, that is a very desirable arrangement.
>
> However, that does not require to keep them in the same
> repository. Cogito _could_ have been shipped this way:
>
> + (top-level)
> / \
> cg git
> (Cogito sources) (copy of core GIT files)
> .git/ for Cogito .git/ for core GIT
> only
>
> with an instruction like:
>
> The tarball contains cg and git subdirectories. cg part
> implements Cogito, and git part is a copy of recent if not
> latest core GIT. Go to cg and type "make" to build both of
> them. Theoretically they can be independently updated to
> the latest but preferred combination is to use at least this
> release of core GIT to use this version of Cogito ...
But when Petr adds something to the core, intended for eventual inclusion
in the mainline, and uses it in cogito, this breaks everything, because
then people have to know to pull both the latest cogito and the latest git
from him. If the new git isn't backwards-compatible, then someone building
an old cogito would have to somehow find the matching old git.
This is far worse than just including git and sending Linus patches; the
only way to make this manageable would be to suspend cogito until git was
completely finished.
The important thing, I think, is being able to connect a Cogito with the
git it uses, while both are unstable and under active development. It
would be nice to be able to have the obvious things happen when you pull
the latest cogito and check it out, and when you commit with changes to
files from each of them, but that's less important.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-10 5:45 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505092012340.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> On Mon, 9 May 2005, Junio C Hamano wrote:
>> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>>
DB> While we're at it, it would be useful to have one for what is normally
DB> ".git",...
>>
>> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
>> your only gripe is about git-init-db creating ".git" in the
>> current working directory regardless of SHA1_FILE_DIRECTORY, I
>> would agree that what git-init-db does is broken. Not that I
>> have a suggested "right behaviour" for it, though.
DB> It could just create all missing parents of the object directory, which
DB> would be better, at least.
I am ambivalent about this. Here is an excerpt from my WIP. I
am trying to keep the original semantics of "we create the
leading paths only if we default to .git/objects":
$ GIT_DIFF_OPTS=-u8 jit-diff 1: init-db.c
# - HEAD: Rename environment variables.
# + (working tree)
--- a/init-db.c
+++ b/init-db.c
@@ -22,21 +22,22 @@
* be the judge. The default case is to have one DB per managed directory.
*/
int main(int argc, char **argv)
{
const char *sha1_dir;
char *path;
int len, i;
- safe_create_dir(".git");
-
- sha1_dir = gitenv(DB_ENVIRONMENT);
- if (!sha1_dir) {
- sha1_dir = DEFAULT_DB_ENVIRONMENT;
+ sha1_dir = get_object_directory();
+ if (!gitenv(DB_ENVIRONMENT) && !gitenv(GIT_DIR_ENVIRONMENT)) {
+ /* We create leading paths only when we fall back
+ * to local ".git/objects".
+ */
+ safe_create_dir(DEFAULT_GIT_DIR_ENVIRONMENT);
fprintf(stderr, "defaulting to local storage area\n");
}
len = strlen(sha1_dir);
path = xmalloc(len + 40);
memcpy(path, sha1_dir, len);
safe_create_dir(sha1_dir);
for (i = 0; i < 256; i++) {
Here DEFAULT_GIT_DIR_ENVIRONMENT is defined as ".git", and the
directory is created only if we do not have GIT_OBJECT_DIRECTORY
nor GIT_DIR environment variables, which should match the intent
of the original by Linus. Otherwise we at least require the
parent directory of GIT_OBJECT_DIRECTORY to exist. I think that
is a reasonable default (well that is not something I can take
credit), in that if the user is clued enough to use something
different from the default he should at least know enough to
create the leading paths beforehand (or the script could do that
for him).
Other than this part, I think the code is ready to go.
^ permalink raw reply
* Re: [RFD] Overlapping projects
From: Junio C Hamano @ 2005-05-10 5:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0505100040320.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> It seems to me like projects like cogito which are based on a core which
DB> is itself a project and which is also part of other projects would benefit
DB> from some sort of support.
I personally feel supporting that kind of development directory
structure is backwards, and Cogito is a very bad example for it.
Things could have been structured in such a way to have Cogito
and core GIT in separate directories hanging from the top level,
and Cogito can borrow pieces of GIT from the neighboring
directory if it needed to build specialized binary using
libgit.a. Unless Petr makes changes to core GIT that is _too_
specific for general use (read: does not meet Linus' taste), we
should be able to port the nicer changes made to the core GIT
for Cogito's use (like git-ls-files "-t" flag) back to core GIT
and there would not be a reason for Cogito to keep carrying its
own copy of modified core GIT.
DB> In particular, it would be nice if Linus could pull the
DB> changes to the core without getting the wrapper programs at
DB> all.
Yes, that is a very desirable arrangement.
However, that does not require to keep them in the same
repository. Cogito _could_ have been shipped this way:
+ (top-level)
/ \
cg git
(Cogito sources) (copy of core GIT files)
.git/ for Cogito .git/ for core GIT
only
with an instruction like:
The tarball contains cg and git subdirectories. cg part
implements Cogito, and git part is a copy of recent if not
latest core GIT. Go to cg and type "make" to build both of
them. Theoretically they can be independently updated to
the latest but preferred combination is to use at least this
release of core GIT to use this version of Cogito ...
Maybe I am being too idealistic. I do not deny there are people
who want to manage "projects within projects" structure and
other people like CVS, subversion and arch do support that
style. My impression about them is that the way CVS does it via
CVSROOT/modules looked like an ugly hack bolted onto it as an
afterthought, external stuff subversion uses did not feel quite
right (although nicer than what CVS does), and what arch does
was more reasonable but the boundary between SCM and build
environment was quite blurry there. And many people "wanting to
do so" and other people "supporting doing it" do not necessarily
make that right.
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Brian Gerst @ 2005-05-10 5:17 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.05.10.03.41.15.683163@smurf.noris.de>
Matthias Urlichs wrote:
> Hi, Brandon Philips wrote:
>
>
>>- find * | xargs cg-add
>>+ find * ! -type d | xargs cg-add
>
>
> Actually, (almost) every use of "find | xargs" which is not a subset of
> "find -print0 | xargs -0r" is a bug.
>
> So please don't do that. Special files aren't liked by git either, thus:
>
> find * -type f -print0 | xargs -0r cg-add
>
But it can handle symlinks:
find * -type f -o -type l -print0 | xargs -0r cg-add
--
Brian Gerst
^ permalink raw reply
* [RFD] Overlapping projects
From: Daniel Barkalow @ 2005-05-10 4:56 UTC (permalink / raw)
To: git
It seems to me like projects like cogito which are based on a core which
is itself a project and which is also part of other projects would benefit
from some sort of support.
In particular, it would be nice if Linus could pull the changes to the
core without getting the wrapper programs at all.
I'm thinking something like having a head for cogito and a head for git in
the same repository, where the trees for git only have the core files, and
the commits for cogito have, in addition to a tree with only the
cogito-specific files, a reference to a git commit that they include.
It seems to me like this area contains a brilliant idea that I haven't
had so far, and maybe someone can come up with it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Prototype git commit viewer
From: Greg KH @ 2005-05-10 4:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17022.49021.344841.79940@cargo.ozlabs.ibm.com>
On Mon, May 09, 2005 at 11:40:13AM +1000, Paul Mackerras wrote:
> Over the weekend I hacked up a prototype viewer for git commits in
> Tk. It's called gitk and is at:
>
> http://ozlabs.org/~paulus/gitk
>
> (that's the actual script itself :).
Very nice, I like it a lot, thanks for doing this.
greg k-h
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: H. Peter Anvin @ 2005-05-10 4:30 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20050510021105.53984.qmail@web41213.mail.yahoo.com>
Mark Allen wrote:
>
> Index: local-pull.c
> ===================================================================
> --- 972d8624458936868e6f392b40858b7c362af8cd/local-pull.c (mode:100644)
> +++ uncommitted/local-pull.c (mode:100644)
> @@ -71,7 +71,7 @@
> close(ofd);
> if (status)
> fprintf(stderr, "cannot write %s (%ld bytes)\n",
> - dest_filename, st.st_size);
> + dest_filename, (long) st.st_size);
> else
> pull_say("copy %s\n", hex);
> return status;
This is just plain WRONG. st.st_size is longer than long on many
architectures, including Linux/i386.
The easiest way to deal with it is to #include <inttypes.h>, use %jd and
cast it to (intmax_t). That is, however, a C99-ism.
-hpa
^ permalink raw reply
* Re: [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Daniel Barkalow @ 2005-05-10 4:23 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20050510021105.53984.qmail@web41213.mail.yahoo.com>
On Mon, 9 May 2005, Mark Allen wrote:
> Darwin puts all of the openssl functionality into libcrypto not
> libssl.
Actually, the relevant openssl functionality is always in libcrypto, not
libssl. It's just that ELF shared libraries include dependancies, and
libssl pulls in libcrypto. If you change it, change it for everyone,
rather than just Darwin.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Matthias Urlichs @ 2005-05-10 3:41 UTC (permalink / raw)
To: git
In-Reply-To: <20050509233904.GB878@osuosl.org>
Hi, Brandon Philips wrote:
> - find * | xargs cg-add
> + find * ! -type d | xargs cg-add
Actually, (almost) every use of "find | xargs" which is not a subset of
"find -print0 | xargs -0r" is a bug.
So please don't do that. Special files aren't liked by git either, thus:
find * -type f -print0 | xargs -0r cg-add
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ 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