* Re: More qgit defects
From: Pavel Roskin @ 2006-05-01 2:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: ydirson, git
In-Reply-To: <e5bfff550604300313n5ebe84f7nf42c88789efe1@mail.gmail.com>
Hello, Marco!
On Sun, 2006-04-30 at 12:13 +0200, Marco Costalba wrote:
> Throwing in the tabs is a *very* big change, but, just to discuss....I
> agree on the note that in qgit we have three different approaches:
> fixed frames (revisions, file tree, affected files), detachable frames
> (patch) and separate windows (annotations).
>
> This is a bit strange and could give an odd GUI feeling.
Agreed.
> I like the tab idea because it's clear and simple and fixes the 'many
> approaches' problem.
I'm glad you liked my idea! And thank you for copying to the list.
qgit is meant for most git users, and they should have their voices
heard.
> What I would suggest is, at least at first step,
> do not change the main view and have only three tabs:
>
> Tab1: Main view with revisions, file tree (hide able), affected files.
> Tab2: Patch view with patch stat and diffs
> Tab3: File history + file content/annotation view
Absolutely. It's easier to make changes incrementally than to rewrite
everything and hunt bugs for months. This change alone would make it
easier to work with qgit.
Once qgit can deal with more than one patch view and more than one file
view, this would provide the fix for qgit's "jumpiness". Mere selection
of objects in listboxes shouldn't affect other tabs.
> In other words just put the frames/windows as are now in browse able
> tabs. In this way main view still gives a good amount of information
> without requiring changing the tab and the tabs are reserved for 'big
> space' needed infos only.
That would be great. I'm eagerly waiting for new commits to test :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-05-01 4:44 UTC (permalink / raw)
To: git
In-Reply-To: <4455638A.3070802@vilain.net>
Take a look at complexity of that explanation. And the need for additional
commit. That balanced against all the headaches of having connectivity
header other than "parent".
Perhaps it would be better (and easier) just to say
note prior parent^1
or
note prior <sha1>
repeating <sha1> found in parent.
Just a thought.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-01 6:32 UTC (permalink / raw)
To: git
This attempts to set up built-in "git grep" to further reduce
our dependence on the shell, while at the same time optionally
allowing to run grep against object database. You could do
funky things like these:
git grep --cached -e pattern ;# grep from index
git grep -e pattern master ;# or in a rev
git grep -e pattern master next ;# or in multiple revs
git grep -e pattern pu^@ ;# even like this with an
;# extension from another topic ;-)
git grep -e pattern master..next ;# or even from rev ranges
git grep -e pattern master~20:Documentation
;# or an arbitrary tree
git grep -e pattern next:git-commit.sh
;# or an arbitrary blob
Right now, it does not understand and/or obey many options grep
should accept, and the pattern matcher using POSIX.2 regex seems
to be excruciatingly slow (I lifted it from Pasky's regexp
pickaxe code almost verbatim without thinking -- I was too
tired). Help to improve things in the grep_buffer() function is
very much appreciated.
But this is going in the right direction. The shell script
version is one of the worst Portability offender in the git
barebone Porcelainish; it uses xargs -0 to pass paths around and
shell arrays to sift flags and parameters.
In order to stay out of the way of real work people want to get
done with the real "git grep", for now this implementation is
called "git grip".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2
builtin-grep.c | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1
git.c | 1
4 files changed, 380 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8ce27a6..8d5122b 100644
--- a/Makefile
+++ b/Makefile
@@ -214,7 +214,7 @@ LIB_OBJS = \
$(DIFF_OBJS)
BUILTIN_OBJS = \
- builtin-log.o builtin-help.o
+ builtin-log.o builtin-help.o builtin-grep.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-grep.c b/builtin-grep.c
new file mode 100644
index 0000000..adcdbaa
--- /dev/null
+++ b/builtin-grep.c
@@ -0,0 +1,377 @@
+/*
+ * Builtin "git grep"
+ *
+ * Copyright (c) 2006 Junio C Hamano
+ */
+#include "cache.h"
+#include "blob.h"
+#include "tree.h"
+#include "commit.h"
+#include "tag.h"
+#include "diff.h"
+#include "revision.h"
+#include "builtin.h"
+#include <regex.h>
+
+struct grep_opt {
+ const char *pattern;
+ regex_t regexp;
+ unsigned linenum:1;
+ unsigned pre_context;
+ unsigned post_context;
+};
+
+static char *end_of_line(char *cp, unsigned long *left)
+{
+ unsigned long l = *left;
+ while (l && *cp != '\n') {
+ l--;
+ cp++;
+ }
+ *left = l;
+ return cp;
+}
+
+static int grep_buffer(struct grep_opt *opt, const char *name,
+ char *buf, unsigned long size)
+{
+ char *bol = buf;
+ unsigned long left = size;
+ unsigned lno = 1;
+ int hit = 0;
+
+ while (left) {
+ regmatch_t pmatch[10];
+ int flags = 0;
+ char *eol, *cp, ch;
+ eol = end_of_line(bol, &left);
+ ch = *eol;
+ *eol = 0;
+ for (cp = bol; cp < eol; cp++) {
+ int status = regexec(&opt->regexp, cp,
+ ARRAY_SIZE(pmatch), pmatch,
+ flags);
+ if (status == REG_NOMATCH)
+ flags |= REG_NOTBOL;
+ else if (status == 0) {
+ /* Hit at this line */
+ printf("%s:", name);
+ if (opt->linenum)
+ printf("%d:", lno);
+ printf("%.*s\n", eol-bol, bol);
+ hit = 1;
+ break;
+ }
+ }
+ *eol = ch;
+ bol = eol + 1;
+ left--;
+ lno++;
+ }
+ return hit;
+}
+
+static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *name)
+{
+ unsigned long size;
+ char *data;
+ char type[20];
+ int hit;
+ data = read_sha1_file(sha1, type, &size);
+ if (!data) {
+ error("'%s': unable to read %s", name, sha1_to_hex(sha1));
+ return 0;
+ }
+ hit = grep_buffer(opt, name, data, size);
+ free(data);
+ return hit;
+}
+
+static int grep_file(struct grep_opt *opt, const char *filename)
+{
+ struct stat st;
+ int i;
+ char *data;
+ if (lstat(filename, &st) < 0) {
+ err_ret:
+ if (errno != ENOENT)
+ error("'%s': %s", filename, strerror(errno));
+ return 0;
+ }
+ if (!st.st_size)
+ return 0; /* empty file -- no grep hit */
+ if (!S_ISREG(st.st_mode))
+ return 0;
+ i = open(filename, O_RDONLY);
+ if (i < 0)
+ goto err_ret;
+ data = xmalloc(st.st_size + 1);
+ if (st.st_size != xread(i, data, st.st_size)) {
+ error("'%s': short read %s", filename, strerror(errno));
+ close(i);
+ free(data);
+ return 0;
+ }
+ close(i);
+ i = grep_buffer(opt, filename, data, st.st_size);
+ free(data);
+ return i;
+}
+
+static int grep_cache(struct grep_opt *opt, struct rev_info *revs, int cached)
+{
+ int hit = 0;
+ int nr;
+ read_cache();
+
+ for (nr = 0; nr < active_nr; nr++) {
+ struct cache_entry *ce = active_cache[nr];
+ if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
+ continue;
+ if (revs->diffopt.nr_paths) {
+ int i;
+ int namelen = ce_namelen(ce);
+ const char *name = ce->name;
+ for (i = 0; i < revs->diffopt.nr_paths; i++) {
+ const char *match = revs->diffopt.paths[i];
+ int matchlen = revs->diffopt.pathlens[i];
+ if (matchlen <= namelen)
+ if (!strncmp(name, match, matchlen))
+ break;
+ }
+ if (revs->diffopt.nr_paths <= i)
+ continue;
+ }
+ if (cached)
+ hit |= grep_sha1(opt, ce->sha1, ce->name);
+ else
+ hit |= grep_file(opt, ce->name);
+ }
+ return hit;
+}
+
+static int pathspec_matches(struct diff_options *opt, const char *name)
+{
+ int i;
+ int namelen;
+ if (!opt->nr_paths)
+ return 1;
+ namelen = strlen(name);
+ for (i = 0; i < opt->nr_paths; i++) {
+ const char *match = opt->paths[i];
+ int matchlen = opt->pathlens[i];
+ if (matchlen <= namelen)
+ if (!strncmp(name, match, matchlen))
+ return 1;
+ }
+ return 0;
+}
+
+static int grep_tree(struct grep_opt *opt, struct rev_info *revs,
+ struct tree_desc *tree,
+ const char *tree_name, const char *base)
+{
+ unsigned mode;
+ int len;
+ int hit = 0;
+ const char *path;
+ const unsigned char *sha1;
+ char *down_base;
+ char *path_buf = xmalloc(PATH_MAX + strlen(tree_name) + 100);
+
+ if (tree_name[0]) {
+ int offset = sprintf(path_buf, "%s:", tree_name);
+ down_base = path_buf + offset;
+ strcat(down_base, base);
+ }
+ else {
+ down_base = path_buf;
+ strcpy(down_base, base);
+ }
+ len = strlen(path_buf);
+
+ while (tree->size) {
+ int pathlen;
+ sha1 = tree_entry_extract(tree, &path, &mode);
+ pathlen = strlen(path);
+ strcpy(path_buf + len, path);
+
+ if (!pathspec_matches(&revs->diffopt, down_base))
+ ;
+ else if (S_ISREG(mode))
+ hit |= grep_sha1(opt, sha1, path_buf);
+ else if (S_ISDIR(mode)) {
+ char type[20];
+ struct tree_desc sub;
+ void *data;
+ data = read_sha1_file(sha1, type, &sub.size);
+ if (!data)
+ die("unable to read tree (%s)",
+ sha1_to_hex(sha1));
+ strcpy(path_buf + len + pathlen, "/");
+ sub.buf = data;
+ hit = grep_tree(opt, revs, &sub, tree_name, down_base);
+ free(data);
+ }
+ update_tree_entry(tree);
+ }
+ return hit;
+}
+
+static int grep_object(struct grep_opt *opt, struct rev_info *revs,
+ struct object *obj, const char *name)
+{
+ if (!strcmp(obj->type, blob_type))
+ return grep_sha1(opt, obj->sha1, name);
+ if (!strcmp(obj->type, commit_type) ||
+ !strcmp(obj->type, tree_type)) {
+ struct tree_desc tree;
+ void *data;
+ int hit;
+ data = read_object_with_reference(obj->sha1, tree_type,
+ &tree.size, NULL);
+ if (!data)
+ die("unable to read tree (%s)", sha1_to_hex(obj->sha1));
+ tree.buf = data;
+ hit = grep_tree(opt, revs, &tree, name, "");
+ free(data);
+ return hit;
+ }
+ die("unable to grep from object of type %s", obj->type);
+}
+
+static const char builtin_grep_usage[] =
+"git-grep <option>* <rev>* [-e] <pattern> [<path>...]";
+
+int cmd_grep(int argc, const char **argv, char **envp)
+{
+ struct rev_info rev;
+ const char **dst, **src;
+ int err;
+ int hit = 0;
+ int no_more_arg = 0;
+ int seen_range = 0;
+ int seen_noncommit = 0;
+ int cached = 0;
+ struct grep_opt opt;
+ struct object_list *list;
+
+ memset(&opt, 0, sizeof(opt));
+
+ /*
+ * Interpret and remove the grep options upfront. Sigh...
+ */
+ for (dst = src = &argv[1]; src < argc + argv; ) {
+ const char *arg = *src++;
+ if (!no_more_arg) {
+ if (!strcmp("--", arg)) {
+ no_more_arg = 1;
+ *dst++ = arg;
+ continue;
+ }
+ if (!strcmp("--cached", arg)) {
+ cached = 1;
+ continue;
+ }
+ if (!strcmp("-e", arg)) {
+ if (src < argc + argv) {
+ opt.pattern = *src++;
+ continue;
+ }
+ usage(builtin_grep_usage);
+ }
+ if (!strcmp("-n", arg)) {
+ opt.linenum = 1;
+ continue;
+ }
+ if (!strcmp("-H", arg)) {
+ /* We always show the pathname, so this
+ * is a noop.
+ */
+ continue;
+ }
+ if (!strcmp("-A", arg) ||
+ !strcmp("-B", arg) ||
+ !strcmp("-C", arg)) {
+ unsigned num;
+ if ((argc + argv <= src) ||
+ sscanf(*src++, "%u", &num) != 1)
+ usage(builtin_grep_usage);
+ switch (arg[1]) {
+ case 'A':
+ opt.post_context = num;
+ break;
+ case 'C':
+ opt.post_context = num;
+ case 'B':
+ opt.pre_context = num;
+ break;
+ }
+ continue;
+ }
+ }
+ *dst++ = arg;
+ }
+ if (!opt.pattern)
+ die("no pattern given.");
+
+ err = regcomp(&opt.regexp, opt.pattern, REG_NEWLINE);
+ if (err) {
+ char errbuf[1024];
+ regerror(err, &opt.regexp, errbuf, 1024);
+ regfree(&opt.regexp);
+ die("'%s': %s", opt.pattern, errbuf);
+ }
+
+ init_revisions(&rev);
+ *dst = NULL;
+ argc = setup_revisions(dst - argv, argv, &rev, NULL);
+
+ /*
+ * Do not walk "grep -e foo master next pu -- Documentation/"
+ * but do walk "grep -e foo master..next -- Documentation/".
+ * Ranged request mixed with a blob or tree object, like
+ * "grep -e foo v1.0.0:Documentation/ master..next"
+ * so detect that and complain.
+ */
+ for (list = rev.pending_objects; list; list = list->next) {
+ struct object *real_obj;
+ if (list->item->flags & UNINTERESTING)
+ seen_range = 1;
+ real_obj = deref_tag(list->item, NULL, 0);
+ if (strcmp(real_obj->type, commit_type))
+ seen_noncommit = 1;
+ }
+ if (!rev.pending_objects)
+ return !grep_cache(&opt, &rev, cached);
+ if (cached)
+ die("both --cached and revisions given.");
+
+ if (seen_range && seen_noncommit)
+ die("both A..B and non commit are given.");
+ if (seen_range) {
+ struct commit *commit;
+ prepare_revision_walk(&rev);
+ while ((commit = get_revision(&rev)) != NULL) {
+ unsigned char *sha1 = commit->object.sha1;
+ char *n = find_unique_abbrev(sha1, DEFAULT_ABBREV);
+ char rev_name[41];
+ strcpy(rev_name, n);
+ if (grep_object(&opt, &rev, &commit->object, rev_name))
+ hit = 1;
+ commit->buffer = NULL;
+ }
+ return !hit;
+ }
+
+ /* all of them are non-commit; do not walk, and
+ * do not lose their names.
+ */
+ for (list = rev.pending_objects; list; list = list->next) {
+ struct object *real_obj;
+ real_obj = deref_tag(list->item, NULL, 0);
+ if (grep_object(&opt, &rev, real_obj, list->name))
+ hit = 1;
+ }
+ return !hit;
+}
diff --git a/builtin.h b/builtin.h
index 47408a0..cf5de3b 100644
--- a/builtin.h
+++ b/builtin.h
@@ -19,5 +19,6 @@ extern int cmd_version(int argc, const c
extern int cmd_whatchanged(int argc, const char **argv, char **envp);
extern int cmd_show(int argc, const char **argv, char **envp);
extern int cmd_log(int argc, const char **argv, char **envp);
+extern int cmd_grep(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 01b7e28..18e857d 100644
--- a/git.c
+++ b/git.c
@@ -46,6 +46,7 @@ static void handle_internal_command(int
{ "log", cmd_log },
{ "whatchanged", cmd_whatchanged },
{ "show", cmd_show },
+ { "grip", cmd_grep },
};
int i;
--
1.3.1.gd233
^ permalink raw reply related
* Re: [PATCH] built-in "git grep" (git grip).
From: Jakub Narebski @ 2006-05-01 6:56 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wvetfuj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This attempts to set up built-in "git grep" to further reduce
> our dependence on the shell, while at the same time optionally
> allowing to run grep against object database.
[...]
> In order to stay out of the way of real work people want to get
> done with the real "git grep", for now this implementation is
> called "git grip".
Wouldn't "git ggrep" (from git-aware grep) or "git bgrep" (from built-in
grep), similar to the egrep and fgrep from the grep package?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Junio C Hamano @ 2006-05-01 6:58 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Jakub Narebski
In-Reply-To: <4455638A.3070802@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> Junio C Hamano wrote:
>
>>To David, the commits he has in the chain between 6b426e to
>>18118c obviously suited the purpose of his tree better, and that
>>was why these commits were made. And the fact Linus fast
>>forwarded to the tip of David is an implicit statement by Linus
>>that that results suits the purpose of Linus tree better as well
>>compared to his old tip, presumably 6b426e.
>
> Aha, now I see reason in the madness. So, the "prior" head is not stored
> in the trees, and tracking the progress of actual head transitions is
> loosely defined / a research topic. But demonstrably derivable. That
> works for me.
I do not think there is any madness involved here, but I should
point out that the above example happens to work only because
Linus and David are two different people. If Linus did the
David's work in a separate repository, or even in the same
repository but on a separate branch, people following the Linus
tip might still want to know about the fast-forward, but that is
something you cannot truly tell by the digging like what I did
in the previous message.
That is why I earlier said this:
*1* IOW, we _are_ losing some information by not recording the
fact that fast-forward was done while doing so.
That record should _not_ be in the commit chain. At the
mechanical level, recording that in the commit chain means two
criss-crossing branches never converge at the commit chain
level, which is already bad. At the philosophical level, the
commit chain is a mesh of many possible "global" histories, and
the record that somebody (a particular branch in a particular
repository) was at what point in the mesh at given time does not
belong there.
But from the repository-owner's point of view, that _might_ be a
useful information to keep. I am just saying this preemptively
so that if somebody wants to record it, that should not be
recorded in the commit object.
I do not think the commit object is the place to record it, even
with a purely-comment field like "note prior". The commit
ancestry DAG is global in nature, and the information under
discussion, "before pointing at this commit, the branch that
made this commit happened to point at this other commit", is
not. That information describes only one-branch's view of the
world, and would not work in the fast-forward case because no
new commit is created. An important property of a fast-forward
is that we do not create an extra commit object that makes it
impossible for two criss-crossing branches to ever converge.
On the other hand, a "note" field that records on which branch
of which repository each commit was made (you need to give each
repository-branch an UUID) when you do create a new commit would
be a sensible thing to have if somebody cares deeply enough. It
is an information that is global in nature, and with that, you
could do the digging like I did without relying on the committer
identity, but instead using the branch identity.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-01 6:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e34bdf$ho4$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Wouldn't "git ggrep" (from git-aware grep) or "git bgrep" (from built-in
> grep), similar to the egrep and fgrep from the grep package?
The eventual goal is to rename it to "git grep" and remove the
shell based one, so the interim name does not matter.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Jakub Narebski @ 2006-05-01 7:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd4as00i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Jakub Narebski <jnareb@gmail.com> writes:
> Wouldn't "git ggrep" (from git-aware grep) or "git bgrep" (from built-in
> grep), similar to the egrep and fgrep from the grep package?
Yes, I understand, but I just don't like using 'grip'. And it would be nice
to have some convention for further not-ready-yet built-in replacements for
script versions of commands, for example adding letter 'b' as 'built-in' at
the beginning of command name: 'bgrep', 'bdiff'. Or use postfix 'n' or
'-ng' to denote transitionary not-ready-yet new version of command:
'grepn', 'diffn' or 'grep-ng', 'diff-ng'.
By the way, [my] grep is linked against libpcre - would it mean that git
would also need to use pcre library, or at least have an option to use it?
I also wonder if anyone would be interested to _force_ using external grep
(probably enhanced)... just a thought.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] built-in "git grep" (git grip) - quickfix
From: Junio C Hamano @ 2006-05-01 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wvetfuj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Right now, it does not understand and/or obey many options grep
> should accept, and the pattern matcher using POSIX.2 regex seems
> to be excruciatingly slow...
I forgot to say that unlike the shell script version you need to
give -e in front of the pattern with this version because of the
way the option parser is structured. Obviously this needs to be
fixed for usability's sake.
But I seem to have managed to fix the "excruciatingly slow" part
trivially. regexec() is not re.match() but re.search(), and
there is no point looking at each character on the line. Here
is a patch.
-- >8 --
diff --git a/builtin-grep.c b/builtin-grep.c
index adcdbaa..6230f44 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -42,26 +42,18 @@ static int grep_buffer(struct grep_opt *
while (left) {
regmatch_t pmatch[10];
- int flags = 0;
- char *eol, *cp, ch;
+ char *eol, ch;
eol = end_of_line(bol, &left);
ch = *eol;
*eol = 0;
- for (cp = bol; cp < eol; cp++) {
- int status = regexec(&opt->regexp, cp,
- ARRAY_SIZE(pmatch), pmatch,
- flags);
- if (status == REG_NOMATCH)
- flags |= REG_NOTBOL;
- else if (status == 0) {
- /* Hit at this line */
- printf("%s:", name);
- if (opt->linenum)
- printf("%d:", lno);
- printf("%.*s\n", eol-bol, bol);
- hit = 1;
- break;
- }
+ if (!regexec(&opt->regexp, bol,
+ ARRAY_SIZE(pmatch), pmatch, 0)) {
+ /* Hit at this line */
+ printf("%s:", name);
+ if (opt->linenum)
+ printf("%d:", lno);
+ printf("%.*s\n", eol-bol, bol);
+ hit = 1;
}
*eol = ch;
bol = eol + 1;
^ permalink raw reply related
* [PATCH] repack: honor -d even when no new pack was created
From: Martin Waitz @ 2006-05-01 10:57 UTC (permalink / raw)
To: git
If all objects are reachable via an alternate object store then we
still have to remove all obsolete local packs.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
Without this patch I got the following behaviour:
".git/objects/info/alternates" [Neu] 1L, 38C geschrieben
admingilde:~/src/linux-2.6 > git count-objects
107852 objects, 665596 kilobytes
admingilde:~/src/linux-2.6 > git repack -a -l -d
Generating pack...
Done counting 0 objects.
Nothing new to pack.
admingilde:~/src/linux-2.6 > git prune
admingilde:~/src/linux-2.6 > git count-objects
0 objects, 0 kilobytes
admingilde:~/src/linux-2.6 > ls .git/objects/pack
pack-b3c6fbdfa36a326815de6358885c7a570a986b1b.idx
pack-b3c6fbdfa36a326815de6358885c7a570a986b1b.pack
pack-e0d76ffe354ef5665028a6cb4506ea902f72e1d0.idx
pack-e0d76ffe354ef5665028a6cb4506ea902f72e1d0.pack
After changing git-repack, objects/pack was empty, as expected.
git-repack.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
c58513fa76e10007fdf15b49a593a2b9c6a080be
diff --git a/git-repack.sh b/git-repack.sh
index e0c9f32..4fb3f26 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -48,15 +48,15 @@ name=$(git-rev-list --objects --all $rev
exit 1
if [ -z "$name" ]; then
echo Nothing new to pack.
- exit 0
-fi
-echo "Pack pack-$name created."
+else
+ echo "Pack pack-$name created."
-mkdir -p "$PACKDIR" || exit
+ mkdir -p "$PACKDIR" || exit
-mv .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
-mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
-exit
+ mv .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
+ mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
+ exit
+fi
if test "$remove_redundant" = t
then
--
1.3.1.g8971-dirty
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] built-in "git grep" (git grip).
From: Sam Ravnborg @ 2006-05-01 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvetfuj.fsf@assigned-by-dhcp.cox.net>
On Sun, Apr 30, 2006 at 11:32:36PM -0700, Junio C Hamano wrote:
> This attempts to set up built-in "git grep" to further reduce
> our dependence on the shell, while at the same time optionally
> allowing to run grep against object database. You could do
> funky things like these:
>
> git grep --cached -e pattern ;# grep from index
> git grep -e pattern master ;# or in a rev
> git grep -e pattern master next ;# or in multiple revs
> git grep -e pattern pu^@ ;# even like this with an
> ;# extension from another topic ;-)
> git grep -e pattern master..next ;# or even from rev ranges
> git grep -e pattern master~20:Documentation
> ;# or an arbitrary tree
> git grep -e pattern next:git-commit.sh
> ;# or an arbitrary blob
>
A feature I have been missing often has been the possibility to limit
grep (and ls-files) to certain filenames.
Say:
git grip -e DEBUG 'Kconfig*'
I usually do something stupid like:
git ls-files | grep Kconfig | xargs grep DEBUG
Thought it may be trivial to extend git grip while you are there anyway.
But obviously only if this is useful for more than just me.
Sam
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Sam Ravnborg @ 2006-05-01 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060501140410.GA3505@mars.ravnborg.org>
>
> I usually do something stupid like:
> git ls-files | grep Kconfig | xargs grep DEBUG
Which is indeed studip. I just learned I could say:
git ls-files '*/Kconfig*' | xargs grep DEBUG
Sam
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Sam Ravnborg @ 2006-05-01 14:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060501140704.GA6096@mars.ravnborg.org>
On Mon, May 01, 2006 at 04:07:04PM +0200, Sam Ravnborg wrote:
> >
> > I usually do something stupid like:
> > git ls-files | grep Kconfig | xargs grep DEBUG
>
> Which is indeed studip. I just learned I could say:
> git ls-files '*/Kconfig*' | xargs grep DEBUG
Seems I have confused myself.
git grep DEBUG '*/Kconfig*'
does indeed work today. And browsing the git grip code that
will also support it.
Sorry for the noise.
Sam
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Linus Torvalds @ 2006-05-01 15:48 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, git
In-Reply-To: <20060501145328.GA14856@mars.ravnborg.org>
On Mon, 1 May 2006, Sam Ravnborg wrote:
>
> Seems I have confused myself.
>
> git grep DEBUG '*/Kconfig*'
>
> does indeed work today.
Indeed. I was a bit confused about your report, since not only does it
work today, that's how it has always worked, and it was very much designed
that way. I use it all the time.
It takes the git-ls-files pathname syntax, which is a bit _different_ from
the normal "limit to these paths" syntax, in that it honors '*'. And it
honors that a bit differently than normal shell pathname expansion,
because for git-ls-files a '*' pattern will match '/' as well.
So
git grep pattern 'net/*.c'
will match every single C file found _recursively_ inside the "net/"
subdirectory, not just in that single directory itself.
So "*" for git grep is a bit more like a "**" pattern in some shells.
Linus
^ permalink raw reply
* cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-01 7:27 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]
[taking this conversation to the list]
OK, I changed the way I was testing this to match your usage plan and I
still got the same results. It works just fine for vanilla CVS; cvs
status shows the re revision in the repo and cvs update brings it in.
Eclipse has the same funky behavior: Compare with latest at the project
level shows no differences, but compare with latest on the changed file
actually does an update instead of popping up the Eclipse diff viewer.
By the way, I had trouble at first accessing the repo with SSH because
of permissions on the sqlite db. I'm not totally sure about the
implications for multiple users, but maybe just using a common group
will work fine?
I'm really happy with git and git-cvsserver! I'm hoping to be able to
standardize on it for our Eclipse work. It seems like it should be
possible for us to continue to do integrations in Eclipse if we manage
git properly. I've been waiting on arch, baz, and bzr for so long and
then suddenly, Linus pulls this out of his butt!
Bill Burdick
---------- Forwarded message ----------
From: *Martin Langhoff (CatalystIT)* < martin@catalyst.net.nz
<mailto:martin@catalyst.net.nz>>
Date: May 1, 2006 6:41 AM
Subject: Re: cvsserver problem with eclipse?
To: Bill Burdick <bill.burdick@gmail.com <mailto:bill.burdick@gmail.com>>
Cc: Martyn Smith < martyn@catalyst.net.nz <mailto:martyn@catalyst.net.nz>>
Hi Bill,
the git repo you are using, did you set it up to just be a "naked" or
"bare" repo, and enabled cvsserver alright? What version of git are you
using?
My usage plan would be to
1 - Have a git test project
2 - Publish it to a naked/bare repository where git-cvsserver is enabled
3 - Get the cvs checkout (try commandline cvs to make sure things work)
4 - Add commits in the git test project and push them to the repo
5 - Run cvs update
If it's running ok with old school CVS client, then try with Eclipse. We
have tested the update scenario quite a bit, and it works for us, so we
need a bit more info.
BTW, can I ask you to bounce these questions off the git@vger.kernel.org
<mailto:git@vger.kernel.org>
mailing list? We will be happier answering these questions in a way that
gets archived publicly. (Unless you are a direct client of Catalyst IT,
that is! Are you at OpenUniversity perhaps?)
cheers,
martin
Bill Burdick wrote:
> I made a test git repo with a branch called WillyTest and slurped it
> into Eclipse. Then I checked out WillyTest into the git directory and
> committed a change. A synchronize in Eclipse did not detect the change,
> nor did comparing with the latest on the head. Showing history on the
> changed file did, however, list the new revision and I could access the
> contents from that view. Compare with latest on the changed file
> actually replaces the current contents with the repository version.
>
> Bill Burdick
>
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-01 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <4455B863.8040808@mobilereasoning.com>
[-- Attachment #1: Type: text/plain, Size: 3527 bytes --]
FWIW, I'm using Eclipse 3.2RC1a.
Bill
Bill Burdick wrote:
> [taking this conversation to the list]
>
> OK, I changed the way I was testing this to match your usage plan and
> I still got the same results. It works just fine for vanilla CVS; cvs
> status shows the re revision in the repo and cvs update brings it in.
> Eclipse has the same funky behavior: Compare with latest at the
> project level shows no differences, but compare with latest on the
> changed file actually does an update instead of popping up the Eclipse
> diff viewer.
>
> By the way, I had trouble at first accessing the repo with SSH because
> of permissions on the sqlite db. I'm not totally sure about the
> implications for multiple users, but maybe just using a common group
> will work fine?
>
> I'm really happy with git and git-cvsserver! I'm hoping to be able to
> standardize on it for our Eclipse work. It seems like it should be
> possible for us to continue to do integrations in Eclipse if we manage
> git properly. I've been waiting on arch, baz, and bzr for so long and
> then suddenly, Linus pulls this out of his butt!
>
>
> Bill Burdick
>
>
>
> ---------- Forwarded message ----------
> From: *Martin Langhoff (CatalystIT)* < martin@catalyst.net.nz
> <mailto:martin@catalyst.net.nz>>
> Date: May 1, 2006 6:41 AM
> Subject: Re: cvsserver problem with eclipse?
> To: Bill Burdick <bill.burdick@gmail.com <mailto:bill.burdick@gmail.com>>
> Cc: Martyn Smith < martyn@catalyst.net.nz
> <mailto:martyn@catalyst.net.nz>>
>
> Hi Bill,
>
> the git repo you are using, did you set it up to just be a "naked" or
> "bare" repo, and enabled cvsserver alright? What version of git are you
> using?
>
> My usage plan would be to
>
> 1 - Have a git test project
> 2 - Publish it to a naked/bare repository where git-cvsserver is enabled
> 3 - Get the cvs checkout (try commandline cvs to make sure things work)
> 4 - Add commits in the git test project and push them to the repo
> 5 - Run cvs update
>
> If it's running ok with old school CVS client, then try with Eclipse. We
> have tested the update scenario quite a bit, and it works for us, so we
> need a bit more info.
>
> BTW, can I ask you to bounce these questions off the
> git@vger.kernel.org <mailto:git@vger.kernel.org>
> mailing list? We will be happier answering these questions in a way that
> gets archived publicly. (Unless you are a direct client of Catalyst IT,
> that is! Are you at OpenUniversity perhaps?)
>
> cheers,
>
>
> martin
>
> Bill Burdick wrote:
>
>> I made a test git repo with a branch called WillyTest and slurped it
>> into Eclipse. Then I checked out WillyTest into the git directory and
>> committed a change. A synchronize in Eclipse did not detect the
>> change,
>> nor did comparing with the latest on the head. Showing history on the
>> changed file did, however, list the new revision and I could access the
>> contents from that view. Compare with latest on the changed file
>> actually replaces the current contents with the repository version.
>>
>> Bill Burdick
>>
>
>
> --
> -----------------------------------------------------------------------
> Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
> WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
> OFFICE: +64(4)916-7224 MOB: +64(21)364-017
> Make things as simple as possible, but no simpler - Einstein
> -----------------------------------------------------------------------
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* git-bisect broken in 1.2.4
From: Olaf Hering @ 2006-05-01 18:10 UTC (permalink / raw)
To: git
Did SuSE just pick up a bad version of git, 1.2.4?
git-bisect doesnt work correctly in the kernel sources, .git/HEAD doesnt
contain the commit id anymore, but 'ref: refs/heads/bisect'
CONFIG_LOCALVERSION_AUTO depends on the id.
^ permalink raw reply
* [PATCH] builtin-grep: wildcard pathspec fixes
From: Junio C Hamano @ 2006-05-01 19:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605010842130.21189@g5.osdl.org>
This tweaks the pathspec wildcard used in builtin-grep to match
that of ls-files. With this:
git grep -e DEBUG -- '*/Kconfig*'
would work like the shell script version, and you could even do:
git grep -e DEBUG --cached -- '*/Kconfig*' ;# from index
git grep -e DEBUG v2.6.12 -- '*/Kconfig*' ;# from rev
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Still haven't improved the "-e" issue (and to a lesser extent
I think requiring -- is not right in this context either), but
builtin-grep.c | 85 +++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 62 insertions(+), 23 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 36150bf..653b65e 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -12,33 +12,66 @@ #include "diff.h"
#include "revision.h"
#include "builtin.h"
#include <regex.h>
+#include <fnmatch.h>
+/*
+ * git grep pathspecs are somewhat different from diff-tree pathspecs;
+ * pathname wildcards are allowed.
+ */
static int pathspec_matches(struct diff_options *opt, const char *name)
{
- int i, j;
- int namelen;
+ int namelen, i;
if (!opt->nr_paths)
return 1;
namelen = strlen(name);
for (i = 0; i < opt->nr_paths; i++) {
const char *match = opt->paths[i];
int matchlen = opt->pathlens[i];
- if (matchlen <= namelen) {
- if (!strncmp(name, match, matchlen))
- return 1;
+ const char *slash, *cp;
+
+ if ((matchlen <= namelen) &&
+ !strncmp(name, match, matchlen) &&
+ (match[matchlen-1] == '/' ||
+ name[matchlen] == '\0' || name[matchlen] == '/'))
+ return 1;
+ if (!fnmatch(match, name, 0))
+ return 1;
+ if (name[namelen-1] != '/')
continue;
- }
- /* If name is "Documentation" and pathspec is
- * "Documentation/", they should match. Maybe
- * we would want to strip it in get_pathspec()???
+
+ /* We are being asked if the name directory is worth
+ * descending into.
+ *
+ * Find the longest leading directory name that does
+ * not have metacharacter in the pathspec; the name
+ * we are looking at must overlap with that directory.
*/
- if (strncmp(name, match, namelen))
- continue;
- for (j = namelen; j < matchlen; j++)
- if (match[j] != '/')
+ for (cp = match, slash = NULL; cp - match < matchlen; cp++) {
+ char ch = *cp;
+ if (ch == '/')
+ slash = cp;
+ if (ch == '*' || ch == '[')
break;
- if (matchlen <= j)
- return 1;
+ }
+ if (!slash)
+ slash = match; /* toplevel */
+ else
+ slash++;
+ if (namelen <= slash - match) {
+ /* Looking at "Documentation/" and
+ * the pattern says "Documentation/howto/", or
+ * "Documentation/diff*.txt".
+ */
+ if (!memcmp(match, name, namelen))
+ return 1;
+ }
+ else {
+ /* Looking at "Documentation/howto/" and
+ * the pattern says "Documentation/h*".
+ */
+ if (!memcmp(match, name, slash - match))
+ return 1;
+ }
}
return 0;
}
@@ -232,17 +265,17 @@ static int grep_tree(struct grep_opt *op
int hit = 0;
const char *path;
const unsigned char *sha1;
- char *down_base;
+ char *down;
char *path_buf = xmalloc(PATH_MAX + strlen(tree_name) + 100);
if (tree_name[0]) {
int offset = sprintf(path_buf, "%s:", tree_name);
- down_base = path_buf + offset;
- strcat(down_base, base);
+ down = path_buf + offset;
+ strcat(down, base);
}
else {
- down_base = path_buf;
- strcpy(down_base, base);
+ down = path_buf;
+ strcpy(down, base);
}
len = strlen(path_buf);
@@ -252,7 +285,14 @@ static int grep_tree(struct grep_opt *op
pathlen = strlen(path);
strcpy(path_buf + len, path);
- if (!pathspec_matches(&revs->diffopt, down_base))
+ if (S_ISDIR(mode))
+ /* Match "abc/" against pathspec to
+ * decide if we want to descend into "abc"
+ * directory.
+ */
+ strcpy(path_buf + len + pathlen, "/");
+
+ if (!pathspec_matches(&revs->diffopt, down))
;
else if (S_ISREG(mode))
hit |= grep_sha1(opt, sha1, path_buf);
@@ -264,9 +304,8 @@ static int grep_tree(struct grep_opt *op
if (!data)
die("unable to read tree (%s)",
sha1_to_hex(sha1));
- strcpy(path_buf + len + pathlen, "/");
sub.buf = data;
- hit = grep_tree(opt, revs, &sub, tree_name, down_base);
+ hit |= grep_tree(opt, revs, &sub, tree_name, down);
free(data);
}
update_tree_entry(tree);
--
1.3.1.gd233
^ permalink raw reply related
* [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-01 20:36 UTC (permalink / raw)
To: git
When adding an alternate object store then add entries from its
info/alternates files, too.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
sha1_file.c | 165 +++++++++++++++++++++++++++++++++--------------------------
1 files changed, 93 insertions(+), 72 deletions(-)
7fabfb214a971b8b45ec36dcf47929f4bf0917eb
diff --git a/sha1_file.c b/sha1_file.c
index f2d33af..ff9c989 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -216,6 +216,8 @@ char *sha1_pack_index_name(const unsigne
struct alternate_object_database *alt_odb_list;
static struct alternate_object_database **alt_odb_tail;
+static void read_info_alternates(const char * alternates);
+
/*
* Prepare alternate object database registry.
*
@@ -231,13 +233,77 @@ static struct alternate_object_database
* SHA1, an extra slash for the first level indirection, and the
* terminating NUL.
*/
+static int link_alt_odb_entry(const char * entry, int len, const char * relative_base)
+{
+ struct stat st;
+ const char *objdir = get_object_directory();
+ struct alternate_object_database *ent;
+ struct alternate_object_database *alt;
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = len;
+ int entlen = pfxlen + 43;
+ int base_len = -1;
+
+ if (*entry != '/' && relative_base) {
+ /* Relative alt-odb */
+ if (base_len < 0)
+ base_len = strlen(relative_base) + 1;
+ entlen += base_len;
+ pfxlen += base_len;
+ }
+ ent = xmalloc(sizeof(*ent) + entlen);
+
+ if (*entry != '/' && relative_base) {
+ memcpy(ent->base, relative_base, base_len - 1);
+ ent->base[base_len - 1] = '/';
+ memcpy(ent->base + base_len, entry, len);
+ }
+ else
+ memcpy(ent->base, entry, pfxlen);
+
+ ent->name = ent->base + pfxlen + 1;
+ ent->base[pfxlen + 3] = '/';
+ ent->base[pfxlen] = ent->base[entlen-1] = 0;
+
+ /* Detect cases where alternate disappeared */
+ if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
+ error("object directory %s does not exist; "
+ "check .git/objects/info/alternates.",
+ ent->base);
+ free(ent);
+ return -1;
+ }
+
+ /* Prevent the common mistake of listing the same
+ * thing twice, or object directory itself.
+ */
+ for (alt = alt_odb_list; alt; alt = alt->next)
+ if (!memcmp(ent->base, alt->base, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+ if (!memcmp(ent->base, objdir, pfxlen)) {
+ free(ent);
+ return -1;
+ }
+
+ /* recursively add alternates */
+ read_info_alternates(ent->base);
+
+ ent->base[pfxlen] = '/';
+
+ /* add the alternate entry */
+ *alt_odb_tail = ent;
+ alt_odb_tail = &(ent->next);
+ ent->next = NULL;
+
+ return 0;
+}
+
static void link_alt_odb_entries(const char *alt, const char *ep, int sep,
const char *relative_base)
{
const char *cp, *last;
- struct alternate_object_database *ent;
- const char *objdir = get_object_directory();
- int base_len = -1;
last = alt;
while (last < ep) {
@@ -248,61 +314,10 @@ static void link_alt_odb_entries(const c
last = cp + 1;
continue;
}
- for ( ; cp < ep && *cp != sep; cp++)
- ;
+ while (cp < ep && *cp != sep)
+ cp++;
if (last != cp) {
- struct stat st;
- struct alternate_object_database *alt;
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = cp - last;
- int entlen = pfxlen + 43;
-
- if (*last != '/' && relative_base) {
- /* Relative alt-odb */
- if (base_len < 0)
- base_len = strlen(relative_base) + 1;
- entlen += base_len;
- pfxlen += base_len;
- }
- ent = xmalloc(sizeof(*ent) + entlen);
-
- if (*last != '/' && relative_base) {
- memcpy(ent->base, relative_base, base_len - 1);
- ent->base[base_len - 1] = '/';
- memcpy(ent->base + base_len,
- last, cp - last);
- }
- else
- memcpy(ent->base, last, pfxlen);
-
- ent->name = ent->base + pfxlen + 1;
- ent->base[pfxlen + 3] = '/';
- ent->base[pfxlen] = ent->base[entlen-1] = 0;
-
- /* Detect cases where alternate disappeared */
- if (stat(ent->base, &st) || !S_ISDIR(st.st_mode)) {
- error("object directory %s does not exist; "
- "check .git/objects/info/alternates.",
- ent->base);
- goto bad;
- }
- ent->base[pfxlen] = '/';
-
- /* Prevent the common mistake of listing the same
- * thing twice, or object directory itself.
- */
- for (alt = alt_odb_list; alt; alt = alt->next)
- if (!memcmp(ent->base, alt->base, pfxlen))
- goto bad;
- if (!memcmp(ent->base, objdir, pfxlen)) {
- bad:
- free(ent);
- }
- else {
- *alt_odb_tail = ent;
- alt_odb_tail = &(ent->next);
- ent->next = NULL;
- }
+ link_alt_odb_entry(last, cp - last, relative_base);
}
while (cp < ep && *cp == sep)
cp++;
@@ -310,23 +325,14 @@ static void link_alt_odb_entries(const c
}
}
-void prepare_alt_odb(void)
+static void read_info_alternates(const char * relative_base)
{
- char path[PATH_MAX];
char *map;
- int fd;
struct stat st;
- char *alt;
-
- alt = getenv(ALTERNATE_DB_ENVIRONMENT);
- if (!alt) alt = "";
-
- if (alt_odb_tail)
- return;
- alt_odb_tail = &alt_odb_list;
- link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+ char path[PATH_MAX];
+ int fd;
- sprintf(path, "%s/info/alternates", get_object_directory());
+ sprintf(path, "%s/info/alternates", relative_base);
fd = open(path, O_RDONLY);
if (fd < 0)
return;
@@ -339,11 +345,26 @@ void prepare_alt_odb(void)
if (map == MAP_FAILED)
return;
- link_alt_odb_entries(map, map + st.st_size, '\n',
- get_object_directory());
+ link_alt_odb_entries(map, map + st.st_size, '\n', relative_base);
+
munmap(map, st.st_size);
}
+void prepare_alt_odb(void)
+{
+ char *alt;
+
+ alt = getenv(ALTERNATE_DB_ENVIRONMENT);
+ if (!alt) alt = "";
+
+ if (alt_odb_tail)
+ return;
+ alt_odb_tail = &alt_odb_list;
+ link_alt_odb_entries(alt, alt + strlen(alt), ':', NULL);
+
+ read_info_alternates(get_object_directory());
+}
+
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
{
char *name = sha1_file_name(sha1);
--
1.3.1.gc585-dirty
--
Martin Waitz
^ permalink raw reply related
* Re: cvsserver problem with eclipse?
From: Martin Langhoff @ 2006-05-01 20:38 UTC (permalink / raw)
To: Bill Burdick; +Cc: git
In-Reply-To: <4455B863.8040808@mobilereasoning.com>
On 5/1/06, Bill Burdick <bill@mobilereasoning.com> wrote:
> OK, I changed the way I was testing this to match your usage plan and I
> still got the same results. It works just fine for vanilla CVS; cvs
> status shows the re revision in the repo and cvs update brings it in.
That's a good start!
> Eclipse has the same funky behavior: Compare with latest at the project
> level shows no differences, but compare with latest on the changed file
> actually does an update instead of popping up the Eclipse diff viewer.
Hmmm. Eclipse does some weird funky sh*t sometimes. Can you ask it to
get you a log? There's an option in Eclipse CVS control settings that
will enable logging of cvs commands to the console. Enable it, and
then start Eclipse from the commandline, piping stderr and stdout to a
logfile.
There are also some weird differences depending on how you ask for the
update or diff. I hate doing this but I'll have to ask you to tell me
exactly how you ask for the diff and for the update.
And the platform you are running Eclipse on.
> By the way, I had trouble at first accessing the repo with SSH because
> of permissions on the sqlite db. I'm not totally sure about the
> implications for multiple users, but maybe just using a common group
> will work fine?
Yes, a common group is the thing to do.
$ chgrp gitusers *sqlite
$ chmod g+w *sqlite
> I'm really happy with git and git-cvsserver! I'm hoping to be able to
> standardize on it for our Eclipse work. It seems like it should be
Great to hear that!
cheers,
martin
^ permalink raw reply
* Re: [RFC] Terms to add to glossary
From: Jakub Narebski @ 2006-05-01 20:55 UTC (permalink / raw)
To: git
In-Reply-To: <e332g6$hpl$1@sea.gmane.org>
cherry picking::
In SCM jargon, cherry picking is used to describe the action of
selecting which commit should be ported from one branch to another.
In GIT it means given one existing commit, apply the change
the patch introduces, and record a new commit that records it.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Junio C Hamano @ 2006-05-01 20:56 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060501203631.GH20847@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> When adding an alternate object store then add entries from its
> info/alternates files, too.
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
Happy. Sometimes it pays off to leave things that can be
improved as they are, mention just "we might want to do this
instead", and forget about it myself. Somebody else comes in
and fixes it for me ;-).
If you have a local copy of Linus, Jeff and David trees, you
could arrange Jeff tree to borrow from Linus and David, and
David tree to borrow from Linus and Jeff. I wonder what the new
code does when you add a new repository that borrows from Jeff
and David. Does it borrow from Linus twice? Four times? Does
it stop without falling into endless recursion? I did not do
this myself because I was lazy and did not want to address these
issues.
^ permalink raw reply
* Re: cvsserver problem with eclipse?
From: Bill Burdick @ 2006-05-01 16:23 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605011338i5498f857lf230d9a965aa759@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3876 bytes --]
OK, I replaced the eclipse file (yoda) with the latest from the head.
Then I changed it in my git project, committed it, and pushed it to the
shared repo. Finally, I did a "compare with latest from head" and it
proceeded to update the file and then said that there were no changes.
Here's the log:
Valid-responses ok error M E Checked-in Valid-requests Template
Set-sticky MT Clear-static-directory Module-expansion
Set-static-directory Clear-sticky New-entry Merged Removed Updated
Remove-entry Update-existing Copy-file Created Notified Mod-time
valid-requests
Valid-requests remove add status Entry watchers ci tag log co Modified
Questionable admin Root history valid-requests Global_option Argumentx
annotate Valid-responses Unchanged Directory rlog Argument
expand-modules diff editors update
ok
Root /tmp/public.git
CMD> cvs -n update -d "/yoda/yoda"
Global_option -n
Argument -d
Directory .
/tmp/public.git/yoda
Entry /yoda/1.9///
Modified yoda
u=rw,g=rw,o=r
48
Argument yoda
Directory .
/tmp/public.git/yoda
update
M C yoda
Update-existing ./
/tmp/public.git/yoda/yoda
/yoda/1.10/+//
u=rw,g=rw,o=rw
95
ok
RESULT> Status OK: org.eclipse.team.cvs.core code=0 ok null
Valid-responses ok error M E Checked-in Valid-requests Template
Set-sticky MT Clear-static-directory Module-expansion
Set-static-directory Clear-sticky New-entry Merged Removed Updated
Remove-entry Update-existing Copy-file Created Notified Mod-time
valid-requests
Valid-requests remove add status Entry watchers ci tag log co Modified
Questionable admin Root history valid-requests Global_option Argumentx
annotate Valid-responses Unchanged Directory rlog Argument
expand-modules diff editors update
ok
Root /tmp/public.git
CMD> cvs status "yoda"
Directory .
/tmp/public.git/yoda
Entry /yoda/0///
Modified yoda
u=rw,g=rw,o=r
0
Argument yoda
Directory .
/tmp/public.git/yoda
status
M ===================================================================
M File: yoda Status: Needs Checkout
M Working revision: 0
M Repository revision: 1.10 /tmp/public.git/yoda/yoda,v
M Sticky Tag: (none)
M Sticky Date: (none)
M Sticky Options: (none)
M
ok
RESULT> Status OK: org.eclipse.team.cvs.core code=0 ok null
Martin Langhoff wrote:
> On 5/1/06, Bill Burdick <bill@mobilereasoning.com> wrote:
>
>> OK, I changed the way I was testing this to match your usage plan and I
>> still got the same results. It works just fine for vanilla CVS; cvs
>> status shows the re revision in the repo and cvs update brings it in.
>
>
> That's a good start!
>
>> Eclipse has the same funky behavior: Compare with latest at the project
>> level shows no differences, but compare with latest on the changed file
>> actually does an update instead of popping up the Eclipse diff viewer.
>
>
> Hmmm. Eclipse does some weird funky sh*t sometimes. Can you ask it to
> get you a log? There's an option in Eclipse CVS control settings that
> will enable logging of cvs commands to the console. Enable it, and
> then start Eclipse from the commandline, piping stderr and stdout to a
> logfile.
>
> There are also some weird differences depending on how you ask for the
> update or diff. I hate doing this but I'll have to ask you to tell me
> exactly how you ask for the diff and for the update.
>
> And the platform you are running Eclipse on.
>
>> By the way, I had trouble at first accessing the repo with SSH because
>> of permissions on the sqlite db. I'm not totally sure about the
>> implications for multiple users, but maybe just using a common group
>> will work fine?
>
>
> Yes, a common group is the thing to do.
>
> $ chgrp gitusers *sqlite
> $ chmod g+w *sqlite
>
>> I'm really happy with git and git-cvsserver! I'm hoping to be able to
>> standardize on it for our Eclipse work. It seems like it should be
>
>
> Great to hear that!
>
> cheers,
>
>
>
> martin
>
[-- Attachment #2: bill.vcf --]
[-- Type: text/x-vcard, Size: 192 bytes --]
begin:vcard
fn:Bill Burdick
n:Burdick;Bill
org:Mobile Reasoning
email;internet:bill@mobilereasoning.com
title:Chief Scientist
tel;work:913-484-0172
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* git-unpack-objects
From: Josh Boyer @ 2006-05-01 22:52 UTC (permalink / raw)
To: Git Mailing List
I was playing around with git repack and decided to "undo" the repack
I did using git-unpack objects. Below is the output:
[jwboyer@vader linux-2.6]$ git-unpack-objects <
.git/objects/pack/pack-497d1e639572013de48eeb00cb95738d2ca959e1.pack
Unpacking 236950 objects
100% (236950/236950) done
[jwboyer@vader linux-2.6]$ ls -l .git/objects/
total 8
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 info
drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 pack
[jwboyer@vader linux-2.6]$
As you can see, the objects don't seem to get unpacked back into the
.git directory. So either I am misunderstanding what that command is
supposed to do, or it isn't working properly.
Any ideas?
thx,
josh
^ permalink raw reply
* Re: [PATCH] Transitively read alternatives
From: Martin Waitz @ 2006-05-01 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvdsbuj.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
hoi :)
On Mon, May 01, 2006 at 01:56:36PM -0700, Junio C Hamano wrote:
> If you have a local copy of Linus, Jeff and David trees, you
> could arrange Jeff tree to borrow from Linus and David, and
> David tree to borrow from Linus and Jeff. I wonder what the new
> code does when you add a new repository that borrows from Jeff
> and David. Does it borrow from Linus twice? Four times? Does
> it stop without falling into endless recursion? I did not do
> this myself because I was lazy and did not want to address these
> issues.
I haven't tested these corner cases extensively yet, but from reading
the code it should behave like this:
If you have loops or multiple references to the same repository then
only the first occurance is used. When reading a reference to an alternate
object store for the second time it is simply ignored.
But of course you should be careful when you set up alternate files.
Having two repositories reference each other and then simultanously
running git-prune in both is obviously not a good idea ;-).
... more testing ...
Well of course practice and reality always differ... I'll send an
updated patch shortly ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-unpack-objects
From: Junio C Hamano @ 2006-05-01 23:09 UTC (permalink / raw)
To: git
In-Reply-To: <625fc13d0605011552j4189338bx14083657acffc18e@mail.gmail.com>
"Josh Boyer" <jwboyer@gmail.com> writes:
> I was playing around with git repack and decided to "undo" the repack
> I did using git-unpack objects. Below is the output:
>
> [jwboyer@vader linux-2.6]$ git-unpack-objects <
> .git/objects/pack/pack-497d1e639572013de48eeb00cb95738d2ca959e1.pack
> Unpacking 236950 objects
> 100% (236950/236950) done
> [jwboyer@vader linux-2.6]$ ls -l .git/objects/
> total 8
> drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 info
> drwxrwxr-x 2 jwboyer jwboyer 4096 May 1 17:48 pack
> [jwboyer@vader linux-2.6]$
>
> As you can see, the objects don't seem to get unpacked back into the
> .git directory. So either I am misunderstanding what that command is
> supposed to do, or it isn't working properly.
>
> Any ideas?
unpack tries to unpack and if it already has the object it
skips.
If you really wanted to do it, here is a way to do so.
mv .git/objets/pack/pack-49*.pack \
.git/objets/pack/pack-49*.idx .
git unpack-objects <pack-49*.pack
^ 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