* [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Mark Allen @ 2005-05-10 2:11 UTC (permalink / raw)
To: git
Darwin puts all of the openssl functionality into libcrypto not libssl. Also, gcc
complains about the st.size return value in local-pull.c if it's not cast explicitly as a
long.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Index: Makefile
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/Makefile (mode:100644)
+++ uncommitted/Makefile (mode:100644)
@@ -80,7 +80,11 @@
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
SHA1_HEADER=<openssl/sha.h>
- LIBS += -lssl
+ ifdef DARWIN
+ LIBS += -lcrypto
+ else
+ LIBS += -lssl
+ endif
endif
endif
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;
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-10 2:16 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505091847050.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
DB> While we're at it, it would be useful to have one for what is normally
DB> ".git", rather than just ".git/objects".
PB> I think it would be nice to have something like GIT_BASEDIR, which would
PB> default to .git, and the objects directory would then default to
PB> $GIT_BASEDIR/objects and the index file would default to
PB> $GIT_BASEDIR/index.
Although what I pushed out at git-jc repository does not have
this, it does not mean I forgot this issue you two have raised,
nor would want to veto it or anything like that. Just that,
unlike the one that I already committed, the proposed change
would touch rather many lines and I have not managed to
determine the extent of the damage yet.
I am willing to make (or take) a separate patch to do this one,
since I agree with Petr's "currently we happen to have just two
but it would still be better to be able to set just one than
having to change both of them in sync." argument.
I am currently waiting for community consensus, including the
final name of the variable. I think the current consensus is
that this is a good idea, the semantics for it is to name what
corresponds to the current "$(pwd)/.git" directory, use it to
build the default for GIT_INDEX_FILE and SHA1_FILE_DIRECTORY,
and this directory does _not_ have anything to do with my
previous "the directory that corresponds to the root of the tree
structure GIT_INDEX_FILE describes". I agree to all of the
above.
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Junio C Hamano @ 2005-05-10 2:29 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List, Linus Torvalds
In-Reply-To: <118833cc05050911255e601fc@mail.gmail.com>
>>>>> "MW" == Morten Welinder <mwelinder@gmail.com> writes:
MW> git-checkout-cache is having problems when files change from directories to
MW> plain files or vice versa.
Changing files vs directories _is_ a big change and happens
rarely in practice; I think the current behaviour is
justified---it makes the user take notice and the user _should_
take notice.
Porcelain layer, if it wanted to, should be able to hide this
from the user, but it depends on which Porcelain layer command
is involved. My understanding of cg-seek is to switch the work
tree to a completely different state, so in that case it
probably should hide this (still it makes me feel a bit nervous
to realize that I am advocating for the tool to silently remove
a whole subtree to make room for a file, though).
^ permalink raw reply
* Re: optimize gitdiff-do script
From: Paul Jackson @ 2005-05-10 2:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050418183038.GB5554@pasky.ji.cz>
Weeks ago, Pasky replied to pj:
> > 1) How do you want me to fix the indentation on my patch
> > to optimize gitdiff-do script:
> > - forget my first patch and resend from scratch, or
> > - a second patch restoring indentation, on top of my first one.
>
> Resend from scratch, please.
As was already no doubt obvious to everyone but me,
I'm not going to get to this. Sorry. Good luck.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: "git-checkout-cache -f -a" failure
From: Morten Welinder @ 2005-05-10 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing List, Linus Torvalds
In-Reply-To: <7v64xru83t.fsf@assigned-by-dhcp.cox.net>
> Changing files vs directories _is_ a big change and happens
> rarely in practice; I think the current behaviour is
> justified---it makes the user take notice and the user _should_
> take notice.
File vs. directory was just the easiest way to demonstrate. In the presense
of symlinks I am not sure you will always get a warning. It'll be more of a
silent file-corrupting failure kind of thing. (Somewhat worse if yyy points
to /your/home/.ssh and zzz is "authorized_keys".)
Morten
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Daniel Barkalow @ 2005-05-10 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7vy8anu8po.fsf@assigned-by-dhcp.cox.net>
On Mon, 9 May 2005, Junio C Hamano wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> DB> While we're at it, it would be useful to have one for what is normally
> DB> ".git", rather than just ".git/objects".
>
> PB> I think it would be nice to have something like GIT_BASEDIR, which would
> PB> default to .git, and the objects directory would then default to
> PB> $GIT_BASEDIR/objects and the index file would default to
> PB> $GIT_BASEDIR/index.
>
> Although what I pushed out at git-jc repository does not have
> this, it does not mean I forgot this issue you two have raised,
> nor would want to veto it or anything like that. Just that,
> unlike the one that I already committed, the proposed change
> would touch rather many lines and I have not managed to
> determine the extent of the damage yet.
It *should* only affect the places where the variables that depend on it
get computed; didn't you already centralize the code to figure this out?
> I am currently waiting for community consensus, including the
> final name of the variable. I think the current consensus is
> that this is a good idea, the semantics for it is to name what
> corresponds to the current "$(pwd)/.git" directory, use it to
> build the default for GIT_INDEX_FILE and SHA1_FILE_DIRECTORY,
> and this directory does _not_ have anything to do with my
> previous "the directory that corresponds to the root of the tree
> structure GIT_INDEX_FILE describes". I agree to all of the
> above.
I agree to all of that, too. I'd suggest GIT_DIR for the variable, simply
because I can't think of anything else that name could mean.
-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
* 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] 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: 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
* [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: [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
* 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: [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: 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: [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
* 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: [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
* 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 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 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: 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: 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: 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: 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
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