* [PATCH 6/8] Builtin git-apply.
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <11483865361243-git-send-email-1>
From: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
104e34d8d562584d212f141b7ce736d47016b60a
Makefile | 8 +++++---
apply.c => builtin-apply.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 10 insertions(+), 5 deletions(-)
rename apply.c => builtin-apply.c (100%)
104e34d8d562584d212f141b7ce736d47016b60a
diff --git a/Makefile b/Makefile
index a5efbc7..eeb4fdb 100644
--- a/Makefile
+++ b/Makefile
@@ -149,7 +149,7 @@ SIMPLE_PROGRAMS = \
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
- git-apply$X git-cat-file$X \
+ git-cat-file$X \
git-checkout-index$X git-clone-pack$X \
git-convert-objects$X git-diff-files$X \
git-diff-index$X git-diff-stages$X \
@@ -172,7 +172,8 @@ BUILT_INS = git-log$X git-whatchanged$X
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-rev-list$X git-check-ref-format$X \
git-init-db$X git-ls-files$X git-ls-tree$X \
- git-tar-tree$X git-read-tree$X git-commit-tree$X
+ git-tar-tree$X git-read-tree$X git-commit-tree$X \
+ git-apply$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -222,7 +223,8 @@ BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
builtin-init-db.o builtin-ls-files.o builtin-ls-tree.o \
- builtin-tar-tree.o builtin-read-tree.o builtin-commit-tree.o
+ builtin-tar-tree.o builtin-read-tree.o builtin-commit-tree.o \
+ builtin-apply.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/apply.c b/builtin-apply.c
similarity index 100%
rename from apply.c
rename to builtin-apply.c
index 0ed9d13..4056b9d 100644
--- a/apply.c
+++ b/builtin-apply.c
@@ -11,6 +11,7 @@ #include "cache.h"
#include "quote.h"
#include "blob.h"
#include "delta.h"
+#include "builtin.h"
// --check turns on checking that the working tree matches the
// files that are being modified, but doesn't apply the patch
@@ -2151,7 +2152,7 @@ static int git_apply_config(const char *
}
-int main(int argc, char **argv)
+int cmd_apply(int argc, const char **argv, char **envp)
{
int i;
int read_stdin = 1;
diff --git a/builtin.h b/builtin.h
index c6b07d9..d6ff88e 100644
--- a/builtin.h
+++ b/builtin.h
@@ -32,5 +32,6 @@ extern int cmd_ls_tree(int argc, const c
extern int cmd_tar_tree(int argc, const char **argv, char **envp);
extern int cmd_read_tree(int argc, const char **argv, char **envp);
extern int cmd_commit_tree(int argc, const char **argv, char **envp);
+extern int cmd_apply(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 4c2c062..f44e08b 100644
--- a/git.c
+++ b/git.c
@@ -57,7 +57,8 @@ static void handle_internal_command(int
{ "ls-tree", cmd_ls_tree },
{ "tar-tree", cmd_tar_tree },
{ "read-tree", cmd_read_tree },
- { "commit-tree", cmd_commit_tree }
+ { "commit-tree", cmd_commit_tree },
+ { "apply", cmd_apply }
};
int i;
--
1.3.3.g288c
^ permalink raw reply related
* [PATCH 7/8] Builtin git-show-branch.
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <11483865361243-git-send-email-1>
From: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
d0d1cfb7985fa90442e423a55ca23e6bc83f912d
Makefile | 6 +++---
show-branch.c => builtin-show-branch.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 8 insertions(+), 5 deletions(-)
rename show-branch.c => builtin-show-branch.c (100%)
d0d1cfb7985fa90442e423a55ca23e6bc83f912d
diff --git a/Makefile b/Makefile
index eeb4fdb..b438a90 100644
--- a/Makefile
+++ b/Makefile
@@ -159,7 +159,7 @@ PROGRAMS = \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
git-peek-remote$X git-prune-packed$X \
git-receive-pack$X git-rev-parse$X \
- git-send-pack$X git-show-branch$X git-shell$X \
+ git-send-pack$X git-shell$X \
git-show-index$X git-ssh-fetch$X \
git-ssh-upload$X git-unpack-file$X \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
@@ -173,7 +173,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-grep$X git-rev-list$X git-check-ref-format$X \
git-init-db$X git-ls-files$X git-ls-tree$X \
git-tar-tree$X git-read-tree$X git-commit-tree$X \
- git-apply$X
+ git-apply$X git-show-branch$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -224,7 +224,7 @@ BUILTIN_OBJS = \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
builtin-init-db.o builtin-ls-files.o builtin-ls-tree.o \
builtin-tar-tree.o builtin-read-tree.o builtin-commit-tree.o \
- builtin-apply.o
+ builtin-apply.o builtin-show-branch.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/show-branch.c b/builtin-show-branch.c
similarity index 100%
rename from show-branch.c
rename to builtin-show-branch.c
index 268c57b..d1be8bb 100644
--- a/show-branch.c
+++ b/builtin-show-branch.c
@@ -3,6 +3,7 @@ #include <fnmatch.h>
#include "cache.h"
#include "commit.h"
#include "refs.h"
+#include "builtin.h"
static const char show_branch_usage[] =
"git-show-branch [--dense] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
@@ -548,7 +549,7 @@ static int omit_in_dense(struct commit *
return 0;
}
-int main(int ac, char **av)
+int cmd_show_branch(int ac, const char **av, char **envp)
{
struct commit *rev[MAX_REVS], *commit;
struct commit_list *list = NULL, *seen = NULL;
diff --git a/builtin.h b/builtin.h
index d6ff88e..01882ec 100644
--- a/builtin.h
+++ b/builtin.h
@@ -33,5 +33,6 @@ extern int cmd_tar_tree(int argc, const
extern int cmd_read_tree(int argc, const char **argv, char **envp);
extern int cmd_commit_tree(int argc, const char **argv, char **envp);
extern int cmd_apply(int argc, const char **argv, char **envp);
+extern int cmd_show_branch(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index f44e08b..d29505c 100644
--- a/git.c
+++ b/git.c
@@ -58,7 +58,8 @@ static void handle_internal_command(int
{ "tar-tree", cmd_tar_tree },
{ "read-tree", cmd_read_tree },
{ "commit-tree", cmd_commit_tree },
- { "apply", cmd_apply }
+ { "apply", cmd_apply },
+ { "show-branch", cmd_show_branch }
};
int i;
--
1.3.3.g288c
^ permalink raw reply related
* [PATCH 4/8] Builtin git-read-tree.
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <11483865361243-git-send-email-1>
From: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
baba8c18d8a5fff876d16a434b49677cd3ebbdb0
Makefile | 6 +++---
read-tree.c => builtin-read-tree.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 8 insertions(+), 5 deletions(-)
rename read-tree.c => builtin-read-tree.c (100%)
baba8c18d8a5fff876d16a434b49677cd3ebbdb0
diff --git a/Makefile b/Makefile
index 966f7ee..667fa5d 100644
--- a/Makefile
+++ b/Makefile
@@ -157,7 +157,7 @@ PROGRAMS = \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-mailinfo$X git-merge-base$X \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
- git-peek-remote$X git-prune-packed$X git-read-tree$X \
+ git-peek-remote$X git-prune-packed$X \
git-receive-pack$X git-rev-parse$X \
git-send-pack$X git-show-branch$X git-shell$X \
git-show-index$X git-ssh-fetch$X \
@@ -172,7 +172,7 @@ BUILT_INS = git-log$X git-whatchanged$X
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-rev-list$X git-check-ref-format$X \
git-init-db$X git-ls-files$X git-ls-tree$X \
- git-tar-tree$X
+ git-tar-tree$X git-read-tree$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -222,7 +222,7 @@ BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
builtin-init-db.o builtin-ls-files.o builtin-ls-tree.o \
- builtin-tar-tree.o
+ builtin-tar-tree.o builtin-read-tree.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/read-tree.c b/builtin-read-tree.c
similarity index 100%
rename from read-tree.c
rename to builtin-read-tree.c
index 82e2a9a..ec40d01 100644
--- a/read-tree.c
+++ b/builtin-read-tree.c
@@ -11,6 +11,7 @@ #include "object.h"
#include "tree.h"
#include <sys/time.h>
#include <signal.h>
+#include "builtin.h"
static int reset = 0;
static int merge = 0;
@@ -763,7 +764,7 @@ static const char read_tree_usage[] = "g
static struct cache_file cache_file;
-int main(int argc, char **argv)
+int cmd_read_tree(int argc, const char **argv, char **envp)
{
int i, newfd, stage = 0;
unsigned char sha1[20];
diff --git a/builtin.h b/builtin.h
index d210543..88b3523 100644
--- a/builtin.h
+++ b/builtin.h
@@ -30,5 +30,6 @@ extern int cmd_init_db(int argc, const c
extern int cmd_ls_files(int argc, const char **argv, char **envp);
extern int cmd_ls_tree(int argc, const char **argv, char **envp);
extern int cmd_tar_tree(int argc, const char **argv, char **envp);
+extern int cmd_read_tree(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index c253e60..300e2b2 100644
--- a/git.c
+++ b/git.c
@@ -55,7 +55,8 @@ static void handle_internal_command(int
{ "check-ref-format", cmd_check_ref_format },
{ "ls-files", cmd_ls_files },
{ "ls-tree", cmd_ls_tree },
- { "tar-tree", cmd_tar_tree }
+ { "tar-tree", cmd_tar_tree },
+ { "read-tree", cmd_read_tree }
};
int i;
--
1.3.3.g288c
^ permalink raw reply related
* [PATCH 1/8] Builtin git-ls-files.
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <11483865361243-git-send-email-1>
From: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
bc0dc50a3e9208011a39adc653e3463aa3ab4886
Makefile | 6 +++---
ls-files.c => builtin-ls-files.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 8 insertions(+), 5 deletions(-)
rename ls-files.c => builtin-ls-files.c (100%)
bc0dc50a3e9208011a39adc653e3463aa3ab4886
diff --git a/Makefile b/Makefile
index efe6b12..e522730 100644
--- a/Makefile
+++ b/Makefile
@@ -155,7 +155,7 @@ PROGRAMS = \
git-diff-index$X git-diff-stages$X \
git-diff-tree$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
- git-ls-files$X git-ls-tree$X git-mailinfo$X git-merge-base$X \
+ git-ls-tree$X git-mailinfo$X git-merge-base$X \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
git-peek-remote$X git-prune-packed$X git-read-tree$X \
git-receive-pack$X git-rev-parse$X \
@@ -171,7 +171,7 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-rev-list$X git-check-ref-format$X \
- git-init-db$X
+ git-init-db$X git-ls-files$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -220,7 +220,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
- builtin-init-db.o
+ builtin-init-db.o builtin-ls-files.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/ls-files.c b/builtin-ls-files.c
similarity index 100%
rename from ls-files.c
rename to builtin-ls-files.c
index 4a4af1c..3a0c5f2 100644
--- a/ls-files.c
+++ b/builtin-ls-files.c
@@ -10,6 +10,7 @@ #include <fnmatch.h>
#include "cache.h"
#include "quote.h"
+#include "builtin.h"
static int abbrev = 0;
static int show_deleted = 0;
@@ -648,7 +649,7 @@ static const char ls_files_usage[] =
"[ --exclude-per-directory=<filename> ] [--full-name] [--abbrev] "
"[--] [<file>]*";
-int main(int argc, const char **argv)
+int cmd_ls_files(int argc, const char **argv, char** envp)
{
int i;
int exc_given = 0;
diff --git a/builtin.h b/builtin.h
index 6054126..a0713d3 100644
--- a/builtin.h
+++ b/builtin.h
@@ -27,5 +27,6 @@ extern int cmd_grep(int argc, const char
extern int cmd_rev_list(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
extern int cmd_init_db(int argc, const char **argv, char **envp);
+extern int cmd_ls_files(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 3216d31..9cfa9eb 100644
--- a/git.c
+++ b/git.c
@@ -52,7 +52,8 @@ static void handle_internal_command(int
{ "grep", cmd_grep },
{ "rev-list", cmd_rev_list },
{ "init-db", cmd_init_db },
- { "check-ref-format", cmd_check_ref_format }
+ { "check-ref-format", cmd_check_ref_format },
+ { "ls-files", cmd_ls_files }
};
int i;
--
1.3.3.g288c
^ permalink raw reply related
* Make more commands builtin
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git
Makefile | 26 +++++++++++++++-----------
apply.c => builtin-apply.c | 3 ++-
commit-tree.c => builtin-commit-tree.c | 3 ++-
diff-files.c => builtin-diff-files.c | 3 ++-
diff-index.c => builtin-diff-index.c | 3 ++-
diff-stages.c => builtin-diff-stages.c | 3 ++-
diff-tree.c => builtin-diff-tree.c | 3 ++-
ls-files.c => builtin-ls-files.c | 3 ++-
ls-tree.c => builtin-ls-tree.c | 3 ++-
read-tree.c => builtin-read-tree.c | 3 ++-
show-branch.c => builtin-show-branch.c | 3 ++-
tar-tree.c => builtin-tar-tree.c | 3 ++-
builtin.h | 12 ++++++++++++
git.c | 13 ++++++++++++-
14 files changed, 61 insertions(+), 23 deletions(-)
Junio, I've formatted this batch of patches with -M, so
they are easier to read. It seems there were some problems
with sending the last batch (patch 1 and 6 hasn't arrived),
but this should work, since I tested it by sending the
batch to myself first.
Sorry for the noise.
Regards,
Peter Eriksen
^ permalink raw reply
* [PATCH 3/8] Builtin git-tar-tree.
From: Peter Eriksen @ 2006-05-23 12:15 UTC (permalink / raw)
To: git; +Cc: Peter Eriksen
In-Reply-To: <11483865361243-git-send-email-1>
From: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
9860ed2d4a598ad100c3b4f6b07dd0a88a4547a6
Makefile | 8 +++++---
tar-tree.c => builtin-tar-tree.c | 3 ++-
builtin.h | 1 +
git.c | 3 ++-
4 files changed, 10 insertions(+), 5 deletions(-)
rename tar-tree.c => builtin-tar-tree.c (99%)
9860ed2d4a598ad100c3b4f6b07dd0a88a4547a6
diff --git a/Makefile b/Makefile
index 9b02264..966f7ee 100644
--- a/Makefile
+++ b/Makefile
@@ -161,7 +161,7 @@ PROGRAMS = \
git-receive-pack$X git-rev-parse$X \
git-send-pack$X git-show-branch$X git-shell$X \
git-show-index$X git-ssh-fetch$X \
- git-ssh-upload$X git-tar-tree$X git-unpack-file$X \
+ git-ssh-upload$X git-unpack-file$X \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X \
@@ -171,7 +171,8 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
git-grep$X git-rev-list$X git-check-ref-format$X \
- git-init-db$X git-ls-files$X git-ls-tree$X
+ git-init-db$X git-ls-files$X git-ls-tree$X \
+ git-tar-tree$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -220,7 +221,8 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
- builtin-init-db.o builtin-ls-files.o builtin-ls-tree.o
+ builtin-init-db.o builtin-ls-files.o builtin-ls-tree.o \
+ builtin-tar-tree.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/tar-tree.c b/builtin-tar-tree.c
similarity index 99%
rename from tar-tree.c
rename to builtin-tar-tree.c
index 3308736..6ada04c 100644
--- a/tar-tree.c
+++ b/builtin-tar-tree.c
@@ -7,6 +7,7 @@ #include "tree-walk.h"
#include "commit.h"
#include "strbuf.h"
#include "tar.h"
+#include "builtin.h"
#define RECORDSIZE (512)
#define BLOCKSIZE (RECORDSIZE * 20)
@@ -301,7 +302,7 @@ static void traverse_tree(struct tree_de
}
}
-int main(int argc, char **argv)
+int cmd_tar_tree(int argc, const char **argv, char** envp)
{
unsigned char sha1[20], tree_sha1[20];
struct commit *commit;
diff --git a/builtin.h b/builtin.h
index 951f206..d210543 100644
--- a/builtin.h
+++ b/builtin.h
@@ -29,5 +29,6 @@ extern int cmd_check_ref_format(int argc
extern int cmd_init_db(int argc, const char **argv, char **envp);
extern int cmd_ls_files(int argc, const char **argv, char **envp);
extern int cmd_ls_tree(int argc, const char **argv, char **envp);
+extern int cmd_tar_tree(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 8574775..c253e60 100644
--- a/git.c
+++ b/git.c
@@ -54,7 +54,8 @@ static void handle_internal_command(int
{ "init-db", cmd_init_db },
{ "check-ref-format", cmd_check_ref_format },
{ "ls-files", cmd_ls_files },
- { "ls-tree", cmd_ls_tree }
+ { "ls-tree", cmd_ls_tree },
+ { "tar-tree", cmd_tar_tree }
};
int i;
--
1.3.3.g288c
^ permalink raw reply related
* Re: Make more commands builtin
From: Peter Eriksen @ 2006-05-23 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <11483865361243-git-send-email-1>
Btw.
I used these commands to produce the patch series:
git diff --stat -C 24b65a30015aedd..pe/builtin
git-send-email --no-chain-reply-to --compose \
--from=s022018@student.dtu.dk --not-signed-off-by-cc \
--quiet \
--subject="Make more commands builtin" \
--to=git@vger.kernel.org Patches/*
Is this a reasonable way to do it?
Peter
^ permalink raw reply
* Re: Make more commands builtin
From: Jakub Narebski @ 2006-05-23 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060523122056.GA5777@bohr.gbar.dtu.dk>
Peter Eriksen wrote:
> Btw.
>
> I used these commands to produce the patch series:
>
> git diff --stat -C 24b65a30015aedd..pe/builtin
> git-send-email --no-chain-reply-to --compose \
> --from=s022018@student.dtu.dk --not-signed-off-by-cc \
> --quiet \
> --subject="Make more commands builtin" \
> --to=git@vger.kernel.org Patches/*
I wonder why the patches themselves are not replies to the main/summary
email, i.e. "Make more commands builtin" email...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Make more commands builtin
From: Peter Eriksen @ 2006-05-23 12:54 UTC (permalink / raw)
To: git
In-Reply-To: <e4uvku$o28$1@sea.gmane.org>
On Tue, May 23, 2006 at 02:36:54PM +0200, Jakub Narebski wrote:
> Peter Eriksen wrote:
>
> > Btw.
> >
> > I used these commands to produce the patch series:
> >
> > git diff --stat -C 24b65a30015aedd..pe/builtin
> > git-send-email --no-chain-reply-to --compose \
> > --from=s022018@student.dtu.dk --not-signed-off-by-cc \
> > --quiet \
> > --subject="Make more commands builtin" \
> > --to=git@vger.kernel.org Patches/*
>
> I wonder why the patches themselves are not replies to the main/summary
> email, i.e. "Make more commands builtin" email...
It seems thay are:
Subject: Make more commands builtin
Message-Id: <11483865361243-git-send-email-1>
Subject: [PATCH 1/8] Builtin git-ls-files.
Message-Id: <11483865362613-git-send-email-1>
In-Reply-To: <11483865361243-git-send-email-1>
Subject: [PATCH 2/8] Builtin git-ls-tree.
Message-Id: <11483865362923-git-send-email-1>
In-Reply-To: <11483865361243-git-send-email-1>
Peter
^ permalink raw reply
* Re: Make more commands builtin
From: Jakub Narebski @ 2006-05-23 13:05 UTC (permalink / raw)
To: git
In-Reply-To: <20060523125400.GA11128@bohr.gbar.dtu.dk>
Peter Eriksen wrote:
> On Tue, May 23, 2006 at 02:36:54PM +0200, Jakub Narebski wrote:
>> Peter Eriksen wrote:
>>
>> > Btw.
>> >
>> > I used these commands to produce the patch series:
>> >
>> > git diff --stat -C 24b65a30015aedd..pe/builtin
>> > git-send-email --no-chain-reply-to --compose \
>> > --from=s022018@student.dtu.dk --not-signed-off-by-cc \
>> > --quiet \
>> > --subject="Make more commands builtin" \
>> > --to=git@vger.kernel.org Patches/*
>>
>> I wonder why the patches themselves are not replies to the main/summary
>> email, i.e. "Make more commands builtin" email...
>
> It seems thay are:
>
> Subject: Make more commands builtin
> Message-Id: <11483865361243-git-send-email-1>
>
> Subject: [PATCH 1/8] Builtin git-ls-files.
> Message-Id: <11483865362613-git-send-email-1>
> In-Reply-To: <11483865361243-git-send-email-1>
Ahh... I'm reading git mailing list through GMane NNTP interface.
It would be nice if git-send-email added 'References:' Usenet/news
header in addition to email one 'In-Reply-To:'.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git status: ignore empty directories (because they cannot be added)
From: Matthias Lederhofer @ 2006-05-23 14:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5e56yi6.fsf@assigned-by-dhcp.cox.net>
> > Well, anyway, here the reasons for this patch:
> > - Working in a git repository with a lot of empty directories is
> > annoying, because all of them show up in git status even though they
> > cannot be added. With --no-empty-directories they are hidden.
>
> What directories are they? Will they some day have files that
> you might want to keep track of? The reason for this question
> is, "otherwise you could .gitignore them".
I have been trying ruby on rails and there are some empty directories
which will have files later. I would even add those empty directories
if it would be possible.
> > - If there is a directory which may be added because it is quite
> > useful to have the -u option to see what is in there to add (without
> > using ls path/to/directory).
>
> It really depends on how many files there are in such a
> "interesting" directory _and_ other "uninteresting" directories
> full of transitory files. The -u option that disables "skip
> contents and show only the top directory" behaviour globally
> might not be so useful in such a case -- you will see useful
> contents of an otherwise "closed" directory (because it defeats
> the --directory flag), but at the same time you would get tons
> of uninteresting files in another directory as well in such a
> case. You are likely to end up doing ls path/to/dir after
> noticing that there are non-empty foo/ and bar/ directories that
> have no tracked files, and you know which one has files
> interesting to you.
> So I am OK with the change, but I am somewhat still doubtful how
> useful the option would be.
The case I think about is that there are some directories which are
not tracked because they contain no files yet. All other directories
which are uninteresting are added to .gitignore. If an untracked
directory shows up in git-status one could easily check with
git-status -u what can be added.
PS: I had a typo in the git mailing list e-mail address and resent my
last e-mail to the list. Your reply did not make it to the list,
perhaps you can send it again.
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-23 14:53 UTC (permalink / raw)
To: Jason Riedy; +Cc: Stefan Pfetzing, Git Mailing List
In-Reply-To: <8157.1148359875@lotus.CS.Berkeley.EDU>
On Mon, 22 May 2006, Jason Riedy wrote:
> And "Stefan Pfetzing" writes:
> - printf ("access: %d\n", access("/etc/motd", X_OK));
> [...]
> - will return 0 on solaris - when run as root, even though /etc/motd
> - is not executeable.
>
> This is explicitly allowed by the SUS, even for non-root:
What kind of CRAP has Solaris become?
Yes, it's allowed. That doesn't mean that a quality implementation should
do it.
SunOS used to be the best system around - it was, compared to others,
_nice_ to work with. It wasn't about what was "allowed by the standards",
that was the HP-SUX and AIX's excuses. It was the highest-quality
implementation.
Now, Solaris had some serious problems early on (yes, I was there when
they switched, and yes, I hated it), but I thought they had fixed their
stuff long long ago.
Have Sun people forgotten the difference between "quality" and "crap that
passes standards tests"?
Not doing a reasonable job on "access()" is a joke. It's like VMS being
"posix". Sure, it's the letter of the law, but it's still not _unix_.
Btw, even SuS says:
"The sentence concerning appropriate privileges and execute permission
bits reflects the two possibilities implemented by historical
implementations when checking superuser access for X_OK.
New implementations are discouraged from returning X_OK unless at
least one execution permission bit is set."
which clearly says "Solaris is CRAP" to me.
What the heck is going on? First the totally broken stdio that doesn't
retry on EINTR, now access(). And these people think they can compete?
Somebody hit some Solaris engineers with a 2x4 clue-stick, please.
Linus
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Edgar Toernig @ 2006-05-23 15:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jason Riedy, Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605230744350.5623@g5.osdl.org>
Linus Torvalds wrote:
>
> > - printf ("access: %d\n", access("/etc/motd", X_OK));
> > [...]
> > - will return 0 on solaris - when run as root, even though /etc/motd
> > - is not executeable.
> >
> > This is explicitly allowed by the SUS, even for non-root:
>
> New implementations are discouraged from returning X_OK unless at
> least one execution permission bit is set."
>
> which clearly says "Solaris is CRAP" to me.
Just for the record: firefox's download manager performs exactly this
test to decide whether you can 'open with' a file (pretty silly because
the test is done on the freshly downloaded file in the temp dir which
never has an x-bit set). But I was hit by this effect on my system
which is - surprise surprise - Linux :-) Ok, it's a pretty old one
with a 2.0 kernel and libc 5. But nevertheless, access(2) is not the
right function to portably test the x-bit.
Ciao, ET.
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-23 15:31 UTC (permalink / raw)
To: Edgar Toernig; +Cc: Jason Riedy, Stefan Pfetzing, Git Mailing List
In-Reply-To: <20060523172053.60ec1145.froese@gmx.de>
On Tue, 23 May 2006, Edgar Toernig wrote:
>
> But I was hit by this effect on my system which is - surprise surprise -
> Linux :-) Ok, it's a pretty old one with a 2.0 kernel and libc 5.
Yes, we've had that bug too, and yes, I was hit by a clue-stick, and still
have the bruise. That's how you teach people.
[ And how the heck does anybody still run 2.0, btw? ]
Linus
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Theodore Tso @ 2006-05-23 15:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <Pine.LNX.4.64.0605221926270.3697@g5.osdl.org>
On Mon, May 22, 2006 at 07:28:37PM -0700, Linus Torvalds wrote:
>
>
> This stupid patch on top of yours seems to make git happier. It's
> disgusting, I know, but it just repacks things every kilo-commit.
>
> I actually think that I found a real ext3 performance bug from trying to
> determine why git sometimes slows down ridiculously when the tree has been
> allowed to go too long without a repack.
Do you have dir_index (the hashed btree) feature enabled by any chance?
- Ted
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Linus Torvalds @ 2006-05-23 16:05 UTC (permalink / raw)
To: Theodore Tso
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <20060523153636.GA21506@thunk.org>
On Tue, 23 May 2006, Theodore Tso wrote:
> On Mon, May 22, 2006 at 07:28:37PM -0700, Linus Torvalds wrote:
> >
> > I actually think that I found a real ext3 performance bug from trying to
> > determine why git sometimes slows down ridiculously when the tree has been
> > allowed to go too long without a repack.
>
> Do you have dir_index (the hashed btree) feature enabled by any chance?
No, and I know I probably should, since it would hopefully help git usage.
But my problem actually happens even with moderately sized directories:
they were just 40kB or so in size, and the problem isn't high system CPU
usage, but tons of extra IO. I ran things on a machine with 2GB of RAM,
and as far as I could tell, the working set _should_ have fit into memory,
but CPU utilization was consistently in the 1% range.
Now, it's possible that I'm just wrong, and it really didn't fit in
memory, but I I _suspect_ that the issue is that ext3 directory handling
still uses the "buffer_head" thing rather than the page cache, and that we
simply don't LRU the memory appropriately so we don't let the memory
pressure expand the buffer cache.
Now, using buffer cache in this day and age is insane and horrible
(there's a reason I suspect the LRU doesn't work that well: the buffer
heads aren't supposed to be used as a cache, and people are supposed to
use the page cache for it these days), but Andrew tells me that the whole
JBD thing basically requires it. Whatever.
Now, repacking obviously hides it entirely (because then the load becomes
entirely a page-cache load, and the kernel does _that_ beautifully), but
I'm a bit bummed that I think I hit an ext3 braindamage.
So an unpacked git archive on ext3 (but not ext2, I believe: ext2 should
use the page cache for directories) ends up being very buffer-cache
intensive. And the buffer cache is basically deprecated..
Linus
PS. I'll see if I can figure out the problem, and maybe the good news is
that I'll be able to just fix a real kernel performance issue. Still,
there's a _reason_ we tried to get away from the buffer heads as a caching
entity..
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Linus Torvalds @ 2006-05-23 16:25 UTC (permalink / raw)
To: Theodore Tso
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <Pine.LNX.4.64.0605230848060.5623@g5.osdl.org>
On Tue, 23 May 2006, Linus Torvalds wrote:
>
> So an unpacked git archive on ext3 (but not ext2, I believe: ext2 should
> use the page cache for directories) ends up being very buffer-cache
> intensive. And the buffer cache is basically deprecated..
A few notes: I'm not 100% sure things really fit in the 2GB (*), so it
really may be IO limited, and the low CPU use is just because that machine
also happens to have a dang fast next-gen Intel CPU that hasn't even been
released yet.
Also, I do realize that hashed directories should actually decrease the
buffer cache pressure too, just because we wouldn't need to read all of
the directory for a lookup.
Linus
(*) cvsps itself grows to 1.6GB of the 2GB and while that memory should be
largely idle, the problem may simply be that we don't swap it out eagerly
enough. Allowing filesystem metadata to swap out processes is something
we've tuned against, because it tends to result in horrible interactive
behaviour after a nightly "updatedb" run. So it's entirely possible that
this is all normal..
^ permalink raw reply
* Re: Make more commands builtin
From: Ryan Anderson @ 2006-05-23 16:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4v1a0$u6c$1@sea.gmane.org>
On Tue, May 23, 2006 at 03:05:12PM +0200, Jakub Narebski wrote:
> Peter Eriksen wrote:
>
> > On Tue, May 23, 2006 at 02:36:54PM +0200, Jakub Narebski wrote:
> >> Peter Eriksen wrote:
> >>
> >> > Btw.
> >> >
> >> > I used these commands to produce the patch series:
> >> >
> >> > git diff --stat -C 24b65a30015aedd..pe/builtin
> >> > git-send-email --no-chain-reply-to --compose \
> >> > --from=s022018@student.dtu.dk --not-signed-off-by-cc \
> >> > --quiet \
> >> > --subject="Make more commands builtin" \
> >> > --to=git@vger.kernel.org Patches/*
> >>
> >> I wonder why the patches themselves are not replies to the main/summary
> >> email, i.e. "Make more commands builtin" email...
> >
> > It seems thay are:
> >
> > Subject: Make more commands builtin
> > Message-Id: <11483865361243-git-send-email-1>
> >
> > Subject: [PATCH 1/8] Builtin git-ls-files.
> > Message-Id: <11483865362613-git-send-email-1>
> > In-Reply-To: <11483865361243-git-send-email-1>
>
> Ahh... I'm reading git mailing list through GMane NNTP interface.
> It would be nice if git-send-email added 'References:' Usenet/news
> header in addition to email one 'In-Reply-To:'.
Things would have worked better if --no-chain-reply-to had *not* been
used, at least for those of us reading via mutt.
I'm still in the process of getting my machines setup after moving, when
I get sorted out, I'll try to look into this.
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Linus Torvalds @ 2006-05-23 16:50 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <46a038f90605230113x2f6b0e4bq5a2ea97308b495e0@mail.gmail.com>
Hmm. Is it just me, or does the current "git cvsimport" have new problems:
[torvalds@merom git]$ git cvsimport -d ~/CVS gentoo-x86
causes
Committing initial tree 34bd3dcd4bfd79bad35ce3fb08b2e21108195db8
Server has gone away while fetching BUGS-TODO 1.1, retrying...
Retry failed at /home/torvalds/bin/git-cvsimport line 366, <GEN2656> line 9.
and that's it for the import.
I don't see what would have caused it in the changes, but it definitely
worked earlier..
Linus
^ permalink raw reply
* Re: [PATCH 2/2] cvsimport: cleanup commit function
From: Morten Welinder @ 2006-05-23 17:47 UTC (permalink / raw)
To: Martin Langhoff, Junio C Hamano, Matthias Urlichs, git
In-Reply-To: <20060523070007.GC6180@coredump.intra.peff.net>
Why run "env" and not just muck with %ENV?
M.
> + my $pid = open2(my $commit_read, my $commit_write,
> + 'env',
> + "GIT_AUTHOR_NAME=$author_name",
> + "GIT_AUTHOR_EMAIL=$author_email",
> + "GIT_AUTHOR_DATE=$commit_date",
> + "GIT_COMMITTER_NAME=$author_name",
> + "GIT_COMMITTER_EMAIL=$author_email",
> + "GIT_COMMITTER_DATE=$commit_date",
> + 'git-commit-tree', $tree, @commit_args);
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Jason Riedy @ 2006-05-23 18:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605230744350.5623@g5.osdl.org>
And Linus Torvalds writes:
-
- What kind of CRAP has Solaris become?
Become? heh. Check mount's output; it's "mountpoint
on device". Always has been. I think there might be
a reason why certain other OSes have eaten their lunch,
and it ain't the price.
- It wasn't about what was "allowed by the standards",
- that was the HP-SUX and AIX's excuses.
No, AIX's excuse is that it's "dictated by these three
standards over here and disallowed by those two, so
clearly we have to support both behaviors depending
on some footnote in our 1e9 page manual." wheee...
- Have Sun people forgotten the difference between "quality" and "crap that
- passes standards tests"?
As far as I've been told, Sun's more interested in
near-perfect backwards compatibility than external
standards tests. It worked for Intel, right? ;)
- Btw, even SuS says:
[...]
- New implementations are discouraged from returning X_OK unless at
- least one execution permission bit is set."
Now there is one possible, cross-OS problem that I
haven't tested. You can chmod a-x and then use
setfacl to grant one person execute access. I'm not
sure if access works in that case, but that might
possibly just say that current ACL systems are crap.
Hmm. Does access handle SELinux or the other systems?
That might be interesting for a public git server, but
I don't know enough about it.
- Somebody hit some Solaris engineers with a 2x4 clue-stick, please.
I think you're targetting the wrong department...
Their hands are tied.
Jason, wondering if you could resist the SUS bait...
^ permalink raw reply
* [PATCH 1/2] Again: remove the artificial restriction tagsize < 8kb
From: Björn Engelmann @ 2006-05-23 18:19 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-remove-the-artificial-restriction-tagsize-8kb.txt --]
[-- Type: text/plain, Size: 4182 bytes --]
Signed-off-by: Björn Engelmann <BjEngelmann@gmx.de>
---
430953ceafbc722226e2300b489e38938220d435
cache.h | 1 +
mktag.c | 19 +++++++++----------
sha1_file.c | 46 ++++++++++++++++++++++++++++++++++++----------
3 files changed, 46 insertions(+), 20 deletions(-)
430953ceafbc722226e2300b489e38938220d435
diff --git a/cache.h b/cache.h
index 4b7a439..19e90eb 100644
--- a/cache.h
+++ b/cache.h
@@ -154,6 +154,7 @@ extern int ce_match_stat(struct cache_en
extern int ce_modified(struct cache_entry *ce, struct stat *st, int);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type);
+extern int read_pipe(int fd, char** return_buf, unsigned long* return_size);
extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
diff --git a/mktag.c b/mktag.c
index 2328878..f1598db 100644
--- a/mktag.c
+++ b/mktag.c
@@ -45,7 +45,7 @@ static int verify_tag(char *buffer, unsi
unsigned char sha1[20];
const char *object, *type_line, *tag_line, *tagger_line;
- if (size < 64 || size > MAXSIZE-1)
+ if (size < 64)
return -1;
buffer[size] = 0;
@@ -105,8 +105,8 @@ static int verify_tag(char *buffer, unsi
int main(int argc, char **argv)
{
- unsigned long size;
- char buffer[MAXSIZE];
+ unsigned long size = 4096;
+ char *buffer = malloc(size);
unsigned char result_sha1[20];
if (argc != 1)
@@ -114,13 +114,9 @@ int main(int argc, char **argv)
setup_git_directory();
- // Read the signature
- size = 0;
- for (;;) {
- int ret = xread(0, buffer + size, MAXSIZE - size);
- if (ret <= 0)
- break;
- size += ret;
+ if (read_pipe(0, &buffer, &size)) {
+ free(buffer);
+ die("could not read from stdin");
}
// Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
@@ -129,6 +125,9 @@ int main(int argc, char **argv)
if (write_sha1_file(buffer, size, tag_type, result_sha1) < 0)
die("unable to write tag file");
+
+ free(buffer);
+
printf("%s\n", sha1_to_hex(result_sha1));
return 0;
}
diff --git a/sha1_file.c b/sha1_file.c
index 2230010..e444d9d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1645,16 +1645,24 @@ int has_sha1_file(const unsigned char *s
return find_sha1_file(sha1, &st) ? 1 : 0;
}
-int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+/*
+ * reads from fd as long as possible into a supplied buffer of size bytes.
+ * If neccessary the buffer's size is increased using realloc()
+ *
+ * returns 0 if anything went fine and -1 otherwise
+ *
+ * NOTE: both buf and size may change, but even when -1 is returned
+ * you still have to free() it yourself.
+ */
+int read_pipe(int fd, char** return_buf, unsigned long* return_size)
{
- unsigned long size = 4096;
- char *buf = malloc(size);
- int iret, ret;
+ char* buf = *return_buf;
+ unsigned long size = *return_size;
+ int iret;
unsigned long off = 0;
- unsigned char hdr[50];
- int hdrlen;
+
do {
- iret = read(fd, buf + off, size - off);
+ iret = xread(fd, buf + off, size - off);
if (iret > 0) {
off += iret;
if (off == size) {
@@ -1663,16 +1671,34 @@ int index_pipe(unsigned char *sha1, int
}
}
} while (iret > 0);
- if (iret < 0) {
+
+ *return_buf = buf;
+ *return_size = off;
+
+ if (iret < 0)
+ return -1;
+ return 0;
+}
+
+int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+{
+ unsigned long size = 4096;
+ char *buf = malloc(size);
+ int ret;
+ unsigned char hdr[50];
+ int hdrlen;
+
+ if (read_pipe(fd, &buf, &size)) {
free(buf);
return -1;
}
+
if (!type)
type = blob_type;
if (write_object)
- ret = write_sha1_file(buf, off, type, sha1);
+ ret = write_sha1_file(buf, size, type, sha1);
else {
- write_sha1_file_prepare(buf, off, type, sha1, hdr, &hdrlen);
+ write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
ret = 0;
}
free(buf);
--
1.3.3.g4309-dirty
^ permalink raw reply related
* [PATCH 2/2] Again: add more informative error messages to git-mktag
From: Björn Engelmann @ 2006-05-23 18:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0002-add-more-informative-error-messages-to-git-mktag.txt --]
[-- Type: text/plain, Size: 2838 bytes --]
Signed-off-by: Björn Engelmann <BjEngelmann@gmx.de>
---
51465a979a25c4363010cbab5798d95ac9f102e7
mktag.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
51465a979a25c4363010cbab5798d95ac9f102e7
diff --git a/mktag.c b/mktag.c
index f1598db..6bd45df 100644
--- a/mktag.c
+++ b/mktag.c
@@ -46,41 +46,45 @@ static int verify_tag(char *buffer, unsi
const char *object, *type_line, *tag_line, *tagger_line;
if (size < 64)
- return -1;
+ return error("wanna fool me ? you obviously got the size wrong !\n");
+
buffer[size] = 0;
/* Verify object line */
object = buffer;
if (memcmp(object, "object ", 7))
- return -1;
+ return error("char%d: does not start with \"object \"\n", 0);
+
if (get_sha1_hex(object + 7, sha1))
- return -1;
+ return error("char%d: could not get SHA1 hash\n", 7);
/* Verify type line */
type_line = object + 48;
if (memcmp(type_line - 1, "\ntype ", 6))
- return -1;
+ return error("char%d: could not find \"\\ntype \"\n", 47);
/* Verify tag-line */
tag_line = strchr(type_line, '\n');
if (!tag_line)
- return -1;
+ return error("char%td: could not find next \"\\n\"\n", type_line - buffer);
tag_line++;
if (memcmp(tag_line, "tag ", 4) || tag_line[4] == '\n')
- return -1;
+ return error("char%td: no \"tag \" found\n", tag_line - buffer);
/* Get the actual type */
typelen = tag_line - type_line - strlen("type \n");
if (typelen >= sizeof(type))
- return -1;
+ return error("char%d: type too long\n", (int)(type_line - buffer) + strlen("type \n"));
+
memcpy(type, type_line+5, typelen);
type[typelen] = 0;
/* Verify that the object matches */
if (get_sha1_hex(object + 7, sha1))
- return -1;
+ return error("char%d: could not get SHA1 hash but this is really odd since i got it before !\n", 7);
+
if (verify_object(sha1, type))
- return -1;
+ return error("char%d: could not verify object %s\n", 7, sha1);
/* Verify the tag-name: we don't allow control characters or spaces in it */
tag_line += 4;
@@ -90,14 +94,14 @@ static int verify_tag(char *buffer, unsi
break;
if (c > ' ')
continue;
- return -1;
+ return error("char%td: could not verify tag name\n", tag_line - buffer);
}
/* Verify the tagger line */
tagger_line = tag_line;
if (memcmp(tagger_line, "tagger", 6) || (tagger_line[6] == '\n'))
- return -1;
+ return error("char%td: could not find \"tagger\"\n", tagger_line - buffer);
/* The actual stuff afterwards we don't care about.. */
return 0;
@@ -118,7 +122,7 @@ int main(int argc, char **argv)
free(buffer);
die("could not read from stdin");
}
-
+
// Verify it for some basic sanity: it needs to start with "object <sha1>\ntype\ntagger "
if (verify_tag(buffer, size) < 0)
die("invalid tag signature file");
--
1.3.3.g4309-dirty
^ permalink raw reply related
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-23 18:24 UTC (permalink / raw)
To: Jason Riedy; +Cc: Git Mailing List
In-Reply-To: <19270.1148407414@lotus.CS.Berkeley.EDU>
On Tue, 23 May 2006, Jason Riedy wrote:
>
> - Btw, even SuS says:
> [...]
> - New implementations are discouraged from returning X_OK unless at
> - least one execution permission bit is set."
>
> Now there is one possible, cross-OS problem that I
> haven't tested. You can chmod a-x and then use
> setfacl to grant one person execute access. I'm not
> sure if access works in that case, but that might
> possibly just say that current ACL systems are crap.
I absolutely agree. That is why the OS has a "access()" system call. It's
there to ask the OS whether the file is executable (or readable/writable).
Otherwise, we'd just do
static inline int executable(const char *path)
{
struct stat st;
return !stat(pathname, &st) &&
S_ISREG(st.st_mode) &&
(st.st_mode & 0111) != 0;
}
and be done with it. But exactly because the OS knows what "executable"
means, we ask it. We don't know about all the ACL's etc, the OS does.
(Similar issues are true for writability too - the file may be "writable"
in the sense that the write permission bits are on, but if the filesystem
is mounted read-only, it sure as hell ain't W_OK _anyway_).
> Hmm. Does access handle SELinux or the other systems?
Yup.
Modulo bugs, of course, but yes, access() on linux should check both
POSIX ACL's and SELinux security extensions. It uses exactly the same
code-paths that open()/execve() does: it uses the "vfs_permission()"
function which is also what execve() uses.
Now, I think access() actually misses a no-exec mount (it doesn't seem to
check MNT_NOEXEC for X_OK), and that looks like it might actually be a
real bug.
Linus
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Edgar Toernig @ 2006-05-23 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jason Riedy, Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605230829020.5623@g5.osdl.org>
Linus Torvalds wrote:
>
> [ And how the heck does anybody still run 2.0, btw? ]
Why not? There was never the need for an upgrade.
All connected hardware is well supported. Sure,
there are no binary packages for it and you have to
compile from sources but most apps can be made to
run on it (on the way you learn to hate autoconf).
And I wish the 2.6 system were as reliable as the
2.0 one ...
Ciao, ET.
^ 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