* [PATCH] apply: match documentation, usage string and code.
From: Junio C Hamano @ 2005-07-14 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The more recent --apply option was not described.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-apply.txt | 28 ++++++++++++++++------------
apply.c | 4 +++-
2 files changed, 19 insertions(+), 13 deletions(-)
ace792c165ec274a18cedbdc78affea4d87d6c76
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -9,8 +9,7 @@ git-apply - Apply patch on a GIT index f
SYNOPSIS
--------
-'git-apply' [--no-merge] [--stat] [--summary] [--check]
-[--index] [--show-files] [-] [<file>...]
+'git-apply' [--no-merge] [--stat] [--summary] [--check] [--index] [--show-files] [--apply] [<patch>...]
DESCRIPTION
-----------
@@ -19,31 +18,29 @@ and a work tree.
OPTIONS
-------
-<file>...::
- The files to read patch from.
-
--::
- Instead of reading from a file, read from standard input.
+<patch>...::
+ The files to read patch from. '-' can be used to read
+ from the standard input.
--no-merge::
The default mode of operation is the merge behaviour
- which is not quite implemented yet. This flag
- explicitly tells the program not to use the merge
- behaviour.
+ which is not implemented yet. This flag explicitly
+ tells the program not to use the merge behaviour.
--stat::
Instead of applying the patch, output diffstat for the
- input.
+ input. Turns off "apply".
--summary::
Instead of applying the patch, output a condensed
summary of information obtained from git diff extended
headers, such as creations, renames and mode changes.
+ Turns off "apply".
--check::
Instead of applying the patch, see if the patch is
applicable to the current work tree and/or the index
- file and detects errors.
+ file and detects errors. Turns off "apply".
--index::
When --check is in effect, or when applying the patch
@@ -57,6 +54,13 @@ OPTIONS
--show-files::
Show summary of files that are affected by the patch.
+--apply::
+ If you use any of the options marked ``Turns off
+ "apply"'' above, git-apply reads and outputs the
+ information you asked without actually applying the
+ patch. Give this flag after those flags to also apply
+ the patch.
+
Author
------
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -32,7 +32,8 @@ static int summary = 0;
static int check = 0;
static int apply = 1;
static int show_files = 0;
-static const char apply_usage[] = "git-apply [--stat] [--summary] [--check] [--show-files] <patch>";
+static const char apply_usage[] =
+"git-apply [--no-merge] [--stat] [--summary] [--check] [--index] [--apply] [--show-files] <patch>...";
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
@@ -1424,6 +1425,7 @@ int main(int argc, char **argv)
read_stdin = 0;
continue;
}
+ /* NEEDSWORK: this does not do anything at this moment. */
if (!strcmp(arg, "--no-merge")) {
merge_patch = 0;
continue;
^ permalink raw reply
* Re: [PATCH] Document two pack push-pull protocols.
From: Linus Torvalds @ 2005-07-14 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64vem5rh.fsf@assigned-by-dhcp.cox.net>
On Wed, 13 Jul 2005, Junio C Hamano wrote:
>
> There currently are these two pack push-pull protocols used for
> different purposes. Maybe you invented another today? I have
> not looked beyond your log message.
No, it's the upload-pack one.
The send-pack protocol is just for writing new stuff, not appropriate for
an anonymous connection with no authentication.
Linus
^ permalink raw reply
* Patch to make README more newbie-friendly
From: Jerry Seutter @ 2005-07-14 4:58 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
Hi,
Attached to this email is a patch that expands the README file a bit,
including info about basic Cogito commands at the beginning of the file.
I also added an distributed VCS paragraph at the beginning for people
like me who are typically stuck in CVS-land.
Comments/critiques/flames welcome.
I'd also like to include stuff about branches, but I haven't gotten my
head wrapped around how they work yet. cg-branch-add expects a location
after the branch name and I'm not sure what to give it. I have a test
project containing hello_world.py and was trying to get 2 branches going
and be able to switch between them. What do you use for a location in
this case? I tried using ".", but switching between branches didn't
seem to have any affect.
On another note, I thought I heard that man pages are desired. Is the a
certain group of commands I should start with? Do you want dirt simple
man pages, or are you looking for some <insert-buzzword-here> formatted
source docs?
Jerry
[-- Attachment #2: expand_README.patch --]
[-- Type: text/plain, Size: 4781 bytes --]
diff --git a/README b/README
--- a/README
+++ b/README
@@ -1,12 +1,24 @@
Cogito and GIT: Quick Introduction
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This document describes the Cogito VCS as well as GIT. The GIT itself 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 Cogito 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).
+This document describes the Cogito VCS as well as GIT. The GIT itself
+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 Cogito 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). Mere Human Beings will seldom use
+the GIT tools directly, but use the Cogito tools instead.
+
+If you've only used a centralized version control system like CVS
+before, this package may require a change in how you visualize source
+code management. With Cogito/GIT, every directory with a checked out
+project is also a repository for that project. When you commit your
+changes, you are committing them into the repository in the current
+directory, not to the main repository. In order to have your changes
+show up in the main repository they need to be merged in by a person
+that manages that repository. This can either be done by mailing them
+a patch containing your changes or by giving them access to your
+repository and having them pull in your changes.
The Cogito Version Control System
@@ -30,8 +42,11 @@ Cogito can be obtained as a tarball from
http://www.kernel.org/pub/software/scm/cogito/
-Download and unpack the latest version, build with make, put the executables
-somewhere in your $PATH (or add your Cogito directory itself to your $PATH),
+Download and unpack the latest version, build with
+
+ $ make
+ $ sudo make install
+
and you're ready to go!
The following tools are required by Cogito:
@@ -43,7 +58,9 @@ The following tools are required by Cogi
The following tools are optional but strongly recommended:
- libcrypto (OpenSSL)
+ libcrypto (OpenSSL) (Cogito also contains an OpenSSL implementation
+ from the Mozilla project. To use it instead of OpenSSL, build
+ with "make MOZILLA_SHA1=1"
rsync
@@ -67,6 +84,46 @@ That's it! You're now in your own GIT re
directory. Go into it and look around, but don't change anything in there.
That's what Cogito commands are for.
+Files that you want to add to the repository can be added with
+
+ $ cg-add newfile1 newfile2 ...
+
+When you do some local changes, you can do
+
+ $ cg-diff
+
+to display them. You can also just show which files have changed by
+
+ $ cg-status
+
+Once you have decided that you want to commit your changes, use the
+
+ $ cg-commit
+
+command, which will present you with the editor of your choice for composing
+the commit message.
+
+If you want to see the changes made to the repository by a certain commit,
+the first thing you need to know is the commit names. A commit name in
+Cogito/Git is the hash of the commit. The commit history of the repository
+is displayed with
+
+ $ cg-log
+
+Once you know the name of the commit you want to see, use
+
+ $ cg-diff -r FROM_COMMIT_ID[:TO_COMMIT_ID]
+
+To tag the repository, use cg-tag. cg-tag defaults to tagging HEAD, but
+you can also give it the name of a commit to tag
+
+ $ cg-tag TAG_NAME [COMMIT_ID]
+
+To display the tags you have in your repository, use
+
+ $ cg-tag-ls
+
+
Turning an Existing Directory Into a Repository
If you have a directory full of files, you can easily turn this into a
@@ -198,24 +255,6 @@ the command
repository). Then you can specify the name to cg-update and cg-pull, or use
it anywhere where you could use the "origin" name.
-When you do some local changes, you can do
-
- $ cg-diff
-
-to display them. Of course you will want to commit. If you added any new
-files, do
-
- $ cg-add newfile1 newfile2 ...
-
-first. Then examine your changes by cg-diff or just show what files did you
-change by
-
- $ cg-status
-
-and feel free to commit by the
-
- $ cg-commit
-
command, which will present you with the editor of your choice for composing
the commit message.
@@ -247,6 +286,9 @@ or, for the same information, try this:
The "core GIT"
~~~~~~~~~~~~~~
+Note that if all you care about is committing some small bits of code
+to a repository, you can stop reading now.
+
GIT - the stupid content tracker
"git" can mean anything, depending on your mood.
^ permalink raw reply
* [PATCH] stgit: allow spaces in filenames (second try)
From: Bryan Larsen @ 2005-07-14 6:27 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git, catalin.marinas
The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
stgit/commands/export.py | 4 -
stgit/git.py | 203 ++++++++++++++++++++++++----------------------
2 files changed, 110 insertions(+), 97 deletions(-)
diff --git a/stgit/commands/export.py b/stgit/commands/export.py
--- a/stgit/commands/export.py
+++ b/stgit/commands/export.py
@@ -144,12 +144,12 @@ def func(parser, options, args):
'supported in the patch template'
f = open(pfile, 'w+')
f.write(descr)
- f.close()
# write the diff
git.diff(rev1 = git_id('%s/bottom' % p),
rev2 = git_id('%s/top' % p),
- output = pfile, append = True)
+ out_fd = f)
+ f.close()
patch_no += 1
series.close()
diff --git a/stgit/git.py b/stgit/git.py
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -18,7 +18,7 @@ along with this program; if not, write t
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
-import sys, os, glob
+import sys, os, glob, popen2
from stgit.utils import *
@@ -35,7 +35,6 @@ else:
head_link = os.path.join(base_dir, 'HEAD')
-
#
# Classes
#
@@ -44,9 +43,10 @@ class Commit:
"""
def __init__(self, id_hash):
self.__id_hash = id_hash
- f = os.popen('git-cat-file commit %s' % id_hash, 'r')
- for line in f:
+ lines = _output_lines('git-cat-file commit %s' % id_hash)
+ for i in range(len(lines)):
+ line = lines[i]
if line == '\n':
break
field = line.strip().split(' ', 1)
@@ -58,10 +58,7 @@ class Commit:
self.__author = field[1]
if field[0] == 'comitter':
self.__committer = field[1]
- self.__log = f.read()
-
- if f.close():
- raise GitException, 'Unknown commit id'
+ self.__log = ''.join(lines[i:])
def get_id_hash(self):
return self.__id_hash
@@ -94,13 +91,46 @@ def get_conflicts():
else:
return None
-def __output(cmd):
- f = os.popen(cmd, 'r')
- string = f.readline().strip()
- if f.close():
- raise GitException, '%s failed' % cmd
+def _output(cmd):
+ p=popen2.Popen3(cmd)
+ string = p.fromchild.read()
+ if p.wait():
+ raise GitException, '%s failed' % str(cmd)
return string
+def _output_one_line(cmd):
+ p=popen2.Popen3(cmd)
+ string = p.fromchild.readline().strip()
+ if p.wait():
+ raise GitException, '%s failed' % str(cmd)
+ return string
+
+def _output_lines(cmd):
+ p=popen2.Popen3(cmd)
+ lines = p.fromchild.readlines()
+ if p.wait():
+ raise GitException, '%s failed' % str(cmd)
+ return lines
+
+def __run(cmd, args=None):
+ """__run: runs cmd using spawnvp.
+
+ Runs cmd using spawnvp. The shell is avoided so it won't mess up
+ our arguments. If args is very large, the command is run multiple
+ times; args is split xargs style: cmd is passed on each
+ invocation. Unlike xargs, returns immediately if any non-zero
+ return code is received.
+ """
+
+ args_l=cmd.split()
+ if args is None:
+ args = []
+ for i in range(0, len(args)+1, 100):
+ r=os.spawnvp(os.P_WAIT, args_l[0], args_l + args[i:min(i+100, len(args))])
+ if r:
+ return r
+ return 0
+
def __check_base_dir():
return os.path.isdir(base_dir)
@@ -114,14 +144,14 @@ def __tree_status(files = [], tree_id =
# unknown files
if unknown:
exclude_file = os.path.join(base_dir, 'exclude')
- extra_exclude = ''
+ extra_exclude = []
if os.path.exists(exclude_file):
- extra_exclude += ' --exclude-from=%s' % exclude_file
- fout = os.popen('git-ls-files --others'
- ' --exclude="*.[ao]" --exclude=".*"'
- ' --exclude=TAGS --exclude=tags --exclude="*~"'
- ' --exclude="#*"' + extra_exclude, 'r')
- cache_files += [('?', line.strip()) for line in fout]
+ extra_exclude.append('--exclude-from=%s' % exclude_file)
+ lines = _output_lines(['git-ls-files', '--others',
+ '--exclude=*.[ao]', '--exclude=.*'
+ '--exclude=TAGS', '--exclude=tags', '--exclude=*~',
+ '--exclude=#*'] + extra_exclude)
+ cache_files += [('?', line.strip()) for line in lines]
# conflicted files
conflicts = get_conflicts()
@@ -130,14 +160,10 @@ def __tree_status(files = [], tree_id =
cache_files += [('C', filename) for filename in conflicts]
# the rest
- files_str = reduce(lambda x, y: x + ' ' + y, files, '')
- fout = os.popen('git-diff-cache -r %s %s' % (tree_id, files_str), 'r')
- for line in fout:
- fs = tuple(line.split()[4:])
+ for line in _output_lines(['git-diff-cache', '-r', tree_id] + files):
+ fs = tuple(line.rstrip().split(' ',4)[-1].split('\t',1))
if fs[1] not in conflicts:
cache_files.append(fs)
- if fout.close():
- raise GitException, 'git-diff-cache failed'
return cache_files
@@ -185,10 +211,9 @@ def add(names):
else:
raise GitException, '%s is not a file or directory' % i
- for f in files:
- print 'Adding file %s' % f
- if os.system('git-update-cache --add -- %s' % f) != 0:
- raise GitException, 'Unable to add %s' % f
+ if files:
+ if __run('git-update-cache --add --', files):
+ raise GitException, 'Unable to add file'
def rm(files, force = False):
"""Remove a file from the repository
@@ -198,26 +223,32 @@ def rm(files, force = False):
else:
git_opt = '--remove'
- for f in files:
- if force:
- print 'Removing file %s' % f
- if os.system('git-update-cache --force-remove -- %s' % f) != 0:
- raise GitException, 'Unable to remove %s' % f
- elif os.path.exists(f):
- raise GitException, '%s exists. Remove it first' %f
- else:
- print 'Removing file %s' % f
- if os.system('git-update-cache --remove -- %s' % f) != 0:
- raise GitException, 'Unable to remove %s' % f
+ if not force:
+ for f in files:
+ if os.path.exists(f):
+ raise GitException, '%s exists. Remove it first' %f
+ if files:
+ __run('git-update-cache --remove --', files)
+ else:
+ if files:
+ __run('git-update-cache --force-remove --', files)
def update_cache(files):
"""Update the cache information for the given files
"""
+ files_here = []
+ files_gone = []
+
for f in files:
if os.path.exists(f):
- os.system('git-update-cache -- %s' % f)
+ files_here.append(f)
else:
- os.system('git-update-cache --remove -- %s' % f)
+ files_gone.append(f)
+
+ if files_here:
+ __run('git-update-cache --', files_here)
+ if files_gone:
+ __run('git-update-cache --remove --', files_gone)
def commit(message, files = [], parents = [], allowempty = False,
author_name = None, author_email = None, author_date = None,
@@ -248,19 +279,29 @@ def commit(message, files = [], parents
# update the cache
if not first:
+ add_files=[]
+ rm_files=[]
+ m_files=[]
for f in cache_files:
if f[0] == 'N':
- git_flag = '--add'
+ add_files.append(f[1])
elif f[0] == 'D':
- git_flag = '--force-remove'
+ rm_files.append(f[1])
else:
- git_flag = '--'
+ m_files.append(f[1])
- if os.system('git-update-cache %s %s' % (git_flag, f[1])) != 0:
- raise GitException, 'Failed git-update-cache -- %s' % f[1]
+ if add_files:
+ if __run('git-update-cache --add --', add_files):
+ raise GitException, 'Failed git-update-cache --add'
+ if rm_files:
+ if __run('git-update-cache --force-remove --', rm_files):
+ raise GitException, 'Failed git-update-cache --rm'
+ if m_files:
+ if __run('git-update-cache --', m_files):
+ raise GitException, 'Failed git-update-cache'
# write the index to repository
- tree_id = __output('git-write-tree')
+ tree_id = _output_one_line('git-write-tree')
# the commit
cmd = ''
@@ -282,7 +323,7 @@ def commit(message, files = [], parents
cmd += ' < .commitmsg'
- commit_id = __output(cmd)
+ commit_id = _output_one_line(cmd)
__set_head(commit_id)
os.remove('.commitmsg')
@@ -292,7 +333,7 @@ def merge(base, head1, head2):
"""Perform a 3-way merge between base, head1 and head2 into the
local tree
"""
- if os.system('git-read-tree -u -m %s %s %s' % (base, head1, head2)) != 0:
+ if __run('git-read-tree -u -m', [base, head1, head2]) != 0:
raise GitException, 'git-read-tree failed (local changes maybe?)'
# this can fail if there are conflicts
@@ -330,51 +371,27 @@ def status(files = [], modified = False,
else:
print '%s' % fs[1]
-def diff(files = [], rev1 = 'HEAD', rev2 = None, output = None,
- append = False):
+def diff(files = [], rev1 = 'HEAD', rev2 = None, out_fd = sys.stdout):
"""Show the diff between rev1 and rev2
"""
- files_str = reduce(lambda x, y: x + ' ' + y, files, '')
-
- extra_args = ''
- if output:
- if append:
- extra_args += ' >> %s' % output
- else:
- extra_args += ' > %s' % output
-
os.system('git-update-cache --refresh > /dev/null')
if rev2:
- if os.system('git-diff-tree -p %s %s %s %s'
- % (rev1, rev2, files_str, extra_args)) != 0:
- raise GitException, 'git-diff-tree failed'
+ out_fd.write(_output(['git-diff-tree', '-p', rev1, rev2]+files))
else:
- if os.system('git-diff-cache -p %s %s %s'
- % (rev1, files_str, extra_args)) != 0:
- raise GitException, 'git-diff-cache failed'
+ out_fd.write(_output(['git-diff-cache', '-p', rev1]+files))
def diffstat(files = [], rev1 = 'HEAD', rev2 = None):
"""Return the diffstat between rev1 and rev2
"""
- files_str = reduce(lambda x, y: x + ' ' + y, files, '')
os.system('git-update-cache --refresh > /dev/null')
- ds_cmd = '| git-apply --stat'
-
- if rev2:
- f = os.popen('git-diff-tree -p %s %s %s %s'
- % (rev1, rev2, files_str, ds_cmd), 'r')
- str = f.read().rstrip()
- if f.close():
- raise GitException, 'git-diff-tree failed'
- else:
- f = os.popen('git-diff-cache -p %s %s %s'
- % (rev1, files_str, ds_cmd), 'r')
- str = f.read().rstrip()
- if f.close():
- raise GitException, 'git-diff-cache failed'
-
+ p=popen2.Popen3('git-apply --stat')
+ diff(files, rev1, rev2, p.tochild)
+ p.tochild.close()
+ str = p.fromchild.read().rstrip()
+ if p.wait():
+ raise GitException, 'git.diffstat failed'
return str
def files(rev1, rev2):
@@ -383,35 +400,31 @@ def files(rev1, rev2):
os.system('git-update-cache --refresh > /dev/null')
str = ''
- f = os.popen('git-diff-tree -r %s %s' % (rev1, rev2),
- 'r')
- for line in f:
- str += '%s %s\n' % tuple(line.split()[4:])
- if f.close():
- raise GitException, 'git-diff-tree failed'
+ for line in _output_lines('git-diff-tree -r %s %s' % (rev1, rev2)):
+ str += '%s %s\n' % tuple(line.rstrip().split(' ',4)[-1].split('\t',1))
return str.rstrip()
def checkout(files = [], force = False):
"""Check out the given or all files
"""
- git_flags = ''
+ git_flags = 'git-checkout-cache -q -u'
if force:
git_flags += ' -f'
if len(files) == 0:
git_flags += ' -a'
else:
- git_flags += reduce(lambda x, y: x + ' ' + y, files, ' --')
+ git_flags += ' --'
- if os.system('git-checkout-cache -q -u%s' % git_flags) != 0:
- raise GitException, 'Failed git-checkout-cache -q -u%s' % git_flags
+ if __run(git_flags, files) != 0:
+ raise GitException, 'Failed git-checkout-cache'
def switch(tree_id):
"""Switch the tree to the given id
"""
to_delete = filter(lambda x: x[0] == 'N', __tree_status(tree_id = tree_id))
- if os.system('git-read-tree -m %s' % tree_id) != 0:
+ if __run('git-read-tree -m', [tree_id]) != 0:
raise GitException, 'Failed git-read-tree -m %s' % tree_id
checkout(force = True)
^ permalink raw reply
* [PATCH] stgit: export without --range does not export the last patch
From: Bryan Larsen @ 2005-07-14 6:27 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git, catalin.marinas
In-Reply-To: <20050714062733.21779.33599.sendpatchset@bryan-larsens-ibook-g4.local>
The top patch is never exported.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
stgit/commands/export.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/export.py b/stgit/commands/export.py
--- a/stgit/commands/export.py
+++ b/stgit/commands/export.py
@@ -90,7 +90,7 @@ def func(parser, options, args):
raise MainException, 'Incorrect patch range order'
else:
start_idx = 0
- stop_idx = -1
+ stop_idx = len(applied)
patches = applied[start_idx:stop_idx]
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames
From: Catalin Marinas @ 2005-07-14 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpstms5pc.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-07-13 at 15:26 -0700, Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> >> I'd very much like to stay on the same list. By the same logic, cogito
> >> should have it's own list as well...
> >
> > I'd like this too and it's probably OK with a low traffic (we'll see if
> > we receive complaints :-) ).
>
> I'd like to keep Porcelain discussions on this list for two
> reasons:
That's great then. I will keep the StGIT discussions on this list.
--
Catalin
^ permalink raw reply
* [PATCH] Documentation: packed GIT support commands.
From: Junio C Hamano @ 2005-07-14 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This adds documentation for creating packed archives, inspecting,
validating them, and unpacking them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-pack-objects.txt | 80 ++++++++++++++++++++++++++++++++++
Documentation/git-show-index.txt | 36 +++++++++++++++
Documentation/git-unpack-objects.txt | 33 ++++++++++++++
Documentation/git-verify-pack.txt | 13 +++++-
4 files changed, 161 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-pack-objects.txt
create mode 100644 Documentation/git-show-index.txt
create mode 100644 Documentation/git-unpack-objects.txt
32a772fa72da57fbbe9ea27d195e6b755c83cd22
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-pack-objects.txt
@@ -0,0 +1,80 @@
+git-pack-objects(1)
+===================
+v0.1, July 2005
+
+NAME
+----
+git-pack-objects - Create a packed archive of objects.
+
+
+SYNOPSIS
+--------
+'git-pack-objects' [--incremental] [--window=N] [--depth=N] {--stdout | base-name} < object-list
+
+
+DESCRIPTION
+-----------
+Reads list of objects from the standard input, and writes a packed
+archive with specified base-name, or to the standard output.
+
+A packed archive is an efficient way to transfer set of objects
+between two repositories, and also is an archival format which
+is efficient to access. The packed archive format (.pack) is
+designed to be unpackable without having anything else, but for
+random access, accompanied with the pack index file (.idx).
+
+'git-unpack-objects' command can read the packed archive and
+expand the objects contained in the pack into "one-file
+one-object" format; this is typically done by the smart-pull
+commands when a pack is created on-the-fly for efficient network
+transport by their peers.
+
+Placing both in pack subdirectory of $GIT_OBJECT_DIRECTORY (or
+any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
+enables GIT to read from such an archive.
+
+
+OPTIONS
+-------
+base-name::
+ Write into a pair of files (.pack and .idx), using
+ <base-name> to determine the name of the created file.
+ When this option is used, the two files are written in
+ <base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash
+ of object names (currently in random order so it does
+ not have any useful meaning) to make the resulting
+ filename reasonably unique, and written to the standard
+ output of the command.
+
+--stdout::
+ Write the pack contents (what would have been writtin to
+ .pack file) out to the standard output.
+
+--window and --depth::
+ These two options affects how the objects contained in
+ the pack are stored using delta compression. The
+ objects are first internally sorted by type, size and
+ optionally names and compared against the other objects
+ within --window to see if using delta compression saves
+ space. --depth limits the maximum delta depth; making
+ it too deep affects the performance on the unpacker
+ side, because delta data needs to be applied that many
+ times to get to the necessary object.
+
+--incremental::
+ This flag causes an object already in a pack ignored
+ even if it appears in the standard input.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-show-index.txt
@@ -0,0 +1,36 @@
+git-show-index(1)
+=================
+v0.1, July 2005
+
+NAME
+----
+git-show-index - Show packed archive index
+
+
+SYNOPSIS
+--------
+'git-show-index' < idx-file
+
+
+DESCRIPTION
+-----------
+Reads given idx file for packed GIT archive created with
+git-pack-objects command, and dumps its contents.
+
+The information it outputs is subset of what you can get from
+'git-verify-pack -v'; this command only shows the packfile
+offset and SHA1 of each object.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-unpack-objects.txt
@@ -0,0 +1,33 @@
+git-unpack-objects(1)
+=====================
+v0.1, July 2005
+
+NAME
+----
+git-unpack-objects - Create a packed archive of objects.
+
+
+SYNOPSIS
+--------
+'git-unpack-objects' < pack-file
+
+
+DESCRIPTION
+-----------
+Reads a packed archive (.pack) from the standard input, and
+expands the objects contained in the pack into "one-file
+one-object" format in $GIT_OBJECT_DIRECTORY.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+-------------
+Documentation by Junio C Hamano
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
--- a/Documentation/git-verify-pack.txt
+++ b/Documentation/git-verify-pack.txt
@@ -9,7 +9,7 @@ git-verify-pack - Validate packed GIT ar
SYNOPSIS
--------
-'git-verify-pack' <pack>.idx ...
+'git-verify-pack' [-v] <pack>.idx ...
DESCRIPTION
@@ -23,6 +23,17 @@ OPTIONS
<pack>.idx ...::
The idx files to verify.
+-v::
+ After verifying the pack, show list of objects contained
+ in the pack. The format used is:
+
+ SHA1 type size offset-in-packfile
+
+ for objects that are not deltified in the pack, and
+
+ SHA1 type size offset-in-packfile depth base-SHA1
+
+ for objects that are deltified.
Author
------
^ permalink raw reply
* [PATCH] Documentation: clone/fetch/upload.
From: Junio C Hamano @ 2005-07-14 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This adds documentation for 'smarter pull' family of commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-clone-pack.txt | 13 +++++--
Documentation/git-fetch-pack.txt | 73 +++++++++++++++++++++++++++++++++++++
Documentation/git-upload-pack.txt | 40 ++++++++++++++++++++
fetch-pack.c | 11 ++++--
4 files changed, 130 insertions(+), 7 deletions(-)
create mode 100644 Documentation/git-fetch-pack.txt
create mode 100644 Documentation/git-upload-pack.txt
1ac6853af4e4a24eaf7008be9b4e9e033bc624f1
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
--- a/Documentation/git-clone-pack.txt
+++ b/Documentation/git-clone-pack.txt
@@ -9,7 +9,7 @@ git-clone-pack - Clones a repository by
SYNOPSIS
--------
-'git-clone-pack' [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>...]
+'git-clone-pack' [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...]
DESCRIPTION
-----------
@@ -36,10 +36,15 @@ OPTIONS
shells by having a lean .bashrc file (they set most of
the things up in .bash_profile).
-[<host>:]<directory::
- The (possibly remote) repository to clone from.
+<host>::
+ A remote host that houses the repository. When this
+ part is specified, 'git-upload-pack' is invoked via
+ ssh.
-<heads>...::
+<directory>::
+ The repository to sync from.
+
+<head>...::
The heads to update. This is relative to $GIT_DIR
(e.g. "HEAD", "refs/heads/master"). When unspecified,
all heads are updated to match the remote repository.
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-fetch-pack.txt
@@ -0,0 +1,73 @@
+git-fetch-pack(1)
+=================
+v0.1, July 2005
+
+NAME
+----
+git-fetch-pack - Receive missing objects from another repository.
+
+
+SYNOPSIS
+--------
+git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...] < <commit-list>
+
+DESCRIPTION
+-----------
+Invokes 'git-upload-pack' on a potentially remote repository,
+and asks it to send objects missing from this repository, to
+update the named heads. The list of commits available locally
+is fed from the standard input, to be sent to 'git-upload-pack'
+running on the other end.
+
+This command can be used only when the local side has a common
+(ancestor) commit with the remote head that is being pulled
+from. Use 'git-clone-pack' for that.
+
+
+OPTIONS
+-------
+-q::
+ Pass '-q' flag to 'git-unpack-objects'; this makes the
+ cloning process less verbose.
+
+--exec=<git-upload-pack>::
+ Use this to specify the path to 'git-upload-pack' on the
+ remote side, if is not found on your $PATH.
+ Installations of sshd ignores the user's environment
+ setup scripts for login shells (e.g. .bash_profile) and
+ your privately installed GIT may not be found on the system
+ default $PATH. Another workaround suggested is to set
+ up your $PATH in ".bashrc", but this flag is for people
+ who do not want to pay the overhead for non-interactive
+ shells by having a lean .bashrc file (they set most of
+ the things up in .bash_profile).
+
+<host>::
+ A remote host that houses the repository. When this
+ part is specified, 'git-upload-pack' is invoked via
+ ssh.
+
+<directory>::
+ The repository to sync from.
+
+<head>...::
+ The remote heads to update from. This is relative to
+ $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When
+ unspecified, update from all heads the remote side has.
+
+ However the program refuses to work if more than one
+ remote head matches the specified heads. I am not sure
+ what this means... Help!!!!!
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-upload-pack.txt
@@ -0,0 +1,40 @@
+git-upload-pack(1)
+==================
+v0.1, July 2005
+
+NAME
+----
+git-upload-pack - Send missing objects packed.
+
+
+SYNOPSIS
+--------
+'git-upload-pack' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-clone-pack' and/or 'git-fetch-pack', learns what
+objects the other side is missing, and sends them after packing.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git-fetch-pack' side, and the
+program pair is meant to be used to pull updates from a remote
+repository. For push operations, see 'git-send-pack'.
+
+
+OPTIONS
+-------
+<directory>::
+ The repository to sync from.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -3,7 +3,8 @@
#include "pkt-line.h"
#include <sys/wait.h>
-static const char fetch_pack_usage[] = "git-fetch-pack [host:]directory [heads]* < mycommitlist";
+static int quiet;
+static const char fetch_pack_usage[] = "git-fetch-pack [-q] [--exec=upload-pack] [host:]directory [heads]* < mycommitlist";
static const char *exec = "git-upload-pack";
static int find_common(int fd[2], unsigned char *result_sha1, unsigned char *remote)
@@ -98,7 +99,8 @@ static int fetch_pack(int fd[2], int nr_
dup2(fd[0], 0);
close(fd[0]);
close(fd[1]);
- execlp("git-unpack-objects", "git-unpack-objects", NULL);
+ execlp("git-unpack-objects", "git-unpack-objects",
+ quiet ? "-q" : NULL, NULL);
die("git-unpack-objects exec failed");
}
close(fd[0]);
@@ -134,7 +136,10 @@ int main(int argc, char **argv)
char *arg = argv[i];
if (*arg == '-') {
- /* Arguments go here */
+ if (!strncmp("--exec=", arg, 7)) {
+ exec = arg + 7;
+ continue;
+ }
usage(fetch_pack_usage);
}
dest = arg;
^ permalink raw reply
* [PATCH] Documentation: send/receive.
From: Junio C Hamano @ 2005-07-14 7:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This adds documentation for 'smarter push' family of commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-receive-pack.txt | 41 ++++++++++++++++++++++++++++++++
Documentation/git-send-pack.txt | 46 ++++++++++++++++++++++++++++++++++++
send-pack.c | 3 ++
3 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-receive-pack.txt
create mode 100644 Documentation/git-send-pack.txt
1cf367fc165560b68a51b6ce4cc91d809cf09c99
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-receive-pack.txt
@@ -0,0 +1,41 @@
+git-receive-pack(1)
+===================
+v0.1, July 2005
+
+NAME
+----
+git-receive-pack - Receive what is pushed into it
+
+
+SYNOPSIS
+--------
+'git-receive-pack' <directory>
+
+DESCRIPTION
+-----------
+Invoked by 'git-send-pack' and updates the repository with the
+information fed from the remote end.
+
+This command is usually not invoked directly by the end user.
+The UI for the protocol is on the 'git-send-pack' side, and the
+program pair is meant to be used to push updates to remote
+repository. For pull operations, see 'git-fetch-pack' and
+'git-clone-pack'.
+
+
+OPTIONS
+-------
+<directory>::
+ The repository to sync into.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-send-pack.txt
@@ -0,0 +1,46 @@
+git-send-pack(1)
+================
+v0.1, July 2005
+
+NAME
+----
+git-send-pack - Push missing objects packed.
+
+
+SYNOPSIS
+--------
+'git-send-pack' [--exec=<git-receive-pack>] [<host>:]<directory> [<head>...]
+
+DESCRIPTION
+-----------
+Invokes 'git-receive-pack' on a possibly remote repository, and
+updates it from the current repository, sending named heads.
+
+
+OPTIONS
+-------
+--exec=<git-receive-pack>::
+ Path to the 'git-receive-pack' program on the remote
+ end. Sometimes useful when pushing to a remote
+ repository over ssh, and you do not have the program in
+ a directory on the default $PATH.
+
+<host>::
+ A remote host to house the repository. When this
+ part is specified, 'git-receive-pack' is invoked via
+ ssh.
+
+<directory>::
+ The repository to update.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -2,7 +2,8 @@
#include "refs.h"
#include "pkt-line.h"
-static const char send_pack_usage[] = "git-send-pack [--exec=other] destination [heads]*";
+static const char send_pack_usage[] =
+"git-send-pack [--exec=git-receive-pack] [host:]directory [heads]*";
static const char *exec = "git-receive-pack";
struct ref {
^ permalink raw reply
* [PATCH] Documentation: push-pull commands into a separate category.
From: Junio C Hamano @ 2005-07-14 7:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This splits push-pull related commands into a separate
category. I think a bigger overhaul of the main index is
needed, but have not got around to it. Help is welcome.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git.txt | 65 ++++++++++++++++++++++++++++++++-----------------
1 files changed, 42 insertions(+), 23 deletions(-)
9ea24aa8739dc23074872679d493dfd6fb0e5321
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -30,8 +30,9 @@ reflect recent changes.
Commands Overview
-----------------
The git commands can helpfully be split into those that manipulate
-the repository, the cache and the working fileset and those that
-interrogate and compare them.
+the repository, the cache and the working fileset, those that
+interrogate and compare them, and those that moves objects and
+references between repositories.
There are also some ancilliary programs that can be viewed as useful
aids for using the core commands but which are unlikely to be used by
@@ -117,16 +118,6 @@ The interrogate commands may create file
touch the working file set - but in general they don't
-Ancilliary Commands
--------------------
-Manipulators:
-
-link:git-apply-patch-script.html[git-apply-patch-script]::
- Sample script to apply the diffs from git-diff-*
-
-link:git-convert-cache.html[git-convert-cache]::
- Converts old-style GIT repository
-
link:git-clone-script.html[git-clone-script]::
Clones a repository into the current repository (user interface)
@@ -134,18 +125,49 @@ 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]::
+ Pull from a repote repository via various protocols
+ (user interface).
+
link:git-http-pull.html[git-http-pull]::
Downloads a remote GIT repository via HTTP
link:git-local-pull.html[git-local-pull]::
Duplicates another GIT repository on a local system
+link:git-ssh-pull.html[git-ssh-pull]::
+ Pulls from a remote repository over ssh connection
+
+link:git-send-pack.html[git-send-pack]::
+ Pushes to a remote repository, intelligently.
+
+link:git-receive-pack.html[git-receive-pack]::
+ Invoked by 'git-send-pack' to receive what is pushed to it.
+
+link:git-clone-pack.html[git-clone-pack]::
+ Clones from a remote repository.
+
+link:git-fetch-pack.html[git-fetch-pack]::
+ Updates from a remote repository.
+
+link:git-upload-pack.html[git-upload-pack]::
+ Invoked by 'git-clone-pack' and 'git-fetch-pack' to push
+ what are asked for.
+
+
+Ancilliary Commands
+-------------------
+Manipulators:
+
+link:git-apply-patch-script.html[git-apply-patch-script]::
+ Sample script to apply the diffs from git-diff-*
+
+link:git-convert-cache.html[git-convert-cache]::
+ Converts old-style GIT repository
+
link:git-merge-one-file-script.html[git-merge-one-file-script]::
The standard helper program to use with "git-merge-cache"
-link:git-pull-script.html[git-pull-script]::
- Script used by Linus to pull and merge a remote repository
-
link:git-prune-script.html[git-prune-script]::
Prunes all unreachable objects from the object database
@@ -155,8 +177,6 @@ link:git-resolve-script.html[git-resolve
link:git-tag-script.html[git-tag-script]::
An example script to create a tag object signed with GPG
-link:git-ssh-pull.html[git-ssh-pull]::
- Pulls from a remote repository over ssh connection
Interogators:
@@ -221,17 +241,16 @@ The git-core manipulates the following a
.git/ The base (overridden with $GIT_DIR)
objects/ The object base (overridden with $GIT_OBJECT_DIRECTORY)
- ??/ 'First 2 chars of object' directories
-
-It can interrogate (but never updates) the following areas:
+ ??/ 'First 2 chars of object' directories.
+ pack/ Packed archives.
refs/ Directories containing symbolic names for objects
(each file contains the hex SHA1 + newline)
heads/ Commits which are heads of various sorts
tags/ Tags, by the tag name (or some local renaming of it)
- snap/ ????
- ... Everything else isn't shared
- HEAD Symlink to refs/heads/<something>
+ */ Any other subdirectory of refs/ can be used to store
+ files similar to what are under refs/heads/.
+ HEAD Symlink to refs/heads/<current-branch-name>
Higher level SCMs may provide and manage additional information in the
GIT_DIR.
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames
From: Bryan Larsen @ 2005-07-14 7:22 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Bryan Larsen, git
In-Reply-To: <1121290004.6876.11.camel@localhost.localdomain>
> Does it make that big difference if the commands are invoked via the
> shell? I haven't run any tests.
>
It wasn't for the time difference that I bypassed the shell, it was to
support spaces and other strange characters in parameters. It's easy
to use spawnvp than it is to escape the parameters properly.
Bryan
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Russell King @ 2005-07-14 7:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507131325170.17536@g5.osdl.org>
On Wed, Jul 13, 2005 at 01:28:18PM -0700, Linus Torvalds wrote:
> On Wed, 13 Jul 2005, Russell King wrote:
> > This says it all. 1min 22secs to generate a patch from a locally
> > modified but uncommitted file.
>
> No, there's something else going on.
>
> Most likely that something forced a total index file re-validation, and
> the time you see is every single checked out file having its SHA1
> re-computed.
>
> Was this a recently cloned tree, or what was the last operation you did on
> that tree before that command? Something must have invalidated the index.
cg-update origin
and then I edited drivers/serial/8250.c
As discovered using:
sh -x /usr/bin/cg-diff drivers/serial/8250.c
it appears that cg-diff does a
git-update-cache --refresh >/dev/null
each time it's run, which is taking the bulk of the time. Also note
that curiously, it exits with status 1.
--
Russell King
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Russell King @ 2005-07-14 7:38 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.13.16.51.28.520681@smurf.noris.de>
On Wed, Jul 13, 2005 at 06:51:30PM +0200, Matthias Urlichs wrote:
> Hi, Russell King wrote:
>
> > This says it all. 1min 22secs to generate a patch from a locally
> > modified but uncommitted file.
>
> I only get that when the index is out-of-date WRT the file modification
> dates, so cg-diff has to examine every file.
>
> The good news is that the index is being updated as it finds that the
> files are in sync, so expect this to be significantly faster the next time
> around.
It isn't. First time it was 1min11, second time _immediately_ after
it was 1min22. See my reply to Linus.
Oddly, show-diff seemed to be a lot more efficient in previous git
revisions.
--
Russell King
^ permalink raw reply
* [PATCH] add inetd mode to git daemon
From: Alexey Nezhdanov @ 2005-07-14 7:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, snake
Adds --inetd command line argument that makes server run in inetd mode.
Signed-off-by: Alexey Nezhdanov <snake@penza-gsm.ru>
---
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -3,7 +3,7 @@
#include <sys/socket.h>
#include <netinet/in.h>
-static const char daemon_usage[] = "git-daemon [--port=n]";
+static const char daemon_usage[] = "git-daemon [--inetd | --port=n]";
static int upload(char *dir, int dirlen)
{
@@ -37,11 +37,21 @@ static int execute(char *line, int len)
return -1;
}
-static void handle(int incoming, struct sockaddr_in *addr, int addrlen)
+static int handle_stdio()
{
static char line[1000];
int len;
+ len = packet_read_line(0, line, sizeof(line));
+
+ if (len && line[len-1] == '\n')
+ line[--len] = 0;
+
+ return execute(line, len);
+}
+
+static void handle(int incoming, struct sockaddr_in *addr, int addrlen)
+{
if (fork()) {
close(incoming);
return;
@@ -50,12 +60,8 @@ static void handle(int incoming, struct
dup2(incoming, 0);
dup2(incoming, 1);
close(incoming);
- len = packet_read_line(0, line, sizeof(line));
-
- if (len && line[len-1] == '\n')
- line[--len] = 0;
- exit(execute(line, len));
+ exit(handle_stdio());
}
static int serve(int port)
@@ -97,6 +103,7 @@ int main(int argc, char **argv)
{
int port = DEFAULT_GIT_PORT;
int i;
+ int inetd_mode = 0;
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -110,8 +117,17 @@ int main(int argc, char **argv)
continue;
}
}
+
+ if (!strncmp(arg, "--inetd", 7)) {
+ inetd_mode = 1;
+ continue;
+ }
+
usage(daemon_usage);
}
- return serve(port);
+ if (inetd_mode)
+ return handle_stdio();
+ else
+ return serve(port);
}
^ permalink raw reply
* Why O_EXCL would make this difference? I am puzzled..
From: Junio C Hamano @ 2005-07-14 8:17 UTC (permalink / raw)
To: git; +Cc: torvalds
The bisect search found that the commit
Make "git-checkout" create files with O_EXCL
makes the test t1005 fail. But it is getting late so I give up
to figuire this out tonight.
^ permalink raw reply
* Why fetching latest kernel sources is failing?
From: Paolo \'Blaisorblade\' Giarrusso @ 2005-07-13 17:22 UTC (permalink / raw)
To: git
cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
gives me the following error:
progress: 2 objects, 921 bytes
error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 (http://www.kernel.org/pub/
scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/
7e338ec2fc6aac461a11fe8049799e65639166) corrupt
Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166
while processing commit 0000000000000000000000000000000000000000.
error: cannot map sha1 file 2a7e338ec2fc6aac461a11fe8049799e65639166
cg-pull: objects pull failed
cg-init: pull failed
What's happening now? On the other local tree (I had already checked out a tree)
I get other kind of problems, so I can't use it either.
^ permalink raw reply
* Re: GIT overlay repositories
From: Junio C Hamano @ 2005-07-13 22:35 UTC (permalink / raw)
To: James Ketrenos; +Cc: git, torvalds
In-Reply-To: <42D5578D.3000301@linux.intel.com>
James Ketrenos <jketreno@linux.intel.com> writes:
> Start with two repositories, let's call them Repo-A and Repo-B. Repo-A
> is hosted on some server somewhere and contains lots of code
> (let's say its a kernel source repository). Repo-B is only adding a
> small amount of changes to the repo (for argument sake, let's say the
> IPW2100 and IPW2200 projects) on top of what is already provided by Repo-A.
>
> For several reasons, we would like users to be able to get just the
> differences between Repo-A and Repo-B from me.
I have done something like this in late April - early May when I
ran git-jc repository. I took the then-current Linus head from
git.git, placed only my commits and objects that are absent from
his tree to a public place, and asked pullers to pull from Linus
first and then from me to get a usable repository. My
understanding is that you are formalizing and automating the
part "please pull from X, Y, Z and then from me to complete what
I have, making it usable". If that is the case, I agree with
the intentions [*1*].
This is related to the reason Linus wanted to have .git/config,
something that records "this object database depends on these
other object databases to be complete", when we talked about
ALTERNATE_OBJECT_DIRECTORIES last time. I am wondering if there
is a way to solve these two related problems in a unified way.
One minor problem is that ALTERNATE_OBJECT_DIRECTORIES is a
local thing and we do not want to be able to express URLs in
there, because we do not want to run rsync nor curl from inside
sha1_file.c. The "partial repository" problem, on the other
hand, is to publish such a repository and you _do_ want to have
URLs, likely to be somewhere completely different from where
such a partial repository is hosted at, reachable from your
pullers.
Regardless of whatever we end up doing, I have one proposal to
make. How about having .git/objects/info/ directory for housing
various "object database" specific (and not repository specific)
information?
The set of files I would see immediate benefits are:
objects/info/ext -- this is your .git/refs/ancestors file [*2*],
that lists external URLs that the objects
in this object database depends upon,
along with the set of head commits
there to start pulling from to complete
this partial object database [*3*]. This
_should_ name URLs accessible to
expected pullers from this repository.
objects/info/alt -- list of local alternate object
directories; probably we should
deprecate ALTERNATE_OBJECT_DIRECTORIES
environment variable with this, and
rewrite parts of sha1_file.c. I'd
volunteer to do it if we have
consensus.
objects/info/pack -- list of pack files in objects/pack/;
this would be useful for discovery
through really dumb web servers [*4*].
Using something like the above structure, pulling from this
"partial" repository at rsync://abc.xz/x.git would go this way:
(1) Sync from rsync://abc.xz/x.git/objects/
(2) Read objects/info/ext just slurped from there. Run the
procedure (1) thru (3) against the URLs listed in the
file, recursively.
(3) [*5*] Read objects/info/alt just slurped from there. Say
it contained ../a.git and ../b.git. Run the procedure
(1) thru (3) against rsync://abc.xz/a.git/objects/ and
rsync://abc.xz/b.git/objects/ recursively.
(4) Sync from rsync://abc.xz/x.git/refs/ as needed.
Non-rsync transfer can and should be done the same way. In
either case, updating the puller's refs/ is done solely based on
the information from rsync://abc.xz/x.git/refs/ and not from
refs in the depended-upon repositories.
Am I basically on the same page as you are?
[Footnote]
*1* But you are conflating it something else. I will not
comment on the part you talk about merges in this message,
because forward-porting your own changes to updated upstream is
orthogonal to the "partial object database" issue. It needs be
taken care of independently even if you maintain a fully
populated object database for your development.
*2* Ancestry is an overused word, so I would propose to call
this "external dependency": your partial object database depends
on them to be complete and usable.
*3* I was wondering why you wanted to record the foreign head in
addition to the URLs first, but you need that information (and
probabaly that needs to be a set of heads, not just a single
head) because their head may move, and in the worst case may
even be rewound to something that is not a descendant of what
you depend upon.
*4* This is not related to the current topic.
*5* This part is optional, because some alternates used locally
at the partial repository site may not be exposed to the same
pullers, or even when exposed, the alternate site may be behind
a slow link and it is preferable to get the same information
from somewhere else listed in info/ext file. On the other hand,
it is simpler to just maintain info/alt file to serve for both
local and remote purposes. I don't offhand know the tradeoffs.
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Chris Wedgwood @ 2005-07-13 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, git
In-Reply-To: <Pine.LNX.4.58.0507131410430.17536@g5.osdl.org>
On Wed, Jul 13, 2005 at 02:23:18PM -0700, Linus Torvalds wrote:
> If you really want to do something like this, then you should do it like
> this:
>
> update_head() {
except there are a number of places I need to frob things in Cogito
and they are not all for the head. If the head is special and the
only candidate sure, that works for me.
> - following multiple links is _wrong_, since the next-level link could
> actually be a symlink to another tree entirely (if somebody is crazy
> enough to use "cp -Rl" to copy trees, then why not "cp -Rs"?)
I already stated that wasn't supposed to work. If you have symlinks
outside of your tree with cogito I think there is a *lot* more code
that probably needs to be checked.
Remember I used cogito here, not git directly. That probably means
things are invoked very differently for me?
> - you got relative links wrong.
Possibly, I was more for RFC/concept reasons I posted the patch. I'm
clueless when it comes to writing decent or reliable bash sh/bash
scripts.
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Catalin Marinas @ 2005-07-14 9:08 UTC (permalink / raw)
To: Russell King; +Cc: Linus Torvalds, git
In-Reply-To: <20050714083700.A26322@flint.arm.linux.org.uk>
Russell King <rmk@arm.linux.org.uk> wrote:
> it appears that cg-diff does a
>
> git-update-cache --refresh >/dev/null
>
> each time it's run, which is taking the bulk of the time. Also note
> that curiously, it exits with status 1.
Does git-ls-files --unmerged show any files?
--
Catalin
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Russell King @ 2005-07-14 9:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linus Torvalds, git
In-Reply-To: <tnxu0ixoiuo.fsf@arm.com>
On Thu, Jul 14, 2005 at 10:08:31AM +0100, Catalin Marinas wrote:
> Russell King <rmk@arm.linux.org.uk> wrote:
> > it appears that cg-diff does a
> >
> > git-update-cache --refresh >/dev/null
> >
> > each time it's run, which is taking the bulk of the time. Also note
> > that curiously, it exits with status 1.
>
> Does git-ls-files --unmerged show any files?
No, and it returns fairly quickly:
$ /usr/bin/time git-ls-files --unmerged
0.29user 0.03system 0:00.43elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+655minor)pagefaults 0swaps
Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
running a little longer. It's not the git-update-cache command which
is taking the time, it's git-diff-cache.
Running the diff several times, both with and without changes to
drivers/serial/8250.c, it seems that sometimes it's faster. I guess
it has to do with dentry invalidation...
However, the point is - I've only asked for _one_ file. Why do we need
to look at _every_ file in the tree?
I could understand this behaviour if I'd asked for a diff across the
whole tree, but I didn't.
Internally, the sha1 of the unmodified drivers/serial/8250.c should be
known, so should be trivial to unpack that and generate a diff. Given
the cache, this should be something which should be lightning fast
when the requested fileset to diff is already known.
--
Russell King
^ permalink raw reply
* Local cg-pull fails
From: Russell King @ 2005-07-14 10:12 UTC (permalink / raw)
To: git
I think I posted about this before, but I can't find it in my git
mailbox...
rmk@dyn-67:[linux-2.6-arm] $ cg-update origin
l
`../linux-2.6/.git/refs/heads/master' -> `.git/refs/heads/origin'
cp: cannot create link `.git/objects/00/ae0c9f3bc24856e7c9fcdf690466f1bbe0a4df': File exists
cp: cannot create link `.git/objects/01/5bd2cf869f70ec708558f1d37980a8b4968604': File exists
cp: cannot create link `.git/objects/02/c7e335d3ef3998dfb49673654152fb10124d2f': File exists
Consider this flow of changes (which represents how I work):
Linus' kernel.org tree --> Local pristine tree
^ ^ | |
| | v v
| | working tree 1 working tree 2
| | | |
| `----------------' |
`---------------------------------'
Changes are made in working tree 1, and made available to Linus. Linus
merges them into his tree. I pull them into the pristine tree. Assume
other changes occurred. in Linus' tree.
The pristine tree is obviously a superset of the working tree.
What happens when I pull those changes back into working tree 1, given
that cogito uses "cp -va -ul".
The pristine tree now contains the GIT objects which I created in tree 1.
For whatever reason I don't understand, they are dated after the same
objects in tree 1. Therefore, because of `-u', cp will want to update
them - by replacing the object with a link. It refuses.
Last time this was discussed, someone suggested -f, which solved the
problem. Can we please modify the cg-pull script to use -f ?
Secondly, can I suggest that cogito developers consider the above
usage scenario and construct a regression test for it to ensure that
future breakages of this nature are caught. For me, cogito has been
extremely fragile, and I don't think the above usage is unreasonable.
--
Russell King
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames (second try)
From: Catalin Marinas @ 2005-07-14 10:22 UTC (permalink / raw)
To: Bryan Larsen; +Cc: bryan.larsen, git
In-Reply-To: <20050714062733.21779.33599.sendpatchset@bryan-larsens-ibook-g4.local>
Bryan Larsen <bryanlarsen@yahoo.com> wrote:
> The current version of stgit does not allow whitespace in filenames. This patch fixes that. It also speeds up operations on large filesets considerably.
>
> Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Applied. It will be visible tonight via the ftp mirror.
One note about patch description. I would prefer to have the
convention of the Linux kernel patches:
---
Short description line
Longer
description
Signed-off-by: ...
---
A future export command with support for sendpatcheset will take the
short description line and use it as a subject. Also, it would be nice
for the longer description to be wrapped somewhere before column 80
(~72 would be OK).
--
Catalin
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames (second try)
From: Catalin Marinas @ 2005-07-14 15:01 UTC (permalink / raw)
To: Bryan Larsen; +Cc: bryan.larsen, git
In-Reply-To: <tnxu0ixn0ux.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> wrote:
> One note about patch description. I would prefer to have the
> convention of the Linux kernel patches:
>
> ---
> Short description line
Probably without this line in the e-mail body since it is already in
the subject line.
--
Catalin
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Linus Torvalds @ 2005-07-14 15:26 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050714083700.A26322@flint.arm.linux.org.uk>
On Thu, 14 Jul 2005, Russell King wrote:
>
> cg-update origin
> and then I edited drivers/serial/8250.c
Hmm..
> it appears that cg-diff does a
>
> git-update-cache --refresh >/dev/null
>
> each time it's run, which is taking the bulk of the time. Also note
> that curiously, it exits with status 1.
That part is normal - a update-cache is fast (it takes me 0.08 sec for the
kernel) if the cache is already mostly up-to-date, and the non-zero exit
status just means that some file was different (ie it's telling the caller
that there are edits in your tree - drivers/serial/8250.c).
The update-cache is slow only if the index isn't up-to-date, which can
happen either if somebody plays games with the index, or if somebody
touches all the files in the tree.
It's quite possible that some path in cg-update ends up not updating the
index properly. For example, I notice that the "fast-forward" uses
"git-checkout-cache -f -a", which can do so (lack of "-u" fila), but then
it does do a "git-update-cache --refresh" later, so that doesn't seem to
be it either.
If you do a "git-diff-files" every once in a while, it will _scream_ at
you whenever you have files that aren't up-to-date in the cache. That's
normal in small doses, of course (eg your edit of drivers/serial/8250.c
would make that one not up-to-date), but if you get a _lot_ of files
listed, that's usually a sign that something screwed up your index.
Linus
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Linus Torvalds @ 2005-07-14 15:51 UTC (permalink / raw)
To: Russell King; +Cc: Catalin Marinas, git
In-Reply-To: <20050714105938.A31383@flint.arm.linux.org.uk>
On Thu, 14 Jul 2005, Russell King wrote:
>
> Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
> running a little longer. It's not the git-update-cache command which
> is taking the time, it's git-diff-cache.
Ok. git-diff-cache actually ends up reading your HEAD tree, and that, in
turn, is 1000+ tree objects. So it can take a while for the whole tree,
especially in the nonpacked and uncached case.
git-diff-tree (comparing two trees) is smart enough to limit itself to
just the sub-trees that have been named, and would have compared the two
trees by looking up just eight objects (three subdirectories from each
tree, and then the file itself from both trees).
But git-diff-cache isn't - because it's comparing the tree against the
index file, and the index is inevitably the whole tree.
And I now think I know what makes it slow. Not only are you basically
opening 1100 files (the tree objects - there's really that many
subdirectories in the kernel. Scary), but because you have alternate
object directories, and almost all of the objects are in the alternate
(not your primary), you'll basically always end up _first_ looking in the
primary, failing, and then looking in the alternate.
Together with the hashing, you'll be looking all over the place, in other
words ;)
Which means that you'll be needing a fair amount of memory to keep all of
those negative dentries etc cached (and the directory tree too).
This is something the pack-files will just help enormously with, but it
was only recently that we turned git around to check the pack-files
_first_, and the object directories second, so you probably won't see it
(not to mention that you probably don't have big pack-files at all ;)
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).
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox