* Re: [PATCH 0/2] Bits from git-pb
From: Junio C Hamano @ 2005-07-30 17:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20050730103103.GB26188@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
>> (iii) Do wild things in the git-pb branch and send you patches.
>
> So I assume (iii) holds?
I have not answered this because I have not made up my mind.
Certainly (iii) is probably the least work for me.
My gut feeling is that I can deal with any of the above, but
even when I pull from your tree, I expect to pull into "pu"
first and after that the patches will go through my regular
reshuffling cycle just like other patches I receive from
e-mails. This may or may not cause "interesting" troubles when
I merge again from git-pb, but we will see.
^ permalink raw reply
* Re: Making it easier to find which change introduced a bug
From: Linus Torvalds @ 2005-07-30 17:08 UTC (permalink / raw)
To: Alexander Nyberg
Cc: Chuck Ebbert, Andrew Morton, linux-kernel, Git Mailing List
In-Reply-To: <20050730122007.GA8364@localhost.localdomain>
On Sat, 30 Jul 2005, Alexander Nyberg wrote:
>
> Linus, do you think we could have something like
> patch-2.6.13-rc4-incremental-broken-out.tar.bz2 that could like Andrew's
> be placed into patches/ in a tree?
Not really. The thing is, since the git patches really _aren't_ serial,
and merging isn't based on patch-merging at all (unlike quilt, that
literally merges patches as patches), you can't really linearize a git
tree without getting some really strange behaviour.
> As it stands today it's easier for us who don't know git to just find
> out in which mainline kernel it works and which -mm it doesn't work in,
> get the broken-out and start push/pop. And I know I'm not the only one
> who has noticed this.
What we can do is try to script the git bisection thing so that it's
really trivial. It's actually very simple to use, and I think somebody had
some example scripts around.
Here's a simple starting point for somebody who wants to try.. It's not
very well tested, but I've done _some_ testing on it to try to make sure
it's at least reasonable. It adds four new git commands:
- "git bisect-start"
reset bisect state
- "git bisect-bad"
mark some version known-bad (if no arguments, then current HEAD)
- "git bisect-good"
mark some version known-good (if no arguments, then current HEAD)
- "git bisect"
do a bisection between the known bad and the known good heads, and
check that version out.
Then, the way you use it is:
git bisect-start
git bisect-bad # Current version is bad
git bisect-good v2.6.13-rc2 # v2.6.13-rc2 was the last version tested that was good
git bisect
which will say something like
Bisecting: 675 revisions left to test after this
and check out the state in the middle. Now, compile that kernel, and boot
it. Now, let's say that this booted kernel works fine, then just do
git bisect-good # this one is good
git bisect
which will now say
Bisecting: 337 revisions left to test after this
and you continue along, compiling that one, testing it, and depending on
whether it is good or bad, you say "git-bisect-good" or "git-bisect-bad",
and ask for the next bisection.
Until you have no more left, and you'll have been left with the first bad
kernel rev in "refs/bisect/bad".
Oh, and then after you want to reset to the original head, do a
git checkout master
to get back to the master branch, instead of being in one of the bisection
branches ("git bisect-start" will do that for you too, actually: it will
reset the bisection state, and before it does that it checks that you're
not using some old bisection branch).
Not really any harder than doing series of "quilt push" and "quilt pop",
now is it?
Linus
---
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -62,7 +62,9 @@ SCRIPTS=git git-apply-patch-script git-m
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
- git-request-pull-script
+ git-request-pull-script git-bisect-bad-script git-bisect-good-script \
+ git-bisect-script git-bisect-start-script
+
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-bisect-bad-script b/git-bisect-bad-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-bad-script
@@ -0,0 +1,4 @@
+#!/bin/sh
+. git-sh-setup-script || dir "Not a git archive"
+rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
+echo "$rev" > "$GIT_DIR/refs/bisect/bad"
diff --git a/git-bisect-good-script b/git-bisect-good-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-good-script
@@ -0,0 +1,4 @@
+#!/bin/sh
+. git-sh-setup-script || dir "Not a git archive"
+rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
+echo "$rev" > "$GIT_DIR/refs/bisect/good-$rev"
diff --git a/git-bisect-script b/git-bisect-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-script
@@ -0,0 +1,15 @@
+#!/bin/sh
+. git-sh-setup-script || dir "Not a git archive"
+bad=$(git-rev-parse --revs-only --verify refs/bisect/bad) || exit
+good=($(git-rev-parse --revs-only --not $(cd "$GIT_DIR" ; ls refs/bisect/good-*))) || exit
+rev=$(git-rev-list --bisect $bad ${good[@]}) || exit
+nr=$(git-rev-list $rev ${good[@]} | wc -l) || exit
+if [ "$nr" = "0" ]; then
+ echo "$bad is first bad commit"
+ git-diff-tree --pretty $bad
+ exit 0
+fi
+echo "Bisecting: $nr revisions left to test after this"
+echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
+git checkout new-bisect || exit
+cd "$GIT_DIR" && mv refs/heads/new-bisect refs/heads/bisect && ln -sf refs/heads/bisect HEAD
diff --git a/git-bisect-start-script b/git-bisect-start-script
new file mode 100755
--- /dev/null
+++ b/git-bisect-start-script
@@ -0,0 +1,26 @@
+#!/bin/sh
+. git-sh-setup-script || die "Not a git archive"
+
+#
+# Verify HEAD. If we were bisecting before this, reset to the
+# top-of-line master first!
+#
+head=$(readlink $GIT_DIR/HEAD) || die "Bad HEAD - I need a symlink"
+case "$head" in
+refs/heads/bisect*)
+ git checkout master || exit
+ ;;
+refs/heads/*)
+ ;;
+*)
+ die "Bad HEAD - strange symlink"
+ ;;
+esac
+
+#
+# Get rid of any old bisect state
+#
+cd "$GIT_DIR"
+rm -f "refs/heads/bisect"
+rm -rf "refs/bisect/"
+mkdir "refs/bisect"
^ permalink raw reply
* Re: Fix interesting git-rev-list corner case
From: Linus Torvalds @ 2005-07-30 16:18 UTC (permalink / raw)
To: Peter Osterlund; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <m31x5gob8k.fsf@telia.com>
On Sat, 30 Jul 2005, Peter Osterlund wrote:
>
> I have problems pulling linux kernel changes from
> 33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
> b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
> I thought your patch would fix it, but it doesn't:
No, this is a merge conflict failure, and you simply have conflicts in the
tree. git did everything right, it just couldn't do an automatic merge.
> ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c.
> ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c.
> ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c.
> ERROR: Merge conflict in include/asm-i386/bitops.h.
> ERROR: Merge conflict in kernel/sys.c.
We don't have any nice graphical tools to show these to you like BitKeeper
had, although it shouldn't be fundamentally hard.
What you need to do is basically edit all those five files, and look for
the conflicts (they are just like normal CVS conflicts:
<<<<<<<
orig-branch
conflict-contents
=======
pulled-branch
conflict-contents
>>>>>>>>
and then you edit them to your liking until you have no more conflicts,
and then you have to commit your manual resolve with
git commit --all
which will commit the merge _and_ your manual conflict resolution.
This is something where a nice wrapper layer could do a lot better. I know
there are graphical three-way merge programs available.
But core git is no worse (and in fact a _lot_ better) than CVS in this
regard, so I feel that the git merge, while obviously not perfect or even
very smart, is "sufficient" for what git is (ie it's up to porcelain to do
anything better).
Linus
^ permalink raw reply
* Re: [PATCH] Under NO_OPENSSL -lssl should not be used
From: Linus Torvalds @ 2005-07-30 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Jon Seymour, git
In-Reply-To: <7vek9g6g4f.fsf_-_@assigned-by-dhcp.cox.net>
On Fri, 29 Jul 2005, Junio C Hamano wrote:
>
> Would this be OK? I think it is ugly but it gets the job done.
Looks ok. I'd suggest having some option to turn of "curl" too - I have
one machine that doesn't have curl installed, and I just turn the things
that depend on it off by hand by editing the makefile right now..
Linus
^ permalink raw reply
* gitk merge display bugs (was: Re: Display of merges in gitk)
From: Sergey Vlasov @ 2005-07-30 14:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17130.56620.137642.941175@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]
On Fri, 29 Jul 2005 20:51:40 -0500 Paul Mackerras wrote:
> I have reworked the way gitk displays merges.
I have found a reproducible bug in gitk which seems to be in that new
code for merges. Run
gitk f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba
on the git or cogito repository (that commit is from 2005-07-05), then
click the topmost commit ("Merge with Linus' current tree"), then click
it again - you get an error popup with this trace:
can't read "filelines(f13bbe7f56e49a11f6bfc3b73a463c741f969c9c,0,137)": no such element in array
can't read "filelines(f13bbe7f56e49a11f6bfc3b73a463c741f969c9c,0,137)": no such element in array
while executing
"$ctext insert end "-$filelines($p,$f,$ol)\n" m$pnum"
(procedure "processgroup" line 143)
invoked from within
"processgroup"
(procedure "processhunks" line 47)
invoked from within
"processhunks"
(procedure "getmergediffline" line 81)
invoked from within
"getmergediffline file10 {f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba f13bbe7f56e49a11f6bfc3b73a463c741f969c9c} f4b3a4c30b5ea3a5de2a2597a3c53266017d02ba"
Another badness which appears with the same repository: run
gitk f13bbe7f56e49a11f6bfc3b73a463c741f969c9c
then repeated clicks on the topmost commit result in a different diff
shown (no error popups, however).
Also if I quickly move between commits, sometimes I get error popups
like:
can't unset "treepending": no such variable
while executing
"unset treepending"
(procedure "gettreediffline" line 9)
invoked from within
"gettreediffline file30 {429a9358763dfb98cd063e40dc49cbc049e2a268 154d3d2dd2656c23ea04e9d1c6dd4e576a7af6de}"
This error does not happen again if the same commit is selected.
All this happens both with current cogito
(134b78a167b5f77725cd8435849de7298b6de477) and git
(9e44f8980b8f41fbeea0a68035865e5778e4dc7d).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Documentation: Add asciidoc.conf file and gitlink: macro
From: Jonas Fonseca @ 2005-07-30 13:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Introduce an asciidoc.conf file with the purpose of adding a gitlink: macro
which will improve the manpage output. Most notably this changes the following
in cogito.7
...
cg-add: cg-add.html [-N] FILE...
Add files to the GIT repository.
cg-branch-add: cg-branch-add.html BRANCH_NAME LOCATION
Add new branch to the GIT repository.
...
to
...
cg-add [-N] FILE...
Add files to the GIT repository.
cg-branch-add BRANCH_NAME LOCATION
Add new branch to the GIT repository.
...
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
I only did the Cogito part, since it was a lot easier. If this is
desirable for the GIT core manpages I'd be happy to provide a similar
patch to remove the confusing .html links from GIT manpages.
Documentation/Makefile | 4 ++--
Documentation/asciidoc.conf | 18 ++++++++++++++++++
Documentation/make-cg-asciidoc | 6 +++---
Documentation/make-cogito-asciidoc | 19 ++++++++++---------
4 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -48,13 +48,13 @@ clean:
rm -f *.xml *.html *.1 *.7 cg-*.txt cogito.txt
%.html : %.txt
- asciidoc -b xhtml11 -d manpage $<
+ asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
%.1 %.7 : %.xml
xmlto man $<
%.xml : %.txt
- asciidoc -b docbook -d manpage $<
+ asciidoc -b docbook -d manpage -f asciidoc.conf $<
cogito.txt : make-cogito-asciidoc
./make-cogito-asciidoc > $@
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
new file mode 100644
--- /dev/null
+++ b/Documentation/asciidoc.conf
@@ -0,0 +1,18 @@
+## gitlink: macro
+#
+# Usage: gitlink:command[manpage-section]
+#
+# Note, {0} is the manpage section, while {target} is the command.
+#
+# Show GIT link as: <command>(<section>); if section is defined, else just show
+# the command.
+
+ifdef::backend-docbook[]
+[gitlink-inlinemacro]
+{target}{0?({0})}
+endif::backend-docbook[]
+
+ifdef::backend-xhtml11[]
+[gitlink-inlinemacro]
+<a href="{target}.html">{target}{0?({0})}</a>
+endif::backend-xhtml11[]
diff --git a/Documentation/make-cg-asciidoc b/Documentation/make-cg-asciidoc
--- a/Documentation/make-cg-asciidoc
+++ b/Documentation/make-cg-asciidoc
@@ -40,7 +40,7 @@ CAPTION=$(echo "$HEADER" | head -n 1 | t
# were referenced as "`cg-command`". This way references from cg-* combos in
# code listings will be ignored.
BODY=$(echo "$HEADER" | sed '0,/^$/d' \
- | sed 's/`\(cg-[a-z-]\+\)`/link:\1.html[\1]/')
+ | sed 's/`\(cg-[a-z-]\+\)`/gitlink:\1[1]/')
DESCRIPTION=
OPTIONS=
@@ -108,6 +108,6 @@ $COPYRIGHT
SEE ALSO
--------
-$COMMAND command is part of link:cogito.html[cogito(7)],
-a toolkit for managing link:git.html[git(1)] trees.
+$COMMAND command is part of gitlink:cogito[7],
+a toolkit for managing gitlink:git[7] trees.
__END__
diff --git a/Documentation/make-cogito-asciidoc b/Documentation/make-cogito-asciidoc
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -8,10 +8,11 @@ ADVANCED_COMMANDS="$(ls ../cg-admin-*)"
HELPER_COMMANDS="$(ls ../cg-X*) $(ls ../*-id | grep -v git-)"
# Shorthand for the link markup.
-link()
+man()
{
- command="$1"
- echo "link:$command.html['$command']"
+ section="$1"
+ command="$2"
+ echo "gitlink:$command[$section]"
}
# Print description list entry.
@@ -28,7 +29,7 @@ print_command_info()
;;
cg-*)
usage=$(sed -n '/^USAGE=/,0s/.*cg-[^ ]*\(.*\)"/\1/p' < $command)
- echo "link:$cmdname.html[$cmdname] $usage::"
+ echo "gitlink:$cmdname[] $usage::"
;;
esac
echo " $caption"
@@ -62,7 +63,7 @@ storage system. Amongst some of the note
for branching, tagging and multiple backends for distributing repositories
(local files, rsync, HTTP, ssh).
-'Cogito' is implemented as a series of 'bash(1)' scripts on top of $(link git)
+'Cogito' is implemented as a series of 'bash(1)' scripts on top of $(man 7 git)
(a content-tracking filesystem) with the goal of providing an interface for
working with the 'GIT' database in a manner similar to other SCM tools (like
'CVS', 'BitKeeper' or 'Monotone').
@@ -107,21 +108,21 @@ $(print_command_listing $HELPER_COMMANDS
Command Identifiers
-------------------
BRANCH_NAME::
- Indicates a branch name added with the $(link cg-branch-add) command.
+ Indicates a branch name added with the $(man 1 cg-branch-add) command.
COMMAND::
Indicates a 'Cogito' command. The \`cg-\` prefix is optional.
LOCATION::
- Indicates a local file path or a URI. See $(link cg-branch-add) for a
+ Indicates a local file path or a URI. See $(man 1 cg-branch-add) for a
list of supported URI schemes.
COMMIT_ID, FROM_ID, TO_ID, BASE_COMMIT::
Indicates an ID resolving to a commit. The following expressions can
be used interchangably as IDs:
- empty string, 'this' or 'HEAD' (current HEAD)
- - branch name (as registered with $(link cg-branch-add))
- - tag name (as registered with $(link cg-tag))
+ - branch name (as registered with $(man 1 cg-branch-add))
+ - tag name (as registered with $(man 1 cg-tag))
- date string (as recognized by the 'date' tool)
- shortcut object hash (shorted unambiguous hash lead)
- commit object hash (as returned by 'commit-id')
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Johannes Schindelin @ 2005-07-30 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vslxw4tb1.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
is it possible that you forgot to initialize commit_graft_nr to 0?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] Bits from git-pb
From: Petr Baudis @ 2005-07-30 10:31 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>
Dear diary, on Fri, Jul 29, 2005 at 10:58:19AM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> (i) Keep the git-pb branch polished and nice-to-merge, if you want to
> pull from it.
>
> (ii) Keep the git-pb branch polished and nice-to-merge and rebase it
> regularily if you don't want loong edges in your history graph, but
> want to pull from it.
>
> (iii) Do wild things in the git-pb branch and send you patches.
So I assume (iii) holds?
--
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: Fix interesting git-rev-list corner case
From: Peter Osterlund @ 2005-07-30 10:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507291542060.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This corner-case was triggered by a kernel commit that was not in date
> order, due to a misconfigured time zone that made the commit appear three
> hours older than it was.
I have problems pulling linux kernel changes from
33ac02aa4cef417871e128ab4a6565e751e5f3b2 to
b0825488a642cadcf39709961dde61440cb0731c into my local tree. At first
I thought your patch would fix it, but it doesn't:
r3000:~/git$ cat linux/.git/HEAD
b0825488a642cadcf39709961dde61440cb0731c
r3000:~/git$ git-clone-script -l linux linux.test
defaulting to local storage area
0 blocks
r3000:~/git$ cd linux.test/
r3000:~/git/linux.test$ echo 33ac02aa4cef417871e128ab4a6565e751e5f3b2 >.git/HEAD
r3000:~/git/linux.test$ git-pull-script ../linux
Packing 291 objects
Unpacking 291 objects
100% (291/291) done
Trying to merge b0825488a642cadcf39709961dde61440cb0731c into 33ac02aa4cef417871e128ab4a6565e751e5f3b2
Simple merge failed, trying Automatic merge
Removing arch/mips/vr41xx/common/giu.c
Auto-merging arch/s390/kernel/head.S.
Auto-merging arch/s390/kernel/head64.S.
Auto-merging arch/um/os-Linux/elf_aux.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/um/os-Linux/elf_aux.c.
Auto-merging arch/x86_64/kernel/smp.c.
Auto-merging arch/x86_64/kernel/smpboot.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c.
Auto-merging drivers/i2c/busses/i2c-mpc.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/i2c/busses/i2c-mpc.c.
Removing drivers/ide/cris/ide-v10.c
Removing drivers/media/dvb/frontends/lgdt3302.c
Removing drivers/media/dvb/frontends/lgdt3302.h
Removing drivers/media/dvb/frontends/lgdt3302_priv.h
Removing drivers/serial/bast_sio.c
Auto-merging drivers/usb/input/hid-input.c.
Auto-merging drivers/video/fbmem.c.
Auto-merging include/asm-i386/bitops.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/asm-i386/bitops.h.
Auto-merging include/asm-x86_64/smp.h.
Auto-merging kernel/sys.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in kernel/sys.c.
Removing net/ipv4/utils.c
Removing sound/pcmcia/vx/vx_entry.c
Removing sound/pcmcia/vx/vxp440.c
fatal: merge program failed
Automatic merge failed, fix up by hand
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Matthias Urlichs @ 2005-07-30 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vslxw4tb1.fsf_-_@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> Introduce a new file $GIT_DIR/info/grafts
Nice work.
Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.
--
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
- -
Whatever occurs from love is always beyond good and evil.
-- Friedrich Nietzsche
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-30 8:07 UTC (permalink / raw)
To: barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0507300118060.25709@iabervon.org>
barkalow@iabervon.org writes:
> I still have the patch to make git-http-pull download packs, and I
> should be able to get it to read the objects/info/packs file without
> too much trouble.
Another thing that may help you gain more parallelism in the
initial set of requests is the rev-cache file. You can find out
the ancestry information upfront by reading it, without waiting
for the commits you asked to arrive.
^ permalink raw reply
* [PATCH] Teach parse_commit_buffer about grafting.
From: Junio C Hamano @ 2005-07-30 8:00 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0507270846360.3227@g5.osdl.org>
Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
which is a list of "fake commit parent records". Each line of
this file is a commit ID, followed by parent commit IDs, all
40-byte hex SHA1 separated by a single SP in between. The
records override the parent information we would normally read
from the commit objects, allowing both adding "fake" parents
(i.e. grafting), and pretending as if a commit is not a child of
some of its real parents (i.e. cauterizing).
Bugs are mine, but the credits for the idea and implementation
outline all go to Linus, who kept hinting how this thing should
work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 2 +
commit.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
sha1_file.c | 13 ++++++-
3 files changed, 127 insertions(+), 2 deletions(-)
0f16b172aa7f0757b2af50ec7be58dc0e23913a6
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -127,10 +127,12 @@ extern unsigned int active_nr, active_al
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
+#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
+extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -91,11 +91,108 @@ static unsigned long parse_commit_date(c
return date;
}
+static struct commit_graft {
+ unsigned char sha1[20];
+ int nr_parent;
+ unsigned char parent[0][20]; /* more */
+} **commit_graft;
+static int commit_graft_alloc, commit_graft_nr;
+
+static int commit_graft_pos(const unsigned char *sha1)
+{
+ int lo, hi;
+ lo = 0;
+ hi = commit_graft_nr;
+ while (lo < hi) {
+ int mi = (lo + hi) / 2;
+ struct commit_graft *graft = commit_graft[mi];
+ int cmp = memcmp(sha1, graft->sha1, 20);
+ if (!cmp)
+ return mi;
+ if (cmp < 0)
+ hi = mi;
+ else
+ lo = mi + 1;
+ }
+ return -lo - 1;
+}
+
+static void prepare_commit_graft(void)
+{
+ char *graft_file = get_graft_file();
+ FILE *fp = fopen(graft_file, "r");
+ char buf[1024];
+ if (!fp) {
+ commit_graft = (struct commit_graft **) "hack";
+ return;
+ }
+ while (fgets(buf, sizeof(buf), fp)) {
+ /* The format is just "Commit Parent1 Parent2 ...\n" */
+ int len = strlen(buf);
+ int i;
+ struct commit_graft *graft = NULL;
+
+ if (buf[len-1] == '\n')
+ buf[--len] = 0;
+ if (buf[0] == '#')
+ continue;
+ if ((len + 1) % 41) {
+ bad_graft_data:
+ error("bad graft data: %s", buf);
+ free(graft);
+ continue;
+ }
+ i = (len + 1) / 41 - 1;
+ graft = xmalloc(sizeof(*graft) + 20 * i);
+ graft->nr_parent = i;
+ if (get_sha1_hex(buf, graft->sha1))
+ goto bad_graft_data;
+ for (i = 40; i < len; i += 41) {
+ if (buf[i] != ' ')
+ goto bad_graft_data;
+ if (get_sha1_hex(buf + i + 1, graft->parent[i/41]))
+ goto bad_graft_data;
+ }
+ i = commit_graft_pos(graft->sha1);
+ if (0 <= i) {
+ error("duplicate graft data: %s", buf);
+ free(graft);
+ continue;
+ }
+ i = -i - 1;
+ if (commit_graft_alloc <= ++commit_graft_nr) {
+ commit_graft_alloc = alloc_nr(commit_graft_alloc);
+ commit_graft = xrealloc(commit_graft,
+ sizeof(*commit_graft) *
+ commit_graft_alloc);
+ }
+ if (i < commit_graft_nr)
+ memmove(commit_graft + i + 1,
+ commit_graft + i,
+ (commit_graft_nr - i - 1) *
+ sizeof(*commit_graft));
+ commit_graft[i] = graft;
+ }
+ fclose(fp);
+}
+
+static struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
+{
+ int pos;
+ if (!commit_graft)
+ prepare_commit_graft();
+ pos = commit_graft_pos(sha1);
+ if (pos < 0)
+ return NULL;
+ return commit_graft[pos];
+}
+
int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size)
{
char *bufptr = buffer;
unsigned char parent[20];
struct commit_list **pptr;
+ struct commit_graft *graft;
if (item->object.parsed)
return 0;
@@ -109,17 +206,32 @@ int parse_commit_buffer(struct commit *i
add_ref(&item->object, &item->tree->object);
bufptr += 46; /* "tree " + "hex sha1" + "\n" */
pptr = &item->parents;
+
+ graft = lookup_commit_graft(item->object.sha1);
while (!memcmp(bufptr, "parent ", 7)) {
struct commit *new_parent;
if (get_sha1_hex(bufptr + 7, parent) || bufptr[47] != '\n')
return error("bad parents in commit %s", sha1_to_hex(item->object.sha1));
+ bufptr += 48;
+ if (graft)
+ continue;
new_parent = lookup_commit(parent);
if (new_parent) {
pptr = &commit_list_insert(new_parent, pptr)->next;
add_ref(&item->object, &new_parent->object);
}
- bufptr += 48;
+ }
+ if (graft) {
+ int i;
+ struct commit *new_parent;
+ for (i = 0; i < graft->nr_parent; i++) {
+ new_parent = lookup_commit(graft->parent[i]);
+ if (!new_parent)
+ continue;
+ pptr = &commit_list_insert(new_parent, pptr)->next;
+ add_ref(&item->object, &new_parent->object);
+ }
}
item->date = parse_commit_date(bufptr);
return 0;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -61,7 +61,8 @@ static int get_sha1_file(const char *pat
return get_sha1_hex(buffer, result);
}
-static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir;
+static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
+ *git_graft_file;
static void setup_git_env(void)
{
git_dir = gitenv(GIT_DIR_ENVIRONMENT);
@@ -79,6 +80,9 @@ static void setup_git_env(void)
git_index_file = xmalloc(strlen(git_dir) + 7);
sprintf(git_index_file, "%s/index", git_dir);
}
+ git_graft_file = gitenv(GRAFT_ENVIRONMENT);
+ if (!git_graft_file)
+ git_graft_file = strdup(git_path("info/grafts"));
}
char *get_object_directory(void)
@@ -102,6 +106,13 @@ char *get_index_file(void)
return git_index_file;
}
+char *get_graft_file(void)
+{
+ if (!git_graft_file)
+ setup_git_env();
+ return git_graft_file;
+}
+
int safe_create_leading_directories(char *path)
{
char *pos = path;
^ permalink raw reply
* Re: [PATCH 2/2] Unify usage strings declaration
From: Matthias Urlichs @ 2005-07-30 6:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vfytx82m3.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I do not have preference either way, and I've already merged
> them, but why char[] not char*?
A char* is a variable which points to the char[].
That's four (or eight) bytes we don't need. ;-)
C conflates the two concepts somewhat, which is one of the reasons
optimizing compiled C is somewhat more challenging than, say, FORTRAN.
--
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
- -
Giving every man a vote has no more made men wise
and free than Christianity has made them good.
-- H.L. Mencken
^ permalink raw reply
* Re: Last mile to 1.0?
From: barkalow @ 2005-07-30 5:40 UTC (permalink / raw)
To: git; +Cc: barkalow
I've been missing for a couple of weeks due to my server dying and needing
to be replaced; I think stuff is mostly back in order now. (But I'm not
yet resubscribed, and I suspect only dumb mailers are currently willing
to talk to my mail server, for some reason I don't yet understand; I'm
sort of reading the archives, at least.)
I still have the patch to make git-http-pull download packs, and I should
be able to get it to read the objects/info/packs file without too much
trouble.
I was also in progress on a series to rearrange the code in pull.c such
that it passes the objects it needs through a list such that it can
request them in parallel. I'd gotten as far as making it blast out
requests for objects over git-ssh-pull (and then break because it doesn't
expect to be able to accidentally read part of the next object while
reading the current object); it shouldn't be too hard to make the HTTP
version use this to parallelize requests as well.
I expect I'll get to work on this on Sunday, in any case.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Under NO_OPENSSL -lssl should not be used
From: Junio C Hamano @ 2005-07-30 5:02 UTC (permalink / raw)
To: Petr Baudis, Jon Seymour; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.58.0507292038160.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This doesn't work at least in the form that Junio merged it (and from
> what I can tell, he merged your patch as-is):
>
> torvalds@shell0:~/src/git> make NO_OPENSSL=1
> cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER="mozilla-sha1/sha1.h"' -o git-rev-list rev-list.o libgit.a -lz -lssl
> /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/bin/ld: cannot find -lssl
>
> it needs to disable the -lssl too..
Would this be OK? I think it is ugly but it gets the job done.
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)?
------------
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
^ permalink raw reply
* Re: Display of merges in gitk
From: Junio C Hamano @ 2005-07-30 4:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17130.56620.137642.941175@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Linus, could you do a pull from the usual place to pick this up?
> (rsync://rsync.kernel.org/pub/scm/gitk/gitk.git). I also included a
> patch from Junio.
In case you did not notice, /pub/scm/git/git.git/ repository is
under the care of yours truly starting this week. I've merged
from your tree up to this commit:
commit c8a4acbf4a7b0f9da3e320877b2b2d12cd58700b
Author: Paul Mackerras <paulus@samba.org>
Date: Fri Jul 29 09:23:03 2005 -0500
Improve the merge display when the result differs from all parents.
Now we see if the result is quite similar to one of the parents, and
if it is, display the result as a diff from that parent. If the result
is similar to more than one parent, pick the one that it's most
similar to.
Thanks for the great tool.
^ permalink raw reply
* Re: [PATCH 7/2] Support for NO_OPENSSL
From: Junio C Hamano @ 2005-07-30 4:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507292038160.29650@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This doesn't work at least in the form that Junio merged it (and from
> what I can tell, he merged your patch as-is):
Slipped my filter. Sorry. Will fix.
^ permalink raw reply
* Display of merges in gitk
From: Paul Mackerras @ 2005-07-30 1:51 UTC (permalink / raw)
To: git
I have reworked the way gitk displays merges. Previously it would
display all the diffs between the child and each parent. That
displayed a lot of unnecessary stuff; for example, for the famous
octopus (pentapus?) merge, each diff was shown 4 times. It also shows
diffs when the merge is perfectly straightforward, i.e. when any given
file has been modified in at most one of the parents, and the child's
version is the same as the parent's.
Now gitk will only list a file as having a difference in a merge if
one or more of the parents has a version of the file that is different
both from the child and from the common ancestor of the parents (if a
common ancestor exists). If there is no common ancestor, then a file
is listed if it is different in the child from all of the parents.
I now also display the diffs for a file in one unified difference
listing. Lines are color-coded according to which parent they come
from, and are in bold with a + at the start of the line if they ended
up in the merge result (the child), or in normal font with a - at the
start of the line if they didn't. In the usual case of two parents,
lines from the first parent are in red and lines from the second
parent are in blue. Lines in the result that don't correspond to
either parent are in bold black.
Linus, could you do a pull from the usual place to pick this up?
(rsync://rsync.kernel.org/pub/scm/gitk/gitk.git). I also included a
patch from Junio.
Paul.
^ permalink raw reply
* Re: [PATCH 7/2] Support for NO_OPENSSL
From: Linus Torvalds @ 2005-07-30 3:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: junkio, git
In-Reply-To: <20050729155051.GJ21909@pasky.ji.cz>
This doesn't work at least in the form that Junio merged it (and from
what I can tell, he merged your patch as-is):
torvalds@shell0:~/src/git> make NO_OPENSSL=1
cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER="mozilla-sha1/sha1.h"' -o git-rev-list rev-list.o libgit.a -lz -lssl
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/bin/ld: cannot find -lssl
it needs to disable the -lssl too..
Linus
^ permalink raw reply
* [PATCH] git-applymbox: allow retrying after fixing up.
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: git
After failing to apply a patch, when operating under -q (query)
flag, give the user an opportunity to fix up the patch in a
separate window and retry.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
tools/git-applymbox | 56 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 41 insertions(+), 15 deletions(-)
2b1077125e629c316905ae480ab4f8699332b7f7
diff --git a/tools/git-applymbox b/tools/git-applymbox
--- a/tools/git-applymbox
+++ b/tools/git-applymbox
@@ -9,7 +9,7 @@
## You give it a mbox-format collection of emails, and it will try to
## apply them to the kernel using "applypatch"
##
-## applymbox [ -c .dotest/msg-number ] [ -q ] mail_archive [Signoff_file]"
+## applymbox [ -q ] (-c .dotest/msg-number | mail_archive) [Signoff_file]"
##
## The patch application may fail in the middle. In which case:
## (1) look at .dotest/patch and fix it up to apply
@@ -35,29 +35,55 @@ case "$continue" in
rm -rf .dotest
mkdir .dotest
git-mailsplit "$1" .dotest || exit 1
+ shift
esac
case "$query_apply" in
t) touch .dotest/.query_apply
esac
-for i in .dotest/0*
+signoff="$1"
+set x .dotest/0*
+shift
+while case "$#" in 0) break;; esac
do
- case "$resume,$continue" in
- f,$i) resume=t;;
- f,*) continue;;
- *)
- git-mailinfo .dotest/msg .dotest/patch <$i >.dotest/info || exit 1
- git-stripspace < .dotest/msg > .dotest/msg-clean
- ;;
- esac
- git-applypatch .dotest/msg-clean .dotest/patch .dotest/info "$2"
- ret=$?
- if [ $ret -ne 0 ]; then
+ i="$1"
+ case "$resume,$continue" in
+ f,$i) resume=t;;
+ f,*) continue;;
+ *)
+ git-mailinfo .dotest/msg .dotest/patch <$i >.dotest/info || exit 1
+ git-stripspace < .dotest/msg > .dotest/msg-clean
+ ;;
+ esac
+ while :; # for fixing up and retry
+ do
+ git-applypatch .dotest/msg-clean .dotest/patch .dotest/info "$signoff"
+ case "$?" in
+ 0 | 2 )
# 2 is a special exit code from applypatch to indicate that
# the patch wasn't applied, but continue anyway
- [ $ret -ne 2 ] && exit $ret
- fi
+ ;;
+ *)
+ ret=$?
+ if test -f .dotest/.query_apply
+ then
+ echo >&2 "* Patch failed."
+ echo >&2 "* You could fix it up in your editor and"
+ echo >&2 " retry. If you want to do so, say yes here"
+ echo >&2 " AFTER fixing .dotest/patch up."
+ echo >&2 -n "Retry [y/N]? "
+ read yesno
+ case "$yesno" in
+ [Yy]*)
+ continue ;;
+ esac
+ fi
+ exit $ret
+ esac
+ break
+ done
+ shift
done
# return to pristine
rm -fr .dotest
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20050729122844.GA21909@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
>> > How would that document anything normal push wouldn't?
>>
>> git-merge?
>
> You have to git-merge anyway if remote head is not your ancestor yet,
> otherwise the push cannot proceed.
Indeed. And if git-merge fast forwards, then you would not get
any trail, so the "documentation by merge" argument does not
stand.
^ permalink raw reply
* Re: Dump http servers still slow?
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1122645821.4263.6.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> Ok... so lets check my assumptions:
>
> 1. Pack files should reduce the number of http round trips.
> 2. What I'm seeing when I check out mainline git is the acquisition of a
> single large pack, then 600+ more recent objects. Better than before,
> but still hundreds of round trips.
> 3. If I wanted to further speed up the initial checkout on my own
> repositories I could frequently repack my most recent few hundred
> objects.
> 4. If curl had pipelining then less pack management would be needed.
All true. Another possibility is to make multiple requests in
parallel; if curl does not do pipelining, either switch to
something that does, or have more then one process using curl.
The dumb server preparation creates three files, two of which is
currently used by clone (one is list of packs, the other is list
of branches and tags). The third one is commit ancestry
information. The commit walker could be taught to read it to
figure out what commits it still needs to fetch without waiting
for the commit being retrieved to be parsed.
Sorry, I am not planning to write that part myself.
One potential low hanging fruit is that even for cloning via
git:// URL we _might_ be better off starting with the dumb
server protocol; get the list of statically prepared packs and
obtain them upfront before starting the clone-pack/upload-pack
protocol pair.
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis
Cc: Catalin Marinas, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050729111056.GR24895@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
>> Petr Baudis <pasky@suse.cz> wrote:
>> > The committer field generally identifies the committer "physically", and
>> > isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my
>> > committer field, e.g.
>>
>> I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
>> the defaults like username@localmachine.
>
> Yes, but IIRC only for rather special cases like recommitting older
> commits, importing from other VCSes, etc.
My recollection coincides with Catalin. Special case is when
you set it to somebody else, "logically" different from you, as
you say. Fixing GECOS fields and mailhost settings as Catalin
says is another.
Setting it to something "physically" different but still the
same you, for example using your work e-mail address when you
are on your home machine, is not special case at all, but is
also a valid use. However when you start to do that, it may
become unusable as a valid e-mail address you can use for From:
and/or Sender: fields.
>> The latest StGIT snapshot uses, by default, the committer's details
>> for the From: line when sending patches by e-mail, assuming that this
>> is a valid e-mail address. One can define his own e-mail template and
>> use a different From: line but I thought it would be simpler to
>> provide some defaults based on this.
>
> Why don't you rather use the GIT_AUTHOR_* variables?
I tend to agree. When forwarding somebody else's commit as a
patch, you would want to name that author on From: line and make
yourself Sender:. Of course, in that case Sender: should be a
valid e-mail address for the originating machine; otherwise
bogus-mail-relay prevention would block your e-mail. In that
sense, using COMMITTER to identify you "physically" (meaning:
tied to your identity with that particular machine) would work
better.
^ permalink raw reply
* Status of git.git repository
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: git
I've been trying to streamline my workflow since I took it over
from Linus, and I think I am getting used to it. So here is a
short summary of what I am doing in the git.git repository.
Right now, there are two branches on kernel.org git.git
repository. I would not rewind "master" so if I find out any
screwups and need to do an emergency fix, that fix would go on
top of the tip of "master" (I just did one today X-< due to lack
of testing).
On the other hand, "pu" is rebased every time "master" advances.
They are queued patches I receive in e-mails, and they hopefully
will graduate to be part of "master" when I feel they look OK,
and I feel that objections from the list were non-issues. Of
course some may drop out without graduating. Please consider
seeing your patch in "pu" branch an ACK from me, but seeing it
sitting in "pu" for a long time is a sign of trouble.
By the way, do people mind my posting my own patches to the
list? I keep the same in the "pu" (proposed updates) branch, so
if the list readers think I am just adding noise to the list
traffic, I would stop doing so, and instead just invite
interested people to browse the "pu" branch.
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-30 2:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729224148.GB22530@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Note that I really _loved_ the Daniel's tools while they lasted. What I
> loved most about them was that they really only pulled objects I needed
> and not a single worthless one. Does the current HTTP transport share
> this property?
I am a big fan of Barkalow puller, too. It is conceptually
simple, very easy to explain, and quite nicely done to be
transport independent. Performance sucks, but that is not Dan's
fault.
If we are talking about a dumb HTTP server that has packed and
then prune-packed its repository, "not a single worthless one"
is asking for moon. If Jeff packed all his 50 branches into a
single pack and prune packed his repository, the only thing a
dumb server could do when you ask for one of his branches is to
give you that statically prepared single pack which contains
everything, because there would be nothing in .git/objects/??/.
You need some CGI support that pulls only needed objects out of
that pack and talks a moral equivalent of the upload-pack
protocol for that.
Barkalow puller is still useful when all the objects you still
need to pull from the remote are unpacked on the remote end.
That's how I resurrected "git clone" over http with packed dumb
servers. For "clone" case, I just slurp all the available
packs, and have Barkalow puller take over the rest.
I have an early WIP for "git fetch", but I have backburnered it
for quite some time. I'll push it in its current form into my
proposed updates branch, so interested people can hack on it.
> Note that I also want to setup a simple "proof-of-concept" GIT homepage
> tomorrow. Well, write it, where it should be hosted can be worked out
> later and I have places for it to reside at for now. (Suggestions for
> final hosting welcome. In reality, how nice (and persistent) the URL
> gets is probably the only thing that really matters. My attempt will
> live at http://git.or.cz/.)
I hope nobody starts another SCM project called CZ ;-).
^ 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