* [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Bryan Larsen @ 2005-07-11 10:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Update the git Makefile to put the results of config.sh into the scripts.
config.sh searches for gnu utilities cp, stat, date and xargs.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Makefile | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -51,9 +51,18 @@ PROG= git-update-cache git-diff-files
all: $(PROG)
-install: $(PROG) $(SCRIPTS)
+config: config.sh
+ ./config.sh
+
+install: $(PROG) $(SCRIPTS) config
$(INSTALL) -m755 -d $(dest)$(bin)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
+ . ./config ; \
+ cd $(dest)$(bin) ; \
+ for file in $(SCRIPTS); do \
+ sed -e "s/DATE\=date/DATE=$${DATE}/" -e "s/CP\=cp/CP=$${CP}/" -e "s/XARGS\=xargs/XARGS=$${XARGS}/" -e "s/STAT\=stat/STAT=$${STAT}/" $$file > $$file.new; \
+ cat $$file.new > $$file; rm $$file.new; \
+ done
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
@@ -190,7 +199,7 @@ test: all
$(MAKE) -C t/ all
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) config
$(MAKE) -C Documentation/ clean
backup: clean
^ permalink raw reply
* [PATCH 2/6] config-sh: find and verify utils
From: Bryan Larsen @ 2005-07-11 10:14 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Add config.sh which searches for gnu versions of 'cp' 'stat' 'date' and 'xargs'.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
config.sh | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/config.sh b/config.sh
new file mode 100755
--- /dev/null
+++ b/config.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+#
+# Search for gnu utils.
+# Copyright (c) Bryan Larsen, 2005
+#
+# cogito and git-*-script rely on gnu versions of
+# cp, date, xargs and stat. Look for them and
+# ensure they're gnu.
+#
+
+set -e
+
+if which gdate > /dev/null ; then
+ DATE=gdate ;
+else
+ DATE=date ;
+fi ;
+
+# you don't actually have to have gnu date, it just works better.
+
+if which gcp > /dev/null ; then
+ CP=gcp ;
+else
+ CP=cp ;
+fi ;
+
+if $CP -a config.sh cp-test-dummy ; then
+ rm cp-test-dummy ;
+else
+ echo 'You must have gnu cp installed';
+ exit 1;
+fi ;
+
+if which gnuxargs > /dev/null ; then
+ XARGS=gnuxargs ;
+else
+ XARGS=xargs ;
+fi ;
+
+if ! ( echo | $XARGS -r ) ; then
+ echo 'You must have gnu xargs installed';
+ exit 1;
+fi ;
+
+if which gstat > /dev/null ; then
+ STAT=gstat ;
+else
+ STAT=stat ;
+fi ;
+
+if ! ($STAT -c '%s' config.sh > /dev/null ) ; then
+ if which awk > /dev/null ; then
+ STAT=dont_have_stat ;
+ else
+ echo 'You must have awk or gnu stat installed.';
+ exit 1;
+ fi
+fi ;
+
+echo CP=$CP > config
+echo XARGS=$XARGS >> config
+echo DATE=$DATE >> config
+echo STAT=$STAT >> config
+
+set +e
^ permalink raw reply
* [PATCH 1/6] git-gnu-progs: parameterize git
From: Bryan Larsen @ 2005-07-11 10:14 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711101417.10318.64006.sendpatchset@bryan-larsens-ibook-g4.local>
Patch git so that the utilities 'cp' 'stat' 'xargs' and 'date' are configurable. Git requires the gnu versions of these tools, and on some BSD derived systems, the gnu versions of these tools have a different name.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
git-clone-script | 4 +++-
git-prune-script | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -5,6 +5,8 @@
#
# Clone a repository into a different directory that does not yet exist.
+CP=cp
+
usage() {
echo >&2 "* git clone [-l] <repo> <dir>"
exit 1
@@ -68,7 +70,7 @@ yes,yes)
l=l
fi &&
rm -f "$D/.git/objects/sample" &&
- cp -r$l "$repo/objects" "$D/.git/" || exit 1
+ ${CP} -r$l "$repo/objects" "$D/.git/" || exit 1
# Make a duplicate of refs and HEAD pointer
HEAD=
diff --git a/git-prune-script b/git-prune-script
--- a/git-prune-script
+++ b/git-prune-script
@@ -1,5 +1,7 @@
#!/bin/sh
+XARGS=xargs
+
. git-sh-setup-script || die "Not a git archive"
dryrun=
@@ -20,6 +22,6 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs -r $dryrun rm -f
+ ${XARGS} -r $dryrun rm -f
}
^ permalink raw reply
* [PATCH 0/6] parameterize gnu tool names; add Portfile for OS X darwinports
From: Bryan Larsen @ 2005-07-11 10:14 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
Cogito and git rely on the gnu version of 4 standard utilities: cp,
date, stat and xargs. On most non-Linux based Unix's, the gnu tools
are optional installs, and are installed under different names.
These patches parameterize the names of these 4 tools, determine what
name should be used, and verify that the tools work. The final patch in
the series creates a Portfile that can be used with OS X's
darwinports.
In this series, patches 3 and 5 conflict: patch 3 is for the git
Makefile, and patch 5 is for the cogito Makefile.
Patches 1-3 should be applied to git.
Patches 1,2,4,5,6 should be applied to cogito.
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Amin Azez @ 2005-07-11 8:56 UTC (permalink / raw)
To: git
In-Reply-To: <42CE9961.3090708@ufomechanic.net>
Dave Jones daily snapshot of git solved the problem, available from:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
I realise that Jeff's howto suggested updating git using git, but it
suggested doing this after following the intermediate steps. I also find
it ironic that the version of git Jeff provides doesn't work with his
instructions; however, still many thanks to Jeff for his HOWTO and to
Dave for git.
Azez
Amin Azez wrote:
> Thanks for the HOWTO, Jeff, but it gives me problems in step 4.
> I checked out your latest git source today and "make install"ed it as
> part of your instructions and at step 4 I get:
>
> $ git checkout -f
> error: cannot map sha1 file f8640c306db2d583b9a30f2e52f8fb0a4cf624e0
> fatal: failed to unpack tree object
> a92b7b80579fe68fe229892815c750f6652eb6a9
>
> $ cat .git/HEAD
> a92b7b80579fe68fe229892815c750f6652eb6a9
>
> Naturally I have no idea what f8640c306db2d583b9a30f2e52f8fb0a4cf624e0
> refers to.
>
> Step 3:
> $ git-pull-script \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> said I was already up to date.
>
> Variations on step 4:
>
> $ git-read-tree -m HEAD
> or
> $ git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9
> also fail in the same way.
>
> My linux-2.6 directory only has one entry, .git, containing about 75M of
> files.
>
> Sam
>
> Jeff Garzik wrote:
>
>>
>> Things in git-land are moving at lightning speed, and usability has
>> improved a lot since my post a month ago:
>> http://lkml.org/lkml/2005/5/26/11
>>
>>
>>
>> 1) installing git
>>
>> git requires bootstrapping, since you must have git installed in order
>> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
>> have put together a bootstrap tarball of today's git repository.
>>
>> Download tarball from:
>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
>>
>>
>> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>>
>> install tarball: unpack && make && sudo make prefix=/usr/local install
>>
>> jgarzik helper scripts, not in official git distribution:
>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
>> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
>>
>> After reading the rest of this document, come back and update your
>> copy of git to the latest:
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>>
>>
>> 2) download a linux kernel tree for the very first time
>>
>> $ mkdir -p linux-2.6/.git
>> $ cd linux-2.6
>> $ rsync -a --delete --verbose --stats --progress \
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> \ <- word-wrapped backslash; sigh
>> .git/
>>
>>
>> 3) update local kernel tree to latest 2.6.x upstream ("fast-forward
>> merge")
>>
>> $ cd linux-2.6
>> $ git-pull-script \
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>
>>
>> 4) check out files from the git repository into the working directory
>>
>> $ git checkout -f
>>
>>
>> 5) check in your own modifications (e.g. do some hacking, or apply a
>> patch)
>>
>> # go to repo
>> $ cd linux-2.6
>>
>> # make some modifications
>> $ patch -sp1 < /tmp/my.patch
>> $ diffstat -p1 < /tmp/my.patch
>>
>> # NOTE: add '--add' and/or '--remove' if files were added or removed
>> $ git-update-cache <list of all files changed>
>>
>> # check in changes
>> $ git commit
>>
>>
>> 6) List all changes in working dir, in diff format.
>>
>> $ git-diff-cache -p HEAD
>>
>>
>> 7) List all changesets (i.e. show each cset's description text) in
>> local branch of local tree, that are not present in remote tree.
>>
>> $ cd my-kernel-tree-2.6
>> $ git-changes-script -L ../linux-2.6 | less
>>
>>
>> 8) List all changesets:
>>
>> $ git-whatchanged
>>
>>
>> 9) apply all patches in a Berkeley mbox-format file
>>
>> First, download and add to your PATH Linus's git tools:
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
>>
>> $ cd my-kernel-tree-2.6
>> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
>>
>>
>> 10) don't forget to download tags from time to time.
>>
>> git-pull-script only downloads sha1-indexed object data, and the
>> requested remote head. This misses updates to the .git/refs/tags/ and
>> .git/refs/heads directories. It is advisable to update your kernel
>> .git directories periodically with a full rsync command, to make sure
>> you got everything:
>>
>> $ cd linux-2.6
>> $ rsync -a --delete --verbose --stats --progress \
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> \ <- word-wrapped backslash; sigh
>> .git/
>>
>>
>> 11) list all branches, such as those found in my netdev-2.6 or
>> libata-dev trees.
>>
>> Download
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>> or
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>>
>> $ cd netdev-2.6
>> $ ls .git/refs/heads/
>>
>> { these are the current netdev-2.6 branches }
>>
>>> 8139cp forcedeth master qeth smc91x we18
>>> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi
>>> airo hdlc ns83820 register-netdev starfire
>>> atmel ieee80211 orinoco remove-drivers tlan
>>> chelsio iff-running orinoco-hch sis900 veth
>>> dm9000 janitor ppp skge viro
>>
>>
>>
>>
>> 12) make desired branch current in working directory
>>
>> $ git checkout -f $branch
>>
>>
>> 13) create a new branch, and make it current
>>
>> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
>> $ git checkout -f my-new-branch-name
>>
>>
>> 14) examine which branch is current
>>
>> $ ls -l .git/HEAD
>>
>>
>> 15) undo all local modifications (same as checkout):
>>
>> $ git checkout -f
>>
>>
>> 16) obtain a diff between current branch, and master branch
>>
>> In most trees WITH BRANCHES, .git/refs/heads/master contains the
>> current 'vanilla' upstream tree, for easy diffing and merging. (in
>> trees without branches, 'master' simply contains your latest changes)
>>
>> $ git-diff-tree -p master HEAD
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: What broke snapshots now?
From: David Woodhouse @ 2005-07-11 8:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507101026430.17536@g5.osdl.org>
On Sun, 2005-07-10 at 10:31 -0700, Linus Torvalds wrote:
> No it's not, as far as I can tell:
>
> torvalds@hera:/home/dwmw2/git/mail-2.6(0)$ cat .git/branches/origin
> rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> so your scripts will go out to rsync with www.kernel.org to get the data,
> when you use "cg-update origin".
Hm, OK. So I have absolutely no recollection of what my own scripts are
actually doing. I could have sworn I made sure it was local. If it was
using that URL for the master I might as well have run it elsewhere...
It does seem to be working again now. I'll probably rewrite it next time
it misbehaves.
>
--
dwmw2
^ permalink raw reply
* [PATCH] Check packs and then files.
From: Junio C Hamano @ 2005-07-11 7:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vfyumj8hn.fsf_-_@assigned-by-dhcp.cox.net>
This reverses the order of object lookup, to check pack index
first and then go to the filesystem to find .git/objects/??/
hierarchy. When most of the objects are packed, this saves
quite many stat() calls and negative dcache entries; while the
price this approach has to pay is negligible, even when most of
the objects are outside pack, because checking pack index file
is quite cheap.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_file.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
0394e2b0ed5b197510340f187d02ef2274b6cad2
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1035,14 +1035,17 @@ void * read_sha1_file(const unsigned cha
{
unsigned long mapsize;
void *map, *buf;
+ struct pack_entry e;
+ if (find_pack_entry(sha1, &e))
+ return read_packed_sha1(sha1, type, size);
map = map_sha1_file_internal(sha1, &mapsize);
if (map) {
buf = unpack_sha1_file(map, mapsize, type, size);
munmap(map, mapsize);
return buf;
}
- return read_packed_sha1(sha1, type, size);
+ return NULL;
}
void *read_object_with_reference(const unsigned char *sha1,
@@ -1343,9 +1346,9 @@ int has_sha1_file(const unsigned char *s
struct stat st;
struct pack_entry e;
- if (find_sha1_file(sha1, &st))
+ if (find_pack_entry(sha1, &e))
return 1;
- return find_pack_entry(sha1, &e);
+ return find_sha1_file(sha1, &st) ? 1 : 0;
}
int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)
^ permalink raw reply
* [PATCH] Dereference tag repeatedly until we get a non-tag.
From: Junio C Hamano @ 2005-07-11 6:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v7jg0wb77.fsf@assigned-by-dhcp.cox.net>
When we allow a tag object in place of a commit object, we only
dereferenced the given tag once, which causes a tag that points
at a tag that points at a commit to be rejected. Instead,
dereference tag repeatedly until we get a non-tag.
This patch makes change to two functions:
- commit.c::lookup_commit_reference() is used by merge-base,
rev-tree and rev-parse to convert user supplied SHA1 to that of
a commit.
- rev-list uses its own get_commit_reference() to do the same.
Dereferencing tags this way helps both of these uses.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Whether having a tag pointing at another tag is a separate
*** issue, but I do not see a reason to forbid it. Maybe it
*** is used to represent a chain of trust.
commit.c | 5 +++--
rev-list.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
0dc9377363ee73c5e3f3711d6f82e49886ce8c6a
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
if (!obj)
return NULL;
- if (obj->type == tag_type)
- obj = ((struct tag *)obj)->tagged;
+ while (obj->type == tag_type)
+ obj = parse_object(((struct tag *)obj)->tagged->sha1);
+
return check_commit(obj, sha1);
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -367,12 +367,12 @@ static struct commit *get_commit_referen
/*
* Tag object? Look what it points to..
*/
- if (object->type == tag_type) {
+ while (object->type == tag_type) {
struct tag *tag = (struct tag *) object;
object->flags |= flags;
if (tag_objects && !(object->flags & UNINTERESTING))
add_pending_object(object, tag->tag);
- object = tag->tagged;
+ object = parse_object(tag->tagged->sha1);
}
/*
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Daniel Barkalow @ 2005-07-11 4:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507102034460.17536@g5.osdl.org>
On Sun, 10 Jul 2005, Linus Torvalds wrote:
> On Sun, 10 Jul 2005, Daniel Barkalow wrote:
> >
> > Perhaps git-pack-objects should have the base as a optional argument,
> > with a default of the filename in $GIT_DIR/objects/pack and an option
> > for sending just the pack file to stdout?
>
> You really _mustn't_ try to create the pack directly to the
> $GIT_DIR/objects/pack subdirectory - that would make git itself start
> possibly using that pack before the index is all done, and that would be
> just wrong and nasty.
>
> So you really should _always_ generate the pack somewhere else, and then
> move it (pack file first, index file second).
It's currently fine ignoring index files without corresponding
pack files (sha1_file.c, line 470). Do you want to make the constraint
that the pack/ directory doesn't have index files for packs that aren't
also there? (I've been putting the index files for packs that might be
possibile to get there, and relying on the above check to make sure that
they don't affect anything if it hasn't fetched the pack.)
Of course, we should never write to files in locations that anything looks
at; we want everything to appear atomically, completely written and
verified. But there's nothing wrong with having the C code place the
objects, which is certainly going to be necessary in the case of
downloading them by HTTP, since the program will want to place them and
enable them while running.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 appears to have broken cg-init
From: Bryan Larsen @ 2005-07-11 4:01 UTC (permalink / raw)
To: Joel Becker; +Cc: Petr Baudis, git
In-Reply-To: <20050711015820.GA16618@ca-server1.us.oracle.com>
Yes, I meant to use $ARGS. I included the fix in the patchset I just sent.
Sorry,
Bryan
Joel Becker wrote:
> Petr,
> Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 contains the
> chunk:
>
> -uri=$1
> +
> +infoonly=
> +while optparse; do
> + if optparse -N; then
> + infoonly=-N
> + else
> + optfail
> + fi
> +done
> +
> +uri=$ARGV
>
> However, $ARGV is not a variable I've ever seen supported in a
> Bourne-like shell. Certainly Bash supports BASH_ARGV, but not ARGV.
> The recent option parsing code adds ARGS in cg-Xlib, but not
> ARGV.
> The upshot is that a cg-clone/cg-init attempt thinks $uri is
> empty, and always creates an initial commit. No clone. I don't know
> how folks have gotten cg-clone rsync://linus to work since this change
> went in.
> I don't know what the proper solution is with the modern option
> code, but changing it back to 'url=$1' allows me to grab Linus' tree.
>
> Joel
^ permalink raw reply
* [PATCH 4/4] switch cg-commit -N to use --missing-ok instead of --no-check
From: Bryan Larsen @ 2005-07-11 3:53 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711035305.22229.87752.sendpatchset@bryan-larsens-ibook-g4.local>
Make cg-commit aware of the rename of git-write-tree --no-check to --missing-ok.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -111,13 +111,13 @@ forceeditor=
ignorecache=
infoonly=
commitalways=
-nocheck=
+missingok=
msgs=()
while optparse; do
if optparse -C; then
ignorecache=1
elif optparse -N; then
- nocheck=--no-check
+ missingok=--missing-ok
infoonly=--info-only
elif optparse -e; then
forceeditor=1
@@ -311,7 +311,7 @@ if [ -s "$_git/HEAD" ]; then
oldheadstr="-p $oldhead"
fi
-treeid=$(git-write-tree ${nocheck})
+treeid=$(git-write-tree ${missingok})
[ "$treeid" ] || die "git-write-tree failed"
if [ ! "$force" ] && [ ! "$merging" ] && [ "$oldhead" ] &&
[ "$treeid" = "$(tree-id)" ]; then
^ permalink raw reply
* [PATCH 3/4] add --missing-ok option to write-tree
From: Bryan Larsen @ 2005-07-11 3:53 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711035305.22229.87752.sendpatchset@bryan-larsens-ibook-g4.local>
Add --missing-ok option to git-write.tree. This option allows a write-tree even if the referenced objects are not in the database.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -10,6 +10,7 @@ git-write-tree - Creates a tree from the
SYNOPSIS
--------
'git-write-tree'
+ [--missing-ok]
DESCRIPTION
-----------
@@ -23,7 +24,11 @@ In order to have that match what is actu
now, you need to have done a "git-update-cache" phase before you did the
"git-write-tree".
-
+OPTIONS
+-------
+--missing-ok::
+ Normally "git-write-tree" ensures that the objects referenced by the
+ directory exist in the object database. This option disables this check.
////////////////////////////////////////////////////////////////
diff --git a/write-tree.c b/write-tree.c
--- a/write-tree.c
+++ b/write-tree.c
@@ -5,6 +5,8 @@
*/
#include "cache.h"
+static int missing_ok = 0;
+
static int check_valid_sha1(unsigned char *sha1)
{
int ret;
@@ -61,7 +63,7 @@ static int write_tree(struct cache_entry
sha1 = subdir_sha1;
}
- if (check_valid_sha1(sha1) < 0)
+ if (!missing_ok && check_valid_sha1(sha1) < 0)
exit(1);
entrylen = pathlen - baselen;
@@ -86,6 +88,16 @@ int main(int argc, char **argv)
int i, funny;
int entries = read_cache();
unsigned char sha1[20];
+
+ if (argc==2) {
+ if (!strcmp(argv[1], "--missing-ok"))
+ missing_ok = 1;
+ else
+ die("unknown option %s", argv[1]);
+ }
+
+ if (argc>2)
+ die("too many options");
if (entries < 0)
die("git-write-tree: error reading cache");
^ permalink raw reply
* [PATCH 2/4] bugfix for cg-init -N: pass -N to cg-commit
From: Bryan Larsen @ 2005-07-11 3:53 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711035305.22229.87752.sendpatchset@bryan-larsens-ibook-g4.local>
Bugfix for cg-init -N: the -N option needs to be passed down into cg-commit as well.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -56,7 +56,7 @@ if [ "$uri" ]; then
else
git-read-tree # Seed the dircache
find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
- cg-commit -C -m"Initial commit" -E
+ cg-commit -C -m"Initial commit" -E ${infoonly}
fi
trap "" SIGTERM EXIT
^ permalink raw reply
* [PATCH 1/4] bugfix for cg-init: ARGV
From: Bryan Larsen @ 2005-07-11 3:53 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
In-Reply-To: <20050711035305.22229.87752.sendpatchset@bryan-larsens-ibook-g4.local>
Bugfix: nasty typo (ARGV instead of ARGS) in my last patch to cg-init.
Signed off by: Bryan Larsen <bryan.larsen@gmail.com>
---
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -33,7 +33,7 @@ while optparse; do
fi
done
-uri=$ARGV
+uri=$ARGS
[ -e $_git ] && die "$_git already exists"
^ permalink raw reply
* [PATCH 0/4] add write-tree --missing OK, fix cogito -N options
From: Bryan Larsen @ 2005-07-11 3:53 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, pasky, git
All of my patches have been applied to git and cogito except for the
first one, the patch that adds the --no-check option to
git-write-tree. This is problematic because one of the patches that
Petr applied to cogito requires git-write-tree --no-check.
As well, there are two bugs in cg-init: the one that Joel Becker
found, plus the -N option needs to be passed to cg-commit.
Finally, Junio suggested that the --no-check option be renamed to
--missing-ok.
These patches fix the situation up.
1/4: bugfix for cg-init ARGV
2/4: bugfix for cg-init.
3/4: add --missing-ok option to git-write-tree.
4/4: change cg-commit to use --missing-ok instead of --no-check.
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Linus Torvalds @ 2005-07-11 3:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0507102253270.30848-100000@iabervon.org>
On Sun, 10 Jul 2005, Daniel Barkalow wrote:
>
> Perhaps git-pack-objects should have the base as a optional argument,
> with a default of the filename in $GIT_DIR/objects/pack and an option
> for sending just the pack file to stdout?
You really _mustn't_ try to create the pack directly to the
$GIT_DIR/objects/pack subdirectory - that would make git itself start
possibly using that pack before the index is all done, and that would be
just wrong and nasty.
So you really should _always_ generate the pack somewhere else, and then
move it (pack file first, index file second).
Which is, btw, exactly what "git repack" does, so the solution to the
problem is to just never use git-pack-objects directly if you don't like
the semantics..
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Daniel Barkalow @ 2005-07-11 3:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507101731330.17536@g5.osdl.org>
On Sun, 10 Jul 2005, Linus Torvalds wrote:
>
>
> On Sun, 10 Jul 2005, Daniel Barkalow wrote:
>
> > On Sun, 10 Jul 2005, Linus Torvalds wrote:
> > >
> > > Well, regardless, we want to be able to specify which directory to write
> > > them to. We don't necessarily want to write them to the current working
> > > directory, nor do we want to write them to their eventual destination in
> > > .git/objects/pack.
> > >
> > > In fact, the main current user ("git repack") really wants to write them
> > > to a temporary file, and one that isn't even called "pack-xxx", since it
> > > ends up doing cleanup with
> > >
> > > rm -f .tmp-pack-*
> > >
> > > in case a previous re-pack was interrupted (in which case it simply cannor
> > > know what the exact name was supposed to be).
> > >
> > > So the "basename" ends up being necessary and meaningful regardless. We do
> > > _not_ want to remove that capability.
> >
> > Shouldn't we do the same thing we do with object files? I don't see any
> > difference in desired behavior.
>
> Well, the main difference is that pack-files can be used for many things.
>
> For example, a web interface for getting a pack-file between two releases:
> say you knew you had version xyzzy, and you want to get version xyzzy+1,
> you could do that through webgit some way even with a "stupid" interface.
> Kay already had some patch to generate pack-files for something.
>
> The point being that pack-files are _not_ like objects. Pack-files are
> meant for communication. Having them in .git/objects/pack is just one
> special case.
Okay, I can see the use for them getting written to arbitrary paths; but I
think that it's worth having a canonical location for a pack that's being
used by the system (either not having been sent anywhere, or after having
been received). Perhaps git-pack-objects should have the base as a
optional argument, with a default of the filename in $GIT_DIR/objects/pack
and an option for sending just the pack file to stdout? I think that
covers everything in order of usefulness, and means that the program deals
with any filename that the user doesn't know in advance.
> > Why not checksum it in a predictable order, either that of the pack file
> > or the index? We do care that it's something verifiable, so that people
> > can't cause intentional collisions (for a DoS) just by naming their packs
> > after existing packs that users might not have downloaded yet.
>
> We could sha1-sum the "sorted by SHA1" list, I guess.
That'd be good; then git-http-pull can validate the hash on the index and
be sure that a matching pack file from a different location still has the
same contents.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Design for http-pull on repo with packs
From: Junio C Hamano @ 2005-07-11 3:18 UTC (permalink / raw)
To: Dan Holmsand, Daniel Barkalow; +Cc: torvalds, git
In-Reply-To: <42D17D89.9080808@innehallsbolaget.se>
One very minor problem I have with Holmsand approach [*1*] is
that the original Barkalow puller allowed a really dumb http
server by not requiring directory index at all. For somebody
like me with a cheap ISP account [*2*], it was great that I did
not have to update 256 index.html files for objects/??/
directories. Admittedly, it would be just one directory
object/pack/, but still...
On the other hand, picking an optimum set of packs from
overlapping set of packs is indeed a very interesting (and hard
combinatorial) problem to solve. I am hoping that in practice
people would not force clients to do it with "interesting" set
of packs. I would hope them to have just a full pack and
incrementals, never having ovelaps, like Linus plans to do on
his kernel repo.
On the other hand, for somebody like Jeff Garzik with 50 heads,
it might make some sense to have a handful different overlapping
packs, optimized for different sets of people wanting to pull
some but not all of his heads.
Having said that, even if we want to support such a repository,
we should remember that the server side optimization needs to be
done only once per push to support many pulls by different
downstream clients. Maybe preparing more than "list of pack
file names" to help clients decide which packs to pull is
desirable anyway. Say, "here are the list of packs. If you want
to sync with this and that head, I would suggest starting by
getting this pack."
[Footnotes]
*1* I was about to type Dan's, but both of you are ;-).
*2* Not having a public, rsync-reachable repository gave me a
lot of incentive to think about issues to support small/cheap
projects well ;-).
^ permalink raw reply
* Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 appears to have broken cg-init
From: Joel Becker @ 2005-07-11 1:58 UTC (permalink / raw)
To: Petr Baudis, git
Petr,
Commit 7c5977297f07c2a52c8c0f486309076b2a795d33 contains the
chunk:
-uri=$1
+
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=-N
+ else
+ optfail
+ fi
+done
+
+uri=$ARGV
However, $ARGV is not a variable I've ever seen supported in a
Bourne-like shell. Certainly Bash supports BASH_ARGV, but not ARGV.
The recent option parsing code adds ARGS in cg-Xlib, but not
ARGV.
The upshot is that a cg-clone/cg-init attempt thinks $uri is
empty, and always creates an initial commit. No clone. I don't know
how folks have gotten cg-clone rsync://linus to work since this change
went in.
I don't know what the proper solution is with the modern option
code, but changing it back to 'url=$1' allows me to grab Linus' tree.
Joel
--
Life's Little Instruction Book #3
"Watch a sunrise at least once a year."
Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Trial git RPM's..
From: Linus Torvalds @ 2005-07-11 1:18 UTC (permalink / raw)
To: Git Mailing List
Ok, I tagged a "v0.99" thing, and pushed it out. I've also made trial
RPM's of it: src, ppc64 and x86. They're build on whatever random machines
I had, and on the ppc64 I chose to do it on my FC4 machine that has newer
libraries than my YDL one. The x86 thing is FC3, I do believe.
I haven't really verified the RPM's in any other way than a trial
installation on one machine, and "gitk" seemed to work. Whoop. The idea
being that this is a good way to check whether the rpm target works, _and_
cogito can have something to build against.
They rpm's are at
http://www.kernel.org/pub/software/scm/git/
or will be once mirrored.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Linus Torvalds @ 2005-07-11 0:34 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0507101959410.30848-100000@iabervon.org>
On Sun, 10 Jul 2005, Daniel Barkalow wrote:
> On Sun, 10 Jul 2005, Linus Torvalds wrote:
> >
> > Well, regardless, we want to be able to specify which directory to write
> > them to. We don't necessarily want to write them to the current working
> > directory, nor do we want to write them to their eventual destination in
> > .git/objects/pack.
> >
> > In fact, the main current user ("git repack") really wants to write them
> > to a temporary file, and one that isn't even called "pack-xxx", since it
> > ends up doing cleanup with
> >
> > rm -f .tmp-pack-*
> >
> > in case a previous re-pack was interrupted (in which case it simply cannor
> > know what the exact name was supposed to be).
> >
> > So the "basename" ends up being necessary and meaningful regardless. We do
> > _not_ want to remove that capability.
>
> Shouldn't we do the same thing we do with object files? I don't see any
> difference in desired behavior.
Well, the main difference is that pack-files can be used for many things.
For example, a web interface for getting a pack-file between two releases:
say you knew you had version xyzzy, and you want to get version xyzzy+1,
you could do that through webgit some way even with a "stupid" interface.
Kay already had some patch to generate pack-files for something.
The point being that pack-files are _not_ like objects. Pack-files are
meant for communication. Having them in .git/objects/pack is just one
special case.
> Why not checksum it in a predictable order, either that of the pack file
> or the index? We do care that it's something verifiable, so that people
> can't cause intentional collisions (for a DoS) just by naming their packs
> after existing packs that users might not have downloaded yet.
We could sha1-sum the "sorted by SHA1" list, I guess.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Daniel Barkalow @ 2005-07-11 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507101637390.17536@g5.osdl.org>
On Sun, 10 Jul 2005, Linus Torvalds wrote:
> On Sun, 10 Jul 2005, Junio C Hamano wrote:
> >
> > So I would suggest either:
> >
> > - droping the packname parameter from git-pack-objects. Make
> > the packs always named pack-X{40}.pack (or just X{40}.pack);
>
> Well, regardless, we want to be able to specify which directory to write
> them to. We don't necessarily want to write them to the current working
> directory, nor do we want to write them to their eventual destination in
> .git/objects/pack.
>
> In fact, the main current user ("git repack") really wants to write them
> to a temporary file, and one that isn't even called "pack-xxx", since it
> ends up doing cleanup with
>
> rm -f .tmp-pack-*
>
> in case a previous re-pack was interrupted (in which case it simply cannor
> know what the exact name was supposed to be).
>
> So the "basename" ends up being necessary and meaningful regardless. We do
> _not_ want to remove that capability.
Shouldn't we do the same thing we do with object files? I don't see any
difference in desired behavior.
> > also have verify-pack to verify the name of the packfile,
> > and make sure X{40} part of the name matches what it claims
> > to contain;
>
> Now, that would be fine, but it can't be done. Not the way things are laid
> out. A SHA1 checksum depends on the order the data was checksummed in, and
> we don't even save that.
Why not checksum it in a predictable order, either that of the pack file
or the index? We do care that it's something verifiable, so that people
can't cause intentional collisions (for a DoS) just by naming their packs
after existing packs that users might not have downloaded yet.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Linus Torvalds @ 2005-07-10 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Petr Baudis, git
In-Reply-To: <7vzmsus1eu.fsf@assigned-by-dhcp.cox.net>
On Sun, 10 Jul 2005, Junio C Hamano wrote:
>
> So I would suggest either:
>
> - droping the packname parameter from git-pack-objects. Make
> the packs always named pack-X{40}.pack (or just X{40}.pack);
Well, regardless, we want to be able to specify which directory to write
them to. We don't necessarily want to write them to the current working
directory, nor do we want to write them to their eventual destination in
.git/objects/pack.
In fact, the main current user ("git repack") really wants to write them
to a temporary file, and one that isn't even called "pack-xxx", since it
ends up doing cleanup with
rm -f .tmp-pack-*
in case a previous re-pack was interrupted (in which case it simply cannor
know what the exact name was supposed to be).
So the "basename" ends up being necessary and meaningful regardless. We do
_not_ want to remove that capability.
> also have verify-pack to verify the name of the packfile,
> and make sure X{40} part of the name matches what it claims
> to contain;
Now, that would be fine, but it can't be done. Not the way things are laid
out. A SHA1 checksum depends on the order the data was checksummed in, and
we don't even save that.
> - or drop sha1_pack_name() and let the user name the pack any
> way he wants.
No, I do want to use a SHA1, because I want to make sure that you can mix
packs in a rsync/wget environment where if two files are named the same,
they'll have the same contents.
So we can make verify-pack check that the pack-name matches the style
"pack-xxxxx." naming convention, but we can't match up the sha1 with
anything.
Linus
^ permalink raw reply
* Re: [PATCH 0/2] Support for packs in HTTP
From: Junio C Hamano @ 2005-07-10 23:10 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0507101539220.30848-100000@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This series has one patch which is ready to go in and one that's not
> (although it's a reasonable phony for the current state of the git world).
I like the general direction in which this patch is leading us.
But before going further, I'd like to see a consensus on the
pack naming convention. The "sha1 of packed object names" was
originally introduced to easily avoid the pack name collisions,
but not enforced, so a user could do the following and still
expect things to work:
$ n=`git-pack-objects pk <list-of-objects`
$ mv pk-$n.pack .git/objects/pack/pk.pack
$ mv pk-$n.idx .git/objects/pack/pk.idx
The first part of this patch makes things stricter, and your
packfile under .git/objects/pack _must_ be named pack-X{40}.pack
(I am not saying this is a bad thing). So I would suggest
either:
- droping the packname parameter from git-pack-objects. Make
the packs always named pack-X{40}.pack (or just X{40}.pack);
also have verify-pack to verify the name of the packfile,
and make sure X{40} part of the name matches what it claims
to contain;
- or drop sha1_pack_name() and let the user name the pack any
way he wants.
I am moderately in favor of the former.
^ permalink raw reply
* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Linus Torvalds @ 2005-07-10 22:36 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1pstrr8k1.fsf@ebiederm.dsl.xmission.com>
On Sat, 9 Jul 2005, Eric W. Biederman wrote:
>
> The current intelligent fetch currently has a problem that it cannot
> be used to bootstrap a repository. If you don't have an ancestor
> of what you are fetching you can't fetch it.
Sure you can.
See the current "git clone". It's actually quite good, it's a pleasure to
use now that it gives updates on how much it has done.
Just do
git clone src dest
to try it out. It starts out silent (for big repositories) because it
takes a while to get the whole rev list, but once it gets going it's quite
nice and gives a nice progress report..
It uses the exact same server side code that "git-fetch-pack" does (ie it
just starts "git-upload-pack" on the server).
Now, one thing you cannot do is to start a totally new _project_ on the
server side. In order to do a "git-send-pack", you need to first create a
directory and do a "git-init-db" on the remote side.
So to create a new project, what you need to do is
src$ ssh target
target$ mkdir new-project
target$ cd new-project
target$ git-init-db
target$ exit
src$ git-send-pack target:new-project master
and you've now sent your "master" branch to the new project at
"target:new-project".
You can even populate multiple branches at a time: just list them all (you
do have to list them, because by default "git-send-pack" will update the
_common_ branches, and since the other end is empty, there obviously are
no common branches to start with).
Ahh, you should even be able to automate the sending of all branches by
doing
git-send-pack target:new-project $(cd .git ; find refs -type f)
I think - that will end up being equivalent to a "reverse clone".
The smart clients are doing pretty damn well, I think.
Linus
^ 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