+++ /dev/null
-From: Junio C Hamano <junkio@cox.net>
-Subject: Re: Make "git clone" less of a deathly quiet experience
-Date: Sun, 12 Feb 2006 19:36:41 -0800
-Message-ID: <7v4q3453qu.fsf@assigned-by-dhcp.cox.net>
-References: <Pine.LNX.4.64.0602102018250.3691@g5.osdl.org>
- <7vwtg2o37c.fsf@assigned-by-dhcp.cox.net>
- <Pine.LNX.4.64.0602110943170.3691@g5.osdl.org>
- <1139685031.4183.31.camel@evo.keithp.com> <43EEAEF3.7040202@op5.se>
- <1139717510.4183.34.camel@evo.keithp.com>
- <46a038f90602121806jfcaac41tb98b8b4cd4c07c23@mail.gmail.com>
-Content-Type: text/plain; charset=us-ascii
-Cc: Keith Packard <keithp@keithp.com>, Andreas Ericsson <ae@op5.se>,
- Linus Torvalds <torvalds@osdl.org>,
- Git Mailing List <git@vger.kernel.org>,
- Petr Baudis <pasky@suse.cz>
-Return-path: <git-owner@vger.kernel.org>
-In-Reply-To: <46a038f90602121806jfcaac41tb98b8b4cd4c07c23@mail.gmail.com>
- (Martin Langhoff's message of "Mon, 13 Feb 2006 15:06:42 +1300")
-
-Martin Langhoff <martin.langhoff@gmail.com> writes:
-
-> +1... there should be an easy-to-compute threshold trigger to say --
-> hey, let's quit being smart and send this client the packs we got and
-> get it over with. Or perhaps a client flag so large projects can
-> recommend that uses do their initial clone with --gimme-all-packs?
-
-What upload-pack does boils down to:
-
- * find out the latest of what client has and what client asked.
-
- * run "rev-list --objects ^client ours" to make a list of
- objects client needs. The actual command line has multiple
- "clients" to exclude what is unneeded to be sent, and
- multiple "ours" to include refs asked. When you are doing
- a full clone, ^client is empty and ours is essentially
- --all.
-
- * feed that output to "pack-objects --stdout" and send out
- the result.
-
-If you run this command:
-
- $ git-rev-list --objects --all |
- git-pack-objects --stdout >/dev/null
-
-It would say some things. The phases of operations are:
-
- Generating pack...
- Counting objects XXXX...
- Done counting XXXX objects.
- Packing XXXXX objects.....
-
-Phase (1). Between the time it says "Generating pack..." upto
-"Done counting XXXX objects.", the time is spent by rev-list to
-list up all the objects to be sent out.
-
-Phase (2). After that, it tries to make decision what object to
-delta against what other object, while twenty or so dots are
-printed after "Packing XXXXX objects." (see #git irc log a
-couple of days ago; Linus describes how pack building works).
-
-Phase (3). After the dot stops, the program becomes silent.
-That is where it actually does delta compression and writeout.
-
-You would notice that quite a lot of time is spent in all
-phases.
-
-There is an internal hook to create full repository pack inside
-upload-pack (which is what runs on the other end when you run
-fetch-pack or clone-pack), but it works slightly differently
-from what you are suggesting, in that it still tries to do the
-"correct" thing. It still runs "rev-list --objects --all", so
-"dangling objects" are never sent out.
-
-We could cheat in all phases to speed things up, at the expense
-of ending up sending excess objects. So let's pretend we
-decided to treat everything in .git/objects/packs/pack-* (and
-the ones found in alternates as well) have interesting objects
-for the cloner.
-
-(1) This part unfortunately cannot be totally eliminated. By
- assume all packs are interesting, we could use the object
- names from the pack index, which is a lot cheaper than
- rev-list object traversal. We still need to run rev-list
- --objects --all --unpacked to pick up loose objects we would
- not be able to tell by looking at the pack index to cover
- the rest.
-
- This however needs to be done in conjunction with the second
- phase change. pack-objects depends on the hint rev-list
- --objects output gives it to group the blobs and trees with
- the same pathnames together, and that greatly affects the
- packing efficiency. Unfortunately pack index does not have
- that information -- it does not know type, nor pathnames.
- Type is relatively cheap to obtain but pathnames for blob
- objects are inherently unavailable.
-
-(2) This part can be mostly eliminated for already packed
- objects, because we have already decided to cheat by sending
- everything, so we can just reuse how objects are deltified
- in existing packs. It still needs to be done for loose
- objects we collected to fill the gap in (1).
-
-(3) This also can be sped up by reusing what are already in
- packs. Pack index records starting (but not end) offset of
- each object in the pack, so we can sort by offset to find
- out which part of the existing pack corresponds to what
- object, to reorder the objects in the final pack. This
- needs to be done somewhat carefully to preserve the locality
- of objects (again, see #git log). The deltifying and
- compressing for loose objects cannot be avoided.
-
- While we are writing things out in (3), we need to keep
- track of running SHA1 sum of what we write out so that we
- can fill out the correct checksum at the end, but I am
- guessing that is relatively cheap compared to the
- deltification and compression cost we are currently paying
- in this phase.
-
-NB. In the #git log, Linus made it sound like I am clueless
-about how pack is generated, but if you check commit 9d5ab96,
-the "recency of delta is inherited from base", one of the tricks
-that have a big performance impact, was done by me ;-).
-
-
+++ /dev/null
-#!/bin/sh
-#
-# Rebuild "pu" from topic branches.
-#
-
-git update-index --refresh || exit
-case "$(git diff-index --name-status HEAD)" in
-'') ;;
-*) echo 2>&1 "Local modifications exist."
- exit 1;;
-esac
-
-case "$1" in
---continue)
- shift
- ;;
-*)
- git checkout pu &&
- git reset --hard master || exit
-esac
-ORIG_HEAD=`git rev-parse ORIG_HEAD` || exit
-LF='
-'
-
-case "$#" in
-0)
- # interactive ;-)
- shift
- HH=`cd .git/refs/heads && find -type f |
- sed -e 's/^\.\///' \
- -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`
- while test "$HH"
- do
- I=0
- echo "0: done"
- NHH=
- for H in $HH
- do
- HSHA1=`git rev-parse --verify $H` || continue
- MB=`git show-branch --merge-base pu $HSHA1`
- case "$LF$MB$LF" in
- *"$LF$HSHA1$LF"*) continue ;; # already merged.
- esac
- I=$(($I+1))
- echo -n "$I: "
- git show-branch $H
- NHH="${NHH}$H "
- done
- case "$I" in
- 0)
- break ;;
- esac
- HH=$NHH
- echo -n "Merge which ones (0 to finish)? "
- read ans
- case "$ans" in
- '' | 0)
- break ;;
- esac
- I=0
- UNUSE= USE= USED=
- for H in $HH
- do
- I=$(($I+1))
- case " $ans " in
- *' '$I' '*)
- USE="$USE$H "
- USED="$USED,$H"
- ;;
- *)
- UNUSE="$UNUSE$H "
- ;;
- esac
- done
- USED=`expr "$USED" : ',\(.*\)'`
- git pull -n . $USE || exit
- # git merge -n "Merge $USED" pu $USE || exit
- HH=$UNUSE
- done
- exit
- ;;
-esac
-
-for H
-do
-# (IFS=",$IFS"; git merge -n "Merge $H" pu $H) || exit
- (IFS=",$IFS"; git pull -n . $H) || exit
-done
-
-(IFS=",$IFS"; git show-branch master $* pu `git rev-parse --short $ORIG_HEAD`)
+++ /dev/null
-Message-ID: <20050927001542.GC15615@reactrix.com>
-From: Nick Hengeveld <nickh@reactrix.com>
-Date: Mon, 26 Sep 2005 17:15:42 -0700
-
-Good point - use of environment variables is more consistent. Use of
-command-line arguments is a bit more convenient in my case since I'm
-driving the transfer from a perl script, but I suppose consistency is
-more important...
-
-Message-ID: <000a01c5c2fe$71fd6200$0200a8c0@AMEER>
-From: "Ameer Armaly" <ameerarmaly@bellsouth.net>
-Date: Mon, 26 Sep 2005 20:57:33 -0400
-
-I am seriously looking at putting one together in the D language
-(http://www.digitalmars.com/d) <plug>, though it doesn't actually do
-anything as of yet, since I have to balance classes along with it.
-
-
-Message-ID: <1127840572.16026.29.camel@mariano>
-From: Mariano Videla <mvidela@ases.com.ar>
-Date: Tue, 27 Sep 2005 14:02:51 -0300
-
-I setup a git repository for gipy... Didn't upload any files in
-sourceforge because I don't think is ready.
-
-http://24.232.198.9:7978/gipy.git
-http://24.232.198.9:7978/cgi/gitweb.cgi
-
-
-Message-ID: <20050928113008.GA11309@snarc.org>
-From: tab@snarc.org (Vincent Hanquez)
-Date: Wed, 28 Sep 2005 13:30:08 +0200
-
-Well, I kinda work on one written in C using a libgit (using exec of git
-executable for the moment) It doesn't do that much at the moment:
-commiting, adding files, removing files.
-
-At some point I'ld like to have a very integrated and easy to use
-porcelain, but for now that's more a learning git by practice kind of
-project.
-
-Message-ID: <pan.2005.09.28.20.22.10.626793@smurf.noris.de>
-From: Matthias Urlichs <smurf@smurf.noris.de>
-Date: Wed, 28 Sep 2005 22:22:13 +0200
-
-Python integration needs either lots of fork+exec, a git rewrite in
-Python, or a libgit reorganization in library-ized C.
-
-I'm doing the latter, but my free time is kindof limited for now.
-
-My library-ize branch is at
- git fetch http://netz.smurf.noris.de/git/git.git libize
-if anybody wants to have a look. My first goal is to get object access
-working sanely (because that's what I need for my Python project).
-
-I haven't merged up for some time, though.
-
-From: Darrin Thompson <darrint@progeny.com>
-Date: Wed, 04 Jan 2006 13:51:32 -0500
-Message-Id: <1136400692.5919.11.camel@localhost.localdomain>
-
-I'd like to make this friendly behavior [ls-files -o not showing
-contents of untracked directory] the default in my porcelain.
-
-
-Message-ID: <cc723f590601261946h101d7000oa1990c31c5b642fc@mail.gmail.com>
-From: Aneesh Kumar <aneesh.kumar@gmail.com>
-Date: Fri, 27 Jan 2006 09:16:58 +0530
-
-I am right now making a gnome based git repository browser [1].
-
-[1] http://www.flickr.com/photos/17388011@N00/91636482/
-This is based on bzrk GUI frontend to bazaar and written in python
+++ /dev/null
-From: Junio C Hamano <junkio@cox.net>
-Subject: Resetting paths
-Date: Thu, 09 Feb 2006 20:40:15 -0800
-Message-ID: <7vlkwjzv0w.fsf@assigned-by-dhcp.cox.net>
-Content-Type: text/plain; charset=us-ascii
-Return-path: <git-owner@vger.kernel.org>
-
-While working on "assume unchanged" git series, I found one
-thing missing from the current set of tools.
-
-While I worked on parts of the system that deals with the cached
-lstat() information, I needed a way to debug that, so I hacked
-ls-files -t option to show entries marked as "always matches the
-index" with lowercase tag letters. This was primarily debugging
-aid hack.
-
-Then I committed the whole thing with "git commit -a" by
-mistake. In order to rewind the HEAD to pre-commit state, I can
-say "git reset --soft HEAD^", but after doing that, now I want
-to unupdate the index so that ls-files.c matches the pre-commit
-HEAD.
-
-"git reset --mixed" is a heavy-handed tool for that. It reads
-the entier index from the HEAD commit without touching the
-working tree, so I would need to add the modified paths back
-with "git update-index".
-
-The low-level voodoo to do so for this particular case is this
-single liner:
-
- git ls-tree HEAD ls-files.c | git update-index --index-info
-
-Have people found themselves in similar need like this? This
-could take different forms.
-
- * you did "git update-index" on a wrong path. This is my
- example and the above voodoo is a recipe for recovery.
-
- * you did "git add" on a wrong path and you want to remove it.
- This is easier than the above:
-
- git update-index --force-remove path
-
- * you did the above recovery from "git add" on a wrong path,
- and you want to add it again. The same voodoo would work in
- this case as well.
-
- git ls-tree HEAD path | git update-index --index-info
-
-We could add "git reset path..." to reduce typing for the above,
-but I am wondering if it is worth it.
-
-BTW, this shows how "index centric" git is. With other SCM that
-has only the last commit and the working tree files, you do not
-have to worry any of these things, so it might appear that index
-is just a nuisance. But if you do not have any "registry of
-paths to be committed", you cannot do a partial commit like what
-I did above ("commit changes to all files other than
-ls-files.c") without listing all the paths to be committed, or
-fall back on CVS style "one path at a time", breaking an atomic
-commit, so there is a drawback for not having an index as well.
-
-
-
+++ /dev/null
-#!/bin/sh
-# Take a snapshot of master and next *after* making an
-# "What's in git.git" announcement, for the next round.
-
-git update-ref refs/hold/sa/master refs/heads/master
-git update-ref refs/hold/sa/maint refs/heads/maint
-
-
+++ /dev/null
-#
-
-our $G = '/opt/packrat/playpen/public/in-place/git';
-$GIT = '/home/junio/bin/Linux/git';
-$projectroot = $G;
-$site_name = 'Gitster Local';
-$stylesheet = '/gitweb.css';
-$logo = '/git-logo.png';
-$favicon = '/git-favicon.png';
-$projects_list = "$G/index/index.aux";
-
-while (my ($k, $v) = each %feature) {
- $feature{$k}{'override'} = 1;
-}
-$feature{'pathinfo'}{'override'} = 0;
-$feature{'pathinfo'}{'default'} = [1];
-1;
+++ /dev/null
-git.junio%2f.git Junio+C+Hamano
-linux-2.6%2F.git Linus+Torvalds
projects / thirdparty / git.git / commitdiff
