From e8c94b5627f6c11d67b36a912a2677026aadf218 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 20 Dec 2016 15:09:53 -0800 Subject: [PATCH] Remove a handful of ancient cruft files --- ClonePlus.txt | 125 --------------------------------------------- PU | 90 -------------------------------- Porcelainistas | 73 -------------------------- ResettingPaths.txt | 64 ----------------------- SA | 8 --- gitweb_config.perl | 17 ------ index.aux | 2 - 7 files changed, 379 deletions(-) delete mode 100644 ClonePlus.txt delete mode 100755 PU delete mode 100644 Porcelainistas delete mode 100644 ResettingPaths.txt delete mode 100755 SA delete mode 100644 gitweb_config.perl delete mode 100644 index.aux diff --git a/ClonePlus.txt b/ClonePlus.txt deleted file mode 100644 index 7417623aae..0000000000 --- a/ClonePlus.txt +++ /dev/null @@ -1,125 +0,0 @@ -From: Junio C Hamano -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: - <7vwtg2o37c.fsf@assigned-by-dhcp.cox.net> - - <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 , Andreas Ericsson , - Linus Torvalds , - Git Mailing List , - Petr Baudis -Return-path: -In-Reply-To: <46a038f90602121806jfcaac41tb98b8b4cd4c07c23@mail.gmail.com> - (Martin Langhoff's message of "Mon, 13 Feb 2006 15:06:42 +1300") - -Martin Langhoff 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 ;-). - - diff --git a/PU b/PU deleted file mode 100755 index 2a7f00b0a6..0000000000 --- a/PU +++ /dev/null @@ -1,90 +0,0 @@ -#!/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`) diff --git a/Porcelainistas b/Porcelainistas deleted file mode 100644 index e30e0495ab..0000000000 --- a/Porcelainistas +++ /dev/null @@ -1,73 +0,0 @@ -Message-ID: <20050927001542.GC15615@reactrix.com> -From: Nick Hengeveld -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" -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) , 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 -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: -From: Matthias Urlichs -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 -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: -From: Aneesh Kumar -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 diff --git a/ResettingPaths.txt b/ResettingPaths.txt deleted file mode 100644 index d101814e00..0000000000 --- a/ResettingPaths.txt +++ /dev/null @@ -1,64 +0,0 @@ -From: Junio C Hamano -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: - -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. - - - diff --git a/SA b/SA deleted file mode 100755 index a54f03b4a6..0000000000 --- a/SA +++ /dev/null @@ -1,8 +0,0 @@ -#!/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 - - diff --git a/gitweb_config.perl b/gitweb_config.perl deleted file mode 100644 index 7d847cb5e4..0000000000 --- a/gitweb_config.perl +++ /dev/null @@ -1,17 +0,0 @@ -# - -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; diff --git a/index.aux b/index.aux deleted file mode 100644 index dd462664bb..0000000000 --- a/index.aux +++ /dev/null @@ -1,2 +0,0 @@ -git.junio%2f.git Junio+C+Hamano -linux-2.6%2F.git Linus+Torvalds -- 2.47.3