* [FILE] GNU BIT
From: Andreas Gal @ 2005-04-25 6:24 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6002 bytes --]
BIT - a little bit like SCM
BIT is a training exercise in shell programming and is the result of
my attempts to wrap my head around GIT's inner working. BIT's
command line interface should be very familiar to anyone who worked
with other(tm) SCM tools before. I try to not depend on custom
GIT features. BIT uses the off-the-shelf GIT core tools distributed
by Linus. This means that BIT has about 2% of the features of
Cogito. Also, it has about 0.1% of the user base of Cogito, so its
probably very broken and I really don't recommend using it.
You can obtain BIT from the following GIT repository:
http://nil.ics.uci.edu/~gal/public/bit
You can use the GIT core utilities to pull and check-out BIT:
init-db
curl http://nil.ics.uci.edu/~gal/public/bit/HEAD > .git/HEAD
http-pull -a `cat .git/HEAD` \
http://nil.ics.uci.edu/~gal/public/bit
read-tree `cat .git/HEAD`
checkout-cache -f -a
Naturally, you can also use BIT to pull the current sources, which
is much simpler:
bit clone http://nil.ics.uci.edu/~gal/public/bit
This will create a directory "bit", pull the latest sources and perform
a check-out for you.
INSTALLATION
Put "bit" anywhere in your search path. Its only a single bash script. It
requires a link "bit-resolve" to itself and the (soft) link should reside
in the same directory as "bit" itself. "bit" acts as merge script when
invoked through that link.
At this point, BIT's functionality is minimal. It does what I need it for.
I will obviously add more commands as we go along, but I won't touch
things like tags and stuff like that until Linus' makes up his mind how to
do it *RIGHT*.
BASIC CONCEPTS
- BIT always checks out all files in your repository and it does so
automatically. In other words, there is no "bit co" command. Not
everyone will like this, but I do.
- You can't seek around in a repository. Checked-out files always
match the HEAD revision. You can diff files against older versions,
but if you want to check out an older version, you will have to
clone the repository (see below).
TRACKING SOMEONE ELSE'S TREE
$ bit clone http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
(Note: Don't forget the '/' at the end, otherwise http-pull won't work.)
This command pulls Linus' latest GIT tree to a local repository "git.git".
You can change the latter by giving clone an additional argument.
$ bit clone http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/ \
git-trunk
Once you have a copy of the remote repository, you can check whether there
are new changesets in the remote repository that you haven't seen yet:
$ bit changes -R \
http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
If you see any changes, you can merge them into your own tree:
$ bit pull http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
BRANCHING
Now lets assume you want to work on an extension to GIT. For this, we will
clone the repository:
$ bit clone git-trunk git-bit
This will create a copy of the git-trunk repository and name it "git-bit".
The object directory is shared (using a soft link), which has the nice
benefit that once you run "bit pull" on one of the repositories, the
other one will be able to merge changes without any network traffic
(except for reading the current HEAD).
Lets say we make some changes to sha1_file.c and want to commit it to
our local repository "git-bit":
... edit sha1_file.c ...
In case we already forgot what file we edited, "bit pending" will tells us:
$ bit pending
sha1_file.c
Just in case we still can remember what we changed, there is "bit diffs",
which shows a diff to the current HEAD or any other version of our
tree.
$ bit diffs
--- 28ad1598e54200ca8ee1261ed7beb4e31e20b2f1/sha1_file.c
+++ sha1_file.c
@@ -70,6 +70,7 @@
int i;
static char *name, *base;
+ /* added a cool new feature here */
if (!base) {
char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : ...
int len = strlen(sha1_file_directory);
To commit our changes, we use "bit commit". It will fire up "vi" to ask for
a commit message.
$ bit commit
... enter commit message in vi ...
MERGING
Lets assume Linus' put out a new version of GIT, so we want to update both of
our repositories. First lets do this for "git-trunk".
$ cd bit-trunk
$ bit pull http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
(Note: You have to specify the URL explicitly every time because there is no
consensus yet where to store this information. Once thats sorted out, this
will be automatic, of course.)
As this repository only tracks Linus' sources, there should be no conflicts.
Now lets go to our "git-bit" repository and do the same there:
$ cd git-bit
$ bit pull http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
Because both repositories share the object directory, you will get away
with minimal network traffic. Conflicts are resolved using RCS merge. If
that fails, you have to edit the offending files yourself.
PUSHING PATCHES UPSTREAM
Lets assume we want to send our improvements to Linus. For this, we can
ask changes to show us all local changes in our repository:
$ bit changes -L \
http://www.kernel.org/pub/linux/kernel/people/torvalds/git.git/
There is currently no mechanism in BIT to generate patches automatically,
but I will add one shortly. What is working already is that you can
push your repository to a remote location:
$ bit push ssh://gal@sam.ics.uci.edu/.nfs/public_html/public/git/
This will update the remote repository via SSH and set HEAD to point
to your latest version. Please note that you have to create a
repository at the remote location using "init-db".
HELP
Try "bit --help" to get some simple instructions how to use BIT. All
commands have builtin help as well. Try "bit commit --help". Not all
options are always implemented. Feel free to send me a patch.
[-- Attachment #2: Type: APPLICATION/x-gzip, Size: 5057 bytes --]
^ permalink raw reply
* Why /usr/bin/env in scripts
From: Philip Pokorny @ 2005-04-25 7:38 UTC (permalink / raw)
To: Git Mailing List
I notice that the first line of the pasky shell scripts is
#!/usr/bin/env bash
rather than what I'm more familiar with:
#!/bin/bash
I see that env can be used to alter the environment before running a
program, but that doesn't seem to be happening here.
In fact, on my system /usr/bin/env is a link to /bin/env...
So what am I missing? Is this a portability aid?
Thanks,
:v)
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: David Greaves @ 2005-04-25 9:31 UTC (permalink / raw)
To: dwheeler
Cc: Linus Torvalds, Fabian Franz, Paul Jakma, Sean, Thomas Glanzmann,
David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <426C64E4.4090600@dwheeler.com>
David A. Wheeler wrote:
> $ cat-file signature 000195297c2a6336c2007548f909769e0862b509
minor comment, cat-file gives you raw access to the object data.
better:
$ cat-file signature $(what-signs 000195297c2a6336c2007548f909769e0862b509)
> signatureof commit 000195297c2a6336c2007548f909769e0862b509
> signer Petr Baudis <pasky@ucw.cz>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQBCbFaRCxlT/+f+SU4RAgYSAKCWpPNlDKDkxuuA649zJop7WkQPnACdF1Fg
> JgXatbJU8YJ7JHqvgyGepRU=
> =Kttg
> -----END PGP SIGNATURE-----
David
--
^ permalink raw reply
* Re: Revised PPC assembly implementation
From: Paul Mackerras @ 2005-04-25 9:40 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20050425031337.16605.qmail@science.horizon.com>
linux@horizon.com writes:
> Three changes:
> - Added stack frame as per your description.
> - Found two bugs. (Cutting & pasting too fast.) Fixed.
> - Minor scheduling improvements. More to come.
>
> Which lead to three questions:
> - Is the stack set properly now?
Not quite; you are saving 20 registers, so you need a 96-byte stack
frame, like this:
stwu %r1,-96(%r1)
stmw %r13,16(%r1)
...
lmw %r13,16(%r1)
addi %r1,%r1,96
blr
Since sha1_core is a leaf function, I suppose you could use the lr
save area (do stwu %r1,-80(%r1); stmw %r13,0(%r1)) but it seems a bit
dodgy.
> - Does it produce the right answer now?
Yes.
> - Is it any faster?
I did 10 repetitions of my program that calls SHA1_Update with a
4096-byte block of zeroes 256,000 times. With my version, the average
time was 4.6191 seconds with a standard deviation of 0.0157. With your
version, the average was 4.6063 and the standard deviation 0.0148. So
I would say that your version is probably just a little faster - of the
order of 0.3% faster.
Paul.
^ permalink raw reply
* Re: Why /usr/bin/env in scripts
From: David Greaves @ 2005-04-25 9:42 UTC (permalink / raw)
To: Philip Pokorny; +Cc: Git Mailing List
In-Reply-To: <426C9E63.4050907@mindspring.com>
Philip Pokorny wrote:
> I notice that the first line of the pasky shell scripts is
>
> #!/usr/bin/env bash
> So what am I missing? Is this a portability aid?
man env:
The first remaining argument specifies the program name to invoke;
it is searched for according to the `PATH' environment variable. Any
remaining arguments are passed as arguments to that program.
It's a trick to do a PATH search for a script interpreter rather than
hard coding the path.
Now all we have to do is make sure every distro on the planet has
/usr/bin/env - and they do.
David
^ permalink raw reply
* [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 11:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Linux Kernel Mailing List
The "git" didn't try store small variables, which aren't referenced, in
the processor registers. It also didn't use the size_t type. I corrected
a C++ style comment too.
Signed-off-by: Matthias-Christian Ott <matthias.christian@tiscali.de>
--
diff -Npru git-0.6/check-files.c git-0.6-ott/check-files.c
--- git-0.6/check-files.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/check-files.c 2005-04-24 17:27:17.000000000 +0200
@@ -38,7 +38,7 @@ static void check_file(const char *path)
int main(int argc, char **argv)
{
- int i;
+ register unsigned int i;
read_cache();
for (i = 1; i < argc ; i++)
diff -Npru git-0.6/checkout-cache.c git-0.6-ott/checkout-cache.c
--- git-0.6/checkout-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/checkout-cache.c 2005-04-24 17:29:59.000000000 +0200
@@ -52,7 +52,7 @@ static void create_directories(const cha
static int create_file(const char *path, unsigned int mode)
{
- int fd;
+ register int fd;
mode = (mode & 0100) ? 0777 : 0666;
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
@@ -67,10 +67,10 @@ static int create_file(const char *path,
static int write_entry(struct cache_entry *ce, const char *path)
{
- int fd;
+ register int fd;
void *new;
unsigned long size;
- long wrote;
+ register long wrote;
char type[20];
new = read_sha1_file(ce->sha1, type, &size);
@@ -142,7 +142,7 @@ static int checkout_file(const char *nam
static int checkout_all(const char *base_dir)
{
- int i;
+ register unsigned int i;
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
@@ -156,7 +156,8 @@ static int checkout_all(const char *base
int main(int argc, char **argv)
{
- int i, force_filename = 0;
+ register unsigned int i;
+ register int force_filename = 0;
const char *base_dir = "";
if (read_cache() < 0) {
diff -Npru git-0.6/commit.c git-0.6-ott/commit.c
--- git-0.6/commit.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/commit.c 2005-04-24 17:30:31.000000000 +0200
@@ -23,7 +23,7 @@ struct commit *lookup_commit(unsigned ch
static unsigned long parse_commit_date(const char *buf)
{
- unsigned long date;
+ register unsigned long date;
if (memcmp(buf, "author", 6))
return 0;
diff -Npru git-0.6/commit-tree.c git-0.6-ott/commit-tree.c
--- git-0.6/commit-tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/commit-tree.c 2005-04-24 19:57:37.000000000 +0200
@@ -5,6 +5,7 @@
*/
#include "cache.h"
+#include <stddef.h>
#include <pwd.h>
#include <time.h>
#include <string.h>
@@ -32,7 +33,7 @@ static void add_buffer(char **bufp, unsi
{
char one_line[2048];
va_list args;
- int len;
+ register int len;
unsigned long alloc, size, newsize;
char *buf;
@@ -64,8 +65,8 @@ static int prepend_integer(char *buffer,
static void finish_buffer(char *tag, char **bufp, unsigned int *sizep)
{
- int taglen;
- int offset;
+ size_t taglen;
+ register int offset;
char *buf = *bufp;
unsigned int size = *sizep;
@@ -82,7 +83,7 @@ static void finish_buffer(char *tag, cha
static void remove_special(char *p)
{
- char c;
+ register char c;
char *dst = p, *src = p;
for (;;) {
@@ -137,7 +138,8 @@ static void parse_rfc2822_date(char *dat
{
struct tm tm;
char *p;
- int i, offset;
+ register unsigned short int i;
+ register int offset;
time_t then;
memset(&tm, 0, sizeof(tm));
@@ -277,8 +279,9 @@ static char *commit_tree_usage = "commit
int main(int argc, char **argv)
{
- int i, len;
- int parents = 0;
+ register int i;
+ register size_t len;
+ register unsigned int parents = 0;
unsigned char tree_sha1[20];
unsigned char parent_sha1[MAXPARENT][20];
unsigned char commit_sha1[20];
diff -Npru git-0.6/convert-cache.c git-0.6-ott/convert-cache.c
--- git-0.6/convert-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/convert-cache.c 2005-04-24 17:42:09.000000000 +0200
@@ -1,5 +1,7 @@
#include "cache.h"
+#include <stddef.h>
+
struct entry {
unsigned char old_sha1[20];
unsigned char new_sha1[20];
@@ -29,7 +31,8 @@ static struct entry *insert_new(unsigned
static struct entry *lookup_entry(unsigned char *sha1)
{
- int low = 0, high = nr_convert;
+ register unsigned int low = 0;
+ register int high = nr_convert;
while (low < high) {
int next = (low + high) / 2;
@@ -70,8 +73,10 @@ static void convert_ascii_sha1(void *buf
static void convert_tree(void *buffer, unsigned long size)
{
+ register size_t len;
+
while (size) {
- int len = 1+strlen(buffer);
+ len = 1+strlen(buffer);
convert_binary_sha1(buffer + len);
@@ -98,7 +103,8 @@ static struct entry * convert_entry(unsi
struct entry *entry = lookup_entry(sha1);
char type[20];
void *buffer, *data;
- unsigned long size, offset;
+ unsigned long size;
+ register unsigned long offset;
if (entry->converted)
return entry;
diff -Npru git-0.6/diff-cache.c git-0.6-ott/diff-cache.c
--- git-0.6/diff-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/diff-cache.c 2005-04-24 19:59:51.000000000 +0200
@@ -1,5 +1,7 @@
#include "cache.h"
+#include <stddef.h>
+
static int cached_only = 0;
static int recursive = 0;
static int line_termination = '\n';
@@ -9,8 +11,8 @@ static int diff_cache(void *tree, unsign
static void update_tree_entry(void **bufp, unsigned long *sizep)
{
void *buf = *bufp;
- unsigned long size = *sizep;
- int len = strlen(buf) + 1 + 20;
+ register unsigned long size = *sizep;
+ register size_t len = strlen(buf) + 1 + 20;
if (size < len)
die("corrupt tree file 1 (%s)", size);
@@ -20,7 +22,7 @@ static void update_tree_entry(void **buf
static const unsigned char *extract(void *tree, unsigned long size,
const char **pathp, unsigned int *modep)
{
- int len = strlen(tree)+1;
+ register size_t len = strlen(tree)+1;
const unsigned char *sha1 = tree + len;
const char *path = strchr(tree, ' ');
@@ -84,10 +86,10 @@ static void show_file(const char *prefix
static int compare_tree_entry(const char *path1, unsigned int mode1,
const unsigned char *sha1,
struct cache_entry **ac, int *entries, const char *base)
{
- int baselen = strlen(base);
+ register size_t baselen = strlen(base);
struct cache_entry *ce = *ac;
const char *path2 = ce->name + baselen;
- unsigned int mode2 = ntohl(ce->ce_mode);
+ register unsigned int mode2 = ntohl(ce->ce_mode);
const unsigned char *sha2 = ce->sha1;
int cmp, pathlen1, pathlen2;
char old_sha1_hex[50];
@@ -160,7 +162,7 @@ static int compare_tree_entry(const char
static int diff_cache(void *tree, unsigned long size, struct
cache_entry **ac, int entries, const char *base)
{
- int baselen = strlen(base);
+ register size_t baselen = strlen(base);
for (;;) {
struct cache_entry *ce;
diff -Npru git-0.6/diff-tree.c git-0.6-ott/diff-tree.c
--- git-0.6/diff-tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/diff-tree.c 2005-04-24 17:48:24.000000000 +0200
@@ -1,5 +1,7 @@
#include "cache.h"
+#include <stddef.h>
+
static int recursive = 0;
static int line_termination = '\n';
@@ -8,8 +10,8 @@ static int diff_tree_sha1(const unsigned
static void update_tree_entry(void **bufp, unsigned long *sizep)
{
void *buf = *bufp;
- unsigned long size = *sizep;
- int len = strlen(buf) + 1 + 20;
+ register unsigned long size = *sizep;
+ register size_t len = strlen(buf) + 1 + 20;
if (size < len)
die("corrupt tree file");
@@ -19,7 +21,7 @@ static void update_tree_entry(void **buf
static const unsigned char *extract(void *tree, unsigned long size,
const char **pathp, unsigned int *modep)
{
- int len = strlen(tree)+1;
+ register size_t len = strlen(tree)+1;
const unsigned char *sha1 = tree + len;
const char *path = strchr(tree, ' ');
@@ -31,7 +33,7 @@ static const unsigned char *extract(void
static char *malloc_base(const char *base, const char *path, int pathlen)
{
- int baselen = strlen(base);
+ register size_t baselen = strlen(base);
char *newbase = malloc(baselen + pathlen + 2);
memcpy(newbase, base, baselen);
memcpy(newbase + baselen, path, pathlen);
@@ -85,7 +87,8 @@ static int compare_tree_entry(void *tree
unsigned mode1, mode2;
const char *path1, *path2;
const unsigned char *sha1, *sha2;
- int cmp, pathlen1, pathlen2;
+ register int cmp;
+ register size_t pathlen1, pathlen2;
char old_sha1_hex[50];
sha1 = extract(tree1, size1, &path1, &mode1);
diff -Npru git-0.6/fsck-cache.c git-0.6-ott/fsck-cache.c
--- git-0.6/fsck-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/fsck-cache.c 2005-04-24 17:50:15.000000000 +0200
@@ -14,7 +14,7 @@ static unsigned char head_sha1[20];
static void check_connectivity(void)
{
- int i;
+ register unsigned int i;
/* Look up all the requirements, warn about missing objects.. */
for (i = 0; i < nr_objs; i++) {
@@ -133,7 +133,7 @@ static int fsck_dir(int i, char *path)
int main(int argc, char **argv)
{
- int i, heads;
+ register unsigned int i, heads;
char *sha1_dir;
sha1_dir = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
diff -Npru git-0.6/init-db.c git-0.6-ott/init-db.c
--- git-0.6/init-db.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/init-db.c 2005-04-24 19:53:49.000000000 +0200
@@ -24,7 +24,8 @@ void safe_create_dir(char *dir)
int main(int argc, char **argv)
{
char *sha1_dir, *path;
- int len, i;
+ register size_t len;
+ register unsigned short int i;
safe_create_dir(".git");
diff -Npru git-0.6/merge-cache.c git-0.6-ott/merge-cache.c
--- git-0.6/merge-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/merge-cache.c 2005-04-24 19:59:07.000000000 +0200
@@ -8,7 +8,8 @@ static const char *arguments[5];
static void run_program(void)
{
- int pid = fork(), status;
+ register int pid = fork();
+ int status;
if (pid < 0)
die("unable to fork");
@@ -27,7 +28,7 @@ static void run_program(void)
static int merge_entry(int pos, const char *path)
{
- int found;
+ register unsigned int found;
if (pos >= active_nr)
die("merge-cache: %s not in the cache", path);
@@ -56,7 +57,7 @@ static int merge_entry(int pos, const ch
static void merge_file(const char *path)
{
- int pos = cache_name_pos(path, strlen(path));
+ register int pos = cache_name_pos(path, strlen(path));
/*
* If it already exists in the cache as stage0, it's
@@ -68,7 +69,7 @@ static void merge_file(const char *path)
static void merge_all(void)
{
- int i;
+ register unsigned int i;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (!ce_stage(ce))
@@ -79,7 +80,7 @@ static void merge_all(void)
int main(int argc, char **argv)
{
- int i, force_file = 0;
+ register unsigned short int i, force_file = 0;
if (argc < 3)
usage("merge-cache <merge-program> (-a | <filename>*)");
diff -Npru git-0.6/object.c git-0.6-ott/object.c
--- git-0.6/object.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/object.c 2005-04-24 19:51:16.000000000 +0200
@@ -9,7 +9,8 @@ static int obj_allocs;
static int find_object(unsigned char *sha1)
{
- int first = 0, last = nr_objs;
+ register int first = 0;
+ register int last = nr_objs;
while (first < last) {
int next = (first + last) / 2;
diff -Npru git-0.6/read-cache.c git-0.6-ott/read-cache.c
--- git-0.6/read-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/read-cache.c 2005-04-24 20:53:51.000000000 +0200
@@ -3,6 +3,7 @@
*
* Copyright (C) Linus Torvalds, 2005
*/
+#include <stddef.h>
#include <stdarg.h>
#include "cache.h"
@@ -11,7 +12,7 @@ unsigned int active_nr = 0, active_alloc
int cache_match_stat(struct cache_entry *ce, struct stat *st)
{
- unsigned int changed = 0;
+ register unsigned int changed = 0;
if (ce->ce_mtime.sec != htonl(st->st_mtime))
changed |= MTIME_CHANGED;
@@ -46,10 +47,10 @@ int cache_match_stat(struct cache_entry
int cache_name_compare(const char *name1, int flags1, const char
*name2, int flags2)
{
- int len1 = flags1 & CE_NAMEMASK;
- int len2 = flags2 & CE_NAMEMASK;
- int len = len1 < len2 ? len1 : len2;
- int cmp;
+ register int len1 = flags1 & CE_NAMEMASK;
+ register int len2 = flags2 & CE_NAMEMASK;
+ register int len = len1 < len2 ? len1 : len2;
+ register int cmp;
cmp = memcmp(name1, name2, len);
if (cmp)
@@ -67,7 +68,7 @@ int cache_name_compare(const char *name1
int cache_name_pos(const char *name, int namelen)
{
- int first, last;
+ register unsigned int first, last;
first = 0;
last = active_nr;
@@ -98,7 +99,7 @@ static int remove_entry_at(int pos)
int remove_file_from_cache(char *path)
{
- int pos = cache_name_pos(path, strlen(path));
+ register int pos = cache_name_pos(path, strlen(path));
if (pos < 0)
pos = -pos-1;
while (pos < active_nr && !strcmp(active_cache[pos]->name, path))
@@ -108,13 +109,13 @@ int remove_file_from_cache(char *path)
static int same_name(struct cache_entry *a, struct cache_entry *b)
{
- int len = ce_namelen(a);
+ register int len = ce_namelen(a);
return ce_namelen(b) == len && !memcmp(a->name, b->name, len);
}
int add_cache_entry(struct cache_entry *ce, int ok_to_add)
{
- int pos;
+ register int pos;
pos = cache_name_pos(ce->name, htons(ce->ce_flags));
@@ -173,9 +174,11 @@ static int verify_hdr(struct cache_heade
int read_cache(void)
{
- int fd, i;
+ register int fd;
+ register unsigned int i;
struct stat st;
- unsigned long size, offset;
+ register unsigned long size;
+ register size_t offset;
void *map;
struct cache_header *hdr;
@@ -192,7 +195,7 @@ int read_cache(void)
if (fd < 0)
return (errno == ENOENT) ? 0 : error("open failed");
- size = 0; // avoid gcc warning
+ size = 0; /* avoid gcc warning */
map = (void *)-1;
if (!fstat(fd, &st)) {
size = st.st_size;
@@ -254,7 +257,7 @@ static int ce_write(SHA_CTX *context, in
static int ce_flush(SHA_CTX *context, int fd)
{
- unsigned int left = write_buffer_len;
+ register unsigned int left = write_buffer_len;
if (left) {
write_buffer_len = 0;
@@ -273,7 +276,7 @@ int write_cache(int newfd, struct cache_
{
SHA_CTX c;
struct cache_header hdr;
- int i;
+ register unsigned int i;
hdr.hdr_signature = htonl(CACHE_SIGNATURE);
hdr.hdr_version = htonl(2);
diff -Npru git-0.6/read-tree.c git-0.6-ott/read-tree.c
--- git-0.6/read-tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/read-tree.c 2005-04-24 19:57:05.000000000 +0200
@@ -9,8 +9,8 @@ static int stage = 0;
static int read_one_entry(unsigned char *sha1, const char *base, int
baselen, const char *pathname, unsigned mode)
{
- int len = strlen(pathname);
- unsigned int size = cache_entry_size(baselen + len);
+ register size_t len = strlen(pathname);
+ register unsigned int size = cache_entry_size(baselen + len);
struct cache_entry *ce = malloc(size);
memset(ce, 0, size);
@@ -29,8 +29,10 @@ static int read_tree_recursive(void *buf
{
if (!buffer || strcmp(type, "tree"))
return -1;
+ register size_t len;
+
while (size) {
- int len = strlen(buffer)+1;
+ len = strlen(buffer)+1;
unsigned char *sha1 = buffer + len;
char *path = strchr(buffer, ' ')+1;
unsigned int mode;
@@ -89,7 +91,7 @@ static void remove_lock_file(void)
static int path_matches(struct cache_entry *a, struct cache_entry *b)
{
- int len = ce_namelen(a);
+ register int len = ce_namelen(a);
return ce_namelen(b) == len &&
!memcmp(a->name, b->name, len);
}
@@ -113,7 +115,7 @@ static struct cache_entry *merge_entries
struct cache_entry *b,
struct cache_entry *c)
{
- int len = ce_namelen(a);
+ register int len = ce_namelen(a);
/*
* Are they all the same filename? We won't do
@@ -221,7 +223,8 @@ static char *read_tree_usage = "read-tre
int main(int argc, char **argv)
{
- int i, newfd, merge;
+ register unsigned int i,merge;
+ register int newfd;
unsigned char sha1[20];
static char lockfile[MAXPATHLEN+1];
const char *indexfile = get_index_file();
diff -Npru git-0.6/revision.h git-0.6-ott/revision.h
--- git-0.6/revision.h 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/revision.h 2005-04-24 18:43:36.000000000 +0200
@@ -33,7 +33,8 @@ static int nr_revs, rev_allocs;
static int find_rev(unsigned char *sha1)
{
- int first = 0, last = nr_revs;
+ register unsigned int first = 0;
+ register int last = nr_revs;
while (first < last) {
int next = (first + last) / 2;
diff -Npru git-0.6/rev-tree.c git-0.6-ott/rev-tree.c
--- git-0.6/rev-tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/rev-tree.c 2005-04-24 18:46:47.000000000 +0200
@@ -32,7 +32,7 @@ static void read_cache_file(const char *
*/
static int interesting(struct commit *rev)
{
- unsigned mask = rev->object.flags;
+ register unsigned int mask = rev->object.flags;
if (!mask)
return 0;
@@ -77,8 +77,8 @@ void process_commit(unsigned char *sha1)
*/
int main(int argc, char **argv)
{
- int i;
- int nr = 0;
+ register unsigned int i;
+ register unsigned int nr = 0;
unsigned char sha1[MAX_COMMITS][20];
/*
diff -Npru git-0.6/sha1_file.c git-0.6-ott/sha1_file.c
--- git-0.6/sha1_file.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/sha1_file.c 2005-04-24 20:46:32.000000000 +0200
@@ -6,6 +6,7 @@
* This handles basic git sha1 object files - packing, unpacking,
* creation etc.
*/
+#include <stddef.h>
#include <stdarg.h>
#include "cache.h"
@@ -24,7 +25,7 @@ static unsigned hexval(char c)
int get_sha1_hex(const char *hex, unsigned char *sha1)
{
- int i;
+ register unsigned int i;
for (i = 0; i < 20; i++) {
unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
if (val & ~0xff)
@@ -40,7 +41,7 @@ char * sha1_to_hex(const unsigned char *
static char buffer[50];
static const char hex[] = "0123456789abcdef";
char *buf = buffer;
- int i;
+ register unsigned short int i;
for (i = 0; i < 20; i++) {
unsigned int val = *sha1++;
@@ -57,7 +58,7 @@ char * sha1_to_hex(const unsigned char *
*/
char *sha1_file_name(const unsigned char *sha1)
{
- int i;
+ register unsigned short int i;
static char *name, *base;
if (!base) {
@@ -96,7 +97,7 @@ int check_sha1_signature(unsigned char *
void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
{
char *filename = sha1_file_name(sha1);
- int fd = open(filename, O_RDONLY);
+ register int fd = open(filename, O_RDONLY);
struct stat st;
void *map;
@@ -118,7 +119,7 @@ void *map_sha1_file(const unsigned char
void * unpack_sha1_file(void *map, unsigned long mapsize, char *type,
unsigned long *size)
{
- int ret, bytes;
+ register int ret, bytes;
z_stream stream;
char buffer[8192];
char *buf;
@@ -173,7 +174,7 @@ void *read_tree_with_tree_or_commit_sha1
char type[20];
void *buffer;
unsigned long isize;
- int was_commit = 0;
+ register unsigned short int was_commit = 0;
unsigned char tree_sha1[20];
buffer = read_sha1_file(sha1, type, &isize);
@@ -208,13 +209,13 @@ void *read_tree_with_tree_or_commit_sha1
int write_sha1_file(char *buf, unsigned len, unsigned char *returnsha1)
{
- int size;
+ register size_t size;
char *compressed;
z_stream stream;
unsigned char sha1[20];
SHA_CTX c;
char *filename;
- int fd;
+ register int fd;
/* Sha1.. */
SHA1_Init(&c);
@@ -264,9 +265,9 @@ static inline int collision_check(char *
{
#ifdef COLLISION_CHECK
void *map;
- int fd = open(filename, O_RDONLY);
+ register int fd = open(filename, O_RDONLY);
struct stat st;
- int cmp;
+ register int cmp;
/* Unreadable object, or object went away? Strange. */
if (fd < 0)
@@ -290,7 +291,7 @@ static inline int collision_check(char *
int write_sha1_buffer(const unsigned char *sha1, void *buf, unsigned
int size)
{
char *filename = sha1_file_name(sha1);
- int fd;
+ register int fd;
fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd < 0) {
diff -Npru git-0.6/show-diff.c git-0.6-ott/show-diff.c
--- git-0.6/show-diff.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/show-diff.c 2005-04-24 19:53:09.000000000 +0200
@@ -38,7 +38,7 @@ static void prepare_diff_cmd(void)
static char *sq_expand(char *src)
{
static char *buf = NULL;
- int cnt, c;
+ register int cnt, c;
char *cp;
/* count bytes needed to store the quoted string. */
@@ -71,7 +71,7 @@ static void show_differences(char *name,
int cmd_size = strlen(name_sq) + strlen(label_sq) * 2 +
strlen(diff_cmd) + strlen(diff_opts) + strlen(diff_arg);
char *cmd = malloc(cmd_size);
- int next_at;
+ register int next_at;
fflush(stdout);
next_at = snprintf(cmd, cmd_size, diff_cmd, label_sq, label_sq);
@@ -106,7 +106,7 @@ static const char *show_diff_usage = "sh
static int matches_pathspec(struct cache_entry *ce, char **spec, int cnt)
{
- int i;
+ register int i;
int namelen = ce_namelen(ce);
for (i = 0; i < cnt; i++) {
int speclen = strlen(spec[i]);
@@ -121,12 +121,12 @@ static int matches_pathspec(struct cache
int main(int argc, char **argv)
{
- int silent = 0;
- int silent_on_nonexisting_files = 0;
- int machine_readable = 0;
- int reverse = 0;
- int entries = read_cache();
- int i;
+ register unsigned short int silent = 0;
+ register unsigned short int silent_on_nonexisting_files = 0;
+ register unsigned short int machine_readable = 0;
+ register unsigned short int reverse = 0;
+ register int entries = read_cache();
+ register int i;
while (1 < argc && argv[1][0] == '-') {
if (!strcmp(argv[1], "-R"))
@@ -153,7 +153,7 @@ int main(int argc, char **argv)
for (i = 0; i < entries; i++) {
struct stat st;
struct cache_entry *ce = active_cache[i];
- int changed;
+ register unsigned short int changed;
unsigned long size;
char type[20];
void *old;
diff -Npru git-0.6/show-files.c git-0.6-ott/show-files.c
--- git-0.6/show-files.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/show-files.c 2005-04-24 19:08:07.000000000 +0200
@@ -5,6 +5,7 @@
*
* Copyright (C) Linus Torvalds, 2005
*/
+#include <stddef.h>
#include <dirent.h>
#include "cache.h"
@@ -91,14 +92,14 @@ static int cmp_name(const void *p1, cons
{
const char *n1 = *(const char **)p1;
const char *n2 = *(const char **)p2;
- int l1 = strlen(n1), l2 = strlen(n2);
+ register size_t l1 = strlen(n1), l2 = strlen(n2);
return cache_name_compare(n1, l1, n2, l2);
}
static void show_files(void)
{
- int i;
+ register unsigned int i;
/* For cached/deleted files we don't need to even do the readdir */
if (show_others | show_ignored) {
@@ -142,7 +143,7 @@ static void show_files(void)
int main(int argc, char **argv)
{
- int i;
+ register unsigned int i;
for (i = 1; i < argc; i++) {
char *arg = argv[i];
diff -Npru git-0.6/tree.c git-0.6-ott/tree.c
--- git-0.6/tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/tree.c 2005-04-24 19:52:40.000000000 +0200
@@ -1,6 +1,7 @@
#include "tree.h"
#include "blob.h"
#include "cache.h"
+#include <stddef.h>
#include <stdlib.h>
const char *tree_type = "tree";
@@ -40,7 +41,7 @@ int parse_tree(struct tree *item)
sha1_to_hex(item->object.sha1));
while (size) {
struct object *obj;
- int len = 1+strlen(bufptr);
+ size_t len = 1+strlen(bufptr);
unsigned char *file_sha1 = bufptr + len;
char *path = strchr(bufptr, ' ');
unsigned int mode;
diff -Npru git-0.6/unpack-file.c git-0.6-ott/unpack-file.c
--- git-0.6/unpack-file.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/unpack-file.c 2005-04-24 19:11:17.000000000 +0200
@@ -6,7 +6,7 @@ static char *create_temp_file(unsigned c
void *buf;
char type[100];
unsigned long size;
- int fd;
+ register int fd;
buf = read_sha1_file(sha1, type, &size);
if (!buf || strcmp(type, "blob"))
diff -Npru git-0.6/update-cache.c git-0.6-ott/update-cache.c
--- git-0.6/update-cache.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/update-cache.c 2005-04-24 19:46:03.000000000 +0200
@@ -3,6 +3,8 @@
*
* Copyright (C) Linus Torvalds, 2005
*/
+#include <stddef.h>
+
#include "cache.h"
/*
@@ -17,11 +19,11 @@ static int allow_add = 0, allow_remove =
static int index_fd(unsigned char *sha1, int fd, struct stat *st)
{
z_stream stream;
- unsigned long size = st->st_size;
- int max_out_bytes = size + 200;
+ register unsigned long size = st->st_size;
+ register int max_out_bytes = size + 200;
void *out = malloc(max_out_bytes);
void *metadata = malloc(200);
- int metadata_size;
+ register int metadata_size;
void *in;
SHA_CTX c;
@@ -87,10 +89,11 @@ static void fill_stat_cache_info(struct
static int add_file_to_cache(char *path)
{
- int size, namelen;
+ register int size;
+ register size_t namelen;
struct cache_entry *ce;
struct stat st;
- int fd;
+ register int fd;
fd = open(path, O_RDONLY);
if (fd < 0) {
@@ -123,7 +126,7 @@ static int match_data(int fd, void *buff
{
while (size) {
char compare[1024];
- int ret = read(fd, compare, sizeof(compare));
+ register int ret = read(fd, compare, sizeof(compare));
if (ret <= 0 || ret > size || memcmp(buffer, compare, ret))
return -1;
@@ -135,8 +138,8 @@ static int match_data(int fd, void *buff
static int compare_data(struct cache_entry *ce, unsigned long
expected_size)
{
- int match = -1;
- int fd = open(ce->name, O_RDONLY);
+ register int match = -1;
+ register int fd = open(ce->name, O_RDONLY);
if (fd >= 0) {
void *buffer;
@@ -169,7 +172,7 @@ static struct cache_entry *refresh_entry
{
struct stat st;
struct cache_entry *updated;
- int changed, size;
+ register int changed, size;
if (stat(ce->name, &st) < 0)
return NULL;
@@ -197,7 +200,7 @@ static struct cache_entry *refresh_entry
static void refresh_cache(void)
{
- int i;
+ register unsigned int i;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce, *new;
@@ -231,7 +234,7 @@ static void refresh_cache(void)
*/
static int verify_path(char *path)
{
- char c;
+ register char c;
goto inside;
for (;;) {
@@ -250,7 +253,8 @@ inside:
static int add_cacheinfo(char *arg1, char *arg2, char *arg3)
{
- int size, len;
+ register int size;
+ register size_t len;
unsigned int mode;
unsigned char sha1[20];
struct cache_entry *ce;
@@ -284,8 +288,8 @@ static void remove_lock_file(void)
int main(int argc, char **argv)
{
- int i, newfd, entries;
- int allow_options = 1;
+ register int i, newfd, entries;
+ register unsigned short int allow_options = 1;
static char lockfile[MAXPATHLEN+1];
const char *indexfile = get_index_file();
diff -Npru git-0.6/write-tree.c git-0.6-ott/write-tree.c
--- git-0.6/write-tree.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-ott/write-tree.c 2005-04-24 19:22:22.000000000 +0200
@@ -8,7 +8,7 @@
static int check_valid_sha1(unsigned char *sha1)
{
char *filename = sha1_file_name(sha1);
- int ret;
+ register int ret;
/* If we were anal, we'd check that the sha1 of the contents actually
matches */
ret = access(filename, R_OK);
@@ -32,9 +32,9 @@ static int prepend_integer(char *buffer,
static int write_tree(struct cache_entry **cachep, int maxentries,
const char *base, int baselen, unsigned char *returnsha1)
{
unsigned char subdir_sha1[20];
- unsigned long size, offset;
+ register unsigned long size, offset;
char *buffer;
- int i, nr;
+ register int i, nr;
/* Guess at some random initial size */
size = 8192;
@@ -100,8 +100,8 @@ static int write_tree(struct cache_entry
int main(int argc, char **argv)
{
- int i, unmerged;
- int entries = read_cache();
+ register int i, unmerged;
+ register int entries = read_cache();
unsigned char sha1[20];
if (entries <= 0)
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.2 && heads-up on upcoming changes
From: Andrew Morton @ 2005-04-25 11:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: pasky, greg, git
In-Reply-To: <Pine.LNX.4.58.0504201503050.6467@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> Yeah, yeah, it looks different from "cvs update", but dammit, wouldn't it
> be cool to just write "cg-<tab><tab>" and see the command choices? Or
> "cg-up<tab>" and get cg-update done for you..
zsh can do this for (for example) cvs. Type "cvs <tab><tab><tab>" and
you get "cvs annotate".
Type "cvs commit foo/bar/<tab>" and zsh will start cycling through the
files which need committing in ./foo/bar/. Yes, the shell knows about
and pokes around inside cvs files.
I just brought this up because I know how much you'd love the whole
concept ;)
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Rene Rebe @ 2005-04-25 11:39 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426CD1F1.2010101@tiscali.de>
Hi,
Matthias-Christian Ott wrote:
> The "git" didn't try store small variables, which aren't referenced, in
> the processor registers. It also didn't use the size_t type. I corrected
> a C++ style comment too.
Well, modern compilers take register as a non-binding hint. Your
register storage specification for those loop counters will not make any
change. You have not looked into the resulting binary?
Also // is valid C99 ...
Yours,
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de/ | http://www.t2-project.org/
+49 (0)30 255 897 45
^ permalink raw reply
* git I/O performance (was: Performance of various compressors)
From: Klaus Robert Suetterlin @ 2005-04-25 12:17 UTC (permalink / raw)
To: Aaron Lehmann; +Cc: Mike Taht, git
In-Reply-To: <20050422203801.GE7437@vitelus.com>
I did some statistics on the freebsd /usr/src/sys directory, as I
did not have access to the linux kernel sources.
This is 5435 Files, of about 81MB (according to du -sh). I did
find sys/ -type f -exec gzip -9 {} +
find sys/ -type f -exec gzip -d {} +
and similar calls to get an impression how different compression
levels and compressors will act on the data most likely handled by
git backend storage.
On a 700MHz p3, UDMA33, freebsd 5.3, ffs (soft updates) I get:
compressor | levels (size, time to compress, time to uncompress)
-----------+-------------------------------------------------------------------
gzip | 9 (28M, 1:19, 30), 6 (28M, 31.7, 30), 3 (30M, 26.1, 28.7)
| 1 (31M, 23.6, 29.8)
bzip2 | 9 (27M, 2:14, 37.4) 6 (27M, 2:11, 38.8) 3 (27M, 2:10, 38.3)
lzop | 9 (32M, 2:15, 35.4) 7 (32M, 57.9, 40.3) 3 (39M, 36.0, 44.4)
These speeds are for the case that our work set fits into filesystem
caches. This will be the most common case --- as normal commits will
not checkin the whole tree.
That is. We should really use gzip -6. It results in the best
compression at a reasonable time. bzip2 can't really compress those
tiny files efficiently. lzop is limited by open/close (see below).
BTW. I also did this for the whole /usr/src of freebsd (which is
35000 files and 350MB, du -sh gives 398MB). The numbers look best
for gzip -6.
The files we work with seem to have an average uncompressed size
of 10-15kB and seem to compress by about a factor of three.
So I did a test in C: open("file%d"), write(file, buf, 10000),
close(file). I repeated this for 35000 files as in the freebsd src
case, to get some statistics. The gprof output tells me, that
open+close take the same ammount of time as the write. (You should
really try do to rm test[0-9]* on those 35000 files :)) I wrote
the full 10000 bytes, to check for the case when we have no compression
at all. When compression gets better we will become more and more
open/close limited.
This means we are open/close limited in git. Even if we compress
the files to zero size, we cannot get faster than by a factor of
two!
Earlier messages in this thread showed that we are also limited by
filesytem cache, so we should use compression and efficient prefetch
to get best performance out of it. Because even if we cannot get
faster than by a factor of two through compression (even delta
compression won't help! It would make things worse IMHO) we can
get a lot worse (like ten times slower) for large sets on slow
machines with few memory.
I also tried to get a better ratio by using the standard db.h btree
database, so I wouldn't have to open and close all those files.
Unfortunately the btree is about twice as large as the files, so I
had to write twice as much data to disk(800MB). Also db->put
is much more complicated than write. So the test ended up taking
about 10% more time, than the open/write/close case. Maybe in the
case of a smaller work set (i.e. 1000 files instead of 35000) this
might provide faster backend speeds. Also one could optimise speed
by tweaking the acccess method parameters.
On Fri, Apr 22, 2005 at 01:38:01PM -0700, Aaron Lehmann wrote:
> On Wed, Apr 20, 2005 at 10:06:38PM -0700, Mike Taht wrote:
> > That doing the compression at a level of 3, rather than the max of 9,
> > cuts the cpu time required for a big git commit by over half, and that
> > that actually translates into a win on the I/O to disk. (these tests
> > were performed on a dual opteron 842)
>
> If (de)compression is slowing things down, you might want to check out
> lzo (http://www.oberhumer.com/opensource/lzo/). I tested it on the
> 2.6.11 kernel source and found that lzo -7 output is only 2% larger
> than gzip -3, but lzo decompression is almost 3 times faster. The
> downside is that lzo took 5 times longer to perform the compression at
> -7. Compression with lzo -3 is 3.5 times faster than gzip -3, but it
> produces a file that's 37% bigger. Unfortunately, lzo has no settings
> in between -3 and -7. I'd expect git to be more sensitive to
> decompression speeds, though.
>
> BTW, lzo decompression speed is not affected by the compression level.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Robert Suetterlin (robert@mpe.mpg.de)
phone: (+49)89 / 30000-3546 fax: (+49)89 / 30000-3950
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Petr Baudis @ 2005-04-25 12:32 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426CD1F1.2010101@tiscali.de>
Dear diary, on Mon, Apr 25, 2005 at 01:18:09PM CEST, I got a letter
where Matthias-Christian Ott <matthias.christian@tiscali.de> told me that...
> The "git" didn't try store small variables, which aren't referenced, in
> the processor registers. It also didn't use the size_t type. I corrected
> a C++ style comment too.
Honestly, I don't think using the register keyword helps anything but to
make the code less readable.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 12:56 UTC (permalink / raw)
To: Rene Rebe; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426CD703.5040009@exactcode.de>
Rene Rebe wrote:
> Hi,
>
> Matthias-Christian Ott wrote:
>
>> The "git" didn't try store small variables, which aren't referenced,
>> in the processor registers. It also didn't use the size_t type. I
>> corrected a C++ style comment too.
>
>
> Well, modern compilers take register as a non-binding hint. Your
> register storage specification for those loop counters will not make any
> change. You have not looked into the resulting binary?
>
> Also // is valid C99 ...
>
> Yours,
>
But if you use only /* */ comments and there's a // comment it looks
ugly :).
I've disassembled the code and it for me (I'm not a professional
assembler coder) it looks like it's stored in a register because the ebp
offsets are smaller and the gcc (4.0) wouldn't cause an error if you
reference them.
Matthias-Christian Ott
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 13:01 UTC (permalink / raw)
To: Matthias-Christian Ott
Cc: Rene Rebe, Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426CE904.9010505@tiscali.de>
Matthias-Christian Ott wrote:
> Rene Rebe wrote:
>
>> Hi,
>>
>> Matthias-Christian Ott wrote:
>>
>>> The "git" didn't try store small variables, which aren't referenced,
>>> in the processor registers. It also didn't use the size_t type. I
>>> corrected a C++ style comment too.
>>
>>
>>
>> Well, modern compilers take register as a non-binding hint. Your
>> register storage specification for those loop counters will not make
>> any change. You have not looked into the resulting binary?
>>
>> Also // is valid C99 ...
>>
>> Yours,
>>
> But if you use only /* */ comments and there's a // comment it looks
> ugly :).
>
> I've disassembled the code and it for me (I'm not a professional
> assembler coder) it looks like it's stored in a register because the ebp
> offsets are smaller and the gcc (4.0) wouldn't cause an error if you
> reference them.
>
> Matthias-Christian Ott
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Here's some example code (diff of the assembler codes) which shows what
I mean:
- movl %eax, -8(%ebp)
+ movl %eax, -4(%ebp)
[..]
- leal 1(%eax), %ecx
- movl -52(%ebp), %edx
+ leal 1(%eax), %edx
movl 12(%ebp), %eax
- subl %edx, %eax
- movl %eax, %edx
- movl -52(%ebp), %eax
+ movl %eax, %ecx
+ subl -80(%ebp), %ecx
+ movl -80(%ebp), %eax
sall $2, %eax
movl %eax, %ebx
addl 8(%ebp), %ebx
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Pekka Enberg @ 2005-04-25 13:07 UTC (permalink / raw)
To: Petr Baudis
Cc: Matthias-Christian Ott, Linus Torvalds, git,
Linux Kernel Mailing List
In-Reply-To: <20050425123236.GC26665@pasky.ji.cz>
Hi,
On 4/25/05, Petr Baudis <pasky@ucw.cz> wrote:
> Honestly, I don't think using the register keyword helps anything but to
> make the code less readable.
Indeed. The use of 'register' keyword blindly can actually make the
generated code _worse_ as it taking away one register from the
compiler's register allocator.
Pekka
^ permalink raw reply
* Re: A darcs that can pull from git
From: David Roundy @ 2005-04-25 13:31 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, Git Mailing List
In-Reply-To: <7ipswjbybx.fsf@lanthane.pps.jussieu.fr>
On Mon, Apr 25, 2005 at 12:32:18AM +0200, Juliusz Chroboczek wrote:
> I've just finished putting together a hack for darcs to allow it to
> pull from Git repositories. You'll find the patch (Darcs patch, not
> diff patch) on
Very cool! :)
> http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs
First off, you need to include a license header in the git files indicating
that unlike the rest of darcs, they may only be distributed under GPL v2.
Something like the following would probably be fine (but it's Linus'
copyright that's involved, not mine)
/*
* GIT - The information manager from hell
*
* Copyright (C) Linus Torvalds, 2005
This program is free software; you can redistribute it and/or modify
it under the terms of version 2 of the GNU General Public License as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
Without this header, it's either illegal to distribute these files, or
they're assumed to be under GPLv2 or later along with the rest of darcs,
which also isn't legal...
> I've just finished putting together a hack for darcs to allow it to
> pull from Git repositories. You'll find the patch (Darcs patch, not
> diff patch) on
> http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs
Any chance you can host a gettable repository? If not, I'd be happy to give
you an account on darcs.net on which you could host darcs-git.
> If you get merge conflicts, try using a version of the darcs-unstable
> tree from 18.04.2005, which is what I started with.
There is a conflict in GNUMakefile, which is moderately easy to resolve.
It would be nice to keep files in alphabetical order (as is mostly
currently the case, which has some small chance of reducing the likelihood
of conflicts.
> A minor problem: there's something broken with the build procedure;
> you'll probably need to manually do a ``make Context.hs'' followed
> with ``make darcs'' when the build breaks.
Or alternatively run "autoconf; ./configure; make"
> After you build darcs-git, you should be able to do something like
>
> $ cd ..
> $ mkdir a
> $ cd a
> $ darcs initialize
> $ ../darcs-git/darcs pull /usr/local/src/git-pasky-0.4
> $ darcs changes
Do you have any plans/ideas for allowing pulls directly from a remote git
repository? Obviously it'll be less efficient, since you'll have to
download at least one file in its entirety. Perhaps we could store a git
mirror in _darcs and use rsync? :(
> David, could you please have a look at the patches
>
> Sun Apr 24 16:50:02 CEST 2005 Juliusz Chroboczek <jch@pps.jussieu.fr>
> * First cut at remodularising repo access.
>
> Sun Apr 24 16:01:32 CEST 2005 Juliusz Chroboczek <jch@pps.jussieu.fr>
> * Change Repository to DarcsRepo.
>
> and tell me whether this sort of restructuring is okay with you.
Those two look fine to me. I'm increasingly liking (as I get to understand
it better) your ideas regarding modularizing repository access.
> (David, I'm not claiming that this scheme is better than the ``tagging
> like crazy'' scheme that you outlined; I'm only trying to prove that
> my scheme is workable.)
Okay, it does look like most of your code will be equally useful for the
"tagging like crazy" scheme.
> Right now, I'm taking a Git commit and manually generating a Darcs
> patch id from that, which is a bad idea. A better way would be to get
> Darcs to deal with arbitrarily shaped patch ids; a patch that
> originates with git would get the git patch id, while a patch that
> comes from Darcs would retain its patch id even when pushed to git.
> David, you had some objections to that; any chance we could discuss
> the issue?
We certainly can discuss it, and I still object. I think it'd be much
better to map from git commits to darcs patch ids. Your scheme and mine
both have uglinesses.
My "tag like crazy" scheme gives a unique mapping of a git commit to one
darcs patch and one darcs tag, but has the ugliness that a darcs patch
can't be mapped to a git commit without adding an additional darcs tag. I
tend to see this as a plus. It reflects the fact semantic difference
between a darcs patch and a git commit--the git commit is actually
equivalent not to a darcs patch but rather a darcs tag.
Your idea has the niceness that it could provide a one-to-one (as opposed
to two-to-one) mapping between darcs patches and git commits, but the catch
is that we don't know the git commit ID until after the patch has been
moved into git-land. This is directly analagous to the wart in my scheme
that darcs patches would acquire a tag when moved into git-land. I prefer
my scheme, since extra tags are relatively harmless, and reflect the
dependencies in the git repository.
> This is slow. There are a few obvious improvements to make to the
> performance, but I'd rather first implement whatsnew, diff and apply,
> and fix the problem with patch dependencies. (Whatsnew is where git's
> performance is actually likely to be better than Darcs, but it will
> require some abstracting of ``Slurpy'' in order to make that
> effective.) Unfortunately, I don't expect to have hacking time before
> next week-end.
All right. I'll look forward to another installment after next weekend
then! :)
I had a few minor comments on your code, which I've forgotten. One was
that either you're compiling with ghc 6.2, or you've disabled
-Werror... It'd be nice to be sure that your code is -Werror-clean with ghc
6.4 as well.
--
David Roundy
http://www.darcs.net
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Linus Torvalds @ 2005-04-25 14:52 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <426CD1F1.2010101@tiscali.de>
On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
> The "git" didn't try store small variables, which aren't referenced, in
> the processor registers. It also didn't use the size_t type. I corrected
> a C++ style comment too.
What kind of ancient C standard are you working against?
// isn't "C++" any more, and "register" variables are sooo 60's, man.
Pass the toke,
Linus
^ permalink raw reply
* Re: A darcs that can pull from git
From: Juliusz Chroboczek @ 2005-04-25 15:12 UTC (permalink / raw)
To: darcs-devel, Git Mailing List
In-Reply-To: <20050425133116.GG11667@abridgegame.org>
>> http://www.pps.jussieu.fr/~jch/software/files/darcs-git-20050424.darcs
> First off, you need to include a license header in the git files indicating
> that unlike the rest of darcs, they may only be distributed under GPL v2.
Linus, could you please suggest a suitable license statement to
include in whichever files of yours we choose to include in Darcs? Is
David's suggestion (stock GPL boilerplate with ``or any later
version'' removed) okay with you?
> Any chance you can host a gettable repository?
The last tag in darcs-unstable is 1.0.0rc2, which prevents me from
publishing a partial repository in my web space. Perhaps you could
pull a recent tag into darcs-unstable?
> If not, I'd be happy to give you an account on darcs.net on which
> you could host darcs-git.
That would be great (let me know if you need an ssh public key).
> Do you have any plans/ideas for allowing pulls directly from a
> remote git repository?
I haven't thought about it yet. Does anyone have any ideas about how
to efficiently pull from git without a complete local copy?
I'll reply to the more technical points below on darcs-devel -- no
point in spamming the kind folks on git@ any further, especially as
they probably know about
http://www.abridgegame.org/pipermail/darcs-devel/
Juliusz
^ permalink raw reply
* Re: [FILE] GNU BIT
From: Daniel Barkalow @ 2005-04-25 15:37 UTC (permalink / raw)
To: Andreas Gal; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504242308460.6454@sam.ics.uci.edu>
On Sun, 24 Apr 2005, Andreas Gal wrote:
> http-pull -a `cat .git/HEAD` \
> http://nil.ics.uci.edu/~gal/public/bit
Don't forget the slash at the end... (one of us should probably fix that
at some point; just stick a slash at the end of any URL without one)
Also, it has become customary to have URLs like .../public/bit.git/, since
the contents match a .git directory.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> @ 2005-04-25 15:47 UTC (permalink / raw)
To: Matt Domsch, David A. Wheeler, Paul Jakma, Linus Torvalds, Sean,
Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <3X1G1-7ug-9@gated-at.bofh.it>
Matt Domsch <Matt_Domsch@dell.com> wrote:
> --------------
> sign
> gpg --armor --clearsign --detach-sign --default-key "${DEFAULT_KEY} -v -v -o -
> ${1} | \ ${CUTSIG} > ${1}.sign
Use quotes!
> exit 0
The exit code should reflect the status from gpg.
If gpg failed, you might also want to remove the .sign file.
--
Top 100 things you don't want the sysadmin to say:
37. What is all this I here about static charges destroying computers?
^ permalink raw reply
* Re: unseeking?
From: Zack Brown @ 2005-04-25 16:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504241742070.30848-100000@iabervon.org>
Hi,
Thanks for all the help!
On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:
> > but I still don't see its significance. What do you get from a fork that
> > you don't get from a regular old init and pull?
>
> Primarily, the ability to inspect and build the mainline tree. If you want
> to take a look at what's going on in the mainline without getting it again
> or messing with your working directory or local commits, you can do that.
OK, I think I understand this so far. So, suppose I want to contribute to
cogito. I would first do a git init on Pasky's cogito tree, to get it on my home
system. This would be my home base, and whenever I wanted to do some work on the
current state of his tree, I would fork off another branch.
So, I want to do this. From inside cogito's root directory, I give the command
git fork mycogito ../mycogito
and ../mycogito is created. In this new directory, the .git directory
contains only symlinks to ../cogito/HEAD, ../cogito/heads, ../cogito/objects,
../cogito/remotes, and ../cogito/tags, and an index file.
Question: when I make changes to mycogito and commit them, is only the index
file in .git/ altered, or are my changes reflected in the cogito/ directory as
well? If I do another fork of cogito, will I see mycogito's changes in the new
fork?
So moving on, I now have this mycogito tree. But I don't do any edits yet. I
just poke around for awhile, reading files. Finally I realize that there have
probably been updates to the upstream sources, and I want to pull those in
before I start my work. So, as I would do in the cogito directory, I give the
command
git pull pasky; git pull linus
this works fine. There are no new updates to be had, and git tells me my tree is
uptodate.
so now I start work. I run aspell on the README file, and it catches some
typos. I fix them and save the file but don't yet commit it. Now mycogito
has some changes that I would ultimately like to push up to Pasky.
Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
directory and post the results to the git list?
Suppose I want to keep working, changing more stuff in mycogito, but I also want
to make sure that mycogito tracks the upstream sources.
Would I just do
git pull pasky; git pull linus
and give that command whenever I wanted to grab the latest changes? What would
happen if there were upstream conflicts with my work on mycogito?
Or do I have that wrong. Instead of a pull, would I now only do
git merge pasky; git merge linus
and give that command to bring the upstream changes into mycogito?
Basically, once I'm editing files in mycogito, what commands to I give to bring
mycogito uptodate WRT the upstream sources? When I'm finally ready, and all my
changes have been committed into mycogito, what command do I give to produce a
patch to send to the git list?
Be well,
Zack
>
> Also, if you're doing two independant sets of edits, you can share the
> downloads for updates between them. Say I'm working on an ambitious
> project to do block-move cross-file merges in git. I've got a fork that
> I'm working on that in. After I've done a bunch of work there, I notice a
> bug report about some of my other code in the project. I fork off another
> branch from the mainline to fix it in, so that I can ignore the fact that
> I'm a dozen commits into this other thing, fix the bug, and ship off the
> changes.
>
> With fork, I save having to download the contents of the remote repository
> again, because the object storage is shared. Also, I can merge my bug
> fixes into my long-term work without waiting for them to show up in the
> mainline (although that makes the later merge potentially trickier) or, in
> general, needing to transfer them between repositories.
>
> The other main thing is the way that I actually split up patches. I have a
> fork of the mainline. I make a second fork of the mainline. I diff
> "second:first" to get the changes I need to split up, apply some of them,
> commit, and then repeat. In order to diff "second:first", both have to be
> stored in the same repository (because, otherwise, git won't be able to
> find one or the other commit to look at). In the first iteration, when
> second is mainline, it doesn't matter, but in later iterations I want to
> get fewer and fewer changes to include or postpone, which requires using
> commits from the splitting process.
>
> -Daniel
> *This .sig left intentionally blank*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Zack Brown
^ permalink raw reply
* [PATCH] Don't fail in http-pull if URL is missing a '/' at the end
From: Andreas Gal @ 2005-04-25 16:21 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <E1DQ5nn-0003au-QN@be1.7eggert.dyndns.org>
http-pull fails if the URL doesn't end with a '/'. This patch adds one if
needed.
Signed-off-by: Andreas Gal <gal@uci.edu>
--- http-pull.c 2005-04-25 09:15:45.000000000 -0700
+++ /home/gal/src/git/git-bit/http-pull.c 2005-04-25 09:09:54.000000000 -0700
@@ -76,6 +76,8 @@
url = malloc(strlen(base) + 50);
strcpy(url, base);
posn = url + strlen(base);
+ if (posn[-1] != '/')
+ *posn++ = '/';
strcpy(posn, "objects/");
posn += 8;
memcpy(posn, hex, 2);
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 16:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0504250751330.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
>>The "git" didn't try store small variables, which aren't referenced, in
>>the processor registers. It also didn't use the size_t type. I corrected
>>a C++ style comment too.
>
>
> What kind of ancient C standard are you working against?
>
> // isn't "C++" any more, and "register" variables are sooo 60's, man.
>
> Pass the toke,
>
> Linus
>
"register" and "auto" variables aren't relicts of the 60's, they're a
part of the ISO-C 99 standard, I'm following, "man".
And if you think "register" variables are outdated, please remove the
CONFIG_REGPARM option from the Kernel source.
Removing a "//" comment makes sense in this case because a "//" comment
between hundrets of "/* */" comments looks extremly ugly and shows that
the source is "patchworked" and unstructured.
Today a lot of people forget about the basic rules of coding. You too. :)
Matthias-Christian Ott
Literature:
[1] Dr.-Ing. Ludwig Claßen, Dipl.-Math. Ulrich Oefler: Unix und C: Ein
Anwenderbuch; VEB Verlag Technik Berlin; 1990
[2] Erik de Castro Lopo, Peter Aitken, Bradley L. Jones: Teach Yourself
C for Linux Programming in 21 Days; SAMS Publishing; 1999
^ permalink raw reply
* Re: [patch] fixup GECOS handling
From: Kyle Hayes @ 2005-04-25 17:02 UTC (permalink / raw)
To: Andy Isaacson; +Cc: azarah, git
In-Reply-To: <20050422233012.GA27638@hexapodia.org>
On Fri, 2005-04-22 at 16:30 -0700, Andy Isaacson wrote:
> On Fri, Apr 22, 2005 at 09:16:39AM -0700, Kyle Hayes wrote:
> > if(comma)
> > if(semi)
> > /* lastname, firstname; room #; phone # format */
> > *semi = 0;
> > else
> > *comma = 0;
> > else if(semi)
> > *semi = 0;
>
> That's a really complicated way of writing
>
> if(semi) *semi = 0;
> else if(comma) *comma = 0;
>
> (The two code fragments are precisely identical. Mmmm, strength
> reduction.)
Indeed :-)
As someone else noted, this was too complex. As another person noted,
this (like the SHA1 thread) has been thrashed around more than enough.
Best,
Kyle
--
Kyle Hayes <kyle@marchex.com>
Marchex Inc.
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Jan-Benedict Glaw @ 2005-04-25 17:12 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426D21FE.3040401@tiscali.de>
On Mon, 2005-04-25 18:59:42 +0200, Matthias-Christian Ott <matthias.christian@tiscali.de> wrote:
["register" variables]
> Literature:
> [2] Erik de Castro Lopo, Peter Aitken, Bradley L. Jones: Teach Yourself
> C for Linux Programming in 21 Days; SAMS Publishing; 1999
Yeah, "register" is what you use after 21 days of programming
pracitce...
SCNR, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Thomas Glanzmann @ 2005-04-25 17:13 UTC (permalink / raw)
To: git, Linux Kernel Mailing List; +Cc: Matthias-Christian Ott, Linus Torvalds
In-Reply-To: <20050425171234.GP24187@lug-owl.de>
Hello,
> Yeah, "register" is what you use after 21 days of programming
> pracitce...
actually it is introduced on day 2.
Thomas
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Linus Torvalds @ 2005-04-25 17:23 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <426D21FE.3040401@tiscali.de>
On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
> "register" and "auto" variables aren't relicts of the 60's, they're a
> part of the ISO-C 99 standard, I'm following, "man".
They _are_ relicts of the 60's. It's just that the C standard hasn't ever
had the reason to remove them.
> And if you think "register" variables are outdated, please remove the
> CONFIG_REGPARM option from the Kernel source.
That does something totally different. And doesn't use "register" at all.
Pass the toke, you've been hogging the drugs for way too long.
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