* git reveals a bug in (some versions) BSD diff
From: Johannes Schindelin @ 2005-08-12 12:32 UTC (permalink / raw)
To: git
Hi,
big was my surprise when my daily routine of "git pull" && "make test"
failed. "git bisect" revealed that commit 8e832e: "String comparison of
test is done with '=', not '=='." was the culprit.
But it isn't. The version of diff present on my iBook (OS 10.2.8) does not
work properly in this case:
(echo a; echo b | tr -d '\012') >frotz.2
(echo a; echo c; echo b | tr -d '\012') >frotz.3
diff -u frotz.2 frotz.3
yields
--- a1 2005-08-12 14:24:19.000000000 +0200
+++ a2 2005-08-12 14:24:27.000000000 +0200
@@ -1,2 +1,3 @@
a
+c
b
Note the missing "\ No newline at end of file". The same happens on
sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
server.
How to go about that? Silently ignore the missing line in apply.c? Force
users to update their diff to a sane version?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Clean generated files a bit more.
From: Petr Baudis @ 2005-08-12 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xz75w6p.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Aug 12, 2005 at 11:41:34AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Also attempt to build a source package for debian.
> ---
>
> Makefile | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> b263f24ce4f12dd39cfcd922c56a32292c6232c9
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -238,14 +238,14 @@ rpm: dist
> deb: dist
> rm -rf $(GIT_TARNAME)
> tar zxf $(GIT_TARNAME).tar.gz
> + dpkg-source -b $(GIT_TARNAME)
> cd $(GIT_TARNAME) && fakeroot debian/rules binary
>
> ### Cleaning rules
>
> clean:
> rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
> - rm -f $(GIT_TARNAME).tar.gz git-core.spec
> - rm -f git-core_$(GIT_VERSION)-*.deb git-tk_$(GIT_VERSION)-*.deb
> + rm -f git-core.spec *.deb *.dsc *.tar.gz
This makes me a bit nervous - why are you making the rules more general?
make clean removing random tarballs of mine happenning to dwell in that
directory is fearsome.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-12 10:35 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0508120139230.19902@qynat.qvtvafvgr.pbz>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
Hi,
David Lang:
> after so many years of software development (and with the policy of never
> having conflicting command names) what three letter combinations are still
> avilable?
>
Lots.
> I'm assuming that the much smaller pool of two letter commands was long
> since exhausted, but if not what two letter commands are available?
>
Lots of them, I hope, but all of them obscure.
We even have 25 one-letter commands that are free. My /usr/bin/ only has
'w'. And if we run out, we could branch off into other alphabets;
unfortunately, not everybody has a quick way to type an ä. Or α. Or ૐ. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The hope that springs eternal
Springs right up your behind.
-- Ian Drury, "This Is What We Find"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [Announce] GIT v0.99.4
From: Junio C Hamano @ 2005-08-12 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <7v64udqtt0.fsf@assigned-by-dhcp.cox.net>
In http://www.kernel.org/pub/software/scm/git/, I have placed
the following binary packages:
git-core-0.99.4.tar.gz
git-core-0.99.4-1.i386.rpm
git-core-0.99.4-1.src.rpm
git-core-debuginfo-0.99.4-1.i386.rpm
debian/git-core_0.99.4-2.dsc
debian/git-core_0.99.4-2.tar.gz
debian/git-core_0.99.4-2_i386.deb
Are people interested in seeing these binary packages? How
about binary packages for platforms other than i386?
If yes, I would need some help generating them. Before anybody
asks, no, I am not planning to do binary package every time I
push to the "master" branch --- I am only talking about tagged
releases.
On the other hand, if there are not much demand for them, I
would stop bothering. I am hoping that I could just stop
generating binary packages once major distributions pick up
git-core themselves, so this is an interim request, but
presumably people who volunteer would be the perfect candidates
for the port maintainers for those distributions.
^ permalink raw reply
* [PATCH] Update unpack-objects usage and documentation.
From: Junio C Hamano @ 2005-08-12 9:41 UTC (permalink / raw)
To: git
It long supported -q flag to suppress progress meter without
properly being documented.
---
Documentation/git-unpack-objects.txt | 8 +++++++-
unpack-objects.c | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
7d4cacb2e5ba94c45c3d5438c1703d0ea80d4ef1
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
--- a/Documentation/git-unpack-objects.txt
+++ b/Documentation/git-unpack-objects.txt
@@ -9,7 +9,7 @@ git-unpack-objects - Unpack objects from
SYNOPSIS
--------
-'git-unpack-objects' < pack-file
+'git-unpack-objects' [-q] <pack-file
DESCRIPTION
@@ -18,6 +18,12 @@ Reads a packed archive (.pack) from the
expands the objects contained in the pack into "one-file
one-object" format in $GIT_OBJECT_DIRECTORY.
+OPTIONS
+-------
+-q::
+ The command usually shows percentage progress. This
+ flag suppresses it.
+
Author
------
diff --git a/unpack-objects.c b/unpack-objects.c
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -6,7 +6,7 @@
#include <sys/time.h>
static int dry_run, quiet;
-static const char unpack_usage[] = "git-unpack-objects < pack-file";
+static const char unpack_usage[] = "git-unpack-objects [-q] < pack-file";
/* We always read in 4kB chunks. */
static unsigned char buffer[4096];
^ permalink raw reply
* [PATCH] fetch-pack: start multi-head pulling.
From: Junio C Hamano @ 2005-08-12 9:41 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
This is a beginning of resurrecting the multi-head pulling support
for git-fetch-pack command. The git-fetch-script wrapper still
only knows about fetching a single head, without renaming, so it is
not very useful unless you directly call git-fetch-pack itself yet.
It also fixes a longstanding obsolete description of how the command
discovers the list of local commits.
---
Linus, I need a bit of guidance from you about this one; an
ancient commit 4f7770c87ce3c302e1639a7737a6d2531fe4b160 removed
the multi-head support fetch-pack once had, labelling it as "a
misguided attempt", and I would like to know if I am making the
same misguided attempt again. This update actually makes
clone-pack almost redundant.
Documentation/git-fetch-pack.txt | 18 +++++-------
fetch-pack.c | 56 +++++++++++++++++++++++++++-----------
git-fetch-script | 4 +++
3 files changed, 51 insertions(+), 27 deletions(-)
880df673e412bae9603782833d8a80a7c7c59769
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -9,19 +9,19 @@ git-fetch-pack - Receive missing objects
SYNOPSIS
--------
-git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<head>...] < <commit-list>
+git-fetch-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
Invokes 'git-upload-pack' on a potentially remote repository,
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
-is fed from the standard input, to be sent to 'git-upload-pack'
-running on the other end.
+is found out by scanning local $GIT_DIR/refs/ and sent to
+'git-upload-pack' running on the other end.
-This command can be used only when the local side has a common
-(ancestor) commit with the remote head that is being pulled
-from. Use 'git-clone-pack' for that.
+This command degenerates to download everything to complete the
+asked refs from the remote side when the local side does not
+have a common ancestor commit.
OPTIONS
@@ -50,15 +50,11 @@ OPTIONS
<directory>::
The repository to sync from.
-<head>...::
+<refs>...::
The remote heads to update from. This is relative to
$GIT_DIR (e.g. "HEAD", "refs/heads/master"). When
unspecified, update from all heads the remote side has.
- However the program refuses to work if more than one
- remote head matches the specified heads. I am not sure
- what this means... Help!!!!!
-
Author
------
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -4,10 +4,13 @@
#include <sys/wait.h>
static int quiet;
-static const char fetch_pack_usage[] = "git-fetch-pack [-q] [--exec=upload-pack] [host:]directory [heads]* < mycommitlist";
+static int verbose;
+static const char fetch_pack_usage[] =
+"git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...";
static const char *exec = "git-upload-pack";
-static int find_common(int fd[2], unsigned char *result_sha1, unsigned char *remote)
+static int find_common(int fd[2], unsigned char *result_sha1,
+ struct ref *refs)
{
static char line[1000];
int count = 0, flushes = 0, retval;
@@ -16,7 +19,16 @@ static int find_common(int fd[2], unsign
revs = popen("git-rev-list $(git-rev-parse --all)", "r");
if (!revs)
die("unable to run 'git-rev-list'");
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+
+ while (refs) {
+ unsigned char *remote = refs->old_sha1;
+ if (verbose)
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ refs = refs->next;
+ }
packet_flush(fd[1]);
flushes = 1;
retval = -1;
@@ -25,6 +37,8 @@ static int find_common(int fd[2], unsign
if (get_sha1_hex(line, sha1))
die("git-fetch-pack: expected object name, got crud");
packet_write(fd[1], "have %s\n", sha1_to_hex(sha1));
+ if (verbose)
+ fprintf(stderr, "have %s\n", sha1_to_hex(sha1));
if (!(31 & ++count)) {
packet_flush(fd[1]);
flushes++;
@@ -38,6 +52,8 @@ static int find_common(int fd[2], unsign
if (get_ack(fd[0], result_sha1)) {
flushes = 0;
retval = 0;
+ if (verbose)
+ fprintf(stderr, "got ack\n");
break;
}
flushes--;
@@ -45,19 +61,19 @@ static int find_common(int fd[2], unsign
}
pclose(revs);
packet_write(fd[1], "done\n");
+ if (verbose)
+ fprintf(stderr, "done\n");
while (flushes) {
flushes--;
- if (get_ack(fd[0], result_sha1))
+ if (get_ack(fd[0], result_sha1)) {
+ if (verbose)
+ fprintf(stderr, "got ack\n");
return 0;
+ }
}
return retval;
}
-/*
- * Eventually we'll want to be able to fetch multiple heads.
- *
- * Right now we'll just require a single match.
- */
static int fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
@@ -70,12 +86,8 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
- if (ref->next) {
- packet_flush(fd[1]);
- die("multiple remote heads");
- }
- if (find_common(fd, sha1, ref->old_sha1) < 0)
- die("git-fetch-pack: no common commits");
+ if (find_common(fd, sha1, ref) < 0)
+ fprintf(stderr, "warning: no common commits\n");
pid = fork();
if (pid < 0)
die("git-fetch-pack: unable to fork off git-unpack-objects");
@@ -97,7 +109,11 @@ static int fetch_pack(int fd[2], int nr_
int code = WEXITSTATUS(status);
if (code)
die("git-unpack-objects died with error code %d", code);
- puts(sha1_to_hex(ref->old_sha1));
+ while (ref) {
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
+ }
return 0;
}
if (WIFSIGNALED(status)) {
@@ -124,6 +140,14 @@ int main(int argc, char **argv)
exec = arg + 7;
continue;
}
+ if (!strcmp("-q", arg)) {
+ quiet = 1;
+ continue;
+ }
+ if (!strcmp("-v", arg)) {
+ verbose = 1;
+ continue;
+ }
usage(fetch_pack_usage);
}
dest = arg;
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -31,6 +31,10 @@ rsync://*)
;;
*)
head=$(git-fetch-pack "$merge_repo" "$merge_head")
+ if h=`expr "$head" : '\([^ ][^ ]*\) '`
+ then
+ head=$h
+ fi
;;
esac || exit 1
^ permalink raw reply
* [PATCH] Clean generated files a bit more.
From: Junio C Hamano @ 2005-08-12 9:41 UTC (permalink / raw)
To: git
Also attempt to build a source package for debian.
---
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
b263f24ce4f12dd39cfcd922c56a32292c6232c9
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -238,14 +238,14 @@ rpm: dist
deb: dist
rm -rf $(GIT_TARNAME)
tar zxf $(GIT_TARNAME).tar.gz
+ dpkg-source -b $(GIT_TARNAME)
cd $(GIT_TARNAME) && fakeroot debian/rules binary
### Cleaning rules
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
- rm -f $(GIT_TARNAME).tar.gz git-core.spec
- rm -f git-core_$(GIT_VERSION)-*.deb git-tk_$(GIT_VERSION)-*.deb
+ rm -f git-core.spec *.deb *.dsc *.tar.gz
rm -rf $(GIT_TARNAME)
$(MAKE) -C tools/ clean
$(MAKE) -C Documentation/ clean
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: David Lang @ 2005-08-12 8:41 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.12.08.34.45.679778@smurf.noris.de>
after so many years of software development (and with the policy of never
having conflicting command names) what three letter combinations are still
avilable?
I'm assuming that the much smaller pool of two letter commands was long
since exhausted, but if not what two letter commands are available?
David Lang
On Fri, 12 Aug 2005, Matthias Urlichs wrote:
> Date: Fri, 12 Aug 2005 10:34:45 +0200
> From: Matthias Urlichs <smurf@smurf.noris.de>
> To: git@vger.kernel.org
> Subject: Re: [PATCH] Debian packaging for 0.99.4
>
> Hi, Alan Chandler wrote:
>> Not sure I understand the proper use of dpkg-divert in Debian, but could
>> _this_ git-core package perhaps ask the user which set of the two
>> packages he wish to keep as git command and use dpkg-divert to change
>> the other to another name to some other name?
>
> IIRC, that's against Policy too, because different users on the system
> might have different expectations WRT which git is git.
>
> --
> Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
> Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
> - -
> You have a strong appeal for members of the opposite sex.
>
>
> -
> 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
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-12 8:34 UTC (permalink / raw)
To: git
In-Reply-To: <42FBCD73.3090507@chandlerfamily.org.uk>
Hi, Alan Chandler wrote:
> Not sure I understand the proper use of dpkg-divert in Debian, but could
> _this_ git-core package perhaps ask the user which set of the two
> packages he wish to keep as git command and use dpkg-divert to change
> the other to another name to some other name?
IIRC, that's against Policy too, because different users on the system
might have different expectations WRT which git is git.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You have a strong appeal for members of the opposite sex.
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4 [u]
From: Andreas Jellinghaus [c] @ 2005-08-12 8:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508111448090.3295@g5.osdl.org>
On Thursday 11 August 2005 23:53, Linus Torvalds wrote:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I
> have a package" crap.
http://popcon.debian.org/by_inst
#Format
#
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
# regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
# information (atime and ctime were 0).
#rank name inst vote old recent no-files
6607 git 114 25 82 7 0
the database reflects 7162 users.
Andreas
^ permalink raw reply
* Re: [PATCH] cg-cat [was: Re: Newbie question: equiv of: cvs co -p <filename> ? ]
From: Matthias Urlichs @ 2005-08-12 7:53 UTC (permalink / raw)
To: git
In-Reply-To: <20050811230343.GJ25280@pasky.ji.cz>
Hi, Petr Baudis wrote:
> cg-admin-cat [-r TREE_ID] FILE...
> cg-admin-ls [-t TREE_ID] [PATH]
I don't know if these need to be merged, *but* please at least
change one of the flag names so that the whole mess is slightly more
consistent.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The thought of 2000 thousand people munching celery at the same time
horrifies me.
-- George Bernard Shaw
^ permalink raw reply
* Re: [PATCH] merge-base.c: pathological case fix.
From: Junio C Hamano @ 2005-08-12 5:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vk6isc5x1.fsf_-_@assigned-by-dhcp.cox.net>
I wrote:
> + * F
> + * / \
> + * E A D
> + * \ / /
> + * B /
> + * \ /
> + * C
> + *
> + * First we push E and F to list to be processed. E gets bit 1
> + * and F gets bit 2. The list becomes:
> + * ...
> + * Next, we pop B and something very interesting happens. It has flags==3
> + * so it is also placed on the result list, and its parents are marked
> + * uninteresting, retroactively, and placed back on the list:
> + *
> + * list=C(7), result=C(7) B(3)
> + *
> + * Now, list does not have any interesting commit. So we find the newest
> + * commit from the result list that is not marked uninteresting. Which is
> + * commit B.
I suspect we could have "list" where all commits on it is
uninteresting, while "result" has an interesting commit that
turns out to be reachable from one of the uninteresting commits
that is still on "list", and we miss it because we give up as
soon as "list" contains nothing but uninteresting ones.
I have not come up with such a pathological example, but if that
is indeed the case, we would still end up terminating the
well-contamination too early. I have a suspicion that no matter
how we cut it we would have this horizon effect anyway, and if
we want to really do the perfect job then we cannot avoid
traversing to the root.
Since merge-base is aiming to be a heuristic that works well
enough in practice, I think we should declare victory now and
not aim for perfection, which is an enemy of the good.
^ permalink raw reply
* Re: [PATCH] Re: git-http-pull broken in latest git
From: Junio C Hamano @ 2005-08-12 5:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.63.0508112256430.12816@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Petr Baudis <pasky@suse.cz> writes:
>> Yes, but cg-clone doesn't - it naively depended on the core git tools
>> actually, er.. working. ;-)
Sorry about that. I used to have a wrapper to deal with packs
around http-pull before Daniel's pack enhancement, and yanking
it before really checking that enhanced http-pull actually
worked was my fault as well.
>> This became a nightmare to me by now - on two machines I tried to pull
>> to over HTTP, that failed miserably, and I got stuck until I applied
>> Daniel's patch there (and cleaned up after previous git-http-pulls).
I'll push one out with two patches from Daniel today in short
order. Currently running the final "make test" round.
> At some point, I have to revisit getting git-ssh-* to generate exactly the
> required pack and transfer that, but that's an efficiency issue, not a
> correctness one, and shouldn't be relevant to the problem you're having.
Wouldn't enhancing ssh-push to generate packs on the fly involve
reinventing send-pack and/or upload-pack?
If send-pack/receive-pack pair for the push side, and/or
fetch&clone-pack/upload-pack pair for the pull side does not
work as well as you would want, then ssh-push/pull pair may
still be a useful tool, at the same time that means send-pack
and upload-pack should be fixed to address the problem you have
with them. But if that is not the case, then it might be better
to declare that ssh-pull/push pair has outlived its usefulness.
The same thing can be said about local-pull to a lesser degree.
Lesser because people, including Pasky who said so on the list
recently, would like its hard-linking behaviour, and its not
exploding the existing packs, which send-pack and upload-pack
would not give. So I would rate local-pull higher than
ssh-push/pull on the priority scale if I were doing them.
^ permalink raw reply
* Re: New script: cg-clean
From: Pavel Roskin @ 2005-08-12 3:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050812010811.GM25280@pasky.ji.cz>
On Fri, 2005-08-12 at 03:08 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Aug 12, 2005 at 02:54:13AM CEST, I got a letter
> where Pavel Roskin <proski@gnu.org> told me that...
> > Hi, Petr!
>
> Hi,
>
> > Unfortunately, my latest revision of cg-clean has "committed suicide"
> > just when I was about to post it. Anyway, I would prefer to wait until
> > you apply my patch to cg-status to ignore all ignores. That would allow
> > me to reuse cg-status.
>
> well, I did quite a while ago. Unless the kernel.org mirroring system
> broke, it should be already public.
Yes, it's there. Thank you.
This is another attempt at cg-clean. Verbose mode is now default (i.e.
everything that's removed is reported), "-q" makes the script quiet.
I've reinstated the "hard" option, it's now "-D".
Signed-off-by: Pavel Roskin <proski@gnu.org>
#!/usr/bin/env bash
#
# Clean unknown files from the working tree.
# Copyright (c) Pavel Roskin, 2005
#
# Cleans file and directories that are not under version control.
# When run without arguments, files ignored by cg-status and directories
# are not removed.
#
# OPTIONS
# -------
# -d::
# Also clean directories and their contents.
#
# -D::
# Same as -d but try harder (change permissions first).
#
# -q::
# Quiet - don't report what's being cleaned.
#
# -x::
# Also clean files ignored by cg-status, such as object files.
USAGE="cg-clean [-d] [-D] [-q] [-x]"
. ${COGITO_LIB}cg-Xlib || exit 1
noexclude=
cleandir=
cleandirhard=
quiet=
while optparse; do
if optparse -d; then
cleandir=1
elif optparse -D; then
cleandir=1
cleandirhard=1
elif optparse -q; then
quiet=1
elif optparse -x; then
noexclude=1
else
optfail
fi
done
[ "$ARGS" ] && usage
clean_dirs()
{
dirlist=$(mktemp -t gitlsfiles.XXXXXX)
git-ls-files --cached | sed -n 's|^'"$_git_relpath"'||p' |
sed -n 's|/[^/]*$||p' | sort -u >"$dirlist"
save_IFS="$IFS"
IFS=$'\n'
fpath=${_git_relpath-./}
find "$fpath" -type d -print | \
sed 's|^'"$fpath"'||;/^$/d;/^\.git$/d;/^\.git\//d' |
cat - "$dirlist" | sort -u | diff - "$dirlist" |
sed -n 's/< //p' |
for file in $(cat); do
path="${_git_relpath}$file"
if [ -z "$cleandir" ]; then
echo "Not removing $file/"
continue
fi
if [ ! -d "$path" ]; then
# Perhaps directory was removed with its parent
continue
fi
[ "$quiet" ] || echo "Removing $file/"
if [ "$cleandirhard" ]; then
chmod -R 700 "$path"
fi
rm -rf "$path"
if [ -e "$path" -o -L "$path" ]; then
echo "Cannot remove $file/"
fi
done
IFS="$save_IFS"
rm -f "$dirlist"
}
clean_files()
{
xopt=
if [ "$noexclude" ]; then
xopt="-x"
fi
save_IFS="$IFS"
IFS=$'\n'
cg-status "$xopt" -w | sed -n 's/^? //p' |
for file in $(cat); do
path="${_git_relpath}$file"
if [ -d "$path" ]; then
# Sanity check, shouldn't happen
echo "FATAL: cg-status reports directories" >&2
exit 1
elif [ -e "$path" -o -L "$path" ]; then
[ "$quiet" ] || echo "Removing $file"
rm -f "$path"
if [ -e "$path" -o -L "$path" ]; then
echo "Cannot remove $file"
fi
else
echo "File $file has disappeared!"
fi
done
IFS="$save_IFS"
}
# Even if -d or -D is not specified, we want to tell user about
# directories that are not removed
if [ -z "$quiet" -o "$cleandir" ]; then
clean_dirs
fi
clean_files
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Re: git-http-pull broken in latest git
From: Daniel Barkalow @ 2005-08-12 3:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050812024552.GO25280@pasky.ji.cz>
On Fri, 12 Aug 2005, Petr Baudis wrote:
> Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> > > tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
> >
> > > Kaboom. I think the issue might be that the reference dependency tree
> > > building is broken and it should've pulled the other pack as well.
> >
> > Last time I checked, git-http-pull did not utilize the pack
> > dependency information, which indeed is wrong. When it decides
> > to fetch a pack instead of an asked-for object, it should check
> > which commits the pack expects to have in your local repository
> > and add them to its list of things to slurp.
> >
> > A good news is that "git clone" as a whole works fine.
>
> Yes, but cg-clone doesn't - it naively depended on the core git tools
> actually, er.. working. ;-)
>
> This became a nightmare to me by now - on two machines I tried to pull
> to over HTTP, that failed miserably, and I got stuck until I applied
> Daniel's patch there (and cleaned up after previous git-http-pulls).
>
> So I have this packless git-pb repository and suspecting no evil, I pull
> from you (thankfully I have .git/objects/pack there from some historical
> pulls). I do a merge commit:
>
> packed
> ... J
> packed \
> > M
> /
> ... P
>
> Now I want to pull on another machine. That pulls M and then fails since
> I have no .git/objects/pack there, bummer. So I mkdir it, but get no
> further w/o Daniel's patch - for git-*-pull, J is missing and that's it.
> So I apply the patch, and get friendly
>
> error: Unable to determine requirements of type (null) for M
>
> and only after I delete M from the database, I finally succeed with
> git-http-pull. (That was with --repair.) That's not good since this
> might occur even naturally when the pull is interrupted.
Insufficient testing on my part; patch at the end.
> With git-ssh-pull, the situation is even more vexing - it refuses to
> fetch the packs for some reason yet unknown to me (I will debug it
> tomorrow).
git-ssh-pull doesn't deal in packs; it gets individual objects out of
packs, which git-ssh-push (on the remote side) should be extracting.
Perhaps you have a git-ssh-push on the remote side that's before I make
packs work (it used to need to have the files for objects it was sending).
At some point, I have to revisit getting git-ssh-* to generate exactly the
required pack and transfer that, but that's an efficiency issue, not a
correctness one, and shouldn't be relevant to the problem you're having.
---
[PATCH] Also parse objects we already have
In the case where we don't know from context what type an object is, but
we don't have to fetch it, we need to parse it to determine the type
before processing it.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
pull.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
b8c382e76da25f45ff86176a6a6affdd9a28d60b
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -127,6 +127,7 @@ static int process(unsigned char *sha1,
{
struct object *obj = lookup_object_type(sha1, type);
if (has_sha1_file(sha1)) {
+ parse_object(sha1);
/* We already have it, so we should scan it now. */
return process_object(obj);
}
^ permalink raw reply
* Re: git-http-pull broken in latest git
From: Petr Baudis @ 2005-08-12 2:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> > tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
>
> > Kaboom. I think the issue might be that the reference dependency tree
> > building is broken and it should've pulled the other pack as well.
>
> Last time I checked, git-http-pull did not utilize the pack
> dependency information, which indeed is wrong. When it decides
> to fetch a pack instead of an asked-for object, it should check
> which commits the pack expects to have in your local repository
> and add them to its list of things to slurp.
>
> A good news is that "git clone" as a whole works fine.
Yes, but cg-clone doesn't - it naively depended on the core git tools
actually, er.. working. ;-)
This became a nightmare to me by now - on two machines I tried to pull
to over HTTP, that failed miserably, and I got stuck until I applied
Daniel's patch there (and cleaned up after previous git-http-pulls).
So I have this packless git-pb repository and suspecting no evil, I pull
from you (thankfully I have .git/objects/pack there from some historical
pulls). I do a merge commit:
packed
... J
packed \
> M
/
... P
Now I want to pull on another machine. That pulls M and then fails since
I have no .git/objects/pack there, bummer. So I mkdir it, but get no
further w/o Daniel's patch - for git-*-pull, J is missing and that's it.
So I apply the patch, and get friendly
error: Unable to determine requirements of type (null) for M
and only after I delete M from the database, I finally succeed with
git-http-pull. (That was with --repair.) That's not good since this
might occur even naturally when the pull is interrupted.
With git-ssh-pull, the situation is even more vexing - it refuses to
fetch the packs for some reason yet unknown to me (I will debug it
tomorrow).
The git-*-pull tools appear yet rather fragile. :/
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Re: git-http-pull broken in latest git
From: Daniel Barkalow @ 2005-08-12 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vzmrnc3qt.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It should work anyway,...
>
> That is true. Please forget about the "recommendation" to slurp
> packs and not falling back on commit walker.
>
> Thanks for the patch.
No problem; I had been wondering what the rest of those lines were about
anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Re: git-http-pull broken in latest git
From: Junio C Hamano @ 2005-08-12 2:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.63.0508111929010.12816@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It should work anyway,...
That is true. Please forget about the "recommendation" to slurp
packs and not falling back on commit walker.
Thanks for the patch.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Petr Baudis @ 2005-08-12 1:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc Singer, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507120938240.17536@g5.osdl.org>
Dear diary, on Tue, Jul 12, 2005 at 06:48:50PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Then "cg-seek" and "cg-unseek" would continue to work, but the core git
> layer would never be confused because they're really using normal
> branches?
That makes sense, I just did exactly that.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* [PATCH] merge-base.c: pathological case fix.
From: Junio C Hamano @ 2005-08-12 1:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508111601000.3295@g5.osdl.org>
Also add some illustration requested by Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
merge-base.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 68 insertions(+), 6 deletions(-)
5cbb01b3bb1828759596bff71e16cfcee798491c
diff --git a/merge-base.c b/merge-base.c
--- a/merge-base.c
+++ b/merge-base.c
@@ -6,18 +6,82 @@
#define PARENT2 2
#define UNINTERESTING 4
-static int interesting(struct commit_list *list)
+static struct commit *interesting(struct commit_list *list)
{
while (list) {
struct commit *commit = list->item;
list = list->next;
if (commit->object.flags & UNINTERESTING)
continue;
- return 1;
+ return commit;
}
- return 0;
+ return NULL;
}
+/*
+ * A pathological example of how this thing works.
+ *
+ * Suppose we had this commit graph, where chronologically
+ * the timestamp on the commit are A <= B <= C <= D <= E <= F
+ * and we are trying to figure out the merge base for E and F
+ * commits.
+ *
+ * F
+ * / \
+ * E A D
+ * \ / /
+ * B /
+ * \ /
+ * C
+ *
+ * First we push E and F to list to be processed. E gets bit 1
+ * and F gets bit 2. The list becomes:
+ *
+ * list=F(2) E(1), result=empty
+ *
+ * Then we pop F, the newest commit, from the list. Its flag is 2.
+ * We scan its parents, mark them reachable from the side that F is
+ * reachable from, and push them to the list:
+ *
+ * list=E(1) D(2) A(2), result=empty
+ *
+ * Next pop E and do the same.
+ *
+ * list=D(2) B(1) A(2), result=empty
+ *
+ * Next pop D and do the same.
+ *
+ * list=C(2) B(1) A(2), result=empty
+ *
+ * Next pop C and do the same.
+ *
+ * list=B(1) A(2), result=empty
+ *
+ * Now it is B's turn. We mark its parent, C, reachable from B's side,
+ * and push it to the list:
+ *
+ * list=C(3) A(2), result=empty
+ *
+ * Now pop C and notice it has flags==3. It is placed on the result list,
+ * and the list now contains:
+ *
+ * list=A(2), result=C(3)
+ *
+ * We pop A and do the same.
+ *
+ * list=B(3), result=C(3)
+ *
+ * Next, we pop B and something very interesting happens. It has flags==3
+ * so it is also placed on the result list, and its parents are marked
+ * uninteresting, retroactively, and placed back on the list:
+ *
+ * list=C(7), result=C(7) B(3)
+ *
+ * Now, list does not have any interesting commit. So we find the newest
+ * commit from the result list that is not marked uninteresting. Which is
+ * commit B.
+ */
+
static struct commit *common_ancestor(struct commit *rev1, struct commit *rev2)
{
struct commit_list *list = NULL;
@@ -58,9 +122,7 @@ static struct commit *common_ancestor(st
insert_by_date(p, &list);
}
}
- if (!result)
- return NULL;
- return result->item;
+ return interesting(result);
}
int main(int argc, char **argv)
^ permalink raw reply
* Re: New script: cg-clean
From: Petr Baudis @ 2005-08-12 1:08 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1123808053.4248.47.camel@dv>
Dear diary, on Fri, Aug 12, 2005 at 02:54:13AM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Hi, Petr!
Hi,
> Unfortunately, my latest revision of cg-clean has "committed suicide"
> just when I was about to post it. Anyway, I would prefer to wait until
> you apply my patch to cg-status to ignore all ignores. That would allow
> me to reuse cg-status.
well, I did quite a while ago. Unless the kernel.org mirroring system
broke, it should be already public.
> On Fri, 2005-08-12 at 01:29 +0200, Petr Baudis wrote:
> > > Here's the simplified cg-clean script. Note that the "-d" option is not
> > > working with the current version of git of a bug in git-ls-files. I can
> > > work it around by scanning all directories in bash, but I think it's
> > > easier to fix git (remove "continue" before DT_REG in ls-files.c).
> >
> > Is that fixed already?
>
> It turn out it's quite tricky. git-ls-files doesn't distinguish between
> known and unknown directories.
In the long term, I would prefer to have directory information in the
index file - to make this kind of tasks easier, allow juggling with
empty directories etc.
> One way to do it would be to check all
> cached files and find all directories they are in. Another approach
> would involve "git-ls-tree -r", but I don't think it would be right
> because we work with cache and current files, not with committed data
> (but my knowledge is limited to make a call - I still need to read the
> documentation about git).
Yes, we should certainly follow the index, otherwise you will e.g. lose
the files added by cg-add but not committed yet.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: New script: cg-clean
From: Pavel Roskin @ 2005-08-12 0:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050811232925.GK25280@pasky.ji.cz>
Hi, Petr!
Unfortunately, my latest revision of cg-clean has "committed suicide"
just when I was about to post it. Anyway, I would prefer to wait until
you apply my patch to cg-status to ignore all ignores. That would allow
me to reuse cg-status.
On Fri, 2005-08-12 at 01:29 +0200, Petr Baudis wrote:
> > Here's the simplified cg-clean script. Note that the "-d" option is not
> > working with the current version of git of a bug in git-ls-files. I can
> > work it around by scanning all directories in bash, but I think it's
> > easier to fix git (remove "continue" before DT_REG in ls-files.c).
>
> Is that fixed already?
It turn out it's quite tricky. git-ls-files doesn't distinguish between
known and unknown directories. One way to do it would be to check all
cached files and find all directories they are in. Another approach
would involve "git-ls-tree -r", but I don't think it would be right
because we work with cache and current files, not with committed data
(but my knowledge is limited to make a call - I still need to read the
documentation about git).
What I did was following:
"git-ls-files --cached" is run, directories are extracted, sorted but
"sort -u" and put to a temporary file dirlist1. "find -type d" is run,
".git" is filtered out, the list is merged with dirlist1, sorted by
"sort -u", and put to dirlist2. dirlist1 and dirlist2 are compared by
diff, the entries in dirlist2 are unknown directories. (That's the kind
of task where Perl hashes would be great). A technical detail - both
lists are limited to $_git_relpath if it's defined.
> > Processing of .gitignore was taken from cg-status, and I don't really
> > understand it. But I think it's important to keep that code in sync.
> > It could later go to cg-Xlib.
>
> It became much simpler a short while later, thankfully. Judging from
> your another patch, I suppose you are going to update this script
> accordingly?
Yes, I'm going to use "cg-status -w" for files.
> > # -d::
> > # Also clean directories.
>
> Perhaps add "and their contents" to prevent bad surprises.
Too late :-)
> > filelist=$(mktemp -t gitlsfiles.XXXXXX)
> > git-ls-files --others $EXCLUDE >"$filelist"
> > save_IFS="$IFS"
> > IFS=$'\n'
> > for file in $(cat "$filelist"); do
>
> Why can't you use git-ls-files | IFS=$'\n' while ?
Good idea.
> > IFS="$save_IFS"
> > if [ -d "$file" ]; then
> > if [ "$cleandir" ]; then
> > # Try really hard by changing permissions
> > chmod -R 700 "$file"
> > rm -rf "$file"
> > fi
>
> An error message would be in order otherwise, I guess.
You mean, list directories if "-d" is not specified? Good idea. Also,
the latest revision included the "-v" option for "verbose" - it would
show everything that gets deleted.
> > return
>
> I suppose you mean continue? I'm not really sure what does return do
> here, if it jumps out of the do block or what, and continue is nicely
> explicit. :-)
My error, it was fixed soon after I posted the script.
--
Regards,
Pavel Roskin
^ permalink raw reply
* git daemon usage
From: Petr Baudis @ 2005-08-12 0:13 UTC (permalink / raw)
To: git
Hello,
is anyone actually using the git daemon in practice, now that the
other transfer methods can deal with packs? I ask since I wonder if I
should actually bother with adding support for it to cg-pull.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git-http-pull broken in latest git
From: Junio C Hamano @ 2005-08-11 23:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Last time I checked, git-http-pull did not utilize the pack
> dependency information, which indeed is wrong. When it decides
> to fetch a pack instead of an asked-for object, it should check
> which commits the pack expects to have in your local repository
> and add them to its list of things to slurp.
Oh, well, the above makes it sound as if I am blaming Daniel for
this, but the blame lies on me who did not document properly
what is going on, in except the comments in the source. So here
is an explanation.
A $GIT_DIR/objects/info/packs file looks like this:
P pack-3c5133604508466855453f3e609428f4bbba9131.pack
P pack-37cba29d3df65b160afabe769470f7857f98d729.pack
D 0
D 1 0
T 0 c1c774e7965ba08061c3fc7bc57aebc7eeb6b40f commit
T 0 d6602ec5194c87b0fc87103ca4d67251c76f233a tag
T 1 0918385dbd9656cab0d1d81ba7453d49bbc16250 tag
T 1 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e tag
T 1 b3e9704ecdf48869f635f0aa99ddfb513f885aff tag
T 1 c5db5456ae3b0873fc659c19fafdde22313cc441 tag
T 1 f25a265a342aed6041ab0cc484224d9ca54b6f41 tag
P lines are list of packs, and they are implicitly numbered
starting from #0. 3c5133 pack is pack #0 and 37cba2 pack is
pack #1 in the above example.
D lines are pack dependencies. "D 0" says pack #0 does not
depend on any, "D 1 0" says pack #1 depends on pack #0.
T lines are what I call "pack edges". They are objects that are
not reachable from any other object contained in the same pack.
What this means is that if you have all of the listed objects
for a pack, downloading that pack is useless for you. This of
course requires that your local repository is not partial.
A D line says that pack #1 depends on pack #0. So if you decide
to slurp pack #1 because you wanted to have one object that is
not available as a plain file under objects/??/, you had better
make sure that you have all the objects available in pack #0.
One way to do so is to look at T lines for pack #0 and make sure
you have those "pack edge" objects in the local repository. If
you discover you do not have them, you either need to slurp pack
#0 as well, or start walking the commits from these pack edges.
If http-pull slurped pack #0, which does not depend on anything
else, this would obviously complete the process. However, even
if http-pull chose to walk the commits, if the remote repository
is fully packed, it would end up slurping pack #0. So either
way would work fine in theory, and the choice of which approach
to take really depends on "which one is more efficient".
The only case when walking the commits from pack edges could be
a win is when your local repository have most but not all of the
objects that are in pack #0 on the remote side, and the remote
side has those needed objects lying around unpacked, in addition
to having them in the pack #0. This is very unlikely because
(1) the remote side says pack #1 depends on pack #0, which means
pack #0 is older than pack #1, and (2) we ended up slurping pack
#1, which means objects in pack #1 have already been removed by
"git prune-packed" on the remote side. These two makes it very
likely that objects in pack #0 are already prune-packed on the
remote side. So my recommendation is to just slurp the depended
on pack, pack #0, in this case instead of adding the pack edge
objects to "to be commit-walked" list.
^ permalink raw reply
* [PATCH] Re: git-http-pull broken in latest git
From: Daniel Barkalow @ 2005-08-11 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree
> > tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45
> > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45
>
> > Kaboom. I think the issue might be that the reference dependency tree
> > building is broken and it should've pulled the other pack as well.
>
> Last time I checked, git-http-pull did not utilize the pack
> dependency information, which indeed is wrong.
Is there documentation on the format?
> When it decides to fetch a pack instead of an asked-for object, it
> should check which commits the pack expects to have in your local
> repository and add them to its list of things to slurp.
It should work anyway, except that I messed up some logic in the parallel
pull stuff; when it finds it has something already, it ignores it
entirely, rather than processing it. The following patch fixes this.
---
[PATCH] Fix parallel pull dependancy tracking.
It didn't refetch an object it already had (good), but didn't process
it, either (bad). Synchronously process anything you already have.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
pull.c | 57 ++++++++++++++++++++++++++++++++-------------------------
1 files changed, 32 insertions(+), 25 deletions(-)
9b6b4b259c6b00d5b2502c158bc800d7623352bc
diff --git a/pull.c b/pull.c
--- a/pull.c
+++ b/pull.c
@@ -98,12 +98,38 @@ static int process_tag(struct tag *tag)
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)
+static int process_object(struct object *obj)
{
- struct object *obj;
- if (has_sha1_file(sha1))
+ if (obj->type == commit_type) {
+ if (process_commit((struct commit *)obj))
+ return -1;
+ return 0;
+ }
+ if (obj->type == tree_type) {
+ if (process_tree((struct tree *)obj))
+ return -1;
return 0;
- obj = lookup_object_type(sha1, type);
+ }
+ if (obj->type == blob_type) {
+ return 0;
+ }
+ if (obj->type == tag_type) {
+ if (process_tag((struct tag *)obj))
+ return -1;
+ return 0;
+ }
+ return error("Unable to determine requirements "
+ "of type %s for %s",
+ obj->type, sha1_to_hex(obj->sha1));
+}
+
+static int process(unsigned char *sha1, const char *type)
+{
+ struct object *obj = lookup_object_type(sha1, type);
+ if (has_sha1_file(sha1)) {
+ /* We already have it, so we should scan it now. */
+ return process_object(obj);
+ }
if (object_list_contains(process_queue, obj))
return 0;
object_list_insert(obj, process_queue_end);
@@ -134,27 +160,8 @@ static int loop(void)
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));
+ if (process_object(obj))
+ return -1;
}
return 0;
}
^ 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