* Re: Where'd my GIT tree go?
From: Thomas Gleixner @ 2005-07-07 20:48 UTC (permalink / raw)
To: Tony Luck; +Cc: jon, git
In-Reply-To: <12c511ca0507062148679af4da@mail.gmail.com>
On Wed, 2005-07-06 at 21:48 -0700, Tony Luck wrote:
> Groan ... as well you should.
>
> My tree has re-appeared now. Thanks to whoever fixed it.
I noticed similar effects recently. Its related to the mirroring of
master.kernel.org to the public server. At some point you have only the
half of updates at the public site and obviously the git webscript
refuses to show your tree when HEAD is updated, but the referenced
commit blob is missing.
I guess that the mirroring is not aware of the update order (objects
first, HEAD last) which would prevent such oddities.
tglx
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Linus Torvalds @ 2005-07-07 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vk6k2sfa4.fsf@assigned-by-dhcp.cox.net>
On Thu, 7 Jul 2005, Junio C Hamano wrote:
>
> - X.git/objects/pack can have packed GIT archives. I
> envision that this will be a series of 5 to 20 MB packs,
> occasionally adding a new incremental pack when
> X.git/objects/??/ directories accumulate enough standalone
> SHA1 files. It is not necessary to have X.git/objects/??/
> files if an object is contained in one of the packs.
Note that I just re-packed the kernel archive on kernel.org, and removed
_all_ unpacked files. Once that percolates to the mirrors, the http
protocol will be useless without anything like this.
That said, I really think the dumb protocols are useless anyway. No other
system supports pure static object pulling anyway, and as far as I'm
concerned, I want "rsync" to kind of work (but it won't be optimal, since
re-packing will delete all the old objects and replace it with the new
pack that is downloaded anew). But plain http? I'm not convinced.
I'd much rather have a "stupid server" that just listens to a port, and
basically forks off and executes "git-upload-pack" when it's connected to
(perhaps reading the directory name first). Nothing else. Then we can do
a security analysis of upload-pack, which should be fairly easy since it's
not actually ever _writing_ anything.
At that point, you can do
git pull git://www.kernel.org/pub/scm/git/..
and it would just connect to some default "git port", pass off the
directory name, and be done with it - exact same discovery protocol that
now use for ssh. And "git clone" would also automatically work.
Linus
^ permalink raw reply
* [GIT PATCH] Add infrastructure for git rpm build
From: Chris Wright @ 2005-07-07 20:25 UTC (permalink / raw)
To: torvalds; +Cc: git
Linus,
You'll find the necessary infrastructure for doing an rpm build here:
kernel.org/pub/scm/linux/kernel/git/chrisw/git.git
The diff is below:
diff-tree a9db297485a7b8c641d3cf686d03cb63b774e530 (from dd7ba8b4949535c24e604a37709db0e3be9ccbbc)
Author: Chris Wright <chrisw@osdl.org>
Date: Thu Jul 7 13:09:50 2005 -0700
Infrastructure for git rpm builds. Adds GIT_VERSION to Makefile and new make
targets: git.spec, dist, and rpm. A simple 'make rpm' will build the rpm.
Also adds git.spec.in which is used to generate git.spec.
Signed-off-by: Chris Wright <chrisw@osdl.org>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -9,6 +9,8 @@
# BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely randomly
# break unless your underlying filesystem supports those sub-second times
# (my ext3 doesn't).
+GIT_VERSION=0.99
+
COPTS=-O2
CFLAGS=-g $(COPTS) -Wall
@@ -49,6 +51,7 @@ PROG= git-update-cache git-diff-files
all: $(PROG)
install: $(PROG) $(SCRIPTS)
+ $(INSTALL) -m755 -d $(dest)$(bin)
$(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin)
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
@@ -164,6 +167,21 @@ diffcore-break.o : $(LIB_H) diffcore.h
diffcore-order.o : $(LIB_H) diffcore.h
epoch.o: $(LIB_H)
+git.spec: git.spec.in
+ sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@
+
+GIT_TARNAME=git-$(GIT_VERSION)
+dist: git.spec
+ git-tar-tree HEAD $(GIT_TARNAME) > $(GIT_TARNAME).tar
+ @mkdir -p $(GIT_TARNAME)
+ @cp git.spec $(GIT_TARNAME)
+ tar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git.spec
+ @rm -rf $(GIT_TARNAME)
+ gzip -9 $(GIT_TARNAME).tar
+
+rpm: dist
+ rpmbuild -ta git-$(GIT_VERSION).tar.gz
+
test: all
$(MAKE) -C t/ all
diff --git a/git.spec.in b/git.spec.in
new file mode 100644
--- /dev/null
+++ b/git.spec.in
@@ -0,0 +1,42 @@
+Name: git
+Version: @@VERSION@@
+Release: 1
+Vendor: Linus Torvalds <torvalds@osdl.org>
+Summary: Git core and tools
+License: GPL
+Group: Development/Tools
+URL: http://kernel.org/pub/software/scm/git/
+Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
+BuildRequires: zlib-devel, openssl-devel, curl-devel
+BuildRoot: %{_tmppath}/%{name}-%{version}-root
+Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
+
+%description
+GIT comes in two layers. The bottom layer is merely an extremely fast
+and flexible filesystem-based database designed to store directory trees
+with regard to their history. The top layer is a SCM-like tool which
+enables human beings to work with the database in a manner to a degree
+similar to other SCM tools (like CVS, BitKeeper or Monotone).
+
+%prep
+%setup -q
+
+%build
+
+make
+
+%install
+rm -rf $RPM_BUILD_ROOT
+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} install
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root)
+%{_bindir}/*
+%doc README COPYING Documentation/*
+
+%changelog
+* Wed Jul 7 2005 Chris Wright <chris@osdl.org>
+- initial git spec file
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Junio C Hamano @ 2005-07-07 20:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507071158220.3293@g5.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> ... No other
LT> system supports pure static object pulling anyway,...
That is true, but on the other hand, no other system is easier
to be deployed by mere mortals on barebone ISP accounts.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Junio C Hamano @ 2005-07-07 19:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0507071158220.3293@g5.osdl.org>
I have two questions on "rev-list --objects".
(1) Would it make sense to have an extra flag to "rev-list
--objects" to make it list all the objects reachable from
commits listed in its output, even when some of them are
unchanged from UNINTERESTING commits? Right now, a pack
produced from "rev-list --objects A ^B" does not have enough
information to reproduce the tree associated with commit A.
(2) When "showing --objects", it lists the top-level tree node
with no name, which makes it indistinguishable from commit
objects by pack-objects, probably impacting the delta logic.
Would something like the following patch make sense, to name
such node "."; giving full-path not just the basename to
all named nodes would be even better, though.
---
# - master: git-format-patch: Prepare patches for e-mail submission.
# + (working tree)
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -179,7 +179,10 @@ static void show_commit_list(struct comm
die("unknown pending object %s (%s)", sha1_to_hex(obj->sha1), name);
}
while (objects) {
- printf("%s %s\n", sha1_to_hex(objects->item->sha1), objects->name);
+ const char *name = objects->name;
+ if (!*name && objects->item->type == tree_type)
+ name = ".";
+ printf("%s %s\n", sha1_to_hex(objects->item->sha1), name);
objects = objects->next;
}
}
^ permalink raw reply
* Re: Stacked GIT 0.3 (now more Quilt-like)
From: Peter Osterlund @ 2005-07-07 19:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT
In-Reply-To: <1120683255.6881.8.camel@localhost.localdomain>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> On Mon, 2005-07-04 at 14:32 +0200, Peter Osterlund wrote:
> > I agree with the other comments, it's probably not wise to rely on
> > wiggle, and wiggle sometimes makes a mess. However, it often does the
> > right thing, and with a configurable merge program and an undo
> > function, this should not be a problem. Just undo and try again if you
> > don't like the result.
>
> In the today's snapshot you can get the 'stg push --undo' command which
> reverts the result of a push operation (either failed or not). The patch
> is reverted to its previous state. It works even if you ran 'refresh'.
Thanks, this seems to work as expected.
> The current implementation does not remove the .older/.local/.remote
> files from the tree when undoing a push. I think I will first implement
> a 'resolve' command which takes care of these files.
>
> Anyway, once I fully test the current state of stgit, I will make the
> 0.4 release (probably this weekend).
I've found an unrelated problem. If I export patches with "stg export
dirname", there are no diffs included in the patches. The patch
description is all that is generated. If I omit the dirname parameter,
the export works correctly though.
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* [PATCH] Prevent t6000 series from dropping useless sed.script in t/
From: Junio C Hamano @ 2005-07-07 18:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Jon Seymour
The Makefile in the test suite directory considers any file
matching t[0-9][0-9][0-9][0-9]-*.sh as the top-level test script
to be executed. Unfortunately this was not documented, and the
common test library, t6000-lib.sh was named to match that
pattern. This caused t6000-lib.sh to be called from Makefile as
the top-level program, causing it to leave t/sed.script file
behind. Rename it to t6000lib.sh to prevent this, and document
the naming convention a bit more clearly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/README | 8 +++
t/t6000-lib.sh | 109 ---------------------------------------
t/t6000lib.sh | 109 +++++++++++++++++++++++++++++++++++++++
t/t6001-rev-list-merge-order.sh | 2 -
t/t6002-rev-list-bisect.sh | 2 -
t/t6003-rev-list-topo-order.sh | 2 -
6 files changed, 120 insertions(+), 112 deletions(-)
delete mode 100644 t/t6000-lib.sh
create mode 100644 t/t6000lib.sh
02e754c481bc5656ccb9b6159c78001d6cf5f552
diff --git a/t/README b/t/README
--- a/t/README
+++ b/t/README
@@ -79,6 +79,14 @@ Second digit tells the particular comman
Third digit (optionally) tells the particular switch or group of switches
we are testing.
+If you create files under t/ directory (i.e. here) that is not
+the top-level test script, never name the file to match the above
+pattern. The Makefile here considers all such files as the
+top-level test script and tries to run all of them. A care is
+especially needed if you are creating a common test library
+file, similar to test-lib.sh, because such a library file may
+not be suitable for standalone execution.
+
Writing Tests
-------------
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
deleted file mode 100644
--- a/t/t6000-lib.sh
+++ /dev/null
@@ -1,109 +0,0 @@
-[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
-
-:> sed.script
-
-# Answer the sha1 has associated with the tag. The tag must exist in .git or .git/refs/tags
-tag()
-{
- _tag=$1
- [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
- cat .git/refs/tags/$_tag
-}
-
-# Generate a commit using the text specified to make it unique and the tree
-# named by the tag specified.
-unique_commit()
-{
- _text=$1
- _tree=$2
- shift 2
- echo $_text | git-commit-tree $(tag $_tree) "$@"
-}
-
-# Save the output of a command into the tag specified. Prepend
-# a substitution script for the tag onto the front of sed.script
-save_tag()
-{
- _tag=$1
- [ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
- shift 1
- "$@" >.git/refs/tags/$_tag
-
- echo "s/$(tag $_tag)/$_tag/g" > sed.script.tmp
- cat sed.script >> sed.script.tmp
- rm sed.script
- mv sed.script.tmp sed.script
-}
-
-# Replace unhelpful sha1 hashses with their symbolic equivalents
-entag()
-{
- sed -f sed.script
-}
-
-# Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
-# tag to a specified value. Restore the original value on return.
-as_author()
-{
- _author=$1
- shift 1
- _save=$GIT_AUTHOR_EMAIL
-
- export GIT_AUTHOR_EMAIL="$_author"
- "$@"
- export GIT_AUTHOR_EMAIL="$_save"
-}
-
-commit_date()
-{
- _commit=$1
- git-cat-file commit $_commit | sed -n "s/^committer .*> \([0-9]*\) .*/\1/p"
-}
-
-on_committer_date()
-{
- _date=$1
- shift 1
- GIT_COMMITTER_DATE=$_date "$@"
-}
-
-# Execute a command and suppress any error output.
-hide_error()
-{
- "$@" 2>/dev/null
-}
-
-check_output()
-{
- _name=$1
- shift 1
- if eval "$*" | entag > $_name.actual
- then
- diff $_name.expected $_name.actual
- else
- return 1;
- fi
-}
-
-# Turn a reasonable test description into a reasonable test name.
-# All alphanums translated into -'s which are then compressed and stripped
-# from front and back.
-name_from_description()
-{
- tr "'" '-' | tr '~`!@#$%^&*()_+={}[]|\;:"<>,/? ' '-' | tr -s '-' | tr '[A-Z]' '[a-z]' | sed "s/^-*//;s/-*\$//"
-}
-
-
-# Execute the test described by the first argument, by eval'ing
-# command line specified in the 2nd argument. Check the status code
-# is zero and that the output matches the stream read from
-# stdin.
-test_output_expect_success()
-{
- _description=$1
- _test=$2
- [ $# -eq 2 ] || error "usage: test_output_expect_success description test <<EOF ... EOF"
- _name=$(echo $_description | name_from_description)
- cat > $_name.expected
- test_expect_success "$_description" "check_output $_name \"$_test\""
-}
diff --git a/t/t6000lib.sh b/t/t6000lib.sh
new file mode 100644
--- /dev/null
+++ b/t/t6000lib.sh
@@ -0,0 +1,109 @@
+[ -d .git/refs/tags ] || mkdir -p .git/refs/tags
+
+:> sed.script
+
+# Answer the sha1 has associated with the tag. The tag must exist in .git or .git/refs/tags
+tag()
+{
+ _tag=$1
+ [ -f .git/refs/tags/$_tag ] || error "tag: \"$_tag\" does not exist"
+ cat .git/refs/tags/$_tag
+}
+
+# Generate a commit using the text specified to make it unique and the tree
+# named by the tag specified.
+unique_commit()
+{
+ _text=$1
+ _tree=$2
+ shift 2
+ echo $_text | git-commit-tree $(tag $_tree) "$@"
+}
+
+# Save the output of a command into the tag specified. Prepend
+# a substitution script for the tag onto the front of sed.script
+save_tag()
+{
+ _tag=$1
+ [ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
+ shift 1
+ "$@" >.git/refs/tags/$_tag
+
+ echo "s/$(tag $_tag)/$_tag/g" > sed.script.tmp
+ cat sed.script >> sed.script.tmp
+ rm sed.script
+ mv sed.script.tmp sed.script
+}
+
+# Replace unhelpful sha1 hashses with their symbolic equivalents
+entag()
+{
+ sed -f sed.script
+}
+
+# Execute a command after first saving, then setting the GIT_AUTHOR_EMAIL
+# tag to a specified value. Restore the original value on return.
+as_author()
+{
+ _author=$1
+ shift 1
+ _save=$GIT_AUTHOR_EMAIL
+
+ export GIT_AUTHOR_EMAIL="$_author"
+ "$@"
+ export GIT_AUTHOR_EMAIL="$_save"
+}
+
+commit_date()
+{
+ _commit=$1
+ git-cat-file commit $_commit | sed -n "s/^committer .*> \([0-9]*\) .*/\1/p"
+}
+
+on_committer_date()
+{
+ _date=$1
+ shift 1
+ GIT_COMMITTER_DATE=$_date "$@"
+}
+
+# Execute a command and suppress any error output.
+hide_error()
+{
+ "$@" 2>/dev/null
+}
+
+check_output()
+{
+ _name=$1
+ shift 1
+ if eval "$*" | entag > $_name.actual
+ then
+ diff $_name.expected $_name.actual
+ else
+ return 1;
+ fi
+}
+
+# Turn a reasonable test description into a reasonable test name.
+# All alphanums translated into -'s which are then compressed and stripped
+# from front and back.
+name_from_description()
+{
+ tr "'" '-' | tr '~`!@#$%^&*()_+={}[]|\;:"<>,/? ' '-' | tr -s '-' | tr '[A-Z]' '[a-z]' | sed "s/^-*//;s/-*\$//"
+}
+
+
+# Execute the test described by the first argument, by eval'ing
+# command line specified in the 2nd argument. Check the status code
+# is zero and that the output matches the stream read from
+# stdin.
+test_output_expect_success()
+{
+ _description=$1
+ _test=$2
+ [ $# -eq 2 ] || error "usage: test_output_expect_success description test <<EOF ... EOF"
+ _name=$(echo $_description | name_from_description)
+ cat > $_name.expected
+ test_expect_success "$_description" "check_output $_name \"$_test\""
+}
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -6,7 +6,7 @@
test_description='Tests git-rev-list --merge-order functionality'
. ./test-lib.sh
-. ../t6000-lib.sh # t6xxx specific functions
+. ../t6000lib.sh # t6xxx specific functions
# test-case specific test function
check_adjacency()
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -5,7 +5,7 @@
test_description='Tests git-rev-list --bisect functionality'
. ./test-lib.sh
-. ../t6000-lib.sh
+. ../t6000lib.sh # t6xxx specific functions
bc_expr()
{
diff --git a/t/t6003-rev-list-topo-order.sh b/t/t6003-rev-list-topo-order.sh
--- a/t/t6003-rev-list-topo-order.sh
+++ b/t/t6003-rev-list-topo-order.sh
@@ -6,7 +6,7 @@
test_description='Tests git-rev-list --topo-order functionality'
. ./test-lib.sh
-. ../t6000-lib.sh # t6xxx specific functions
+. ../t6000lib.sh # t6xxx specific functions
list_duplicates()
{
------------
^ permalink raw reply
* [PATCH] cogito.spec.in update
From: Chris Wright @ 2005-07-07 18:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, John Ellson
Update cogito.spec.in to current. This uses .gz instead of .bz2 for source
target as suggested by John Ellson, as well as some assorted minor changes.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/cogito.spec.in b/cogito.spec.in
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -6,11 +6,11 @@ Summary: Git core and tools
License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/cogito/
-Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.bz2
+Source: http://kernel.org/pub/software/scm/cogito/%{name}-%{version}.tar.gz
Obsoletes: git
BuildRequires: zlib-devel, openssl-devel, curl-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-root
-Prereq: sh-utils, diffutils, rcs, mktemp >= 1.5
+Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
%description
GIT comes in two layers. The bottom layer is merely an extremely fast
@@ -35,11 +35,20 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
-/usr/bin/*
-/usr/lib/cogito
+%{_bindir}/*
+%dir /usr/lib/cogito
+/usr/lib/cogito/*
%doc README COPYING Documentation/*
%changelog
+* Wed Jul 6 2005 Chris Wright <chris@osdl.org> 0.12-1
+- update spec file
+
+* Thu Jun 9 2005 Chris Wright <chrisw@osdl.org> 0.11.3-1
+- Add openssl patch from Dan Holmsand <holmsand@gmail.com>
+- Add cg-Xlib patch to fix showdate output
+- Update %files with changes inspired by Neil Horman <nhorman@redhat.com>
+
* Mon May 9 2005 H. Peter Anvin <hpa@zytor.com> 0.10-1
- New upstream revision
- Rename spec file to cogito.spec
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: Chris Wright @ 2005-07-07 17:26 UTC (permalink / raw)
To: John Ellson; +Cc: Chris Wright, git
In-Reply-To: <42CD64F9.1010304@research.att.com>
* John Ellson (ellson@research.att.com) wrote:
> So now I have to ask, where does that come from if its not created by
> "make dist" ?
It's automated by kernel.org mirroring (along with signature
generation). So .gz is built, uploaded, the rest is automatic.
> Is what I'm asking to do in the above sequence somehow unreasonable?
> Would it
> be any loss if the Source: line in cogito.spec.in refered to the .gz
> instead of the .bz2 such that the
> above sequence works for those of us that like to build rpms directly
> from the git tree?
Yes, I've got a patch for the spec.in, I'll toss that in.
> Alternatively, perhaps "make dist" could generate the .bz2 instead?
No, because of the way kernel.org mirroring works.
thanks,
-chris
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Junio C Hamano @ 2005-07-07 17:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050707144501.GG19781@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@suse.cz> writes:
PB> It won't happen. Or rather, I hope the HTTP pulls become more efficient
PB> soon. Actually, perhaps Linus has something done already, my workstation
PB> is a bit derailed now so I couldn't pull from him in the last few days
PB> (hopefully will sort that out today).
PB> Hmm, yes, I guess Linus won't be touching the HTTP backend at all. ;-) I
PB> suggest you to check the last development in Linus' branch and sync with
PB> Daniel Barkalow, who promised improving the pull tools as well.
If this weekend is not too late, I have been brewing what is
called an "efficient pull from dumb servers" suite, which would
hopefully fill this gap. I am still in the process of finishing
the details, but basically it already seems to work.
Linus, please drop the patch I sent you earlier, privately by
mistake not CCing the list, that implemented only the server
end. I've changed some file formats already from that one.
The outline of how it works is like this.
* I assume a dumb transport (read: static files only HTTP
server) and no on-request server side processing. All the
smarts must go in the client. The server side X.git being an
ordinary GIT archive (no need for files in the work tree),
plus:
- X.git/objects/pack can have packed GIT archives. I
envision that this will be a series of 5 to 20 MB packs,
occasionally adding a new incremental pack when
X.git/objects/??/ directories accumulate enough standalone
SHA1 files. It is not necessary to have X.git/objects/??/
files if an object is contained in one of the packs.
- X.git/info/ has three extra files.
- "inventory" lists all the branches stored in X.git/refs
and looks like this (contents and path):
ff83c8f3554ceb444b413beaeb49b4a781dae944 snap/0
013e7c7ff498aae82d799f80da37fbd395545456 snap/10
ff83c8f3554ceb444b413beaeb49b4a781dae944 heads/master
dd7ba8b4949535c24e604a37709db0e3be9ccbbc heads/linus
This is to facilitate discovery from a transport that is
not so "ls" friendly, like HTTP.
- "pack" lists available packs under X.git/objects/pack and
looks like this (size and name):
432495 pk-65fe69e9bc2e8a3e0881e008dde182522156ba7c.pack
The file is there for discovery. The size is used by the
client to discover optimum set of packs to slurp.
- "rev-cache" is a binary file that describes commit
ancestry information in a dense format. It lists all
commits available from this repository along with who
its parents are for each of the commit. This file is
produced append-only, so that the server side can use
rsync based mirroring scheme.
A new command "git-update-dumb-server" is used to prepare
these three files. There may need a helper script that uses
git-pack-objects and friends to prepare packs partitioned to
allow pulling a popular branch efficiently.
* The client side is called "git-dumb-pull-script". This
downloads the above three files, and .idx files associated
with packs described in "pack". With the information in
"inventory" about desired branch to pull from along with
"rev-cache" ancestry information, it discovers the set of
commits that is lacking from its local store. By comparing
that list with downloaded .idx files, along with size
information for each pack, it comes up a list of packs to
download to cover the most commits that it wants to obtain,
and downloads them, verifies them and stores them in its
.git/objects/pack/ directory.
The above process of downloading packs would typically not
cover all the things lacking, because some new commits may
not be in any of the packs. After this point, the usual
commit-walking git-http-pull can be used to fill the rest,
and it does not have to pull that many objects. Dan's
http-pull parallelism improvement would be very useful
independently here.
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: John Ellson @ 2005-07-07 17:23 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050707170748.GN5324@shell0.pdx.osdl.net>
Chris Wright wrote:
>* John Ellson (ellson@research.att.com) wrote:
>
>
>>But:
>> cd cogito
>> cg-update
>> make dist
>> rpmbuild -ta cogito-0.12.tar.gz
>>
>>still doesn't work. Do you have a different process for generating
>>the initial cogito-0.12-1src.rpm ?
>>
>>
>
>I start from the bz2 from kernel.org.
>
>thanks,
>-chris
>
>
So now I have to ask, where does that come from if its not created by
"make dist" ?
Is what I'm asking to do in the above sequence somehow unreasonable?
Would it
be any loss if the Source: line in cogito.spec.in refered to the .gz
instead of the .bz2 such that the
above sequence works for those of us that like to build rpms directly
from the git tree?
Alternatively, perhaps "make dist" could generate the .bz2 instead?
John
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: Chris Wright @ 2005-07-07 17:07 UTC (permalink / raw)
To: John Ellson; +Cc: Chris Wright, git
In-Reply-To: <42CD2859.10608@research.att.com>
* John Ellson (ellson@research.att.com) wrote:
> But:
> cd cogito
> cg-update
> make dist
> rpmbuild -ta cogito-0.12.tar.gz
>
> still doesn't work. Do you have a different process for generating
> the initial cogito-0.12-1src.rpm ?
I start from the bz2 from kernel.org.
thanks,
-chris
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: John Ellson @ 2005-07-07 13:04 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050707062019.GL5324@shell0.pdx.osdl.net>
Chris Wright wrote:
>* John Ellson (ellson@research.att.com) wrote:
>
>
>>"rpmbuild -ta cogito-0.12.tar.gz" fails because cogito.spec.in refers to
>>".bz2" in its "Source:" line, instead of to ".gz".
>>
>>
>
>Just grab the .bz2, or the SRPM http://kernel.org/pub/software/scm/cogito/RPMS
>(still mirroring, I just uploaded it a bit ago)
>
>
But:
cd cogito
cg-update
make dist
rpmbuild -ta cogito-0.12.tar.gz
still doesn't work. Do you have a different process for generating
the initial cogito-0.12-1src.rpm ?
>
>
>>This is obviously a trivial patch. Do I need prior approval to send
>>patches to this group? What is the the significance of
>>"Signed-off-by:" Is there a FAQ I should read?
>>
>>
>
>No approval needed. Signed-off-by is in reference to the Developer's
>Certificate of Origin 1.1 (see item 11 in the Linux kernel's source file
>Documentation/SubmittingPatches).
>
>
Thanks. Thats what I was looking for.
John
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: Petr Baudis @ 2005-07-07 14:47 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <dah8i2$c8v$1@sea.gmane.org>
Dear diary, on Wed, Jul 06, 2005 at 08:40:00PM CEST, I got a letter
where John Ellson <ellson@research.att.com> told me that...
> "rpmbuild -ta cogito-0.12.tar.gz" fails because cogito.spec.in refers to
> ".bz2" in its "Source:" line, instead of to ".gz".
(FYI, cogito.spec.in is Chris' sole teritorry in Cogito, so I'll just
put in whatever he tells me to. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Petr Baudis @ 2005-07-07 14:45 UTC (permalink / raw)
To: Brian Gerst; +Cc: git
In-Reply-To: <42CBC822.30701@didntduck.org>
Dear diary, on Wed, Jul 06, 2005 at 02:01:38PM CEST, I got a letter
where Brian Gerst <bgerst@didntduck.org> told me that...
> Petr Baudis wrote:
> > Also, I've deprecated rsync, as I explained in another mail. Use
> >cg-branch-chg to change the branch URLs to some more sensible scheme -
> >most likely HTTP, or SSH if you want to push as well.
>
> I really question removing rsync before HTTP pulls become more
> effecient.
It won't happen. Or rather, I hope the HTTP pulls become more efficient
soon. Actually, perhaps Linus has something done already, my workstation
is a bit derailed now so I couldn't pull from him in the last few days
(hopefully will sort that out today).
> I did a complete pull of cogito from kernel.org, and http
> took over 50 minutes to pull everything, while rsync was done in just
> over 1 minute. I dared not even try to pull the full kernel at that speed.
>
> I suspect that part of the problem is that the pull methods are doing a
> depth first search, so we can't request the next object until the
> current object is fully received and parsed. Changing to a breadth
> first search would allow multiple requests in flight and asynchronous
> processing which should speed things up. I am exploring using the
> curl_multi_* functions to do this, but this will require changes to
> common code in pull.c.
Hmm, yes, I guess Linus won't be touching the HTTP backend at all. ;-) I
suggest you to check the last development in Linus' branch and sync with
Daniel Barkalow, who promised improving the pull tools as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: 2.6.12 hangs on boot
From: Alexander Y. Fomichev @ 2005-07-07 14:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, admin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506241446440.11175@ppc970.osdl.org>
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor 2/1 rip 6000 rsp ffff8100023dbf58
> > Initializing CPU#2
>
> Hmm.. Since you seem to be a git user, maybe you could try the git
> "bisect" thing to help narrow down exactly where this happened (and help
> test that thing too ;).
>
> You can basically use git to find the half-way point between a set of
> "known good" points and a "known bad" point ("bisecting" the set of
> commits), and doing just a few of those should give us a much better view
> of where things started going wrong.
>
> For example, since you know that 2.6.12-rc3 is good, and 2.6.12 is bad,
> you'd do
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3
>
> where the "v2.6.12 ^v2.6.12-rc3" thing basically means "everything in
> v2.6.12 but _not_ in v2.6.12-rc3" (that's what the ^ marks), and the
> "--bisect" flag just asks git-rev-list to list the middle-most commit,
> rather than all the commits in between those kernel versions.
>
> You should get the answer "0e6ef3e02b6f07e37ba1c1abc059f8bee4e0847f", but
> before you go any further, just make sure your git index is all clean:
>
> git status
>
> should not print anything else than "nothing to commit". If so, then
> you're ready to try the new "mid-point" head:
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 > .git/refs/heads/try1
> git checkout try1
>
> which will create a new branch called "try1", where the head is that
> "mid-point", and it will switch to that branch (this requires a fairly
> recent "git", btw, so make sure you update your git first).
>
> Then, compile that kernel, and try it out.
>
> Now, there are two possibilities: either "try1" ends up being good, or it
> still shows the bug. If it is a buggy kernel, then you now have a new
> "bad" point, and you do
>
> git-rev-list --bisect try1 ^v2.6.12-rc3 > .git/refs/heads/try2
> git checkout try2
>
> which is all the same thing as you did before, except now we use "try1" as
> the known bad one rather than v2.6.12 (and we call the new branch "try2"
> of course).
>
> However, if that "try1" is _good_, and doesn't show the bug, then you
> shouldn't replace the other "known good" case, but instead you should add
> it to the list of good commits (aka commits we don't want to know about):
>
> git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 ^try1 > .git/refs/heads/try2
> git checkout try2
>
> ie notice how we now say: want to get the bisection of the commits in
> v2.6.12 (known bad) but _not_ in either of v2.6.12-rc3 or the 'try1'
> branch (which are known good).
>
> After compiling and testing a few kernels, you will have narrowed the
> range down a _lot_, and at some point you can just say
>
> git-rev-list --pretty try4 ^v2.6.12-rc3 ^try1 ^try3
>
> (or however the "success/failure" pattern ends up being - the above
> example line assumes that "try1" didn't have the bug, but "try2" did, and
> then "try3" was ok again but "try4" was buggy), and you'll get a fairly
> small list of commits that are the potential "bad" ones.
>
> After the above four tries, you'd have limited it down to a list of 95
> changes (from the original 1520), so it would really be best to try six or
> seven different kernels, but at that point you'd have it down to less than
> 20 commits and then pinpointing the bug is usually much easier.
>
> And when you're done, you can just do
>
> git checkout master
>
> and you're back to where you started.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Thank you for your answer, i've been on vacations last two weeks,
and i didn't have an access to my mail account.
Hmmm... it seems that 'bisect' method not applicable to this host, this
is production server, not so critical to one or two reboots but 'bisect' will
require much more, i suspect. I've another host, nearly the same as of
hardware and non-critical where such tests could be done , but i haven't a
serial console on it as now. It takes some time to link console because both
of this are remote hosts.
--
Best regards.
Alexander Y. Fomichev <gluk@php4.ru>
Public PGP key: http://sysadminday.org.ru/gluk.asc
^ permalink raw reply
* using git without blobs in the object database
From: Bryan Larsen @ 2005-07-07 12:10 UTC (permalink / raw)
To: git
Use Case: A large set of large binary files, geographically
distributed. Each location has some unique files, some identical files
and some slightly modified files.
I want to use git to tell me what changed and when. But I cannot afford
to have it store the blobs in the object database, nor do I need to;
knowing the signature of previous objects is good enough.
It seems to me that most operations should work without these objects,
and that some people do so. For instance, git-update-cache has a
--cacheinfo option that facilitates this operation.
But not all commands work so well. For instance, git-write-tree will
fail if --cacheinfo was used to add a file. This failure is caused by a
call to check_valid_sha1(). It appears that this check is not strictly
necessary, just very useful for normal operation.
Would a patch that added a flag "--disable-sha1-check" to git-write-tree
be accepted? I hope that's all I need to add, but I haven't completed
my evaluation yet.
thanks,
Bryan
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Chris Wright @ 2005-07-07 6:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050703234629.GF13848@pasky.ji.cz>
* Petr Baudis (pasky@suse.cz) wrote:
> I'm happy to announce the release of the 0.12 version of the Cogito
> SCM-like layer over Linus' GIT tree history storage tool. Get it at
>
> http://www.kernel.org/pub/software/scm/cogito/
RPMs uploading to:
http://www.kernel.org/pub/software/scm/cogito/RPMS
thanks,
-chris
^ permalink raw reply
* Re: BUG: "rpmbuild -ta cogito-0.12.tar.gz" fails
From: Chris Wright @ 2005-07-07 6:20 UTC (permalink / raw)
To: John Ellson; +Cc: git
In-Reply-To: <dah8i2$c8v$1@sea.gmane.org>
* John Ellson (ellson@research.att.com) wrote:
> "rpmbuild -ta cogito-0.12.tar.gz" fails because cogito.spec.in refers to
> ".bz2" in its "Source:" line, instead of to ".gz".
Just grab the .bz2, or the SRPM http://kernel.org/pub/software/scm/cogito/RPMS
(still mirroring, I just uploaded it a bit ago)
> This is obviously a trivial patch. Do I need prior approval to send
> patches to this group? What is the the significance of
> "Signed-off-by:" Is there a FAQ I should read?
No approval needed. Signed-off-by is in reference to the Developer's
Certificate of Origin 1.1 (see item 11 in the Linux kernel's source file
Documentation/SubmittingPatches).
^ permalink raw reply
* Re: Where'd my GIT tree go?
From: Tony Luck @ 2005-07-07 4:48 UTC (permalink / raw)
To: jon; +Cc: git
In-Reply-To: <2cfc40320507062059233bb98c@mail.gmail.com>
On 7/6/05, Jon Seymour <jon.seymour@gmail.com> wrote:
> Ok, you asked for it:
>
> ...the GIT bucket.
>
> jon.
>
> ... ducks for cover ...
Groan ... as well you should.
My tree has re-appeared now. Thanks to whoever fixed it.
-Tony
^ permalink raw reply
* Re: Where'd my GIT tree go?
From: Jon Seymour @ 2005-07-07 3:59 UTC (permalink / raw)
To: Tony Luck; +Cc: git
In-Reply-To: <12c511ca0507062023291a098e@mail.gmail.com>
Ok, you asked for it:
...the GIT bucket.
jon.
... ducks for cover ...
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-07 3:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Daniel Barkalow, H. Peter Anvin, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507051132530.3570@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 5 Jul 2005, Eric W. Biederman wrote:
>>
>> True but if you can you will get multiple tags with the
>> same suggested name. So you need so way to find the one you
>> care about.
>
> I do agree that it would make sense to have a "tagger" field with the same
> semantics as the "committer" in a commit (including all the same fields:
> real name, email, and date).
Ok here is a patch that implements it.
I don't know how robust my code to get the defaults of tagger
email address and especially tagger name are but basically it
works.
In addition I added a message when git-tag-script is waiting
for you to type the tag message so people aren't confused.
And of course I modified git-mktag to check that the tagger
field is present.
Now git-pull-script just needs to be tweaked to optionally
add tags in the update into .git/refs/tags :) Using git-fsck-cache
to find tags is doable but it slows down as your archive grows.
Eric
diff --git a/date.c b/date.c
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -1,12 +1,30 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
+usage() {
+ echo 'git tag <tag name> [<sha1>]'
+ exit 1
+}
+
: ${GIT_DIR=.git}
+if [ ! -d "$GIT_DIR" ]; then
+ echo Not a git directory 1>&2
+ exit 1
+fi
+
+if [ $# -gt 2 -o $# -lt 1 ]; then
+ usage
+fi
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
+tagger_name=${GIT_COMMITTER_NAME:-$(sed -n -e "s/^$(whoami):[^:]*:[^:]*:[^:]*:\([^:,]*\).*:.*$/\1/p" < /etc/passwd)}
+tagger_email=${GIT_COMMITTER_EMAIL:-"$(whoami)@$(hostname --fqdn)"}
+tagger_date=$(date -d "${GIT_COMMITTER_DATE:-$(date -R)}" +"%s %z") || exit 1
+echo "Enter tag message now. ^D when finished"
+( echo -e "object $object\ntype $type\ntag $1\ntagger $tagger_name <$tagger_email> $tagger_date\n"; cat) > .tmp-tag
rm -f .tmp-tag.asc
gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
-git-mktag < .tmp-tag
-#rm .tmp-tag .tmp-tag.sig
+exit 1
+./git-mktag < .tmp-tag
+rm -f .tmp-tag .tmp-tag.sig
diff --git a/mktag.c b/mktag.c
--- a/mktag.c
+++ b/mktag.c
@@ -42,7 +42,7 @@ static int verify_tag(char *buffer, unsi
int typelen;
char type[20];
unsigned char sha1[20];
- const char *object, *type_line, *tag_line;
+ const char *object, *type_line, *tag_line, *tagger_line;
if (size < 64 || size > MAXSIZE-1)
return -1;
@@ -91,6 +91,11 @@ static int verify_tag(char *buffer, unsi
continue;
return -1;
}
+ /* Verify the tagger line */
+ tagger_line = tag_line;
+
+ if (memcmp(tagger_line, "tagger ", 7) || (tagger_line[7] == '\n'))
+ return -1;
/* The actual stuff afterwards we don't care about.. */
return 0;
@@ -119,7 +124,7 @@ int main(int argc, char **argv)
size += ret;
}
- // Verify it for some basic sanity: it needs to start with "object <sha1>\ntype "
+ // Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
if (verify_tag(buffer, size) < 0)
die("invalid tag signature file");
^ permalink raw reply
* Where'd my GIT tree go?
From: Tony Luck @ 2005-07-07 3:23 UTC (permalink / raw)
To: git
http://www.kernel.org/git has stopped showing my linux-2.6 tree (the
"to Linus" one, my "test-2.6" tree is still there).
This is probably my fault ... but I'm not sure exactly why.
Here's what I did. Last Thursday I applied a set of patches ... and my "apply"
script choked on one of them. Some casual inspection convinced me that the
changes had been applied, and I pushed the tree up to kernel.org.
But I was wrong, the 2nd out od a series of six was all messed up. And I'd
applied a couple more patches on top of that. Since none of this had been
pulled by Linus, I thought I'd clean it up and apologise to anyone who had
pulled from my tree.
So I backed HEAD up to the last good commit. Re-applied the changes with
a fixed version of the script, and then expected to find some detritus from
the first application in .git/objects. But "git-fsck-cache --unreachable ..."
only complained about the 2.6.11 tag/tree. Odd.
Then I pushed up to master.kernel.org ... and an hour later when the mirrors
did their thing, git-web stopped showing my tree.
HEAD is still a symlink to refs/heads/master. And that has the SHA1 of my
most recent commit ... which is present in .git/objects.
So what's wrong???
-Tony
^ permalink raw reply
* Summary Of Jon's Recent Patches
From: Jon Seymour @ 2005-07-07 2:51 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List
Hi,
I've recently posted the following patches, in this order:
These ones are tidy ups:
[PATCH] Remove use of SHOWN flag
[PATCH] Move SEEN flag into epoch.h, replace use of VISITED flag with SEEN flag
[PATCH] Simplification - remove unnecessary list reversal from epoch.c
This series contains a big fix, but assumes the tidy ups above have
been applied:
[PATCH 1/2] Fix --topo-order, --max-age interaction issue
[PATCH 2/2] Add test case that shows --topo-order, --max-age break
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: Summary Of Jon's Recent Patches
From: Jon Seymour @ 2005-07-07 2:53 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List
In-Reply-To: <2cfc40320507061951563bdd76@mail.gmail.com>
> This series contains a big fix, but assumes the tidy ups above have
> been applied:
That'd be a _bug_ fix
jon.
^ 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