* Experimental "git prune"
From: Linus Torvalds @ 2006-07-04 22:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This is an example of how "git prune" could be speeded up a lot.
This needs the builtin magic to actually enable it, and the "printf" needs
to be made a real unlink, but as far as I can tell it actually works.
Comments?
Linus
----
/*
* builtin-prune.c
*/
#include "cache.h"
#include "refs.h"
#include "tag.h"
#include "commit.h"
#include "tree.h"
#include "blob.h"
#include "tree-walk.h"
#include "diff.h"
#include "revision.h"
#include "builtin.h"
#include "cache-tree.h"
static struct rev_info revs;
static int prune_object(char *path, const char *filename, const unsigned char *sha1)
{
printf("%s/%s should be pruned\n", path, filename);
return 0;
}
static int prune_dir(int i, char *path)
{
DIR *dir = opendir(path);
struct dirent *de;
if (!dir)
return 0;
while ((de = readdir(dir)) != NULL) {
char name[100];
unsigned char sha1[20];
int len = strlen(de->d_name);
switch (len) {
case 2:
if (de->d_name[1] != '.')
break;
case 1:
if (de->d_name[0] != '.')
break;
continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
if (get_sha1_hex(name, sha1) < 0)
break;
/*
* Do we know about this object?
* It must have been reachable
*/
if (lookup_object(sha1))
continue;
prune_object(path, de->d_name, sha1);
continue;
}
fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
}
closedir(dir);
return 0;
}
static void prune_object_dir(const char *path)
{
int i;
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
prune_dir(i, dir);
}
}
static void process_blob(struct blob *blob,
struct object_array *p,
struct name_path *path,
const char *name)
{
struct object *obj = &blob->object;
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
/* Nothing to do, really .. The blob lookup was the important part */
}
static void process_tree(struct tree *tree,
struct object_array *p,
struct name_path *path,
const char *name)
{
struct object *obj = &tree->object;
struct tree_desc desc;
struct name_entry entry;
struct name_path me;
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
if (parse_tree(tree) < 0)
die("bad tree object %s", sha1_to_hex(obj->sha1));
name = strdup(name);
add_object(obj, p, path, name);
me.up = path;
me.elem = name;
me.elem_len = strlen(name);
desc.buf = tree->buffer;
desc.size = tree->size;
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
else
process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
}
free(tree->buffer);
tree->buffer = NULL;
}
static void process_tag(struct tag *tag, struct object_array *p, const char *name)
{
struct object *obj = &tag->object;
struct name_path me;
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
me.up = NULL;
me.elem = "tag:/";
me.elem_len = 5;
if (parse_tag(tag) < 0)
die("bad tag object %s", sha1_to_hex(obj->sha1));
add_object(tag->tagged, p, NULL, name);
}
static void walk_commit_list(struct rev_info *revs)
{
int i;
struct commit *commit;
struct object_array objects = { 0, 0, NULL };
/* Walk all commits, process their trees */
while ((commit = get_revision(revs)) != NULL)
process_tree(commit->tree, &objects, NULL, "");
/* Then walk all the pending objects, recursively processing them too */
for (i = 0; i < revs->pending.nr; i++) {
struct object_array_entry *pending = revs->pending.objects + i;
struct object *obj = pending->item;
const char *name = pending->name;
if (obj->type == TYPE_TAG) {
process_tag((struct tag *) obj, &objects, name);
continue;
}
if (obj->type == TYPE_TREE) {
process_tree((struct tree *)obj, &objects, NULL, name);
continue;
}
if (obj->type == TYPE_BLOB) {
process_blob((struct blob *)obj, &objects, NULL, name);
continue;
}
die("unknown pending object %s (%s)", sha1_to_hex(obj->sha1), name);
}
}
static int add_one_ref(const char *path, const unsigned char *sha1)
{
struct object *object = parse_object(sha1);
if (!object)
die("bad object ref: %s:%s", path, sha1_to_hex(sha1));
add_pending_object(&revs, object, "");
return 0;
}
static void add_one_tree(const unsigned char *sha1)
{
struct tree *tree = lookup_tree(sha1);
add_pending_object(&revs, &tree->object, "");
}
static void add_cache_tree(struct cache_tree *it)
{
int i;
if (it->entry_count >= 0)
add_one_tree(it->sha1);
for (i = 0; i < it->subtree_nr; i++)
add_cache_tree(it->down[i]->cache_tree);
}
static void add_cache_refs(void)
{
int i;
read_cache();
for (i = 0; i < active_nr; i++) {
lookup_blob(active_cache[i]->sha1);
/*
* We could add the blobs to the pending list, but quite
* frankly, we don't care. Once we've looked them up, and
* added them as objects, we've really done everything
* there is to do for a blob
*/
}
if (active_cache_tree)
add_cache_tree(active_cache_tree);
}
int cmd_prune(int argc, const char **argv, char **envp)
{
/*
* Set up revision parsing, and mark us as being interested
* in all object types, not just commits.
*/
init_revisions(&revs);
revs.tag_objects = 1;
revs.blob_objects = 1;
revs.tree_objects = 1;
/* Add all external refs */
for_each_ref(add_one_ref);
/* Add all refs from the index file */
add_cache_refs();
/*
* Set up the revision walk - this will move all commits
* from the pending list to the commit walking list.
*/
prepare_revision_walk(&revs);
walk_commit_list(&revs);
prune_object_dir(get_object_directory());
return 0;
}
^ permalink raw reply
* [PATCH] Beautifulise git-show output
From: beber.mailing @ 2006-07-04 22:34 UTC (permalink / raw)
To: git; +Cc: Bertrand Jacquin
From: Bertrand Jacquin (Beber) <beber.mailing@gmail.com>
diff --git a/log-tree.c b/log-tree.c
index ebb49f2..55f77ad 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -164,7 +164,7 @@ int log_tree_diff_flush(struct rev_info
}
if (opt->loginfo && !opt->no_commit_id)
- show_log(opt, opt->loginfo, opt->diffopt.with_stat ? "---\n" : "\n");
+ show_log(opt, opt->loginfo, opt->diffopt.with_stat ? "\n---\n" : "\n");
diff_flush(&opt->diffopt);
return 1;
}
--
1.4.1
^ permalink raw reply related
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xn9gjh5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > We could introduce a time.maximumSkew variable, and just walk only
> > that much further when traversing the commits.
>
> We could have had "commit generation number" in the commit
> object header, and use that instead of commit timestamps for
> these traversal purposes. The generation number for a commit is
> defined to be max(generation number of its parents)+1 and we
> prime the recursive this definition by defining the generation
> number for the root commit to be one.
Are you really, really sure this is a remedy? I, for one, am quite sure of
the opposite. What you propose is just another time scale, only this time,
it is not universally true (not even minus local incompetence to keep the
clock accurate).
If that should be not true, you always could rely on topo order. Which
does not seem to solve the problem for you.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a custom ./configure script
From: Petr Baudis @ 2006-07-04 21:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8drmq$8ec$1@sea.gmane.org>
Dear diary, on Tue, Jul 04, 2006 at 03:50:16PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > The patch is on top of pu, that is Jakub Narebski's autoconf patch, because
> > it reuses most of its infrastructure and just replaces the configure script.
>
> If you named it for example configure.sh, then autoconf generated version,
> and your by hand created version could coexist.
I'm not opposed to it per se, but I'm just not sure if it makes any
sense to support them both in parallel, since then you have parallel
infrastructure doing the exactly same thing, or worse yet - performing
a subtly different set of tests. The benefit is unclear to me.
Another thing is that it's named *everywhere* ./configure and if I use a
different name now then it will be hard to rename.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: contrib/ status
From: Eric Wong @ 2006-07-04 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqs6pfhi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Junio C Hamano <junkio@cox.net> wrote:
> >> Junio C Hamano <junkio@cox.net> writes:
> >>
> >> > ... the
> >> > things under contrib/ are not part of git.git but are there only
> >> > for convenience....
> >>
> >> This reminds me of something quite different. I am getting an
> >> impression that enough people have been helped by git-svn and it
> >> might be a good idea to have it outside contrib/ area.
> >
> > That would be great. IMHO, it puts git in a position to supplant
> > centralized SVN usage one developer at a time, making it easier
> > to make a gradual transition to git. Of course, there's also svk
> > in a similar position...
>
> OK, then let's give a few days (it's a long weekend extendeding
> into July 4th in the US) to let others from the list chime in,
> and then please help me migrate your test scripts and Makefile
> pieces into the toplevel project.
Ok, I'll have a patch ready by then. I'm not sure which number family I
should take for the tests, 8xxx and 9xxx don't have any rules for their
use, but the [89]0xx area seems taken. Would naming them 91xx be good?
Also, the tests can be extremely slow since they rely on svn, so there
will be a way to skip the tests if users are not interested.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] rev-list: free commit_list in ... handler
From: Junio C Hamano @ 2006-07-04 21:37 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <20060704192220.GA9500@lsrfire.ath.cx>
Thanks.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 21:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> We could introduce a time.maximumSkew variable, and just walk only
> that much further when traversing the commits.
We could have had "commit generation number" in the commit
object header, and use that instead of commit timestamps for
these traversal purposes. The generation number for a commit is
defined to be max(generation number of its parents)+1 and we
prime the recursive this definition by defining the generation
number for the root commit to be one. A moral equivalent
alternative would be to notice that the commit timestamp we are
going to use to create for a new commit is smaller than one of
the commit timestamps of its parent commits and adjust the
commit timestamp in such a case by git-commit-tree, perhaps with
a warning.
These are pretty much water under the bridge by now, for two
reasons. One is that I think it is better to make the tools
that use get_merge_bases() prepared for the case the function
includes suboptimal bases anyway, and the other is once we do
that this is not a strong enough justification to modify the
commit object format.
^ permalink raw reply
* Re: git2rss --- publish changes from git-log via RSS
From: Jakub Narebski @ 2006-07-04 21:09 UTC (permalink / raw)
To: git
In-Reply-To: <20060704191135.GB10534@rahul.net>
Bennett Todd wrote:
> Just switched Bent Linux[1] from darcs to git (darcs is sexy, but I
> can build git; ghc defeats me). So I hacked up a quick and simple
> git2rss to replace my use of darcs2rss for publishing updates.
>
> <URL:http://bent.latency.net/git2rss>
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#git2rss
Please correct/expand the info if needed.
BTW. gitweb includes RSS feed, see e.g.:
http://www.kernel.org/git/?p=git/git.git;a=rss
http://www.kernel.org/git/?p=git/git.git;a=opml
> I like to read the back archives before posting to a list I've just
> subscribed to, but couldn't find a downloadable version of the git
> list. If anybody could point me to one, I'd appreciate it.
Both GitWiki and Wikipedia
http://git.or.cz/gitwiki/GitCommunity
http://en.wikipedia.org/wiki/Git_%28software%29
mentions several git mailing list archives
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 21:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607041219540.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> But I have to say that the diffstat at least for me is absolutely
> invaluable.
Oh, I absolutely agree with that and somebody who suggests to
turn it off by default needs a very good argument to convince
me.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 20:18 UTC (permalink / raw)
To: Johannes Schindelin, git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
>> A Large Angry SCM <gitzilla@gmail.com> writes:
>>
>>>> This is a good demonstration that merge-base may not give you
>>>> minimal set for pathological cases. If you want to be through
>>>> you could traverse everything to make sure we do not say 'S' is
>>>> relevant, but that is quite expensive, so I think there will
>>>> always be artifacts of horizon effect like this no matter how
>>>> you try to catch it (didn't I keep saying that already?).
>>> The problem is in mark_reachable_commits(); it is either superfluous
>>> or it needs to parse_commit() those commits that haven't been parsed
>>> yet that it needs to traverse.
>> Yes, you could traverse everything. But that is not practical.
>> We have known that the clean-up pass has this horizon effect,
>> and it is a compromise.
>
> We could introduce a time.maximumSkew variable, and just walk only
> that much further when traversing the commits.
>
> So, if you do not trust your clients to have a proper ntp setup, just say
> "I trust my peers to be off at most 1 day". That would save lots vs
> traverse-everything.
The fuzz would only serve to mask, even more, that the heuristic is
broken. But, it would also allow the (broken) heuristic to be used _and_
let the user decide how much effort may be used to find the correct bases.
If this happens, it should be (yet another) user configurable; either,
per repository, command line, or both.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 20:08 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vpsgllsnp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>> This is a good demonstration that merge-base may not give you
>>> minimal set for pathological cases. If you want to be through
>>> you could traverse everything to make sure we do not say 'S' is
>>> relevant, but that is quite expensive, so I think there will
>>> always be artifacts of horizon effect like this no matter how
>>> you try to catch it (didn't I keep saying that already?).
>> The problem is in mark_reachable_commits(); it is either superfluous
>> or it needs to parse_commit() those commits that haven't been parsed
>> yet that it needs to traverse.
>
> Yes, you could traverse everything. But that is not practical.
> We have known that the clean-up pass has this horizon effect,
> and it is a compromise.
The clean-up pass was devised to eliminate bases that are reachable from
other bases. It just doesn't look hard enough.
> If you apply this testing patch on top of yours, you will see
> that parsing more commits at that point makes the clean-up
> pass go all the way down to the root commit.
Yes, I was aware of graphs that would have that behavior.
The root of the problem is that the heuristic, that attempts to use
timestamps to detect that a commit is _not_ reachable from a given
commit, relies on the timestamps of commits with a reachability
relationship to have a relationship that matches the graph.
> We may alternatively not use the clean-up pass at all, but I
> suspect that might give us many false positives. I don't
> remember the details but I think we added it while fixing
> merge-base in the real life situation.
The history of the clean-up pass is that before it was added,
git-merge-base was returning a base reachable from another base, and the
base returned was, in some significant way, worse for merging. My
construct demonstrates that the clean-up pass only deals with special case.
> It may be interesting to run tests on real merges (I believe the
> kernel repository has a handful merges that have more than one
> merge bases) to see how effective the current clean-up pass is.
> It may turn out to be ineffective in practice, in which case we
> could kill it off.
Although a very important set of repositories to Git, the linux kernel
repositories may no longer be representative of the diversity of Git
use. Still, it would be interesting to know the outcome.
^ permalink raw reply
* Re: Improve git-peek-remote
From: Linus Torvalds @ 2006-07-04 20:01 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607041222110.12404@g5.osdl.org>
On Tue, 4 Jul 2006, Linus Torvalds wrote:
>
> This makes git-peek-remote able to basically do everything that
> git-ls-remote does (but obviously just for the native protocol, so no
> http[s]: or rsync: support).
Btw, if it wasn't clear - it's not actually a git-ls-remote replacement
yet, even for native protocols. It doesn't actually do the remote URL
thing, so you can't do simple things like
git peek-remote origin
for example.
Things like "git fetch", that do their own remote parsing anyway, don't
actually care, but I thought I'd mention it anyway, just so nobody gets
surprised.
Linus
^ permalink raw reply
* Improve git-peek-remote
From: Linus Torvalds @ 2006-07-04 19:29 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This makes git-peek-remote able to basically do everything that
git-ls-remote does (but obviously just for the native protocol, so no
http[s]: or rsync: support).
The default behaviour is the same, but you can now give a mixture of
"--refs", "--tags" and "--heads" flags, where "--refs" forces
git-peek-remote to only show real refs (ie none of the fakey tag lookups,
but also not the special pseudo-refs like HEAD and MERGE_HEAD).
The "--tags" and "--heads" flags respectively limit the output to just
regular tags and heads, of course.
You can still also ask to limit them by name too.
You can combine the flags, so
git peek-remote --refs --tags .
will show all local _true_ tags, without the generated tag lookups
(compare the output without the "--refs" flag).
And "--tags --heads" will show both tags and heads, but will avoid (for
example) any special refs outside of the standard locations.
I'm also planning on adding a "--ignore-local" flag that allows us to ask
it to ignore any refs that we already have in the local tree, but that's
an independent thing.
All this is obviously gearing up to making "git fetch" cheaper.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cache.h | 6 +++++-
connect.c | 35 +++++++++++++++++++++++++++++++----
peek-remote.c | 28 +++++++++++++++++++++-------
send-pack.c | 2 +-
4 files changed, 58 insertions(+), 13 deletions(-)
diff --git a/cache.h b/cache.h
index 84770bf..7b5c91c 100644
--- a/cache.h
+++ b/cache.h
@@ -322,13 +322,17 @@ struct ref {
char name[FLEX_ARRAY]; /* more */
};
+#define REF_NORMAL (1u << 0)
+#define REF_HEADS (1u << 1)
+#define REF_TAGS (1u << 2)
+
extern int git_connect(int fd[2], char *url, const char *prog);
extern int finish_connect(pid_t pid);
extern int path_match(const char *path, int nr, char **match);
extern int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all);
extern int get_ack(int fd, unsigned char *result_sha1);
-extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, int ignore_funny);
+extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, unsigned int flags);
extern int server_supports(const char *feature);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
diff --git a/connect.c b/connect.c
index 9a87bd9..4422a0d 100644
--- a/connect.c
+++ b/connect.c
@@ -12,11 +12,40 @@ #include <signal.h>
static char *server_capabilities = NULL;
+static int check_ref(const char *name, int len, unsigned int flags)
+{
+ if (!flags)
+ return 1;
+
+ if (len > 45 || memcmp(name, "refs/", 5))
+ return 0;
+
+ /* Skip the "refs/" part */
+ name += 5;
+ len -= 5;
+
+ /* REF_NORMAL means that we don't want the magic fake tag refs */
+ if ((flags & REF_NORMAL) && check_ref_format(name) < 0)
+ return 0;
+
+ /* REF_HEADS means that we want regular branch heads */
+ if ((flags & REF_HEADS) && !memcmp(name, "heads/", 6))
+ return 1;
+
+ /* REF_TAGS means that we want tags */
+ if ((flags & REF_TAGS) && !memcmp(name, "tags/", 5))
+ return 1;
+
+ /* All type bits clear means that we are ok with anything */
+ return !(flags & ~REF_NORMAL);
+}
+
/*
* Read all the refs from the other end
*/
struct ref **get_remote_heads(int in, struct ref **list,
- int nr_match, char **match, int ignore_funny)
+ int nr_match, char **match,
+ unsigned int flags)
{
*list = NULL;
for (;;) {
@@ -43,10 +72,8 @@ struct ref **get_remote_heads(int in, st
server_capabilities = strdup(name + name_len + 1);
}
- if (ignore_funny && 45 < len && !memcmp(name, "refs/", 5) &&
- check_ref_format(name + 5))
+ if (!check_ref(name, name_len, flags))
continue;
-
if (nr_match && !path_match(name, nr_match, match))
continue;
ref = xcalloc(1, sizeof(*ref) + len - 40);
diff --git a/fetch-pack.c b/fetch-pack.c
diff --git a/peek-remote.c b/peek-remote.c
index a90cf22..2b30980 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -7,11 +7,11 @@ static const char peek_remote_usage[] =
"git-peek-remote [--exec=upload-pack] [host:]directory";
static const char *exec = "git-upload-pack";
-static int peek_remote(int fd[2])
+static int peek_remote(int fd[2], unsigned flags)
{
struct ref *ref;
- get_remote_heads(fd[0], &ref, 0, NULL, 0);
+ get_remote_heads(fd[0], &ref, 0, NULL, flags);
packet_flush(fd[1]);
while (ref) {
@@ -28,6 +28,7 @@ int main(int argc, char **argv)
int fd[2];
pid_t pid;
int nongit = 0;
+ unsigned flags = 0;
setup_git_directory_gently(&nongit);
@@ -35,22 +36,35 @@ int main(int argc, char **argv)
char *arg = argv[i];
if (*arg == '-') {
- if (!strncmp("--exec=", arg, 7))
+ if (!strncmp("--exec=", arg, 7)) {
exec = arg + 7;
- else
- usage(peek_remote_usage);
- continue;
+ continue;
+ }
+ if (!strcmp("--tags", arg)) {
+ flags |= REF_TAGS;
+ continue;
+ }
+ if (!strcmp("--heads", arg)) {
+ flags |= REF_HEADS;
+ continue;
+ }
+ if (!strcmp("--refs", arg)) {
+ flags |= REF_NORMAL;
+ continue;
+ }
+ usage(peek_remote_usage);
}
dest = arg;
break;
}
+
if (!dest || i != argc - 1)
usage(peek_remote_usage);
pid = git_connect(fd, dest, exec);
if (pid < 0)
return 1;
- ret = peek_remote(fd);
+ ret = peek_remote(fd, flags);
close(fd[0]);
close(fd[1]);
finish_connect(pid);
diff --git a/send-pack.c b/send-pack.c
index af93b11..4019a4b 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -239,7 +239,7 @@ static int send_pack(int in, int out, in
int expect_status_report = 0;
/* No funny business with the matcher */
- remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
+ remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL);
get_local_heads();
/* Does the other end support the reporting? */
^ permalink raw reply related
* [PATCH] rev-list: free commit_list in ... handler
From: Rene Scharfe @ 2006-07-04 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
Johannes noticed the missing call to free_commit_list() in the
patch from Santi to add ... support to rev-parse. Turns out I
forgot it too in rev-list. This patch is against the next branch
(3b1d06a).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
diff --git a/revision.c b/revision.c
index 66390c9..a7750e6 100644
--- a/revision.c
+++ b/revision.c
@@ -817,6 +817,7 @@ int setup_revisions(int argc, const char
exclude = get_merge_bases(a, b, 1);
add_pending_commit_list(revs, exclude,
flags_exclude);
+ free_commit_list(exclude);
a->object.flags |= flags;
} else
a->object.flags |= flags_exclude;
^ permalink raw reply related
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jnareb
In-Reply-To: <7vk66tgt6n.fsf@assigned-by-dhcp.cox.net>
On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
> I had an impression, though the report does not talk about this
> specific detail, that the extra time we are paying is because
> the "git pull" test is done without suppressing the final
> diffstat phase.
I'm pretty sure that was the reason for the particular hg issue. Looking
at the "clone" times, the problem is almost certainly not the actual
pulling.
The diffstat generation is often the largest part of a git merge. It's
gotten cheaper since the hg benchmarks were done (I think they were done
back before the integrated diff generation, so they also have the overhead
of executing a lot of external GNU diff processes), but it's still not
"cheap".
But I have to say that the diffstat at least for me is absolutely
invaluable.
Linus
^ permalink raw reply
* git2rss --- publish changes from git-log via RSS
From: Bennett Todd @ 2006-07-04 19:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Just switched Bent Linux[1] from darcs to git (darcs is sexy, but I
can build git; ghc defeats me). So I hacked up a quick and simple
git2rss to replace my use of darcs2rss for publishing updates.
<URL:http://bent.latency.net/git2rss>
I hardcoded a couple of Bent-linux-specific bits in there, if
anybody else is actually interested in this, let me know, we can
discuss how to peel 'em out.
I like to read the back archives before posting to a list I've just
subscribed to, but couldn't find a downloadable version of the git
list. If anybody could point me to one, I'd appreciate it.
-Bennett
[1] Bent Linux probably isn't of interest to anybody else, it's my
mid-life crisis project, sound bite "unix as I came to love hear in
the early '80s, when she and I were both much younger, slimmer, and
healthier". uClibc, static linking only, no dynamic loading, no
i18n, nothing gui. Handy for building initrds, perhaps useful for
embedded applications. Nobody but a total crank like me would use it
as their favoured workstation OS.
<URL:http://bent.latency.net/bent/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Making perl scripts include the correct Git.pm
From: Marco Costalba @ 2006-07-04 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwtavxyas.fsf@assigned-by-dhcp.cox.net>
On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> On the other front, I applied the --remove-empty --parents fix
> by Linus to "master". Since this broke gitk and qgit it might
> warrant a 1.4.1.1 hotfix.
>
Well on the qgit side the bug is plus or less harmless, you see some
spurious revisions in file annotation history and a warning message on
stderr, but not a show stopper.
Marco
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <e8dqfo$3ff$1@sea.gmane.org>
On 7/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> >
> > Is this something that can fulfill you request? do you need something
> > different? perhaps something as a "default to current selected SHA as
> > input argument" flag.
>
> It would be nice (I don't know if feasible) that either to provide some kind
> of parameters substitution in the likes of "%head" in the invocation line
> for a script to be expanded to the sha1 or name of head of currently
> selected commit.
>
Well, I think that the indiscussed champion in this field is git-rev-parse
Please note that an action have not to be _one_ git command, but you
can assign a command sequence to an action, if the first command is
git-rev-parse probably you have what you need.
I have to better explain some implemantation details. In case a multi
line text is set as an action content, qgit wraps up the content in a
temporary script and run the script as a whole.
So you can use anything inside your action definition.
NOTE: this is possible because the input parameters are _always_
appended to the first line command only.
As example if the action 'test' is defined as:
echo
echo 2
echo 3
When you run 'test' and insert '1' when prompted for input
parameters the output will be:
1
2
3
Hope this helps.
Marco
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5bfff550607040421id4e71efw38ee2bd773c949de@mail.gmail.com>
On 7/4/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/4/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Marco Costalba" <mcostalba@gmail.com> writes:
> >
>
> I have started to implement the feature suggested by Jakub (patch in
> working dir only, not committed).
Ok. I have pushed two patches, the first with support for applying a
patch series in working dir only, i.e. without to create new commits,
the second to add "branch that a rev belongs to" info as in gitk, near
tags information was already there.
The difference with gitk is that only loaded branch/tags are
considered, this is to better scale.
Anyhow, due to little tricks ;-) , indexing is very fast, about 250ms
to index the whole Linux tree on my box.
Marco
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 17:45 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I wonder if the problem detected here is also responsible with results
> of Jeremy Blosser benchmark comparing git with Mercurial
> http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
> where git wins for clone, status and log, but is slower for pull.
I had an impression, though the report does not talk about this
specific detail, that the extra time we are paying is because
the "git pull" test is done without suppressing the final
diffstat phase.
^ permalink raw reply
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Junio C Hamano @ 2006-07-04 17:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607041617290.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Ummm. After reading my original mail again: bad tobacco that was. Of
> course, I meant discard_cache(), not get_merge_bases(). Setting
> index_file_timestamp in get_merge_bases() would be wrong.
I was well aware you were talking about discard_cache(). I
think these two clean-ups are good to have there.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Thomas Glanzmann @ 2006-07-04 16:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8e28j$v8v$1@sea.gmane.org>
Hello,
> See summary at
> http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
thank you for clarifing! I finally understand why Solaris folks prefer
hg over git: It is dog slow. - So it fits the general philosophy behind
Solaris.
Thomas
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Jakub Narebski @ 2006-07-04 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <1151949764.4723.51.camel@neko.keithp.com>
I wonder if the problem detected here is also responsible with results
of Jeremy Blosser benchmark comparing git with Mercurial
http://lists.ibiblio.org/pipermail/sm-discuss/2006-May/014586.html
where git wins for clone, status and log, but is slower for pull.
See summary at
http://git.or.cz/gitwiki/GitBenchmarks#head-85df1bb7f019c4c504e34cde43450ef69349882f
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Jakub Narebski @ 2006-07-04 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30606240918m6b452314m6514b5e5fc86f147@mail.gmail.com>
Paolo Ciarrocchi wrote:
> I was wondering whether it could be a good idea to have a kind of "GIT
> users survey" when google pointed my eyes to this page:
> http://www.selenic.com/pipermail/mercurial/2006-April/007513.html
>
> So I modified the content of the survey and published a DRAFT here:
> http://paolo.ciarrocchi.googlepages.com/GITSurvey
Could you please add the final version (and of course results) on
Git Wiki (http://git.or.cz/gitwiki), like original one is on Mercurial
wiki: http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey ?
Thanks in advance
P.S. I wonder why my Mozilla 1.7.12 sees GITSurvey as binary/octet-stream
instead of text/plain file...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] Add read_cache_from() and discard_cache()
From: Johannes Schindelin @ 2006-07-04 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virmepfhx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay. After reading the comment, I am quite certain we can just set the
> > index_file_timestamp to 0.
>
> Thanks.
>
> > So, I still think that these two lines should be in the cleanup part of
> > get_merge_bases().
>
> I think that is sane -- please make it so.
Ummm. After reading my original mail again: bad tobacco that was. Of
course, I meant discard_cache(), not get_merge_bases(). Setting
index_file_timestamp in get_merge_bases() would be wrong.
Sorry for the noise,
Dscho
^ 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