* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-03 21:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510031522590.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Are these all before 1.0, or are some of them supposed to happen
> eventually but later?
The latter.
>> * Libification. There are many places "run once" mentality is
>> ingrained in the management of basic data structures, which
>> need to be fixed.
>
> I think this should be a post-1.0 thing; I think after 1.0, we should
> rearrange a lot of the code to make more sense from a programmer
> perspective.
I agree.
>> * Look at libified GNU diff CVS seems to use, or libxdiff.
>
> I've almost got a suffix-tree-based diff that works reasonably well,
> that's built as a library, and outputs unified diff. I need to merge it
> with git, hook up input from trees and blobs, and test it on a wider set
> of data.
Sounds like fun.
> I'd also like to add:
>
> * Accept patches to fetch multiple objects by HTTP in parallel.
>
> I think this may be necessary to get good performance without rsync for
> repositories hosted without specific git support.
Surely. I'd love to see you work with Nick Hengeveld on this
one, perhaps even before 1.0. Looking out the fetch.c code, I
think you already have set up a reasonable "work queue" during
the last round, with a lot of simplification thanks to Sergey,
and parallel fetching would be a very nice addition.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: H. Peter Anvin @ 2005-10-03 21:08 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200510032048.37363.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
>
> I did wonder today in response to a discussion at work about version control
> of documentation, whether git could in some way understand OpenDocument
> format and allow some form of merging of concurrent changes to the same
> document. I am not sure if just unzipping the files and applying standard
> merge strategies the resultant xml would be good enough.
>
> Sadly just a thought at the moment.
>
I believe in the medium-to-long term a plugin architecture for merging
is imperative. It's not even different media types, but some *files*
have specific merging policies. Think, for example, of pci.ids in the
Linux kernel tree.
-hpa
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-03 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzlqnwmw.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Oct 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Are these all before 1.0, or are some of them supposed to happen
> > eventually but later?
>
> The latter.
Good. It would be nice to mark things as being post-1.0 or not.
> > I'd also like to add:
> >
> > * Accept patches to fetch multiple objects by HTTP in parallel.
> >
> > I think this may be necessary to get good performance without rsync for
> > repositories hosted without specific git support.
>
> Surely. I'd love to see you work with Nick Hengeveld on this
> one, perhaps even before 1.0. Looking out the fetch.c code, I
> think you already have set up a reasonable "work queue" during
> the last round, with a lot of simplification thanks to Sergey,
> and parallel fetching would be a very nice addition.
The code in ssh-fetch already does parallel fetching, actually (only over
one connection, but requests are sent before responses are read), so
multiple requests are in progress at the same time.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Horst von Brand @ 2005-10-03 21:39 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200510032048.37363.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> On Monday 03 Oct 2005 01:14, Junio C Hamano wrote:
> ...
> >
> > Technical (heavier)
> > -------------------
> ...
> > * Look at libified GNU diff CVS seems to use, or libxdiff.
> I did wonder today in response to a discussion at work about version control
> of documentation, whether git could in some way understand OpenDocument
> format and allow some form of merging of concurrent changes to the same
> document. I am not sure if just unzipping the files and applying standard
> merge strategies the resultant xml would be good enough.
A student of mine worked on layering SCM under a code design tool that uses
XML as its representation of the project it is working on. He started with
CVS, and ended up grafting a problem-specific merge strategy on top. The
standard merge from CVS just messed everything up. Dunno if this is very
relevant for OASIS, but I suspect you'd see the same.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-03 22:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Dan Aloni
In-Reply-To: <Pine.LNX.4.63.0510031709360.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> The code in ssh-fetch already does parallel fetching, actually (only over
> one connection, but requests are sent before responses are read), so
> multiple requests are in progress at the same time.
This reminds me of one patch:
From: Dan Aloni <da-x@monatomic.org>
Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
Date: Sat, 1 Oct 2005 21:39:42 +0300
Message-ID: <20051001183942.GA2099@localdomain>
I'd appreciate it if you had a chance to take a look at it and
comment on it.
The change is isolated to ssh-fetch [*1*], so even if it were to
break something it would only break ssh-fetch and in that sense
it is a safer change.
But it still is a lot of code, and I felt there might be a
simpler way to do this. That is why I am deliberately holding
it off.
[Footnote]
*1* The patch touches sha1_file.c and cache.h but that is to
update write_sha1_from_fd(), which is used only by ssh-fetch
AFAICT. We may want to move it from sha1_file.c to sha1-fetch.c
and make it static, removing it from cache.h.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Linus Torvalds @ 2005-10-03 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git, Dan Aloni
In-Reply-To: <7v1x32l0gz.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Oct 2005, Junio C Hamano wrote:
>
> This reminds me of one patch:
>
> From: Dan Aloni <da-x@monatomic.org>
> Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
> Date: Sat, 1 Oct 2005 21:39:42 +0300
> Message-ID: <20051001183942.GA2099@localdomain>
>
> I'd appreciate it if you had a chance to take a look at it and
> comment on it.
I personally hate it.
It adds horrible patches to fairly core stuff, all because the prefetching
is not limited.
As far as I can tell, it should be much easier to just limit the
prefetching to some reasonable limit (say, a few objects deep), which
guarantees that the prefetching doesn't fill up the write queues on the
fetching side.
It's not like prefetching improves performance once you get to the point
where you can stream. I suspect having more than two or three objects "in
flight" really only helps with
- lots of small objects
- high latency
- high bandwidth
and the thing is, high latency together with high bandwidth is really
quite uncommon - usually high latency goes along with _low_ bandwidth (the
one exception is things like satellite links, which can have latencies in
the seconds, even with good throughput).
It should be pretty easy to benchmark, but my _suspicion_ is that limiting
the read-ahead to even just five is likely to get you 99% of the way, and
that the performance impact of going higher is very limited.
(It might need some extra code to make the synchronous receiving side
re-start the prefetching if the prefetching has stopped after a few
entries - but at that point the extra code is where it is supposed to be,
rather than having core code work around problems in the fetching. I also
suspect that the prefetch limiting can happily be done in the generic
"pull" code, rather than separately for each protocol, so it would need to
be done in just one place).
Linus
^ permalink raw reply
* What's new in GIT today
From: Junio C Hamano @ 2005-10-04 2:20 UTC (permalink / raw)
To: git
GIT 0.99.8a is found in the usual places. It contains the
following fixes:
- Documentation formatting updates, by Jonas Fonseca.
- Fredrik Kuivinen fixed git-merge to stash away the original
tree state correctly when using more than one merge
strategy. The same commit also adds support for baseless
merges.
- 'git repack' can get confused if the tree had a funny
filename.
- Specifying object name with just a short SHA1 prefix sort-of
worked, but did not do the right thing when ambiguities
existed between packed and unpacked objects; after thinking
about it more, I realize that the fixed code still misses
some ambiguities, but it is a bit better than before.
On the "master" branch front:
- All of the above, plus the missing fix for SHA1 prefix
uniqueness check (to be included in 0.99.8b).
- Cygwin port by H. Peter Anvin.
- Option parsing in 'git pull' was buggy and could not
recognize the following sequence:
$ git fetch http://kernel.org/pub/scm/git/git-cygwin.git/
$ git pull -a . fixes pull
to fetch a remote and use that head along with two other
local heads to create a four-head Octopus.
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-04 4:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dan Aloni, Linus Torvalds
In-Reply-To: <7v1x32l0gz.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Oct 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > The code in ssh-fetch already does parallel fetching, actually (only over
> > one connection, but requests are sent before responses are read), so
> > multiple requests are in progress at the same time.
>
> This reminds me of one patch:
>
> From: Dan Aloni <da-x@monatomic.org>
> Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
> Date: Sat, 1 Oct 2005 21:39:42 +0300
> Message-ID: <20051001183942.GA2099@localdomain>
>
> I'd appreciate it if you had a chance to take a look at it and
> comment on it.
I think it's overly hacky; we should be able, in prefetch, to check
whether we've stuffed in a lot of hashes already, and actually read an
object out before requesting another; there's nothing in the fetch
contract that says that an object can't become available at some random
time between the start of the fetch and when it gets requested with
fetch(). (In fact, I had a pack-exchange version of the ssh stuff which
would notice that you have certain things and you're looking for a commit,
and get a bunch of stuff you probably want as a pack before you actually
ask for it, but Linus beat me on that one with send-pack/upload-pack.)
I think that a limit of 100 objects in transit is about right, because the
requests for 100 objects fits well within 4K and I expect that we
commonly have small enough objects that we need to queue up a relatively
large number of requests to maintain streaming.
I've got a patch, which I'll send in the next email.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Limit the number of requests outstanding in ssh-fetch.
From: Daniel Barkalow @ 2005-10-04 4:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Dan Aloni, Linus Torvalds
This completes fetches if there are more than 100 outstanding requests
and there are more to prefetch.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Lightly tested; I reduced the limit to 5, and pulled a small tree
successfully with some of the requests being completed early. I didn't
have the test case to verify that a limit of 100 is sufficiently low, but
handwaving suggests that it should be.
ssh-fetch.c | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
528f784890df88a5c054913136bbc53b164ebb94
diff --git a/ssh-fetch.c b/ssh-fetch.c
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -36,12 +36,26 @@ static ssize_t force_write(int fd, void
return ret;
}
+static int prefetches = 0;
+
+static struct object_list *in_transit = NULL;
+static struct object_list **end_of_transit = &in_transit;
+
void prefetch(unsigned char *sha1)
{
char type = 'o';
+ struct object_list *node;
+ if (prefetches > 100) {
+ fetch(in_transit->item->sha1);
+ }
+ node = xmalloc(sizeof(struct object_list));
+ node->next = NULL;
+ node->item = lookup_unknown_object(sha1);
+ *end_of_transit = node;
+ end_of_transit = &node->next;
force_write(fd_out, &type, 1);
force_write(fd_out, sha1, 20);
- //memcpy(requested + 20 * prefetches++, sha1, 20);
+ prefetches++;
}
static char conn_buf[4096];
@@ -51,6 +65,18 @@ int fetch(unsigned char *sha1)
{
int ret;
signed char remote;
+ struct object_list *temp;
+
+ if (memcmp(sha1, in_transit->item->sha1, 20)) {
+ // we must have already fetched it to clean the queue
+ return has_sha1_file(sha1) ? 0 : -1;
+ }
+ prefetches--;
+ temp = in_transit;
+ in_transit = in_transit->next;
+ if (!in_transit)
+ end_of_transit = &in_transit;
+ free(temp);
if (conn_buf_posn) {
remote = conn_buf[0];
^ permalink raw reply
* [PATCH] Return error when not checking out an entry due to dirtiness.
From: Junio C Hamano @ 2005-10-04 5:11 UTC (permalink / raw)
To: git
Without -f flag, 'git-checkout-index foo.c' issued an error message
when foo.c already existed in the working tree and did not match index.
However it did not return an error from the underlying checkout_entry()
function and resulted in a successful exit(0).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I've made sure that the existing scripts do not use
checkout-index without -f in a way that could be affected by
this change. However, third-party scripts may be affected by
this. Cogito and StGIT should be OK -- they either run
checkout with -f, do not check the error return when it does
not use -f, or runs checkout without -f in an empty working
tree.
checkout-index.c | 11 ++++++++---
entry.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
5a166f6a9d1b7ca2de673139fbfc4112b1b2e308
diff --git a/checkout-index.c b/checkout-index.c
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -63,15 +63,20 @@ static int checkout_file(const char *nam
static int checkout_all(void)
{
- int i;
+ int i, errs;
- for (i = 0; i < active_nr ; i++) {
+ for (errs = i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce))
continue;
if (checkout_entry(ce, &state) < 0)
- return -1;
+ errs++;
}
+ if (errs)
+ /* we have already done our error reporting.
+ * exit with the same code as die().
+ */
+ exit(128);
return 0;
}
diff --git a/entry.c b/entry.c
--- a/entry.c
+++ b/entry.c
@@ -132,7 +132,7 @@ int checkout_entry(struct cache_entry *c
if (!state->force) {
if (!state->quiet)
fprintf(stderr, "git-checkout-index: %s already exists\n", path);
- return 0;
+ return -1;
}
/*
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Junio C Hamano @ 2005-10-04 5:57 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200510031455.30187.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> But why did we choose to make git-pull/git-push
> to accept a remote repository as first argument, and not a head/refspec
> in the first place? [Of course, this needs the remote repository be
> retrievable by head name: see branches/ files. And currently missing here is
> the distinction between fetch and push direction].
I do not understand this comment. I do not think you are just
talking about the syntax:
$ git-push <remote> <refspec1> <refspec2>...
vs
$ git-push' <refspec1> <refspec2>... <remote>
There must be something deeper you are talking about I am
missing. The branches/ file allowed optionally specifying one
single refname (otherwise defaulting HEAD) since we tried to
become compatible with what Cogito did.
It appears that cg-push uses the same branches information for
pushing into remote, which is what I missed when I did
git-parse-remote --- we do not use this information to decide
the default ref to push into, and not to break expectations of
Cogito users we may need to fix this. Is this what you are
discussing here?
> In the current state, it would be better to get rid of branches/
> parsing in GIT at all: By keeping it in, we force Cogito to keep the current
> format.
Hmph. The intent was to keep people's existing Cogito derived
configuration working.
^ permalink raw reply
* Re: [PATCH] Enable and fix support for base less merges.
From: Fredrik Kuivinen @ 2005-10-04 6:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, git
In-Reply-To: <46a038f90510022334k63884c6x377104e7eca29c48@mail.gmail.com>
On Mon, Oct 03, 2005 at 07:34:19PM +1300, Martin Langhoff wrote:
> > With this it's possible to use
> > git merge -s recursive 'merge message' A B
> > to do a base less merge of A and B.
>
> Would it be possible/useful to teach git-apply about this?
>
I don't really understand what you mean. In what way could git-apply
use this? Is there a specific use case you are thinking about?
- Fredrik
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Dan Aloni @ 2005-10-04 7:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0510031606550.31407@g5.osdl.org>
On Mon, Oct 03, 2005 at 04:16:27PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 3 Oct 2005, Junio C Hamano wrote:
> >
> > This reminds me of one patch:
> >
> > From: Dan Aloni <da-x@monatomic.org>
> > Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
> > Date: Sat, 1 Oct 2005 21:39:42 +0300
> > Message-ID: <20051001183942.GA2099@localdomain>
> >
> > I'd appreciate it if you had a chance to take a look at it and
> > comment on it.
>
> I personally hate it.
>
> It adds horrible patches to fairly core stuff, all because the prefetching
> is not limited.
Well it can be reworked to be more clean...
> As far as I can tell, it should be much easier to just limit the
> prefetching to some reasonable limit (say, a few objects deep), which
> guarantees that the prefetching doesn't fill up the write queues on the
> fetching side.
I'm not sure how this will be completely reliable, even if you limit the
prefetching to one object.
Suppose that this one object's size is larger than the receiving queues of
the receiving end (like 1 MB?) and the bandwidth is high, wouldn't that
break?
--
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net
^ permalink raw reply
* Re: [PATCH] Limit the number of requests outstanding in ssh-fetch.
From: Dan Aloni @ 2005-10-04 7:16 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0510040016110.23242@iabervon.org>
On Tue, Oct 04, 2005 at 12:24:55AM -0400, Daniel Barkalow wrote:
> This completes fetches if there are more than 100 outstanding requests
> and there are more to prefetch.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
>
> Lightly tested; I reduced the limit to 5, and pulled a small tree
> successfully with some of the requests being completed early. I didn't
> have the test case to verify that a limit of 100 is sufficiently low, but
> handwaving suggests that it should be.
Good, it seems that your patch works alright with the local Linux complete
database fetch.
--
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net
^ permalink raw reply
* Re: StGit command completions - and Git ones?
From: Catalin Marinas @ 2005-10-04 7:23 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200510021303.44960.blaisorblade@yahoo.it>
On 02/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> I noticed in your TODO you talk about adding command line completions. I've
> been doing it for my needs, and the thing is still very incomplete, even if
> it's not a "XXX hack hack hack", and I wanted to send this first draft.
Thanks, I will have a look at it.
FYI, the tla-contrib package has a script which automatically
generates the bash completion script from the help messages (well,
only for tla, but can be adapted).
--
Catalin
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Daniel Barkalow @ 2005-10-04 7:31 UTC (permalink / raw)
To: Dan Aloni; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20051004071210.GA18716@localdomain>
On Tue, 4 Oct 2005, Dan Aloni wrote:
> On Mon, Oct 03, 2005 at 04:16:27PM -0700, Linus Torvalds wrote:
> >
> >
> > On Mon, 3 Oct 2005, Junio C Hamano wrote:
> > >
> > > This reminds me of one patch:
> > >
> > > From: Dan Aloni <da-x@monatomic.org>
> > > Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
> > > Date: Sat, 1 Oct 2005 21:39:42 +0300
> > > Message-ID: <20051001183942.GA2099@localdomain>
> > >
> > > I'd appreciate it if you had a chance to take a look at it and
> > > comment on it.
> >
> > I personally hate it.
> >
> > It adds horrible patches to fairly core stuff, all because the prefetching
> > is not limited.
>
> Well it can be reworked to be more clean...
>
> > As far as I can tell, it should be much easier to just limit the
> > prefetching to some reasonable limit (say, a few objects deep), which
> > guarantees that the prefetching doesn't fill up the write queues on the
> > fetching side.
>
> I'm not sure how this will be completely reliable, even if you limit the
> prefetching to one object.
>
> Suppose that this one object's size is larger than the receiving queues of
> the receiving end (like 1 MB?) and the bandwidth is high, wouldn't that
> break?
It shouldn't cause any problem, unless there isn't a 4K buffer between the
git-ssh-fetch and ssh; the fetch side would have to fill this buffer
before getting stuck, even if ssh can't send out any more data until the
object has been read, and 100 requests (each 21 bytes) wouldn't be enough.
I remember that there's a lot that depends on being able to put 4K into an
empty pipe without blocking, and I'd guess that UNIX sockets have a
similar capacity (although I'm not going to look it up tonight).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [RFH] commit object name in git-diff-tree output header?
From: Junio C Hamano @ 2005-10-04 7:28 UTC (permalink / raw)
To: git
This is a request for help from your clueless/forgetful
maintainer.
With a single commit as its parameter, 'git-diff-tree' outputs
the name of the commit object when run without the -v flag as
its first line, like this:
$ git-diff-tree -p HEAD
22a27042603fc9068ca562a8b5c46b3417f99777
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -9,7 +9,7 @@ git-apply - Apply patch on a GIT index f
SYNOPSIS
--------
...
I have a vague recollection to have seen some code that detects
this ^[0-9a-f]{40}$ pattern and uses it as a separator between
logical patchset, but I seem to be unable to find it now.
Does anybody have scripts that depend on this behaviour? This
commit object name is carried over to format-patch output, and I
would like to change it now. So if your own patch acceptance
script relies on this behaviour, please speak up before I break
it.
This has been the format since Jun 23, change made by Linus.
Before that change, we used to say two commit object ID, like
this:
$ git-diff-tree -p HEAD
aefa4a5... (from 5fca669...)
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -860,7 +860,6 @@ static int find_offset(const char *buf,
...
^ permalink raw reply
* Re: [PATCH] Limit the number of requests outstanding in ssh-fetch.
From: Stefan Roese @ 2005-10-04 7:46 UTC (permalink / raw)
To: Dan Aloni; +Cc: Daniel Barkalow, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <20051004071638.GA23725@localdomain>
On Tuesday 04 October 2005 09:16, Dan Aloni wrote:
> > Lightly tested; I reduced the limit to 5, and pulled a small tree
> > successfully with some of the requests being completed early. I didn't
> > have the test case to verify that a limit of 100 is sufficiently low, but
> > handwaving suggests that it should be.
>
> Good, it seems that your patch works alright with the local Linux complete
> database fetch.
Works for me too (on a big ssh fetch, which stalled always without this
patch).
Best regards,
Stefan
^ permalink raw reply
* Re: What to expect after 0.99.8
From: Josef Weidendorfer @ 2005-10-04 9:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x31hlj4.fsf@assigned-by-dhcp.cox.net>
On Tuesday 04 October 2005 07:57, Junio C Hamano wrote:
> I do not understand this comment.
I talk about configuration per remote repository vs. configuration per
local head, and a consistent user interface regarding these.
Cogito is using configuration per head: If there is a remote fetch mapping,
this is stored in branches/<headname>. There is no new shortcut to
remember, because every file in branches corresponds to a local head.
On the other hand, a remotes/<remote> file is configuration per remote
repository, and it introduces a new shortname <remote> for a repository,
which by itself has nothing to do with a head name.
You look for a file in branches/ if there is nothing in remotes/.
I think this is quite confusing for newbies, and blurs the understanding
of remotes/ files, as a file name in branches/ (which is a existing head),
and the file name in remotes/ (which is an arbitrary choosen shortcut for a
remote repository) are quite different things.
If GIT makes use of per-remote-repository only (as it is now), I
suggest getting rid of parsing branches/. Cogito can do its
per-head configuration in addition/layered on top of GITs
per-remote-repository configuration, e.g. by refering to a repository
shortcut name in its files in branches/.
> I do not think you are just
> talking about the syntax:
>
> $ git-push <remote> <refspec1> <refspec2>...
> vs
> $ git-push' <refspec1> <refspec2>... <remote>
No. It is about specifying local head names only, without remote.
Please forget for the moment the current command lines, and
and suppose it is about
$ git-fetch <localhead>
Given per-head configuration for <localhead>, the <remote> would
be already available (in branches/<localhead>); it does not
need to be specified at all. And a
$ git-fetch <localhead1> <localhead2> ...
would potentially fetch from different remote repositories.
The nice thing here is that without a head, you can use the
current HEAD as default.
I do not advocate to change this in GIT at all; but what about
git-fetch-head/git-pull-head/git-push-head ?
> It appears that cg-push uses the same branches information for
> pushing into remote, which is what I missed when I did
> git-parse-remote --- we do not use this information to decide
> the default ref to push into, and not to break expectations of
> Cogito users we may need to fix this.
This even would be the wrong behavior: cg-clone creates local <origin>
head, branches off <master>, and checks out <master>. So when running
cg-push afterwards, you are in fact on the <master> branch, and there
is no remote specified for <master>. Cogito
currently is hardcoded to push to the remote head specified in <origin>
when on <master>.
I suggested Pasky to get rid of this hardcoding, support a "Push:"
line in branches/ files, and create a branches/master in cg-clone.
Similar, a configuration to specify the relation of origin and master
is missing.
Then, to be correct, you would have to use the remote head
in the "Push:" line of the current HEAD.
> Is this what you are
> discussing here?
No. We can not do this, as Cogito currently only stores half of its
behavior in configuration files.
> > In the current state, it would be better to get rid of branches/
> > parsing in GIT at all: By keeping it in, we force Cogito to keep the
> > current format.
>
> Hmph. The intent was to keep people's existing Cogito derived
> configuration working.
If you really want to still parse branches/ files, perhaps it would be
better to create a remotes/ file the first time after parsing it, and
give out a warning that a new repository shortcut was created, to be
used with git-pull etc.
I still think it is wrong to use one head name of a repository as the
default for the repository's name.
Josef
^ permalink raw reply
* Quilt vs. StGIT Performance
From: Catalin Marinas @ 2005-10-04 9:09 UTC (permalink / raw)
To: git
I ran some benchmarks on both Quilt and StGIT (only the push/pop
operations) with the -mm series (2.6.14-rc2-mm2, 566 patches). All the
patches were refreshed since GIT does not support fuzzy patches. The
tools output was directed to /dev/null (a slight advantage for Quilt
since it prints more information). For the StGIT benchmarks, the base
of the stack was modified before each 'stg push -a' command because
otherwise pushing would just fast-forward the patches (timing similar
to the pop command).
As you can see below, 'quilt push' is much faster than 'stg push'. The
profiling information on the latest snapshot shows that StGIT spends
most of the time (~75%) in git-write-tree (which calculates the SHA1
value of the index file after every push). Unfortunately, this cannot
be avoided (otherwise, we would simply re-write Quilt).
There are other advantages of StGIT vs. Quilt but I won't go through
them in this e-mail. For huge number of patches, it's up to you to
decide whether speed is more important than the other StGIT features.
Quilt vs. StGIT (push/pop)
==========================
No. patches: 566 (linux-2.6.14-rc2-mm2)
Machine: P4 @ 2.5GHz, 512MB RAM, WDC IDE disk
OS: Linux 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux
StGIT version: snapshot of 2005-10-04
Quilt version: 0.39-2 (on Debian)
GIT version: 0.99.8.GIT
run 1 run 2 run 3 run 4 run 5 average per patch
---------------------------------------------------------------------------
stg push
---------------------------------------------------------------------------
real 4:56.261 4:07.660 3:37.361 4:20.393 4:16.312 4:15.597 0.452s
user 1:44.004 1:44.051 1:44.047 1:43.802 1:43.718 1:43.924
sys 0:49.803 0:49.812 0:49.458 0:49.714 0:49.954 0:49.748
---------------------------------------------------------------------------
stg pop
---------------------------------------------------------------------------
real 0:27.918 0:14.123 0:17.280 0:45.767 0:26.957 0:26.409 0.047s
user 0:01.857 0:01.852 0:01.864 0:01.883 0:01.867 0:01.865
sys 0:00.761 0:00.703 0:00.680 0:00.796 0:00.740 0:00.736
---------------------------------------------------------------------------
quilt push
---------------------------------------------------------------------------
real 1:00.584 0:36.191 0:34.728 0:24.723 0:30.498 0:37.345 0.066s
user 0:05.687 0:05.551 0:05.632 0:05.591 0:05.618 0:05.616
sys 0:07.835 0:07.588 0:07.454 0:07.536 0:07.552 0:07.593
---------------------------------------------------------------------------
quilt pop
---------------------------------------------------------------------------
real 0:55.772 0:44.721 0:45.503 0:58.081 0:51.621 0:51.140 0.090s
user 0:13.606 0:13.601 0:13.646 0:13.725 0:13.590 0:13.634
sys 0:24.813 0:24.762 0:24.697 0:24.658 0:24.833 0:24.750
--
Catalin
^ permalink raw reply
* Re: StGit command completions - and Git ones?
From: Blaisorblade @ 2005-10-04 9:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0510040023h287b9d44w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]
On Tuesday 04 October 2005 09:23, Catalin Marinas wrote:
> On 02/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> > I noticed in your TODO you talk about adding command line completions.
> > I've been doing it for my needs, and the thing is still very incomplete,
> > even if it's not a "XXX hack hack hack", and I wanted to send this first
> > draft.
>
> Thanks, I will have a look at it.
If you haven't yet, here's today's version.
> FYI, the tla-contrib package has a script which automatically
> generates the bash completion script from the help messages (well,
> only for tla, but can be adapted).
Yes, I wanted to do something like that to speed things up...
if possible, I'd also like to generate option lists from help messages but
that doesn't seem so obvious (not much thought on this, though).
Finally, I'd like to reimplement directly stg applied and unapplied, since
they reduce to trivial "cat"...
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
[-- Attachment #2: stg-compl --]
[-- Type: text/plain, Size: 5043 bytes --]
#Stacked git bash completion.
#TODO:
# My opinion about bash completion is that they're excessively slow, especially
# when the system is under load.
#
# So:
# - save the list of stg commands in a file, created at install moment; on an
# idle Athlon 64 laptop at 800MHz, stg help takes 0.22 seconds of CPU time,
# without disk I/O.
#
# - read .git/patches/$branch/{applied,unapplied} directly instead of invoking
# stg.
#
#XXX: must test for bash version, done in generic bash-completion and the
#generic value can be seen from here, if we are included by the loop at the end
#of /etc/bash_completion, i.e. if we're installed in /etc/bash-completion.d.
#
#Gentoo should be fixed to allow this.
bashdefault="-o bashdefault"
default="-o default"
#XXX: not StGit specific, valid for git too.
__git_refs()
{
for i in $(echo .git/refs/heads/*); do
echo ${i#.git/refs/heads/}
done
for i in $(echo .git/refs/tags/*); do
echo ${i#.git/refs/tags/}
done
echo HEAD
}
__stg_unapplied()
{
stg unapplied 2>/dev/null $@
}
__stg_applied()
{
stg applied 2>/dev/null $@
}
__stg_all_patches()
{
__stg_applied $@; __stg_unapplied $@
}
#XXX: Find a better name for this.
#
__stg_all_patch_ranges()
{
__stg_all_patches $@|while read i; do echo $i/; done
}
__stg_top()
{
stg top 2>/dev/null $@
}
__stg_branches()
{
#for i in $(compgen -f .git/patches/); do
for i in $(echo .git/patches/*); do
echo ${i#.git/patches/}
done
}
_stg ()
{
local cur cmd cmds opts
cur=${COMP_WORDS[COMP_CWORD]}
COMPREPLY=()
if [ $COMP_CWORD -eq 1 ]; then
cmds=$(stg help|tail +4|awk '{print $1}')
COMPREPLY=( $(compgen -W "${cmds}" -- $cur) )
else
local cmd=${COMP_WORDS[1]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
local o_help="-h --help"
local o_branch="-b --branch"
#XXX: Add -b support - pass "-b branch" to unapplied and applied.
#This can be done by calling __stg_unapplied directly below
#instead of setting patches here.
#But: how to look for -b? I'm scared about looping over opts
#(I don't like completions when they take so much time).
case $cmd in
push)
if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
if [ "${cur#*:}" != "${cur}" ]; then
# Complete the 2nd range component, after ':'.
COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- ${cur#*:}) )
else
COMPREPLY=( $(compgen -W "$(__stg_unapplied)" -- $cur) )
fi
else
opts="-a --all -n --number -t --to --reverse --undo $o_help"
COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied)" -- $cur) )
fi
;;
pop)
if [ "$prev" = "-t" -o "$prev" = "--to" ]; then
COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
else
opts="-a --all -n --number -t --to $o_help"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
mail)
if [ "$prev" = "-r" -o "$prev" = "--range" ]; then
if [ "${cur#*:}" != "${cur}" ]; then
COMPREPLY=( $(compgen -W "$(__stg_applied)" -- ${cur#*:}) )
else
COMPREPLY=( $(compgen -W "$(__stg_applied)" -- $cur) )
fi
else
opts="-a --all -r --range --to --cc --bcc -v --version \
-t --template -f --first -s --sleep --refid -u --smtp-user \
-p --smtp-password $o_branch $o_help"
COMPREPLY=( $(compgen $bashdefault -W "${opts} \
$(__stg_applied)" -- $cur) )
fi
;;
diff)
if [ "$prev" = "-r" ]; then
if [ "${cur#*:}" != "${cur}" ]; then
COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
${cur#*:}) )
else
COMPREPLY=( $(compgen -W "$(__stg_all_patch_ranges)" -- \
$cur) )
fi
else
opts="-r -s --stat $o_help"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
id)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
opts="$o_branch $o_help"
#there's a lot of possible id's to complete
COMPREPLY=( $(compgen -W "${opts} $(__stg_all_patch_ranges) \
$(__git_refs)" -- $cur) )
fi
;;
rename)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
COMPREPLY=( $(compgen -W "$(__stg_all_patches)" -- $cur) )
fi
;;
delete)
opts="${o_help}"
COMPREPLY=( $(compgen -W "${opts} $(__stg_unapplied; __stg_top)" \
-- $cur) )
;;
series|unapplied|applied)
if [ "$prev" = "-b" -o "$prev" = "--branch" ]; then
COMPREPLY=( $(compgen -W "$(__stg_branches)" -- $cur) )
else
opts="$o_branch $o_help"
[ "$cmd" = "series" ] && \
opts="$opts -e --empty"
COMPREPLY=( $(compgen -W "${opts}" -- $cur) )
fi
;;
refresh)
opts="-f --force -e --edit -s --showpatch -m --message \
-a --author --authname --authemail --authdate --commname
--commemail $o_help"
COMPREPLY=( $(compgen $bashdefault -W "${opts}" -- $cur) )
;;
*)
COMPREPLY=( $(compgen $bashdefault -W "${o_help}" -f -- $cur) )
;;
esac
fi
}
complete $default -F _stg stg
# vi: set ft=sh sw=4:
^ permalink raw reply
* [ANNOUNCE] gitfs pre-release 0.02
From: Mitchell Blank Jr @ 2005-10-04 10:51 UTC (permalink / raw)
To: git
When I announced the first pre-release of my little gitfs tool back in
June[1] I didn't get much response. (Actually, that's not quite true -- I
got zero response :-) I've been very busy and haven't had the chance to
implement any of the big missing functionality yet, nor will I have time
for at least awhile. Hopefully I'll have some time over the holidays to
hack on it.
However, two things HAVE changed:
1. FUSE is now in the latest mainline kernels, so the barrier-to-entry for
toying with it is lower now
2. The introduction of git packs a couple months ago broke it; this is now
fixed
Other than rebasing against git-core-0.99.8 the only major changes are:
* now runs in non-debugging mode by default (use '-d' to enable debugging
mode)
* some efficiency improvements in the directory-handling code
All the limitations and caveats in the original announcement still apply.
As always -- http://www.sfgoth.com/~mitch/linux/gitfs/
-Mitch
[1] -- http://marc.theaimsgroup.com/?l=git&m=111975978111303&w=2
^ permalink raw reply
* git-commits-head@vger.kernel.org mailbomb
From: David Woodhouse @ 2005-10-04 11:32 UTC (permalink / raw)
To: linux-kernel; +Cc: git
Apologies for the mailbomb of ancient patches yesterday; the git
installation on master.kernel.org was upgraded and one of the tools
which I was using (git-rev-tree) disappeared.
I've just updated the script which feeds the mailing list, and it ought
to be behaving itself again with this week's git tools. Until the next
time... :)
--
dwmw2
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Alex Riesen @ 2005-10-04 12:31 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <433B3B10.5050407@zytor.com>
On 9/29/05, H. Peter Anvin <hpa@zytor.com> wrote:
> I have made a first cut at a git port to Cygwin. It looks like the
> "git-diff-tree -p" problem has been resolved independently, or at least
> I can't reproduce it on a fresh Cygwin install (running on XP Home), but
> I have added support for running without the IPv6 and the getaddrinfo() API.
>
> There are still funnies. In particular, Cygwin and Samba handle
> symlinks differently, so you can't trivially share a repository via
> Samba. Linus' "symbolic refs" changes should eventually take care of that.
I noticed that rename(2) in my copy of cygwin (1.5.18-1) does not remove the
target and returns an error (probably EPERM, but I have reasons not to trust
strerror on that thing).
The repository was on FAT.
Taking "rename(2)" from cygwin's libiberty solved this (they unlink if link(2)
returns EEXIST).
PS: Does broken rename(2) qualify a system "not worthy to support"?
^ permalink raw reply
* Re: [COGITO] cg-status in an empty repo spits out git-diff-index usage info
From: Elfyn McBratney @ 2005-10-04 13:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list
In-Reply-To: <7vpsqp905i.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]
On Sat, Oct 01, 2005 at 12:17:13 -0700, Junio C Hamano wrote:
> Elfyn McBratney <beu@gentoo.org> writes:
>
> > which I'm guessing isn't expected behaviour ;) `git status` does the
> > same, FWIW.
>
> Yes, I noticed 'git status' did it that some time ago, and I
> thought "gee, that was ugly". But then I imagined what any
> other realist maintainer would have said if I reported it as a
> bug.
>
> Lbh xabj lbh'ir whfg perngrq lbhe ercb naq vg vf rzcgl.
> Jung qvq lbh rkcrpg sebz 'fgnghf' bhgchg? Jub pnerf! Naq
> ubj bsgra jbhyq lbh rkcrpg gb eha 'tvg fgnghf' va n arjyl
> perngrq ercbfvgbel sebz abj ba, abj lbh xabj jung lbh jbhyq
> frr? Trg hfrq gb vg.
>
> But I fixed it anyway, exactly a month ago.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hehe - cool, thanks. :)
Best,
Elfyn
--
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc
PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
DBD3 B756 ED58 B1B4 47B9 B3BD 8D41 E597 69DF 17AD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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