On a new machine, trying to boostrap into latest cogito, I download
and make cogito 0.12.1, and then...
$ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git cogito
defaulting to local storage area
14:48:53 URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master
[41/41] -> "refs
This patch makes the core pull algorithm request all of the objects it can
(with prefetch()) before actually reading them (with fetch()). Future
patches (in a later series) will make use of this behavior to have
multiple requests in flight at the same time, reducing the need for
round-trips.
S
This adds support for calling lookup_object_type() with NULL for the type,
which will cause it to allocate enough memory for the largest type. This
allows struct object_lists for objects that need to be fetched to find out
what they are.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
This series makes the core of the pull programs parallel. It should not
actually make any difference yet. It arranges to call prefetch() for each
object as soon as it is determined to be needed, and then call fetch() on
each object once there is nothing left to prefetch. By implementing
prefetc
On Sun, 31 Jul 2005, Andrew Morton wrote:
>
> So I finally decided to take a look at my git problems. Discovered I
> couldn't fix them with zero git knowledge :(
Heh. We're here to please.
I'll cc the git list too, because there really _are_ a lot of people out
there that know it fairly well
This adds support for reading an uninstalled index, and installing a
pack file that was added while the program was running, as well as
functions for determining where to put the file.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
cache.h | 13 ++
sha1_file.c | 123 ++
This adds support to http-pull for finding the list of pack files
available on the server, downloading the index files for those pack
files, and downloading pack files when they contain needed objects not
available individually. It retains the index files even if the pack
files were not needed, but
Ryan Anderson <[EMAIL PROTECTED]> writes:
> If I hope that nobody has done something like:
> GIT_AUTHOR="Ryan <> Anderson"
> GIT_AUTHOR_EMAIL="[EMAIL PROTECTED]"
>
> I get more confusing results.
The function git_author_info() would remove <> from the above
GIT_AUTHOR_* environment va
On Sun, 31 Jul 2005, Junio C Hamano wrote:
>
> You are absolutely right. It should grab some sort of lock
> while it does its thing (would fcntl(F_GETLK) be acceptable to
> networked filesystem folks?).
There is no lock that works reliably except for the "create a directory
and rename it onto
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In the "central repo model" you have another issue - you have potentially
> parallell pushes to different branches with no locking what-so-ever (and
> that's definitely _supposed_ to work), and I have this suspicion that the
> "update for dumb servers"
On Sun, Jul 31, 2005 at 12:25:13PM +0200, Johannes Schindelin wrote:
> Hi,
>
> wouldn't it be a good idea to make $from and $to required parameters? At
> least you could infer a sensible default of $from from GIT_* environment
> variables, no? I am not quite comfortable with a hard coded sender in
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
>
> > All emails are sent as a reply to the previous email, making it easy to
> > skip a collection of emails that are uninteresting.
>
> I understand why _some_ people consider thi
Daniel, I would really have liked to merge this immediately, but
somehow the patch is whitespace damaged. Depressingly enough,
almost all patches I got from various people today had different
whitespace damages, and I started to suspect if there is
something wrong on my end, but it does not appear
Hi,
On Sun, 31 Jul 2005, Junio C Hamano wrote:
> Let's yank out the update_server_info() call when Josef's patch
> can handle a single hook call at the end of the run, in addition
> to one call per each ref getting updated.
How about executing update_server_info() if no hook was found? That way,
On Sun, 31 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > No I'm not. Try all the machines behind my firewall.
>
> Ah, that's true. Do you push into them?
Yup, I do. I have this thing that I don't do backups, but I end up having
redundancy instead, so I ke
Linus Torvalds <[EMAIL PROTECTED]> writes:
> No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Let's yank out the update_server_info() call when Josef's patch
can handle a single hook call at the end of the run, in addition
to one call per each ref get
On Sunday 31 July 2005 22:15, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> > +It is assured that sha1-old is an ancestor of sha1-new (otherwise,
> > +the update would have not been allowed). refname is relative to
> > +$GIT_DIR; e.g. for the master head this is "refs/hea
On Sun, 31 Jul 2005, Junio C Hamano wrote:
>
> But you are. I can run this just fine:
No I'm not. Try all the machines behind my firewall.
kernel.org is just the place I put things to when I publish them. It
doesn't have any of my working directories on it.
Linus
-
T
Hi,
I tried to avoid the work. But I'll do it.
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This looks sane. However, I also get the strong feeling that
> git-update-server-info should be run as part of a hook and not be built
> into receive-pack..
> Personally, I simply don't want to update any dumb server info stuff for
> my own local rep
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> +It is assured that sha1-old is an ancestor of sha1-new (otherwise,
> +the update would have not been allowed). refname is relative to
> +$GIT_DIR; e.g. for the master head this is "refs/heads/master".
I think this description is inaccurate; the se
On Sun, 31 Jul 2005, Josef Weidendorfer wrote:
>
> Added hook in git-receive-pack
>
> After successful update of a ref,
>
> $GIT_DIR/hooks/update refname old-sha1 new-sha2
>
> is called if present. This allows e.g sending of a mail
> with pushed commits on the remote repository.
> Documentati
This adds support for reading an uninstalled index, and installing a
pack file that was added while the program was running, as well as
functions for determining where to put the file.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
cache.h | 13 ++
sha1_file.c | 123 +
This adds support to http-pull for finding the list of pack files
available on the server, downloading the index files for those pack
files, and downloading pack files when they contain needed objects not
available individually. It retains the index files even if the pack
files were not needed, bu
This series adds support for downloading pack files when appropriate in
http-pull. When it finds that a needed object is not available, it
downloads info/packs (into memory), identifies any pack files it doesn't
have from there, downloads indices of any of these that it doesn't have,
and downlo
Old libcurl has curl_easy_setopt(), and http-pull requires it; it just
doesn't have one of the options.
Signed-off-by: Daniel Barkalow <[EMAIL PROTECTED]>
---
http-pull.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
9c32b0230180d507b4429fb35432bc404a89e637
diff --git a/http-p
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update with example hook included.
Signed-off-by: Josef Weidendor
Oh, another thing. Could you refrain from doing
quoted-printable when possible? Thanks.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Yes, I agree. I'm happy to send you an email when I have committed
> changes to gitk if that will help.
Please do not waste your time on that doing it regularly, but do
not hesitate to drop me a note if you have something newsworthy.
I always fetch fr
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Maybe we should decide on a common terminology before kicking out 1.0, and
> look through all files in Documentation/ to have a consistent vocabulary.
> And poor me does not get confused no more.
Glad to see you started the discussion on this one.
Hi,
the other day I got confused by the terminology. Maybe I'm not the only
one:
The GIT equivalent of a CVS branch is sometimes called a branch
(git-new-branch), sometimes a tree (git-switch-tree), and sometimes a
head (which seems counterintuitive to CVS people: they only have one
HEAD; pun(s)
Junio C Hamano writes:
> It appears that gitk gets wider test coverage only after it is
> pulled into git.git repository. I think it would be a good idea
> for me to pull from you often.
Yes, I agree. I'm happy to send you an email when I have committed
changes to gitk if that will help.
> Rec
On Sun, 31 Jul 2005 04:17:25 -0400 Ryan Anderson wrote:
> This is based off of GregKH's script, send-lots-of-email.pl, and
> strives to do all the nice things a good subsystem maintainer does
> when forwarding a patch or 50 upstream:
>
> All the prior handlers of the patch, as determined by
Hi,
wouldn't it be a good idea to make $from and $to required parameters? At
least you could infer a sensible default of $from from GIT_* environment
variables, no? I am not quite comfortable with a hard coded sender in a
script possibly deployed into a multi-user environment.
Ciao,
Dscho
-
To
Ryan Anderson <[EMAIL PROTECTED]> writes:
> All emails are sent as a reply to the previous email, making it easy to
> skip a collection of emails that are uninteresting.
I understand why _some_ people consider this preferable, but
wonder if this should have a knob to be tweaked.
For
Hi, Ryan Anderson wrote:
> And yes, I did generate this thread with this script - so I have proof
> that it works nicely.
It might make sense to create a "Patch 0/N" with a short explanation, and
have the actual patches be replies to that -- or to patch 1/N if that's
not necessary.
As it is, pat
On Sun, Jul 31, 2005 at 04:17:25AM -0400, Ryan Anderson wrote:
> This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
> all the nice things a good subsystem maintainer does when forwarding a patch
> or
> 50 upstream:
>
> All the prior handlers of the patch, as dete
Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]>
---
Documentation/git-send-email-script.txt | 61 +++
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-send-email-script.txt
799a6320d3b07347869093beec303afbc005cf26
diff --git a
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do
all the nice things a good subsystem maintainer does when forwarding a patch or
50 upstream:
All the prior handlers of the patch, as determined by the
Signed-off-by: lines, and/or the author of the commi
Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]>
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
6dbf602b0931608831888e779612fcc89b90d16f
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.6.1
40 matches
Mail list logo
