* [PATCH 3/6] Add git-var a tool for reading interesting git variables.
From: Eric W. Biederman @ 2005-07-15 0:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Sharing code between shell scripts and C is a challenge.
The program git-var allows us to have a set of named values
that a shell script can interrogate and a normal C program
can simply call the functions that compute them. Allowing
sharing when computing plain test values.
---
Documentation/git-var.txt | 60 ++++++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 ++
Makefile | 3 +-
var.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 130 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-var.txt
create mode 100644 var.c
2c929de1b5444fadda13becb6df3d852277e6e27
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-var.txt
@@ -0,0 +1,60 @@
+git-var(1)
+==================
+v0.1, July 2005
+
+NAME
+----
+git-var - Print the git users identity
+
+
+SYNOPSIS
+--------
+git-var [ -l | <variable> ]
+
+DESCRIPTION
+-----------
+Prints a git logical variable.
+
+-l causes the logical variables to be listed.
+
+EXAMPLE
+--------
+$git-var GIT_AUTHOR_IDENT
+
+Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
+
+
+VARIABLES
+----------
+GIT_AUTHOR_IDENT
+ The author of a piece of code.
+
+GIT_COMMITTER_IDENT
+ The person who put a piece of code into git.
+
+Diagnostics
+-----------
+You don't exist. Go away!::
+ The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+ The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must have hate you!::
+ The password(5) name field is longer than a giant static buffer.
+
+See Also
+--------
+link:git-commit-tree.html[git-commit-tree]
+link:git-tag-script.html[git-tag-script]
+
+Author
+------
+Written by Eric Biederman <ebiederm@xmission.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -111,6 +111,9 @@ link:git-tar-tree.html[git-tar-tree]::
link:git-unpack-file.html[git-unpack-file]::
Creates a temporary file with a blob's contents
+link:git-var.html[git-var]::
+ Displays a git logical variable
+
link:git-verify-pack.html[git-verify-pack]::
Validates packed GIT archive files
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -48,7 +48,7 @@ PROG= git-update-cache git-diff-files
git-diff-stages git-rev-parse git-patch-id git-pack-objects \
git-unpack-objects git-verify-pack git-receive-pack git-send-pack \
git-prune-packed git-fetch-pack git-upload-pack git-clone-pack \
- git-show-index git-daemon
+ git-show-index git-daemon git-var
all: $(PROG)
@@ -148,6 +148,7 @@ git-receive-pack: receive-pack.c
git-send-pack: send-pack.c
git-prune-packed: prune-packed.c
git-fetch-pack: fetch-pack.c
+git-var: var.c
git-http-pull: LIBS += -lcurl
git-rev-list: LIBS += -lssl
diff --git a/var.c b/var.c
new file mode 100644
--- /dev/null
+++ b/var.c
@@ -0,0 +1,65 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Eric Biederman, 2005
+ */
+#include "cache.h"
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+
+static char *var_usage = "git-var [-l | <variable>]";
+
+struct git_var {
+ const char *name;
+ char *(*read)(void);
+};
+static struct git_var git_vars[] = {
+ { "GIT_COMMITTER_IDENT", git_committer_info },
+ { "GIT_AUTHOR_IDENT", git_author_info },
+ { "", NULL },
+};
+
+static void list_vars(void)
+{
+ struct git_var *ptr;
+ for(ptr = git_vars; ptr->read; ptr++) {
+ printf("%s=%s\n", ptr->name, ptr->read());
+ }
+}
+
+static const char *read_var(const char *var)
+{
+ struct git_var *ptr;
+ const char *val;
+ val = NULL;
+ for(ptr = git_vars; ptr->read; ptr++) {
+ if (strcmp(var, ptr->name) == 0) {
+ val = ptr->read();
+ break;
+ }
+ }
+ return val;
+}
+
+int main(int argc, char **argv)
+{
+ const char *val;
+ if (argc != 2) {
+ usage(var_usage);
+ }
+ setup_ident();
+ val = NULL;
+
+ if (strcmp(argv[1], "-l") == 0) {
+ list_vars();
+ return 0;
+ }
+ val = read_var(argv[1]);
+ if (!val)
+ usage(var_usage);
+
+ printf("%s\n", val);
+
+ return 0;
+}
^ permalink raw reply
* [PATCH 4/6] Update the list of diagnostics for git-commit-tree
From: Eric W. Biederman @ 2005-07-15 0:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
With the recent work on setup_ident() there are
a few more possible diagnostic messages form git-commit-tree
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/git-commit-tree.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
3dccd7f0c9e3cbc8bc17d3af01f9f1d273090082
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -68,6 +68,10 @@ Diagnostics
-----------
You don't exist. Go away!::
The passwd(5) gecos field couldn't be read
+Your parents must have hated you!::
+ The password(5) gecos field is longer than a giant static buffer.
+Your sysadmin must have hate you!::
+ The password(5) name field is longer than a giant static buffer.
See Also
--------
^ permalink raw reply
* [PATCH 5/6] Update git-tag-script to create the .git/refs/tags if it does not already exist
From: Eric W. Biederman @ 2005-07-15 1:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
When testing tags I ran into an interesting problem.
git-tag-script dies if .git/refs/tags/ does not exist.
And that directory didn't get created when I build my repository,
so we need to create it if it doesn't exist.
Signed-of-by: Eric W. Biederman <ebiederm@xmission.com>
---
git-tag-script | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
362c96f2a2959b648c8313d3530ea1e6df17e96c
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -20,5 +20,6 @@ grep -v '^#' < .editmsg | git-stripspace
( echo -e "object $object\ntype $type\ntag $name\n"; cat .tagmsg ) > .tmp-tag
rm -f .tmp-tag.asc .tagmsg
gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
+mkdir -p "$GIT_DIR/refs/tags"
git-mktag < .tmp-tag > "$GIT_DIR/refs/tags/$name"
#rm .tmp-tag .tmp-tag.sig
^ permalink raw reply
* [PATCH 6/6] Update tags to record who made them
From: Eric W. Biederman @ 2005-07-15 1:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
And finally what all of this has been leading up to.
The 2 line code change to record who made a tag,
and the 8 line code change to check that we recorded
the tag.
Gosh the error checking is always so much bigger than the code :)
---
git-tag-script | 3 ++-
mktag.c | 10 ++++++++--
2 files changed, 10 insertions(+), 3 deletions(-)
6ba7a00f34b28cf6761b517a2ad377c80780186b
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -7,6 +7,7 @@ name="$1"
object=${2:-$(cat "$GIT_DIR"/HEAD)}
type=$(git-cat-file -t $object) || exit 1
+tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
( echo "#"
echo "# Write a tag message"
@@ -17,7 +18,7 @@ grep -v '^#' < .editmsg | git-stripspace
[ -s .tagmsg ] || exit
-( echo -e "object $object\ntype $type\ntag $name\n"; cat .tagmsg ) > .tmp-tag
+( echo -e "object $object\ntype $type\ntag $name\ntagger $tagger\n"; cat .tagmsg ) > .tmp-tag
rm -f .tmp-tag.asc .tagmsg
gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
mkdir -p "$GIT_DIR/refs/tags"
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;
@@ -92,6 +92,12 @@ static int verify_tag(char *buffer, unsi
return -1;
}
+ /* Verify the tagger line */
+ tagger_line = tag_line;
+
+ if (memcmp(tagger_line, "tagger", 6) || (tagger_line[6] == '\n'))
+ return -1;
+
/* The actual stuff afterwards we don't care about.. */
return 0;
}
@@ -119,7 +125,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
* [PATCH] Add a RPMBUILD make variable
From: Eric W. Biederman @ 2005-07-15 1:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This allows RPMBUILD to be overridden for people with
old versions of rpm or people who want to pass rpmbuild extra options.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
50c6a0b3b5d461b81bd5ceb0808206bfa20a8bfa
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,7 @@ bin=$(prefix)/bin
CC=gcc
AR=ar
INSTALL=install
+RPMBUILD=rpmbuild
#
# sparse is architecture-neutral, which means that we need to tell it
@@ -185,7 +186,7 @@ dist: git-core.spec git-tar-tree
gzip -9 $(GIT_TARNAME).tar
rpm: dist
- rpmbuild -ta git-core-$(GIT_VERSION).tar.gz
+ $(RPMBUILD) -ta git-core-$(GIT_VERSION).tar.gz
test: all
$(MAKE) -C t/ all
^ permalink raw reply
* [PATCH] Use gzip -f when building the git-core tarball
From: Eric W. Biederman @ 2005-07-15 1:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This allows rebuilding the tarball when it is already present
without having to answer annoying questions from gzip
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d7c4e5ae707a6ad3028c48d800d568c554cc10af
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -183,7 +183,7 @@ dist: git-core.spec git-tar-tree
@cp git-core.spec $(GIT_TARNAME)
tar rf $(GIT_TARNAME).tar $(GIT_TARNAME)/git-core.spec
@rm -rf $(GIT_TARNAME)
- gzip -9 $(GIT_TARNAME).tar
+ gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
$(RPMBUILD) -ta git-core-$(GIT_VERSION).tar.gz
^ permalink raw reply
* [PATCH] Add doc and install-doc targets to the Makefile
From: Eric W. Biederman @ 2005-07-15 1:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This makes it straight forward for people wanting to build
and install the git man pages and the rest of the documentation
to do so.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/Makefile | 13 +++++++++++++
Makefile | 6 ++++++
2 files changed, 19 insertions(+), 0 deletions(-)
81c744189071d241dbb43b55b8694365a769e08d
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -6,6 +6,14 @@ DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_
DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
+prefix=$(HOME)
+bin=$(prefix)/bin
+mandir=$(prefix)/man
+man1=$(mandir)/man1
+man7=$(mandir)/man7
+
+INSTALL=install
+
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@@ -24,6 +32,11 @@ man: man1 man7
man1: $(DOC_MAN1)
man7: $(DOC_MAN7)
+install:
+ $(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7)
+ $(INSTALL) $(DOC_MAN1) $(dest)/$(man1)
+ $(INSTALL) $(DOC_MAN7) $(dest)/$(man7)
+
# 'include' dependencies
git-diff-%.txt: diff-format.txt diff-options.txt
touch $@
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -191,6 +191,12 @@ rpm: dist
test: all
$(MAKE) -C t/ all
+doc:
+ $(MAKE) -C Documentation all
+
+install-doc:
+ $(MAKE) -C Documentation install
+
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
rm -f git-core-*.tar.gz git-core.spec
^ permalink raw reply
* [PATCH] Update the spec file so it can build and install the documentation
From: Eric W. Biederman @ 2005-07-15 1:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
If you don't want the documentation simply build with
make RPMBUILD="rpmbuild --without docs"
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
git-core.spec.in | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
18d85dbab2fca214bfb625e65733d5fa52502111
diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -1,3 +1,4 @@
+# Pass --without docs to rpmbuild if you don't want the documetnation
Name: git-core
Version: @@VERSION@@
Release: 1
@@ -7,7 +8,7 @@ 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
+BuildRequires: zlib-devel, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
@@ -23,11 +24,11 @@ similar to other SCM tools (like CVS, Bi
%build
-make
+make all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make dest=$RPM_BUILD_ROOT prefix=%{_prefix} install
+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install %{!?_without_docs: install-doc}
%clean
rm -rf $RPM_BUILD_ROOT
@@ -35,8 +36,13 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%{_bindir}/*
-%doc README COPYING Documentation/*
+%doc README COPYING Documentation/*.txt
+%{!?_without_docs: %doc Documentation/*.html }
+%{!?_without_docs: %{_mandir}/man1/*.1.gz}
+%{!?_without_docs: %{_mandir}/man7/*.7.gz}
%changelog
+* Thu Jul 14 2005 Eric Biederman <ebiederm@xmission.com>
+- Add the man pages, and the --without docs build option
* Wed Jul 7 2005 Chris Wright <chris@osdl.org>
- initial git spec file
^ permalink raw reply
* [PATCH] Initial support for building a debian package (.deb)
From: Eric W. Biederman @ 2005-07-15 1:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
It's not any harder to include debian package support
than to include a spec file so here is the setup
to build the equivalent debian package.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
debian/changelog | 5 +++
debian/control | 17 ++++++++++
debian/copyright | 3 ++
debian/docs | 3 ++
debian/git-core.doc-base | 12 +++++++
debian/rules | 81 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 debian/changelog
create mode 100644 debian/control
create mode 100644 debian/copyright
create mode 100644 debian/docs
create mode 100644 debian/git-core.doc-base
create mode 100644 debian/rules
a1f78e1ec9e95720b8d349d5095ed66b0137f862
diff --git a/debian/changelog b/debian/changelog
new file mode 100644
--- /dev/null
+++ b/debian/changelog
@@ -0,0 +1,5 @@
+git-core (0.99-0) unstable; urgency=low
+
+ * Initial deb package support
+
+ -- Eric Biederman <ebiederm@xmission.com> Tue, 12 Jul 2005 10:57:51 -0600
diff --git a/debian/control b/debian/control
new file mode 100644
--- /dev/null
+++ b/debian/control
@@ -0,0 +1,17 @@
+Source: git-core
+Section: devel
+Priority: optional
+Maintainer: Linus Torvalds <torvalds@osdl.org>
+Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc > 6.0.3, xmlto, debhelper (>= 4.0.0)
+Standards-Version: 3.6.1
+
+Package: git-core
+Architecture: any
+Depends: ${shlibs:Depends}, shellutils, diff, rysnc, rcs
+Description: The git content addressable filesystem
+ 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).
+
diff --git a/debian/copyright b/debian/copyright
new file mode 100644
--- /dev/null
+++ b/debian/copyright
@@ -0,0 +1,3 @@
+License:
+
+GPL v2 (see COPYING for details)
diff --git a/debian/docs b/debian/docs
new file mode 100644
--- /dev/null
+++ b/debian/docs
@@ -0,0 +1,3 @@
+README
+COPYING
+
diff --git a/debian/git-core.doc-base b/debian/git-core.doc-base
new file mode 100644
--- /dev/null
+++ b/debian/git-core.doc-base
@@ -0,0 +1,12 @@
+Document: git-core
+Title: git-core
+Author:
+Abstract: This manual describes git
+Section: Devel
+
+Format: HTML
+Index: /usr/share/doc/git-core/html/git.html
+Files: /usr/share/doc/git-core/html/*.html
+
+Format: text
+Files: /usr/share/doc/git-core/git-core.txt
diff --git a/debian/rules b/debian/rules
new file mode 100644
--- /dev/null
+++ b/debian/rules
@@ -0,0 +1,81 @@
+#!/usr/bin/make -f
+# -*- makefile -*-
+
+# Uncomment this to turn on verbose mode.
+#export DH_VERBOSE=1
+
+CFLAGS = -g -Wall
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -O0
+else
+ CFLAGS += -O2
+endif
+export CFLAGS
+
+PREFIX := /usr
+MANDIR := /usr/share/man/
+
+SRC := ./
+DOC := Documentation/
+DESTDIR := $(CURDIR)/debian/tmp
+DOC_DESTDIR := $(DESTDIR)/usr/share/doc/git-core/
+MAN_DESTDIR := $(DESTDIR)/$(MANDIR)
+
+build: build-stamp
+build-stamp:
+ dh_testdir
+ $(MAKE) all doc
+ touch debian/build-stamp
+
+debian-clean:
+ dh_testdir
+ dh_testroot
+ rm -f debian/build-stamp
+ dh_clean
+
+clean: debian-clean
+ $(MAKE) clean
+
+install: debian/build-stamp
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+ dh_installdirs
+
+ make dest=$(DESTDIR) prefix=$(PREFIX) mandir=$(MANDIR) install install-doc
+
+ mkdir -p $(DOC_DESTDIR)
+ find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
+
+ dh_install --sourcedir=$(DESTDIR)
+
+binary:
+ dh_testdir
+ dh_testroot
+ dh_installchangelogs
+ dh_installdocs
+ dh_installexamples
+# dh_installmenu
+# dh_installdebconf
+# dh_installlogrotate
+# dh_installemacsen
+# dh_installpam
+# dh_installmime
+# dh_installinit
+# dh_installcron
+# dh_installinfo
+ dh_installman
+ dh_link
+ dh_strip
+ dh_compress
+ dh_fixperms
+# dh_perl
+# dh_python
+ dh_makeshlibs
+ dh_installdeb
+ dh_shlibdeps
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+
+.PHONY: build clean binary install clean debian-clean
^ permalink raw reply
* [PATCH] Complain about sysadmins in the present tense.
From: Eric W. Biederman @ 2005-07-15 2:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v8y083k5o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Actually I could not see something the system administrator
>> had bone being anything but present tense. If you have to type
>> 500+ characters just to login, I think you would have noticed
>> and complained to your sysadmin earlier...
>
> I think "must have hate you" is simply an incorrect grammar, not
> present tense. You mean "must hate you", perhaps?
Yes. It looks like I failed to delete the have :(
Somethings you just can't see when you know what you meant.
Here is a patch to fix it up.
Eric
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-var.txt | 2 +-
ident.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
554595e307653e90e5945bcef739fde935d7bcef
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -70,7 +70,7 @@ You don't exist. Go away!::
The passwd(5) gecos field couldn't be read
Your parents must have hated you!::
The password(5) gecos field is longer than a giant static buffer.
-Your sysadmin must have hate you!::
+Your sysadmin must hate you!::
The password(5) name field is longer than a giant static buffer.
See Also
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -38,7 +38,7 @@ You don't exist. Go away!::
The passwd(5) gecos field couldn't be read
Your parents must have hated you!::
The password(5) gecos field is longer than a giant static buffer.
-Your sysadmin must have hate you!::
+Your sysadmin must hate you!::
The password(5) name field is longer than a giant static buffer.
See Also
diff --git a/ident.c b/ident.c
--- a/ident.c
+++ b/ident.c
@@ -32,7 +32,7 @@ int setup_ident(void)
/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
len = strlen(pw->pw_name);
if (len > sizeof(real_email)/2)
- die("Your sysadmin must have hate you!");
+ die("Your sysadmin must hate you!");
memcpy(real_email, pw->pw_name, len);
real_email[len++] = '@';
gethostname(real_email + len, sizeof(real_email) - len);
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Junio C Hamano @ 2005-07-15 2:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507141725280.19183@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 14 Jul 2005, Linus Torvalds wrote:
>>
>> I'll look into making diff-cache be more efficient. I normally don't use
>> it myself, so I didn't bother (I use git-diff-files, which is way more
>> efficient, but doesn't show the difference against the _tree_, it shows
>> the difference against the index. Since cogito tries to hide the index
>> from you, cogito can't very well use that).
>
> Ok, done.
Wonderful.
> Junio - I think this makes gitcore-pathspec pretty pointless, but I didn't
> actually remove it. I guess "git-diff-helper" still uses it.
And probably it shouldn't; diff-helper should be raw-to-patch
converter, nothing more.
Usually I'd volunteer to clean up the remaining mess (which was
originally my mess anyway) myself, but since I'd already asked
smurf to help cleaning up the diff option parsing, and recently
I've suddenly got quite busy in the day job, so ...
^ permalink raw reply
* Re: [PATCH 3/6] Add git-var a tool for reading interesting git variables.
From: Junio C Hamano @ 2005-07-15 2:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1k6jsyjki.fsf@ebiederm.dsl.xmission.com>
Wonderful.
^ permalink raw reply
* Re: cg update failing
From: James Cloos @ 2005-07-15 4:12 UTC (permalink / raw)
To: git; +Cc: Darrin Thompson
In-Reply-To: <m3d5plm50o.fsf@lugabout.cloos.reno.nv.us>
Well, it wasn't as Ok as I first thought. There were several .rej and
backup files as left behind by patch(1). cg update HEAD says: Branch
already fully merged but Makefile still says 2.6.12.
I'm cloning now to a remote uml and will try and rsync from there to
the laptop. Perhaps *that* will get me a working repo.
[SIGH]
-JimC
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Linus Torvalds @ 2005-07-15 5:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7vmzop56fo.fsf@assigned-by-dhcp.cox.net>
On Thu, 14 Jul 2005, Junio C Hamano wrote:
>
> That said, I have been hating that diff options parsing for
> quite a while, and I've been thinking about cleaning it up along
> the lines I'll outline here, but have not done anything about
> it. Care to help me out?
I didn't do what you suggested, but I _did_ split the "format" up into
"format + line_termination", which in my opinion cleaned up part of it a
_lot_.
So now "-z" only sets "line_termination" to NUL. "format" starts out as
"DIFF_FORMAT_RAW" (which is the old HUMAN/MACHINE format - the difference
between those two are now the line termination) but can be "PATCH" and
"NAME".
Now, DIFF_FORMAT_PATCH + -z wouldn't seem to make any sense at all, but
you can actually do so, and it actually makes some amount of sense for the
case of
git-diff-tree -v -p -z HEAD
where the "-z" means that the commit _message_ will be terminated by a NUL
character, while the "-v" obviously means that the commit message will be
printed at all, and the "-p" means that the diff gets printed as a patch.
But the diff obviously gets printed with newlines (as does any newlines
_within_ the commit message), not with lines terminated by NUL's.
So "--name-only-z" no longer exists. It's "-z --name-only" (in any order,
quite naturally).
Linus
^ permalink raw reply
* Re: [PATCH] git-diff-*: Allow "--name-only -z" as alias for "--name-only-z"
From: Junio C Hamano @ 2005-07-15 5:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.58.0507142205580.19183@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 14 Jul 2005, Junio C Hamano wrote:
>>
>> That said, I have been hating that diff options parsing for
>> quite a while, and I've been thinking about cleaning it up along
>> the lines I'll outline here, but have not done anything about
>> it. Care to help me out?
>
> I didn't do what you suggested, but I _did_ split the "format" up into
> "format + line_termination", which in my opinion cleaned up part of it a
> _lot_.
Agreed 100%. Regardless of the further cleanup I suggested,
what you did was something I should have done in the first
place. Thanks for the cleanup.
^ permalink raw reply
* [PATCH] Documentation: update tutorial to talk about push.
From: Junio C Hamano @ 2005-07-15 7:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vbr55kgq2.fsf@assigned-by-dhcp.cox.net>
Talk about publishing to a public repository. Also fixes a
couple of typos.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** To be consistent with the rest of the text, I said "I" push
*** to master.kernel.org, but obviously I am lying there ;-). I
*** do not know if your changes enters the public repo starting
*** at master.kernel.org, nor you would particularly want to
*** publicize how it actually works in the documentation. I
*** just tried giving readers realistic enough feel, but I
*** welcome editorial fixes.
Documentation/tutorial.txt | 87 ++++++++++++++++++++++++++++++++++++++++----
1 files changed, 80 insertions(+), 7 deletions(-)
37a26024be1ec6b5ea04ecf109fd149fb6984fe8
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -480,9 +480,10 @@ This has two implications:
history outside of the project you created.
- if you want to move or duplicate a git archive, you can do so. There
- is no "git clone" command: if you want to create a copy of your
- archive (with all the full history that went along with it), you can
- do so with a regular "cp -a git-tutorial new-git-tutorial".
+ is "git clone" command, but if all you want to do is just to
+ create a copy of your archive (with all the full history that
+ went along with it), you can do so with a regular
+ "cp -a git-tutorial new-git-tutorial".
Note that when you've moved or copied a git archive, your git index
file (which caches various information, notably some of the "stat"
@@ -534,7 +535,7 @@ create your own copy of the git reposito
mkdir my-git
cd my-git
- rsync -rL rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git
+ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git .git
followed by
@@ -549,14 +550,14 @@ those, you'd check them out with
where the "-u" flag means that you want the checkout to keep the index
up-to-date (so that you don't have to refresh it afterward), and the
-"-a" file means "check out all files" (if you have a stale copy or an
+"-a" flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the "-f"
-file first, to tell git-checkout-cache to _force_ overwriting of any old
+flag first, to tell git-checkout-cache to _force_ overwriting of any old
files).
Again, this can all be simplified with
- git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ my-git
+ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
cd my-git
git checkout
@@ -770,3 +771,75 @@ point, just create a private tag for it,
name for the state at that point.
[ to be continued.. cvsimports, pushing and pulling ]
+
+
+ Publishing your work
+ --------------------
+
+We already talked about using somebody else's work from a remote
+repository, in the "merging external work" section. It involved
+fetching the work from a remote repository; but how would _you_
+prepare a repository so that other people can fetch from it?
+
+Your real work happens in your working directory with your
+primary repository hanging under it as its ".git" subdirectory.
+You _could_ make it accessible remotely and ask people to pull
+from it, but in practice that is not the way things are usually
+done. A recommended way is to have a public repository, make it
+reachable by other people, and when the changes you made in your
+primary working directory are in good shape, update the public
+repository with it.
+
+[ Side note: this public repository could further be mirrored,
+ and that is how kernel.org git repositories are done. ]
+
+Publishing the changes from your private repository to your
+public repository requires you to have write privilege on the
+machine that hosts your public repository, and it is internally
+done via an SSH connection.
+
+First, you need to create an empty repository to push to on the
+machine that houses your public repository. This needs to be
+done only once.
+
+Your private repository's GIT directory is usually .git, but
+often your public repository is named "<projectname>.git".
+Let's create such a public repository for project "my-git".
+After logging into the remote machine, create an empty
+directory:
+
+ mkdir my-git.git
+
+Then, initialize that directory with git-init-db, but this time,
+since it's name is not usual ".git", we do things a bit
+differently:
+
+ GIT_DIR=my-git.git git-init-db
+
+Make sure this directory is available for others you want your
+changes to be pulled by. Also make sure that you have the
+'git-receive-pack' program on the $PATH.
+
+[ Side note: many installations of sshd does not invoke your
+ shell as the login shell when you directly run programs; what
+ this means is that if your login shell is bash, only .bashrc
+ is read bypassing .bash_profile. As a workaround, make sure
+ .bashrc sets up $PATH so that 'git-receive-pack' program can
+ be run. ]
+
+Your 'public repository' is ready to accept your changes. Now,
+come back to the machine you have your private repository. From
+there, run this command:
+
+ git push <public-host>:/path/to/my-git.git master
+
+This synchronizes your public repository to match the named
+branch head (i.e. refs/heads/master in this case) and objects
+reachable from them in your current repository.
+
+As a real example, this is how I update my public git
+repository. Kernel.org mirror network takes care of the
+propagation to other publically visible machines:
+
+ git push master.kernel.org:/pub/scm/git/git.git/
+
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Russell King @ 2005-07-15 9:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.58.0507141725280.19183@g5.osdl.org>
On Thu, Jul 14, 2005 at 05:29:09PM -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Linus Torvalds wrote:
> > I'll look into making diff-cache be more efficient. I normally don't use
> > it myself, so I didn't bother (I use git-diff-files, which is way more
> > efficient, but doesn't show the difference against the _tree_, it shows
> > the difference against the index. Since cogito tries to hide the index
> > from you, cogito can't very well use that).
>
> Ok, done.
Thanks Linus. I'll look forward to trying this out.
--
Russell King
^ permalink raw reply
* Kernel Hacker's guide to git (updated)
From: Jeff Garzik @ 2005-07-15 17:36 UTC (permalink / raw)
To: Linux Kernel; +Cc: Git Mailing List, Dave Jones
I've updated my git quickstart guide at
http://linux.yyz.us/git-howto.html
It now points to DaveJ's daily snapshots for the initial bootstrap
tarball, is reorganized for better navigation, and other things.
Also, a bonus recipe: how to import Linus's pack files (it's easy).
This recipe presumes that you have a vanilla-Linus repo
(/repo/linux-2.6) and your own repo (/repo/myrepo-2.6).
$ cd /repo/myrepo-2.6
$ git-fsck-cache # fsck, make sure we're OK
$ git pull /repo/linux-2.6/.git # make sure we're up-to-date
$ cp -al ../linux-2.6/.git/objects/pack .git/objects
$ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags
$ git-prune-packed
$ git-fsck-cache # fsck #2, make sure we're OK
This recipe reduced my kernel.org sync from ~50,000 files to ~5,000 files.
Jeff
^ permalink raw reply
* [PATCH] Documentation: pull, push, packing repository and working with others.
From: Junio C Hamano @ 2005-07-15 18:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vzmsots7t.fsf@assigned-by-dhcp.cox.net>
Describe where you can pull from with a bit more detail.
Clarify description of pushing.
Add a section on packing repositories.
Add a section on recommended workflow for the project lead,
subsystem maintainers and individual developers.
Move "Tag" section around to make the flow of example simpler to
follow.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/tutorial.txt | 371 ++++++++++++++++++++++++++++++++++----------
1 files changed, 290 insertions(+), 81 deletions(-)
9ad5d377ecf29ab6d7044db128bee98bf9690bbe
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -453,6 +453,55 @@ With that, you should now be having some
can explore on your own.
+[ Side note: most likely, you are not directly using the core
+ git Plumbing commands, but using Porcelain like Cogito on top
+ of it. Cogito works a bit differently and you usually do not
+ have to run "git-update-cache" yourself for changed files (you
+ do tell underlying git about additions and removals via
+ "cg-add" and "cg-rm" commands). Just before you make a commit
+ with "cg-commit", Cogito figures out which files you modified,
+ and runs "git-update-cache" on them for you. ]
+
+
+ Tagging a version
+ -----------------
+
+In git, there's two kinds of tags, a "light" one, and a "signed tag".
+
+A "light" tag is technically nothing more than a branch, except we put
+it in the ".git/refs/tags/" subdirectory instead of calling it a "head".
+So the simplest form of tag involves nothing more than
+
+ cat .git/HEAD > .git/refs/tags/my-first-tag
+
+after which point you can use this symbolic name for that particular
+state. You can, for example, do
+
+ git diff my-first-tag
+
+to diff your current state against that tag (which at this point will
+obviously be an empty diff, but if you continue to develop and commit
+stuff, you can use your tag as a "anchor-point" to see what has changed
+since you tagged it.
+
+A "signed tag" is actually a real git object, and contains not only a
+pointer to the state you want to tag, but also a small tag name and
+message, along with a PGP signature that says that yes, you really did
+that tag. You create these signed tags with
+
+ git tag <tagname>
+
+which will sign the current HEAD (but you can also give it another
+argument that specifies the thing to tag, ie you could have tagged the
+current "mybranch" point by using "git tag <tagname> mybranch").
+
+You normally only do signed tags for major releases or things
+like that, while the light-weight tags are useful for any marking you
+want to do - any time you decide that you want to remember a certain
+point, just create a private tag for it, and you have a nice symbolic
+name for the state at that point.
+
+
Copying archives
-----------------
@@ -729,117 +778,277 @@ simply do
and optionally give a branch-name for the remote end as a second
argument.
-[ Todo: fill in real examples ]
-
-
- Tagging a version
- -----------------
-
-In git, there's two kinds of tags, a "light" one, and a "signed tag".
-
-A "light" tag is technically nothing more than a branch, except we put
-it in the ".git/refs/tags/" subdirectory instead of calling it a "head".
-So the simplest form of tag involves nothing more than
-
- cat .git/HEAD > .git/refs/tags/my-first-tag
-
-after which point you can use this symbolic name for that particular
-state. You can, for example, do
-
- git diff my-first-tag
-
-to diff your current state against that tag (which at this point will
-obviously be an empty diff, but if you continue to develop and commit
-stuff, you can use your tag as a "anchor-point" to see what has changed
-since you tagged it.
-
-A "signed tag" is actually a real git object, and contains not only a
-pointer to the state you want to tag, but also a small tag name and
-message, along with a PGP signature that says that yes, you really did
-that tag. You create these signed tags with
-
- git tag <tagname>
-
-which will sign the current HEAD (but you can also give it another
-argument that specifies the thing to tag, ie you could have tagged the
-current "mybranch" point by using "git tag <tagname> mybranch").
-
-You normally only do signed tags for major releases or things
-like that, while the light-weight tags are useful for any marking you
-want to do - any time you decide that you want to remember a certain
-point, just create a private tag for it, and you have a nice symbolic
-name for the state at that point.
-
-[ to be continued.. cvsimports, pushing and pulling ]
+The "remote" repository can even be on the same machine. One of
+the following notations can be used to name the repository to
+pull from:
+
+ Rsync URL
+ rsync://remote.machine/path/to/repo.git/
+
+ HTTP(s) URL
+ http://remote.machine/path/to/repo.git/
+
+ GIT URL
+ git://remote.machine/path/to/repo.git/
+ remote.machine:/path/to/repo.git/
+
+ Local directory
+ /path/to/repo.git/
+
+[ Side Note: currently, HTTP transport is slightly broken in
+ that when the remote repository is "packed" they do not always
+ work. But we have not talked about packing repository yet, so
+ let's not worry too much about it for now. ]
+
+[ Digression: you could do without using any branches at all, by
+ keeping as many local repositories as you would like to have
+ branches, and merging between them with "git pull", just like
+ you merge between branches. The advantage of this approach is
+ that it lets you keep set of files for each "branch" checked
+ out and you may find it easier to switch back and forth if you
+ juggle multiple lines of development simultaneously. Of
+ course, you will pay the price of more disk usage to hold
+ multiple working trees, but disk space is cheap these days. ]
Publishing your work
--------------------
-We already talked about using somebody else's work from a remote
-repository, in the "merging external work" section. It involved
-fetching the work from a remote repository; but how would _you_
-prepare a repository so that other people can fetch from it?
+So we can use somebody else's work from a remote repository; but
+how can _you_ prepare a repository to let other people pull from
+it?
-Your real work happens in your working directory with your
+Your do your real work in your working directory that has your
primary repository hanging under it as its ".git" subdirectory.
-You _could_ make it accessible remotely and ask people to pull
-from it, but in practice that is not the way things are usually
-done. A recommended way is to have a public repository, make it
-reachable by other people, and when the changes you made in your
-primary working directory are in good shape, update the public
-repository with it.
+You _could_ make that repository accessible remotely and ask
+people to pull from it, but in practice that is not the way
+things are usually done. A recommended way is to have a public
+repository, make it reachable by other people, and when the
+changes you made in your primary working directory are in good
+shape, update the public repository from it. This is often
+called "pushing".
[ Side note: this public repository could further be mirrored,
and that is how kernel.org git repositories are done. ]
-Publishing the changes from your private repository to your
-public repository requires you to have write privilege on the
-machine that hosts your public repository, and it is internally
-done via an SSH connection.
-
-First, you need to create an empty repository to push to on the
-machine that houses your public repository. This needs to be
+Publishing the changes from your local (private) repository to
+your remote (public) repository requires a write privilege on
+the remote machine. You need to have an SSH account there to
+run a single command, "git-receive-pack".
+
+First, you need to create an empty repository on the remote
+machine that will house your public repository. This empty
+repository will be populated and be kept up-to-date by pushing
+into it later. Obviously, this repository creation needs to be
done only once.
+[ Digression: "git push" uses a pair of programs,
+ "git-send-pack" on your local machine, and "git-receive-pack"
+ on the remote machine. The communication between the two over
+ the network internally uses an SSH connection. ]
+
Your private repository's GIT directory is usually .git, but
-often your public repository is named "<projectname>.git".
-Let's create such a public repository for project "my-git".
-After logging into the remote machine, create an empty
-directory:
+your public repository is often named after the project name,
+i.e. "<project>.git". Let's create such a public repository for
+project "my-git". After logging into the remote machine, create
+an empty directory:
mkdir my-git.git
-Then, initialize that directory with git-init-db, but this time,
-since it's name is not usual ".git", we do things a bit
-differently:
+Then, make that directory into a GIT repository by running
+git-init-db, but this time, since it's name is not the usual
+".git", we do things slightly differently:
GIT_DIR=my-git.git git-init-db
Make sure this directory is available for others you want your
-changes to be pulled by. Also make sure that you have the
-'git-receive-pack' program on the $PATH.
-
-[ Side note: many installations of sshd does not invoke your
- shell as the login shell when you directly run programs; what
- this means is that if your login shell is bash, only .bashrc
- is read bypassing .bash_profile. As a workaround, make sure
- .bashrc sets up $PATH so that 'git-receive-pack' program can
- be run. ]
+changes to be pulled by via the transport of your choice. Also
+you need to make sure that you have the "git-receive-pack"
+program on the $PATH.
+
+[ Side note: many installations of sshd do not invoke your shell
+ as the login shell when you directly run programs; what this
+ means is that if your login shell is bash, only .bashrc is
+ read and not .bash_profile. As a workaround, make sure
+ .bashrc sets up $PATH so that you can run 'git-receive-pack'
+ program. ]
-Your 'public repository' is ready to accept your changes. Now,
-come back to the machine you have your private repository. From
+Your "public repository" is now ready to accept your changes.
+Come back to the machine you have your private repository. From
there, run this command:
git push <public-host>:/path/to/my-git.git master
This synchronizes your public repository to match the named
-branch head (i.e. refs/heads/master in this case) and objects
-reachable from them in your current repository.
+branch head (i.e. "master" in this case) and objects reachable
+from them in your current repository.
As a real example, this is how I update my public git
repository. Kernel.org mirror network takes care of the
-propagation to other publically visible machines:
+propagation to other publicly visible machines:
git push master.kernel.org:pub/scm/git/git.git/
+
+[ Digression: your GIT "public" repository people can pull from
+ is different from a public CVS repository that lets read-write
+ access to multiple developers. It is a copy of _your_ primary
+ repository published for others to use, and you should not
+ push into it from more than one repository (this means, not
+ just disallowing other developers to push into it, but also
+ you should push into it from a single repository of yours).
+ Sharing the result of work done by multiple people are always
+ done by pulling (i.e. fetching and merging) from public
+ repositories of those people. Typically this is done by the
+ "project lead" person, and the resulting repository is
+ published as the public repository of the "project lead" for
+ everybody to base further changes on. ]
+
+
+ Packing your repository
+ -----------------------
+
+Earlier, we saw that one file under .git/objects/??/ directory
+is stored for each git object you create. This representation
+is convenient and efficient to create atomically and safely, but
+not so to transport over the network. Since git objects are
+immutable once they are created, there is a way to optimize the
+storage by "packing them together". The command
+
+ git repack
+
+will do it for you. If you followed the tutorial examples, you
+would have accumulated about 17 objects in .git/objects/??/
+directories by now. "git repack" tells you how many objects it
+packed, and stores the packed file in .git/objects/pack
+directory.
+
+[ Side Note: you will see two files, pack-*.pack and pack-*.idx,
+ in .git/objects/pack directory. They are closely related to
+ each other, and if you ever copy them by hand to a different
+ repository for whatever reason, you should make sure you copy
+ them together. The former holds all the data from the objects
+ in the pack, and the latter holds the index for random
+ access. ]
+
+If you are paranoid, running "git-verify-pack" command would
+detect if you have a corrupt pack, but do not worry too much.
+Our programs are always perfect ;-).
+
+Once you have packed objects, you do not need to leave the
+unpacked objects that are contained in the pack file anymore.
+
+ git prune-packed
+
+would remove them for you.
+
+You can try running "find .git/objects -type f" before and after
+you run "git prune-packed" if you are curious.
+
+[ Side Note: as we already mentioned, "git pull" is broken for
+ some transports dealing with packed repositories right now, so
+ do not run "git prune-packed" if you plan to give "git pull"
+ access via HTTP transport for now. ]
+
+If you run "git repack" again at this point, it will say
+"Nothing to pack". Once you continue your development and
+accumulate the changes, running "git repack" again will create a
+new pack, that contains objects created since you packed your
+archive the last time. We recommend that you pack your project
+soon after the initial import (unless you are starting your
+project from scratch), and then run "git repack" every once in a
+while, depending on how active your project is.
+
+When a repository is synchronized via "git push" and "git pull",
+objects packed in the source repository is usually stored
+unpacked in the destination, unless rsync transport is used.
+
+
+ Working with Others
+ -------------------
+
+A recommended work cycle for a "project lead" is like this:
+
+ (1) Prepare your primary repository on your local machine. Your
+ work is done there.
+
+ (2) Prepare a public repository accessible to others.
+
+ (3) Push into the public repository from your primary
+ repository.
+
+ (4) "git repack" the public repository. This establishes a big
+ pack that contains the initial set of objects.
+
+ (5) Keep working in your primary repository, and push your
+ changes to the public repository. Your changes include
+ your own, patches you receive via e-mail, and merge resulting
+ from pulling the "public" repositories of your "subsystem
+ maintainers".
+
+ You can repack this private repository whenever you feel
+ like.
+
+ (6) Every once in a while, "git repack" the public repository.
+ Go back to step (5) and continue working.
+
+A recommended work cycle for a "subsystem maintainer" that
+works on that project and has own "public repository" is like
+this:
+
+ (1) Prepare your work repository, by "git clone" the public
+ repository of the "project lead".
+
+ (2) Prepare a public repository accessible to others.
+
+ (3) Copy over the packed files from "project lead" public
+ repository to your public repository by hand; this part is
+ currently not automated.
+
+ (4) Push into the public repository from your primary
+ repository.
+
+ (5) Keep working in your primary repository, and push your
+ changes to your public repository, and ask your "project
+ lead" to pull from it. Your changes include your own,
+ patches you receive via e-mail, and merge resulting from
+ pulling the "public" repositories of your "project lead"
+ and possibly your "sub-subsystem maintainers".
+
+ You can repack this private repository whenever you feel
+ like.
+
+ (6) Every once in a while, "git repack" the public repository.
+ Go back to step (5) and continue working.
+
+A recommended work cycle for an "individual developer" who does
+not have a "public" repository is somewhat different. It goes
+like this:
+
+ (1) Prepare your work repositories, by "git clone" the public
+ repository of the "project lead" (or "subsystem
+ maintainer", if you work on a subsystem).
+
+ (2) Copy .git/refs/master to .git/refs/upstream.
+
+ (3) Do your work there. Make commits.
+
+ (4) Run "git fetch" from the public repository of your upstream
+ every once in a while. This does only the first half of
+ "git pull" but does not merge. The head of the public
+ repository is stored in .git/FETCH_HEAD. Copy it in
+ .git/refs/heads/upstream.
+
+ (5) Use "git cherry" to see which ones of your patches were
+ accepted, and/or use "git rebase" to port your unmerged
+ changes forward to the updated upstream.
+
+ (6) Use "git format-patch upstream" to prepare patches for
+ e-mail submission to your upstream and send it out.
+ Go back to step (3) and continue.
+
+[Side Note: I think Cogito calls this upstream "origin".
+ Somebody care to confirm or deny? ]
+
+
+[ to be continued.. cvsimports ]
^ permalink raw reply
* [PATCH] fetch/pull: support Cogito-style remote branch information.
From: Junio C Hamano @ 2005-07-15 21:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vzmsots7t.fsf@assigned-by-dhcp.cox.net>
Since pull and fetch are done often against the same remote
repository, keeping the URL to pull from along with the name of
the head in $GIT_DIR/branches/$name like Cogito does makes a lot
of sense. Adopt that and be compatible with Cogito for usability.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Although I have tested it to see the change does what it
*** advertises to do, I would like to hear comments from the
*** list if things like this would be good to have in the
*** barebone Porcelain. I personally think this is a good
*** usability enhancement without complicating it too much.
Documentation/git-fetch-script.txt | 40 +++++++++++++++++++++++++++
Documentation/git-pull-script.txt | 20 +++++++++++--
Documentation/git.txt | 9 +++++-
Documentation/tutorial.txt | 13 +++++++++
git-fetch-script | 44 +++++++++++++++++++++++------
git-pull-script | 54 +++++++++++++++++++++++++++---------
6 files changed, 152 insertions(+), 28 deletions(-)
create mode 100644 Documentation/git-fetch-script.txt
804f1002c007106fb1aeade4b4549169e92042a2
diff --git a/Documentation/git-fetch-script.txt b/Documentation/git-fetch-script.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-fetch-script.txt
@@ -0,0 +1,40 @@
+git-fetch-script(1)
+===================
+v0.1, July 2005
+
+NAME
+----
+git-fetch-script - Download objects and a head from another repository.
+
+
+SYNOPSIS
+--------
+'git-fetch-script' <repository> [ <head> | tag <tag> ]
+
+'git-fetch-script' -b <name>
+
+
+DESCRIPTION
+-----------
+Fetches a named head or a tag from another repository, along
+with the objects necessary to complete that head or tag. The
+head to pull defaults to HEAD if unspecified.
+
+When '-b' flag is specified to give a name, not an URL to the
+repository, it reads from .git/branches/<name> to get the
+repository URL, possibly immediately followed by '#' and the
+name of the head or the tag. The latter is meant to make this
+command a bit more Cogito-user friendly.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/Documentation/git-pull-script.txt b/Documentation/git-pull-script.txt
--- a/Documentation/git-pull-script.txt
+++ b/Documentation/git-pull-script.txt
@@ -4,17 +4,29 @@ v0.1, May 2005
NAME
----
-git-pull-script - Script used by Linus to pull and merge a remote repository
+git-pull-script - Pull and merge from another repository.
SYNOPSIS
--------
-'git-pull-script'
+'git-pull-script' <repository> [ <head> | tag <tag> ]
+
+'git-pull-script' -b <name>
+
DESCRIPTION
-----------
-This script is used by Linus to pull from a remote repository and perform
-a merge.
+Fetches a named head or a tag from another repository, along
+with the objects necessary to complete that head or tag, and
+merges it into the current repository by running
+'git-resolve-script'. The head to pull defaults to HEAD if
+unspecified.
+
+When '-b' flag is specified to give a name, not an URL to the
+repository, it reads from .git/branches/<name> to get the
+repository URL, possibly immediately followed by '#' and the
+name of the head or the tag. The latter is meant to make this
+command a bit more Cogito-user friendly.
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -121,6 +121,9 @@ The interrogate commands may create file
touch the working file set - but in general they don't
+Synching multiple repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
link:git-clone-script.html[git-clone-script]::
Clones a repository into the current repository (user interface)
@@ -128,10 +131,14 @@ link:git-clone-pack.html[git-clone-pack]
Clones a repository into the current repository (engine
for ssh and local transport)
-link:git-pull-script.html[git-pull-script]::
+link:git-fetch-script.html[git-pull-script]::
Pull from a repote repository via various protocols
(user interface).
+link:git-pull-script.html[git-pull-script]::
+ Fetch from and merge with a repote repository via
+ various protocols (user interface).
+
link:git-http-pull.html[git-http-pull]::
Downloads a remote GIT repository via HTTP
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -810,6 +810,19 @@ pull from:
course, you will pay the price of more disk usage to hold
multiple working trees, but disk space is cheap these days. ]
+It is likely that you will be pulling from the same remote
+repository from time to time. As a short hand, you can store
+the remote repository URL in a file under .git/branches/
+directory, like this:
+
+ mkdir -p .git/branches
+ echo rsync://rsync.kernel.org/pub/scm/git/git.git/ \
+ >.git/branches/linus
+
+and give "-b" option to "git pull" to use that URL:
+
+ git pull -b linus
+
Publishing your work
--------------------
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,23 +1,47 @@
#!/bin/sh
#
-destination=FETCH_HEAD
-
-merge_repo=$1
-merge_name=${2:-HEAD}
-if [ "$2" = "tag" ]; then
- merge_name="refs/tags/$3"
- destination="$merge_name"
-fi
. git-sh-setup-script || die "Not a git archive"
+destination=FETCH_HEAD
+
+case "$1" in
+-b)
+ # Using Cogito style remote branch information.
+ # The user did not call us via git-pull, but just wants to
+ # fetch from the remote head.
+ name=$2 &&
+ destination=refs/heads/"$name" &&
+ remote_branch=$(cat "$GIT_DIR/branches/$name") ||
+ die "cannot read remote branch $name."
+ case "$remote_branch" in
+ *'#'*)
+ merge_repo=$(expr "$remote_branch" : '\(.*\)#') &&
+ merge_name=$(expr "$remote_branch" : '.*#\(.*\)$')
+ ;;
+ *)
+ merge_repo="$remote_branch" &&
+ merge_name=HEAD
+ ;;
+ esac
+ ;;
+*)
+ merge_repo=$1
+ merge_name=${2:-HEAD}
+ if [ "$2" = "tag" ]; then
+ merge_name="refs/tags/$3"
+ destination="$merge_name"
+ fi
+ ;;
+esac
+
TMP_HEAD="$GIT_DIR/TMP_HEAD"
case "$merge_repo" in
http://*)
head=$(wget -q -O - "$merge_repo/$merge_name") || exit 1
- echo Fetching $head using http
- git-http-pull -v -a "$head" "$merge_repo/"
+ echo Fetching $merge_name using http
+ git-http-pull -v -a "$merge_name" "$merge_repo/"
;;
rsync://*)
rsync -L "$merge_repo/$merge_name" "$TMP_HEAD" || exit 1
diff --git a/git-pull-script b/git-pull-script
--- a/git-pull-script
+++ b/git-pull-script
@@ -2,20 +2,48 @@
#
. git-sh-setup-script || die "Not a git archive"
-merge_repo=$1
+usage () {
+ echo >&2 "* git pull <repo> [ <head> | tag <tag> ]"
+ echo >&2 "* git pull -b <name>"
+ exit 1
+}
-merge_name=$(echo "$1" | sed 's:\.git/*$::')
-merge_head=HEAD
-type=head
-if [ "$2" = "tag" ]; then
- type=tag
- shift
-fi
-if [ "$2" ]
-then
- merge_name="$type '$2' of $merge_name"
- merge_head="refs/${type}s/$2"
-fi
+case "$1" in
+-b)
+ # Use Cogito style remote branch information.
+ name=$2 &&
+ remote_branch=$(cat "$GIT_DIR/branches/$name") ||
+ die "cannot read remote branch $name."
+ case "$remote_branch" in
+ *'#'*)
+ merge_repo=$(expr "$remote_branch" : '\(.*\)#') &&
+ merge_head=$(expr "$remote_branch" : '.*#\(.*\)$') &&
+ merge_name=$(echo "$merge_repo" | sed 's:\.git/*$::') &&
+ merge_name="'$merge_head' of $merge_name"
+ ;;
+ *)
+ merge_head=HEAD &&
+ merge_repo="$remote_branch" &&
+ merge_name=$(echo "$merge_repo" | sed 's:\.git/*$::')
+ ;;
+ esac
+ ;;
+*)
+ merge_repo=$1
+ merge_name=$(echo "$merge_repo" | sed 's:\.git/*$::')
+ merge_head=HEAD
+ type=head
+ if [ "$2" = "tag" ]; then
+ type=tag
+ shift
+ fi
+ if [ "$2" ]
+ then
+ merge_name="$type '$2' of $merge_name"
+ merge_head="refs/${type}s/$2"
+ fi
+ ;;
+esac
git-fetch-script "$merge_repo" "$merge_head" || exit 1
^ permalink raw reply
* Re: [PATCH] fetch/pull: support Cogito-style remote branch information.
From: Linus Torvalds @ 2005-07-15 22:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net>
Hmm..
This patch actually brings up two different issues
- I actually prefer code and documentation to be separated. Finding the
actual changes to code in this patch is made much harder by the fact
that most of the changes are documentation updates. In many ways it
would have been nicer to separate the two out - first the actual
change, then the docs updates.
Maybe that's just me.
- I'd much rather have a generic "address rewriting layer" than a "-b"
flag.
I don't mind the shorthand at all, but I don't think it should be that
special. It's not "worthy" of a flag - if you have a shorthand that
says "linus == rsync://kernel.org/pub/scm/git/git.git", then I think it
should just work, and
git pull linus
should end up not needing a "-b" flag. It's not like there is any
real ambiguity.
Now, I'd like the address rewriting to actually be fairly capable, so it
should be a script of its own.
And it's not necessarily just the branch handling, but more of a generic
shorthand: I'd love to be able to mix something like
git pull jgarzik/misc-2.6 upstream
and "jgarzik" would be expanded (through something like .git/branches) to
"master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/"), resulting in the
_full_ path being expanded to
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 upstream
which I have to write out in full (or, more commonly, cut-and-paste) right
now.
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH] fetch/pull: support Cogito-style remote branch information.
From: Junio C Hamano @ 2005-07-15 23:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507151529590.19183@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> - I actually prefer code and documentation to be separated. ...
> first the actual change, then the docs updates.
Understood.
> - I'd much rather have a generic "address rewriting layer" than a "-b"
> flag.
>
> I don't mind the shorthand at all, but I don't think it should be that
> special. It's not "worthy" of a flag - if you have a shorthand that
> says "linus == rsync://kernel.org/pub/scm/git/git.git", then I think it
> should just work, and
>
> git pull linus
>
> should end up not needing a "-b" flag. It's not like there is any
> real ambiguity.
That makes sense. Naturally,
git pull linus experimental
git pull linus tag v2.6.13
should expand to:
git pull rsync://kernel.org/pub/scm/git/git.git/ experimental
git pull rsync://kernel.org/pub/scm/git/git.git/ tag v2.6.13
If a user is usually interested in e100 driver work, we should
allow:
echo rsync://kernel.org/pub/.../git/jgarzik/netdev-2.6.git#e100
>.git/branches/jgarzik-e100
and "git pull jgarzik-e100" should expand to:
git pull rsync://kernel.org/pub/.../netdev-2.6.git/ e100
If the user says:
git fetch jgarzik-e100 ieee80211-wifi
because the user wanted to peek his other branch just once, but
did not want to bother creating another remote reference
("jgarzik-wifi", perhaps) for this one-time use. This should
expand to:
git fetch rsync://kernel.org/pub/.../netdev-2.6.git/ ieee80211-wifi
> And it's not necessarily just the branch handling, but more of a generic
> shorthand: I'd love to be able to mix something like
>
> git pull jgarzik/misc-2.6 upstream
>
> and "jgarzik" would be expanded (through something like .git/branches) to
> "master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/"), resulting in the
> _full_ path being expanded to
>
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6 upstream
Nice, and sounds doable without too much ambiguities. This last
one, however, needs to be coordinated with Pasky, if we want to
use .git/branches/$name convention. I think Cogito would barf
with your partial URL that ends with "...git/jgarzik/".
I'll code something up.
^ permalink raw reply
* Re: "git daemon"
From: H. Peter Anvin @ 2005-07-16 2:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507131946540.17536@g5.osdl.org>
Linus Torvalds wrote:
>
> What I'd ask people to check is how comfortable for example kernel.org
> would be to have one machine that runs this kind of service? I've tried
> very hard to set it up so that it doesn't have any security issues: the
> daemon can be run as "nobody", and it shouldn't ever even write to any
> files, although I guess we should do a full check of that.
>
Since it can be run as a sequestered user, and we now have plenty of CPU
horsepower on the download servers, it seems like it should be an
entirely sane thing to do.
Is this thing meant to be run from inetd, or is it a "listen and fork"
daemon? Especially the latter case, it absolutely *have* to have
protections for:
- "SYN and run" DoS attacks;
- Too many connections from the same IP;
- Too many processes running total.
-hpa
^ permalink raw reply
* Re: "git daemon"
From: Linus Torvalds @ 2005-07-16 3:04 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <42D86B92.7010303@zytor.com>
On Fri, 15 Jul 2005, H. Peter Anvin wrote:
>
> Since it can be run as a sequestered user, and we now have plenty of CPU
> horsepower on the download servers, it seems like it should be an
> entirely sane thing to do.
Goodie.
> Is this thing meant to be run from inetd, or is it a "listen and fork"
> daemon?
It can do both, now (since earlier today). Use the "--inetd" flag if you
run it from something like inetd that will have done the accept/fork for
it. In that case the "--port=xxx" argument obviously doesn't make any
sense.
There are "git-core-0.99.1" rpm (src, x86, ppc64 as usual) at
http://www.kernel.org/pub/software/scm/git/
which are new enough that they already have the --inetd flag support.
> Especially the latter case, it absolutely *have* to have
> protections for:
>
> - "SYN and run" DoS attacks;
> - Too many connections from the same IP;
> - Too many processes running total.
Do you prefer just relying on inetd, or should I extend the server? inetd
obviously involves an extra execve(), but on the other hand, it's a very
very small program, so it's not like it's a huge expense (it does some
very trivial parsing, and then it ends up executing "git-upload-pack").
Right now you're right - you definitely want to use inetd. I just realized
that my built-in server leaves zombies around, for example.
On the security front:
I've still not audited the full source and quite frankly I'd like somebody
else to do that since it's not only boring, but it's all my code, so I'm
blind to any bugs anyway.
But I _have_ straced a full sequence of the daemon side of a "git pull"
and grepped every "open()", and they were all O_RDONLY, and every read()
from the incoming file descriptor was using the "packet-line" interface
which is designed to be safe too (ie there are no possibilities of
overflows there that I can see).
Linus
^ permalink raw reply
* [PATCH] Documentation: adjust cvsimport command line.
From: Junio C Hamano @ 2005-07-16 3:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net>
The cvsimport example in the cvs migration document was still
using the old syntax for target repository after new and
improved cvsimport-script was merged.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/cvs-migration.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
b29d86237da6af317cd0053aa9c8ebd72455c113
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -63,7 +63,7 @@ Once you've gotten (and installed) cvsps
any more familiar with it, but make sure it is in your path. After that,
the magic command line is
- git cvsimport -v -d <cvsroot> <module> <destination>
+ git cvsimport -v -d <cvsroot> -C <destination> <module>
which will do exactly what you'd think it does: it will create a git
archive of the named CVS module. The new archive will be created in the
^ 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