* [PATCH] Do not rely on a sane wc
From: Johannes Schindelin @ 2005-08-01 14:32 UTC (permalink / raw)
To: git
Some implementations of wc pad the line number with white space, which
expr does not grok as a number.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-format-patch-script | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
da0488e94f7f949cbfce7422980eb2fe38166b9a
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -109,7 +109,7 @@ _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x4
stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
git-rev-list --merge-order "$junio" "^$linus" >$series
-total=`wc -l <$series`
+total=`wc -l <$series | tr -dc "[0-9]"`
i=$total
while read commit
do
^ permalink raw reply
* [PATCH] Updates to tutorial.txt
From: Johannes Schindelin @ 2005-08-01 14:33 UTC (permalink / raw)
To: git
Fix a few typos.
Adapt to git-http-pull not borking on packed repositories.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/tutorial.txt | 36 +++++++++++++++++-------------------
1 files changed, 17 insertions(+), 19 deletions(-)
161f6e2d135e2b24e6629aaf8be65ede4fdf1ad3
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -241,7 +241,7 @@ creating the equivalent of a git "direct
git-write-tree
and this will just output the name of the resulting tree, in this case
-(if you have does exactly as I've described) it should be
+(if you have done exactly as I've described) it should be
8988da15d077d4829fc51d8544c097def6644dbb
@@ -283,7 +283,7 @@ message ever again.
Again, normally you'd never actually do this by hand. There is a
helpful script called "git commit" that will do all of this for you. So
-you could have just writtten
+you could have just written
git commit
@@ -312,7 +312,7 @@ have committed something, we can also le
Unlike "git-diff-files", which showed the difference between the index
file and the working directory, "git-diff-cache" shows the differences
-between a committed _tree_ and either the the index file or the working
+between a committed _tree_ and either the index file or the working
directory. In other words, git-diff-cache wants a tree to be diffed
against, and before we did the commit, we couldn't do that, because we
didn't have anything to diff against.
@@ -482,7 +482,7 @@ particular state. You can, for example,
to diff your current state against that tag (which at this point will
obviously be an empty diff, but if you continue to develop and commit
-stuff, you can use your tag as a "anchor-point" to see what has changed
+stuff, you can use your tag as an "anchor-point" to see what has changed
since you tagged it.
A "signed tag" is actually a real git object, and contains not only a
@@ -800,16 +800,13 @@ pull from:
GIT URL
git://remote.machine/path/to/repo.git/
+
+ SSH URL
remote.machine:/path/to/repo.git/
Local directory
/path/to/repo.git/
-[ Side Note: currently, HTTP transport is slightly broken in
- that when the remote repository is "packed" they do not always
- work. But we have not talked about packing repository yet, so
- let's not worry too much about it for now. ]
-
[ Digression: you could do without using any branches at all, by
keeping as many local repositories as you would like to have
branches, and merging between them with "git pull", just like
@@ -829,7 +826,7 @@ directory, like this:
echo rsync://kernel.org/pub/scm/git/git.git/ \
>.git/branches/linus
-and use the filenae to "git pull" instead of the full URL.
+and use the filename to "git pull" instead of the full URL.
The contents of a file under .git/branches can even be a prefix
of a full URL, like this:
@@ -983,10 +980,11 @@ would remove them for you.
You can try running "find .git/objects -type f" before and after
you run "git prune-packed" if you are curious.
-[ Side Note: as we already mentioned, "git pull" is broken for
- some transports dealing with packed repositories right now, so
- do not run "git prune-packed" if you plan to give "git pull"
- access via HTTP transport for now. ]
+[ Side Note: "git pull" is slightly cumbersome for HTTP transport,
+ as a packed repository may contain relatively few objects in a
+ relatively large pack. If you expect many HTTP pulls from your
+ public repository you might want to repack & prune often, or
+ never. ]
If you run "git repack" again at this point, it will say
"Nothing to pack". Once you continue your development and
@@ -998,7 +996,7 @@ project from scratch), and then run "git
while, depending on how active your project is.
When a repository is synchronized via "git push" and "git pull",
-objects packed in the source repository is usually stored
+objects packed in the source repository are usually stored
unpacked in the destination, unless rsync transport is used.
@@ -1048,8 +1046,8 @@ A recommended workflow for a "project le
Go back to step (5) and continue working.
-A recommended work cycle for a "subsystem maintainer" that works
-on that project and has own "public repository" goes like this:
+A recommended work cycle for a "subsystem maintainer" who works
+on that project and has an own "public repository" goes like this:
(1) Prepare your work repository, by "git clone" the public
repository of the "project lead". The URL used for the
@@ -1058,8 +1056,8 @@ on that project and has own "public repo
(2) Prepare a public repository accessible to others.
(3) Copy over the packed files from "project lead" public
- repository to your public repository by hand; this part is
- currently not automated.
+ repository to your public repository by hand; preferrably
+ use rsync for that task.
(4) Push into the public repository from your primary
repository. Run "git repack", and possibly "git
^ permalink raw reply
* [PATCH] Updates for cvs-migration.txt
From: Johannes Schindelin @ 2005-08-01 14:32 UTC (permalink / raw)
To: git
Describe core git, not cogito.
Tell something about emulating the CVS work flow.
Fix small typos.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/cvs-migration.txt | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
4d171682e6e6499db8563aa61e68fc4a04abf413
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -90,7 +90,7 @@ from CVS.
You can merge those updates (or, in fact, a different CVS branch) into
your main branch:
- cg-merge <branch>
+ git resolve HEAD origin "merge with current CVS HEAD"
The HEAD revision from CVS is named "origin", not "HEAD", because git
already uses "HEAD". (If you don't like 'origin', use cvsimport's
@@ -101,10 +101,26 @@ Emulating CVS behaviour
-----------------------
-FIXME! Talk about setting up several repositories, and pulling and
-pushing between them. Talk about merging, and branches. Some of this
-needs to be in the tutorial too.
+So, by now you are convinced you absolutely want to work with git, but
+at the same time you absolutely have to have a central repository.
+Step back and think again. Okay, you still need a single central
+repository? There are several ways to go about that:
+
+1. Designate a person responsible to pull all branches. Make the
+repository of this person public, and make every team member
+pull regularly from it.
+
+2. Set up a public repository with read/write access for every team
+member. Use "git pull/push" as you used "cvs update/commit". Beware!
+Linus says that "git push" does no locking, since it was not meant
+for multi-user repositories!
+
+3. Make the repository of every team member public. It is the
+responsibility of each single member to pull from every other
+team member.
+4. Read Documentation/tutorial.txt and admit that the described work
+flow is the best.
CVS annotate
@@ -157,7 +173,7 @@ modifications that are not related to th
interested in. You would see many log messages and patches that
do not have anything to do with the piece of code you are
interested in. As an example, assuming that you have this piece
-code that you are interested in in the HEAD version:
+of code that you are interested in in the HEAD version:
if (frotz) {
nitfol();
@@ -207,7 +223,7 @@ in the current HEAD commit, even if the
called "o-file.c" and then renamed in an earlier commit, or if
the file was created by copying an existing "o-file.c" in an
earlier commit, you will not lose track. If the "if" statement
-did not change across such rename or copy, then the commit that
+did not change across such a rename or copy, then the commit that
does rename or copy would not show in the output, and if the
"if" statement was modified while the file was still called
"o-file.c", it would find the commit that changed the statement
^ permalink raw reply
* Re: git diffs
From: Linus Torvalds @ 2005-08-01 15:51 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.01.07.55.40.43904@smurf.noris.de>
On Mon, 1 Aug 2005, Matthias Urlichs wrote:
>
> Hi, Linus Torvalds wrote:
>
> > git checkout -f master
> > git-rev-parse master > .git/refs/heads/merge-branch
> >
> > #
> > # Switch to it, always leaving "master" untouched
> > #
> > git checkout -f merge-branch
>
> Isn't that equivalent to (but slower than)
>
> git checkout -f -b merge-branch master
No.
If you had a previous merge-branch (because something went wrong last
time, and you just re-start the whole thing), you really want to _first_
force the branch to "master", and then create the new merge-branch.
Also, the last "git checkout -f merge-branch" will be pretty much zero
time, because the stuff is already at the right point, so it will
basically end up just re-doing the symlink.
So I did it that strange way for a reason.
Linus
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Wayne Scott @ 2005-08-01 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vd5p2hve1.fsf@assigned-by-dhcp.cox.net>
On 7/29/05, Junio C Hamano <junkio@cox.net> wrote:
> While I would in principle prefer to offer more freedom to shoot
> yourselves in the foot ;-), the pragmatic side of me says too
> much flexibility is just asking for trouble with not much
> additional gain.
For an example of just how far you can go down the road to mind
numbing complexity try reading the rsync manpage about how to exclude
files.
-Wayne
^ permalink raw reply
* Fix sparse warnings
From: Linus Torvalds @ 2005-08-01 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
A few sparse warnings have crept in again since I checked last time:
undeclared variables with global scope.
Fix them by marking the private variables properly "static".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
Btw, sparse also warns about the "return 0" in receive-pack.c: unpack(),
since that function is supposed to return void. I think somebody else
already sent a patch for that one.
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -71,13 +71,13 @@ static int max_connections = 25;
/* These are updated by the signal handler */
static volatile unsigned int children_reaped = 0;
-pid_t dead_child[MAX_CHILDREN];
+static pid_t dead_child[MAX_CHILDREN];
/* These are updated by the main loop */
static unsigned int children_spawned = 0;
static unsigned int children_deleted = 0;
-struct child {
+static struct child {
pid_t pid;
socklen_t addrlen;
struct sockaddr_storage address;
diff --git a/rev-cache.c b/rev-cache.c
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -5,7 +5,7 @@
struct rev_cache **rev_cache;
int nr_revs, alloc_revs;
-struct rev_list_elem *rle_free;
+static struct rev_list_elem *rle_free;
#define BATCH_SIZE 512
diff --git a/server-info.c b/server-info.c
--- a/server-info.c
+++ b/server-info.c
@@ -62,7 +62,7 @@ static int update_info_refs(int force)
}
/* packs */
-struct pack_info {
+static struct pack_info {
unsigned long latest;
struct packed_git *p;
int old_num;
^ permalink raw reply
* Re: [OT] Perl-ish perl vs. C-ish perl.
From: Noel Maddy @ 2005-08-02 12:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Noel Maddy, Ryan Anderson, git
In-Reply-To: <7vk6j52qhn.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, Aug 01, 2005 at 04:21:08PM -0700, Junio C Hamano wrote:
> Noel Maddy <noel@zhtwn.com> writes:
(silly perl stuff)
> Please refrain from making this thread "I know more Perl than
> you do"; thank you.
Sorry. Just trying to help, but suitably chastened.
Thanks
--
Time is an illusion. Lunchtime doubly so.
-- Ford Prefect
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Noel Maddy <noel@zhtwn.com>
^ permalink raw reply
* Re: [OT] Perl-ish perl vs. C-ish perl.
From: Junio C Hamano @ 2005-08-02 16:37 UTC (permalink / raw)
To: Noel Maddy; +Cc: Ryan Anderson, git
In-Reply-To: <20050802124824.GA13096@uglybox.localnet>
Noel Maddy <noel@zhtwn.com> writes:
>> Please refrain from making this thread "I know more Perl than
>> you do"; thank you.
>
> Sorry. Just trying to help, but suitably chastened.
I realize that what you sent was not _too_ Perlish and being
helpful. If you feel I overreacted, I am sorry; I _do_ think I
did overreact, attempting to be preemptive.
^ permalink raw reply
* Re: [OT] Perl-ish perl vs. C-ish perl.
From: Noel Maddy @ 2005-08-02 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Noel Maddy, Ryan Anderson, git
In-Reply-To: <7v3bpscn1r.fsf@assigned-by-dhcp.cox.net>
On Tue, Aug 02, 2005 at 09:37:36AM -0700, Junio C Hamano wrote:
> Noel Maddy <noel@zhtwn.com> writes:
>
> >> Please refrain from making this thread "I know more Perl than
> >> you do"; thank you.
> >
> > Sorry. Just trying to help, but suitably chastened.
>
> I realize that what you sent was not _too_ Perlish and being
> helpful. If you feel I overreacted, I am sorry; I _do_ think I
> did overreact, attempting to be preemptive.
No, I don't think you overreacted. Well, maybe a _little_ bit. ;)
I think you're focused on making git good (as in reliable and
maintainable), and that strong focus is admirable.
Your clarification on the expected developer profile, and how to target
the code to those developers helps, too.
For those of us who've spent years living in Perl, the idioms come much
easier than those who are coming from other languages like C. But if
the expected maintainers are not perl weenies (like me, I guess), then
you're right, it's better to stay away from the more perl-y stuffy.
Again, thanks.
>
--
If we can't define the user experience of Windows so that all Windows
machines operate the same way, then the Windows brand is meaningless.
-- Bill Gates
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Noel Maddy <noel@zhtwn.com>
^ permalink raw reply
* Parallel pull for ssh-pull
From: barkalow @ 2005-08-02 20:02 UTC (permalink / raw)
To: git
I think I've now got the parallel pull use in ssh-pull to the point where
it could be useful to post. Similar stuff should work for http-pull (where
it will probably be more interesting), but I have to read more libcurl
documentation.
Initial results on ssh-pull are encouraging: on my local ethernet, I moved
the current git repository in 16 seconds, unpacked and with the push
side acting dumb. I think it was requesting objects about 6 ahead of where
it was reading them. I didn't test how much time the pipe spent empty in
the final version; when I was printing debugging messages, the pipe was
often empty, but it also took 3 times as long, and was therefore probably
blocking on debugging output, not the network.
This work is based on some now in -pu; what should I base my patches on? I
would ideally like to add a function to one of the patches in -pu and fix
a subtle bug in the other, in addition to further patches to actually use
the feature in ssh-pull.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Parallel pull for ssh-pull
From: Junio C Hamano @ 2005-08-02 20:38 UTC (permalink / raw)
To: barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508021544430.23721@iabervon.org>
barkalow@iabervon.org writes:
> This work is based on some now in -pu; what should I base my patches on? I
> would ideally like to add a function to one of the patches in -pu and fix
> a subtle bug in the other, in addition to further patches to actually use
> the feature in ssh-pull.
The proposed patch queue is just a throw-away branch that I use
for the purpose of (1) not to lose patches from people, (2) to
ack patches from others, and (3) let people know which ones are
under consideration.
Either a patch on top of the pu branch, or a brand new patch on
top of the master branch would work fine for me. If you feel
some stuff that are in pu need to be fixed or cleaned up, you
may want choose the latter --- that way, software archaeologists
do not need to know that you made a mess in earlier rounds ;-).
If you choose to do so, I would appreciate a warning to tell me
which existing patches to drop from pu, although that would
probably be pretty clear from the context.
Thanks.
^ permalink raw reply
* [patch] list shortlog items in commit order
From: Nicolas Pitre @ 2005-08-02 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The current shortlog list is backward making it look odd.
This reverses it so things appear more logically.
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/git-shortlog b/git-shortlog
--- a/git-shortlog
+++ b/git-shortlog
@@ -90,7 +90,7 @@ sub shortlog_output {
# output author's 1-line summaries
$obj = $map{$key};
- foreach $desc (@$obj) {
+ foreach $desc (reverse @$obj) {
print " $desc\n";
$n_output++;
}
^ permalink raw reply
* Email patch -> git commit?
From: H. Peter Anvin @ 2005-08-02 22:15 UTC (permalink / raw)
To: Git Mailing List
Anyone have any good scripts for taking patches in email and turning
them into git commits, preferrably while preserving the author information?
-hpa
^ permalink raw reply
* Re: Email patch -> git commit?
From: Sam Ravnborg @ 2005-08-02 22:27 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <42EFF077.6080606@zytor.com>
On Tue, Aug 02, 2005 at 03:15:19PM -0700, H. Peter Anvin wrote:
> Anyone have any good scripts for taking patches in email and turning
> them into git commits, preferrably while preserving the author information?
git-applymbox seems to be what you are looking for.
It was named dotest in the old days.
Sam
^ permalink raw reply
* git-fsck-cache cleaning
From: Jon Loeliger @ 2005-08-02 22:24 UTC (permalink / raw)
To: Git List
Hi GITers,
So, after you dink around in a GIT tree for a while,
and you discover little bloblets left around by using
git-fsck-cache, what do you do? How can you clean up
afterwards?
Specifically, I have a GIT tree that shows some dangling
blobs that are unreferenced in my tree. Not sure how the
got there, but I've verified through git-cat-file that
the contents of many of those blobs are actually validly
represented in my tree. Yet, fsck suggests they dangle.
So, for each of the various fsck warnings, what can be
done to clean things up and yet maintain integrity in
the tree? I have apparently unreferenced blobs. I should
be able to just "rm .git/objects/xx/<sha1>" and be done
with them, right? What about the other warnings?
Thanks,
jdl
^ permalink raw reply
* Re: Email patch -> git commit?
From: H. Peter Anvin @ 2005-08-02 22:32 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Git Mailing List
In-Reply-To: <20050802222718.GA19107@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Tue, Aug 02, 2005 at 03:15:19PM -0700, H. Peter Anvin wrote:
>
>>Anyone have any good scripts for taking patches in email and turning
>>them into git commits, preferrably while preserving the author information?
>
>
> git-applymbox seems to be what you are looking for.
> It was named dotest in the old days.
>
Looks like it's not in cogito-0.12.1, which is why I didn't find it. I
guess I'll wait until the layered cogito comes out, hopefully this week.
-hpa
^ permalink raw reply
* Re: [patch] list shortlog items in commit order
From: Junio C Hamano @ 2005-08-02 22:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds, Jeff Garzik
In-Reply-To: <Pine.LNX.4.63.0508021713230.15300@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> The current shortlog list is backward making it look odd.
> This reverses it so things appear more logically.
Sorry, I do not know how the shortlog looked like in BK days,
but it would be nice to match that order. I do not have
preference either way myself.
I'll let it simmer and let the list decide, but I think the
kernel folks care the most about this one, so I am asking the
original authors, Linus and Jeff, if they want to go for it, or
veto it.
^ permalink raw reply
* cogito missing asciidoc.conf?
From: Sebastian Kuzminsky @ 2005-08-02 22:40 UTC (permalink / raw)
To: git
Or am I missing something?
The most recent commit to cogito makes the documentation depend on
asciidoc.conf, but it looks like the actual config file was not added.
--
Sebastian Kuzminsky
^ permalink raw reply
* Re: [patch] list shortlog items in commit order
From: Nicolas Pitre @ 2005-08-02 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Jeff Garzik
In-Reply-To: <7vvf2oklwy.fsf@assigned-by-dhcp.cox.net>
On Tue, 2 Aug 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > The current shortlog list is backward making it look odd.
> > This reverses it so things appear more logically.
>
> Sorry, I do not know how the shortlog looked like in BK days,
> but it would be nice to match that order.
This is precisely why I made this patch: to make it look like the BK
shortlog.
Nicolas
^ permalink raw reply
* Re: [PATCH] Under NO_OPENSSL -lssl should not be used
From: Jon Seymour @ 2005-08-02 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Linus Torvalds, git
In-Reply-To: <7vek9g6g4f.fsf_-_@assigned-by-dhcp.cox.net>
G'day Junio,
>
> Jon, do we really need bignum to do the flow computation? From
> a quick glance, it appears to me that the fraction manipulation
> part is quite well isolated. Do you think adding the support
> for using other bignum implementation be reasonable (assuming
> you do need to use bignum based fraction)?
>
Sorry, only just saw this. An alternative bignum implementation would
be ok, I just used the ssl stuff since it happened to do what I want
and was available. I also have a patch in the pipes that gets around
the need for arbitrary precision fractions completely.
jon.
> ------------
> This is quick and dirty but under NO_OPENSSL we should not
> attempt to link with -lssl (nor -lcrypto).
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> cd /opt/packrat/playpen/public/in-place/git/git.junio/
> jit-diff
> # - pu: Fetch from a packed repository on dumb servers.
> # + (working tree)
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -108,9 +108,11 @@ LIBS += -lz
>
> ifndef NO_OPENSSL
> LIB_OBJS += epoch.o
> + OPENSSL_LIBSSL=-lssl
> else
> CFLAGS += '-DNO_OPENSSL'
> MOZILLA_SHA1=1
> + OPENSSL_LIBSSL=
> endif
> ifdef MOZILLA_SHA1
> SHA1_HEADER="mozilla-sha1/sha1.h"
> @@ -148,7 +150,7 @@ git-ssh-pull: rsh.o pull.o
> git-ssh-push: rsh.o
>
> git-http-pull: LIBS += -lcurl
> -git-rev-list: LIBS += -lssl
> +git-rev-list: LIBS += $(OPENSSL_LIBSSL)
>
> $(LIB_OBJS): $(LIB_H)
> $(DIFF_OBJS): diffcore.h
>
> Compilation finished at Fri Jul 29 21:48:01
>
>
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: git-fsck-cache cleaning
From: Johannes Schindelin @ 2005-08-02 23:06 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1123021481.2614.6.camel@cashmere.sps.mot.com>
Hi,
do you mean git-prune-script? It is documented in
Documentation/git-prune-script.txt.
Ciao,
Dscho
^ permalink raw reply
* Users of git-check-files?
From: Johannes Schindelin @ 2005-08-02 23:10 UTC (permalink / raw)
To: git
Hi,
there's git-check-files in the repository, but AFAIK nobody uses it, not
even "git status", which would be the primary candidate. If really no
users of git-check-files exist, maybe we should remove it?
Ciao,
Dscho
^ permalink raw reply
* [PATCH 0/3] Parallel pull for SSH
From: barkalow @ 2005-08-02 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This series pipelines pulling by ssh; objects are requested as soon as
possible, and read once as many hashes as possible have been stuffed in
the queue. This seems to be a major improvement in throughput, although it
doesn't do any packing, so the total data transferred is higher than it
could be.
1: Object library additions
2: Parallel pull algorithm
3: Pipelined SSH support
It replaces these commits from -pu:
9d469633827c3ac9736ff5cca620db0491ecb200
7e11bade2166d11e3ce0b8635eb9f61716cddcd6
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 1/3] Object library enhancements
From: barkalow @ 2005-08-02 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508021939320.23721@iabervon.org>
Add function to look up an object which is entirely unknown, so that
it can be put in a list. Various other functions related to lists of
objects.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
object.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
object.h | 10 ++++++++++
tree.h | 1 +
3 files changed, 65 insertions(+), 1 deletions(-)
6f610ea3a0118fd7bcda89b75b538d3711418b72
diff --git a/object.c b/object.c
--- a/object.c
+++ b/object.c
@@ -99,7 +99,9 @@ void mark_reachable(struct object *obj,
struct object *lookup_object_type(const unsigned char *sha1, const char *type)
{
- if (!strcmp(type, blob_type)) {
+ if (!type) {
+ return lookup_unknown_object(sha1);
+ } else if (!strcmp(type, blob_type)) {
return &lookup_blob(sha1)->object;
} else if (!strcmp(type, tree_type)) {
return &lookup_tree(sha1)->object;
@@ -113,6 +115,27 @@ struct object *lookup_object_type(const
}
}
+union any_object {
+ struct object object;
+ struct commit commit;
+ struct tree tree;
+ struct blob blob;
+ struct tag tag;
+};
+
+struct object *lookup_unknown_object(const unsigned char *sha1)
+{
+ struct object *obj = lookup_object(sha1);
+ if (!obj) {
+ union any_object *ret = xmalloc(sizeof(*ret));
+ memset(ret, 0, sizeof(*ret));
+ created_object(sha1, &ret->object);
+ ret->object.type = NULL;
+ return &ret->object;
+ }
+ return obj;
+}
+
struct object *parse_object(const unsigned char *sha1)
{
unsigned long size;
@@ -150,3 +173,33 @@ struct object *parse_object(const unsign
}
return NULL;
}
+
+struct object_list *object_list_insert(struct object *item,
+ struct object_list **list_p)
+{
+ struct object_list *new_list = xmalloc(sizeof(struct object_list));
+ new_list->item = item;
+ new_list->next = *list_p;
+ *list_p = new_list;
+ return new_list;
+}
+
+unsigned object_list_length(struct object_list *list)
+{
+ unsigned ret = 0;
+ while (list) {
+ list = list->next;
+ ret++;
+ }
+ return ret;
+}
+
+int object_list_contains(struct object_list *list, struct object *obj)
+{
+ while (list) {
+ if (list->item == obj)
+ return 1;
+ list = list->next;
+ }
+ return 0;
+}
diff --git a/object.h b/object.h
--- a/object.h
+++ b/object.h
@@ -31,8 +31,18 @@ void created_object(const unsigned char
/** Returns the object, having parsed it to find out what it is. **/
struct object *parse_object(const unsigned char *sha1);
+/** Returns the object, with potentially excess memory allocated. **/
+struct object *lookup_unknown_object(const unsigned char *sha1);
+
void add_ref(struct object *refer, struct object *target);
void mark_reachable(struct object *obj, unsigned int mask);
+struct object_list *object_list_insert(struct object *item,
+ struct object_list **list_p);
+
+unsigned object_list_length(struct object_list *list);
+
+int object_list_contains(struct object_list *list, struct object *obj);
+
#endif /* OBJECT_H */
diff --git a/tree.h b/tree.h
--- a/tree.h
+++ b/tree.h
@@ -14,6 +14,7 @@ struct tree_entry_list {
unsigned int mode;
char *name;
union {
+ struct object *any;
struct tree *tree;
struct blob *blob;
} item;
^ permalink raw reply
* [PATCH 2/3] Parallelize the pull algorithm
From: barkalow @ 2005-08-02 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508021939320.23721@iabervon.org>
This processes objects in two simultaneous passes. Each object will
first be given to prefetch(), as soon as it is possible to tell that
it will be needed, and then will be given to fetch(), when it is the
next object that needs to be parsed. Unless an implementation does
something with prefetch(), this should have no effect.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
http-pull.c | 4 ++
local-pull.c | 4 ++
pull.c | 132 ++++++++++++++++++++++++++++++++++------------------------
pull.h | 7 +++
ssh-pull.c | 4 ++
5 files changed, 97 insertions(+), 54 deletions(-)
adf8aa039f2db3fb3bfc4dee0a7354b662cd5422
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -67,6 +67,10 @@ static size_t fwrite_sha1_file(void *ptr
return size;
}
+void prefetch(unsigned char *sha1)
+{
+}
+
static int got_indices = 0;
static struct packed_git *packs = NULL;
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -11,6 +11,10 @@ static int use_filecopy = 1;
static char *path; /* "Remote" git repository */
+void prefetch(unsigned char *sha1)
+{
+}
+
int fetch(unsigned char *sha1)
{
static int object_name_start = -1;
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -17,11 +17,8 @@ int get_all = 0;
int get_verbosely = 0;
static unsigned char current_commit_sha1[20];
-static const char commitS[] = "commit";
-static const char treeS[] = "tree";
-static const char blobS[] = "blob";
-
-void pull_say(const char *fmt, const char *hex) {
+void pull_say(const char *fmt, const char *hex)
+{
if (get_verbosely)
fprintf(stderr, fmt, hex);
}
@@ -48,93 +45,118 @@ static int make_sure_we_have_it(const ch
return status;
}
-static int process_unknown(unsigned char *sha1);
+static int process(unsigned char *sha1, const char *type);
-static int process_tree(unsigned char *sha1)
+static int process_tree(struct tree *tree)
{
- struct tree *tree = lookup_tree(sha1);
struct tree_entry_list *entries;
if (parse_tree(tree))
return -1;
for (entries = tree->entries; entries; entries = entries->next) {
- const char *what = entries->directory ? treeS : blobS;
- if (make_sure_we_have_it(what, entries->item.tree->object.sha1))
+ if (process(entries->item.any->sha1,
+ entries->directory ? tree_type : blob_type))
return -1;
- if (entries->directory) {
- if (process_tree(entries->item.tree->object.sha1))
- return -1;
- }
}
return 0;
}
-static int process_commit(unsigned char *sha1)
+static int process_commit(struct commit *commit)
{
- struct commit *obj = lookup_commit(sha1);
-
- if (make_sure_we_have_it(commitS, sha1))
+ if (parse_commit(commit))
return -1;
- if (parse_commit(obj))
- return -1;
+ memcpy(current_commit_sha1, commit->object.sha1, 20);
if (get_tree) {
- if (make_sure_we_have_it(treeS, obj->tree->object.sha1))
- return -1;
- if (process_tree(obj->tree->object.sha1))
+ if (process(commit->tree->object.sha1, tree_type))
return -1;
if (!get_all)
get_tree = 0;
}
if (get_history) {
- struct commit_list *parents = obj->parents;
+ struct commit_list *parents = commit->parents;
for (; parents; parents = parents->next) {
if (has_sha1_file(parents->item->object.sha1))
continue;
- if (make_sure_we_have_it(NULL,
- parents->item->object.sha1)) {
- /* The server might not have it, and
- * we don't mind.
- */
- continue;
- }
- if (process_commit(parents->item->object.sha1))
+ if (process(parents->item->object.sha1,
+ commit_type))
return -1;
- memcpy(current_commit_sha1, sha1, 20);
}
}
return 0;
}
-static int process_tag(unsigned char *sha1)
+static int process_tag(struct tag *tag)
{
- struct tag *obj = lookup_tag(sha1);
-
- if (parse_tag(obj))
+ if (parse_tag(tag))
return -1;
- return process_unknown(obj->tagged->sha1);
+ return process(tag->tagged->sha1, NULL);
}
-static int process_unknown(unsigned char *sha1)
+static struct object_list *process_queue = NULL;
+static struct object_list **process_queue_end = &process_queue;
+
+static int process(unsigned char *sha1, const char *type)
{
struct object *obj;
- if (make_sure_we_have_it("object", sha1))
- return -1;
- obj = parse_object(sha1);
- if (!obj)
- return error("Unable to parse object %s", sha1_to_hex(sha1));
- if (obj->type == commit_type)
- return process_commit(sha1);
- if (obj->type == tree_type)
- return process_tree(sha1);
- if (obj->type == blob_type)
+ if (has_sha1_file(sha1))
return 0;
- if (obj->type == tag_type)
- return process_tag(sha1);
- return error("Unable to determine requirement of type %s for %s",
- obj->type, sha1_to_hex(sha1));
+ obj = lookup_object_type(sha1, type);
+ if (object_list_contains(process_queue, obj))
+ return 0;
+ object_list_insert(obj, process_queue_end);
+ process_queue_end = &(*process_queue_end)->next;
+
+ //fprintf(stderr, "prefetch %s\n", sha1_to_hex(sha1));
+ prefetch(sha1);
+
+ return 0;
+}
+
+static int loop(void)
+{
+ while (process_queue) {
+ struct object *obj = process_queue->item;
+ /*
+ fprintf(stderr, "%d objects to pull\n",
+ object_list_length(process_queue));
+ */
+ process_queue = process_queue->next;
+ if (!process_queue)
+ process_queue_end = &process_queue;
+
+ //fprintf(stderr, "fetch %s\n", sha1_to_hex(obj->sha1));
+
+ if (make_sure_we_have_it(obj->type ?: "object",
+ obj->sha1))
+ return -1;
+ if (!obj->type)
+ parse_object(obj->sha1);
+ if (obj->type == commit_type) {
+ if (process_commit((struct commit *)obj))
+ return -1;
+ continue;
+ }
+ if (obj->type == tree_type) {
+ if (process_tree((struct tree *)obj))
+ return -1;
+ continue;
+ }
+ if (obj->type == blob_type) {
+ continue;
+ }
+ if (obj->type == tag_type) {
+ if (process_tag((struct tag *)obj))
+ return -1;
+ continue;
+ }
+ return error("Unable to determine requirements "
+ "of type %s for %s",
+ obj->type, sha1_to_hex(obj->sha1));
+ }
+ return 0;
}
static int interpret_target(char *target, unsigned char *sha1)
@@ -164,7 +186,9 @@ int pull(char *target)
if (interpret_target(target, sha1))
return error("Could not interpret %s as something to pull",
target);
- if (process_unknown(sha1))
+ if (process(sha1, NULL))
+ return -1;
+ if (loop())
return -1;
if (write_ref) {
diff --git a/pull.h b/pull.h
--- a/pull.h
+++ b/pull.h
@@ -9,6 +9,13 @@
extern int fetch(unsigned char *sha1);
/*
+ * Fetch the specified object and store it locally; fetch() will be
+ * called later to determine success. To be provided by the particular
+ * implementation.
+ */
+extern void prefetch(unsigned char *sha1);
+
+/*
* Fetch ref (relative to $GIT_DIR/refs) from the remote, and store
* the 20-byte SHA1 in sha1. Return 0 on success, -1 on failure. To
* be provided by the particular implementation.
diff --git a/ssh-pull.c b/ssh-pull.c
--- a/ssh-pull.c
+++ b/ssh-pull.c
@@ -10,6 +10,10 @@ static int fd_out;
static unsigned char remote_version = 0;
static unsigned char local_version = 1;
+void prefetch(unsigned char *sha1)
+{
+}
+
int fetch(unsigned char *sha1)
{
int ret;
^ 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