* [PATCH] Documentation: adjust cvsimport command line.
From: Junio C Hamano @ 2005-07-16 3:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7voe93rbmu.fsf_-_@assigned-by-dhcp.cox.net>
The cvsimport example in the cvs migration document was still
using the old syntax for target repository after new and
improved cvsimport-script was merged.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/cvs-migration.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
b29d86237da6af317cd0053aa9c8ebd72455c113
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -63,7 +63,7 @@ Once you've gotten (and installed) cvsps
any more familiar with it, but make sure it is in your path. After that,
the magic command line is
- git cvsimport -v -d <cvsroot> <module> <destination>
+ git cvsimport -v -d <cvsroot> -C <destination> <module>
which will do exactly what you'd think it does: it will create a git
archive of the named CVS module. The new archive will be created in the
^ permalink raw reply
* [PATCH] Documentation: update recommended workflow when working with others.
From: Junio C Hamano @ 2005-07-16 3:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Clarify that the hierarchy implied by the recommended workflow
is only informal.
Refer readers to nice illustration by Rundy Dunlap.
Separate out the step to "push" to own public repository in the
workflow.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/tutorial.txt | 65 ++++++++++++++++++++++++++++++--------------
1 files changed, 44 insertions(+), 21 deletions(-)
70a7f8c18de2006a500059f3cb23d353250d0a9d
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -967,7 +967,19 @@ unpacked in the destination, unless rsyn
Working with Others
-------------------
-A recommended work cycle for a "project lead" is like this:
+Although git is a truly distributed system, it is often
+convenient to organize your project with an informal hierarchy
+of developers. Linux kernel development is run this way. There
+is a nice illustration (page 17, "Merges to Mainline") in Rundy
+Dunlap's presentation (http://tinyurl.com/a2jdg).
+
+It should be stressed that this hierarchy is purely "informal".
+There is nothing fundamental in git that enforces the "chain of
+patch flow" this hierarchy implies. You do not have to pull
+from only one remote repository.
+
+
+A recommended workflow for a "project lead" goes like this:
(1) Prepare your primary repository on your local machine. Your
work is done there.
@@ -978,23 +990,28 @@ A recommended work cycle for a "project
repository.
(4) "git repack" the public repository. This establishes a big
- pack that contains the initial set of objects.
-
- (5) Keep working in your primary repository, and push your
- changes to the public repository. Your changes include
- your own, patches you receive via e-mail, and merge resulting
- from pulling the "public" repositories of your "subsystem
- maintainers".
+ pack that contains the initial set of objects as the
+ baseline, and possibly "git prune-packed" if the transport
+ used for pulling from your repository supports packed
+ repositories.
+
+ (5) Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "subsystem maintainers".
You can repack this private repository whenever you feel
like.
- (6) Every once in a while, "git repack" the public repository.
+ (6) Push your changes to the public repository, and announce it
+ to the public.
+
+ (7) Every once in a while, "git repack" the public repository.
Go back to step (5) and continue working.
-A recommended work cycle for a "subsystem maintainer" that
-works on that project and has own "public repository" is like
-this:
+
+A recommended work cycle for a "subsystem maintainer" that works
+on that project and has own "public repository" goes like this:
(1) Prepare your work repository, by "git clone" the public
repository of the "project lead".
@@ -1006,21 +1023,27 @@ this:
currently not automated.
(4) Push into the public repository from your primary
- repository.
-
- (5) Keep working in your primary repository, and push your
- changes to your public repository, and ask your "project
- lead" to pull from it. Your changes include your own,
- patches you receive via e-mail, and merge resulting from
- pulling the "public" repositories of your "project lead"
- and possibly your "sub-subsystem maintainers".
+ repository. Run "git repack" (and possibly "git
+ prune-packed" if the transport used for pulling from your
+ repository supports packed repositories.
+
+ (5) Keep working in your primary repository. Your changes
+ include modifications of your own, patches you receive via
+ e-mails, and merges resulting from pulling the "public"
+ repositories of your "project lead" and possibly your
+ "sub-subsystem maintainers".
You can repack this private repository whenever you feel
like.
- (6) Every once in a while, "git repack" the public repository.
+ (6) Push your changes to your public repository, and ask your
+ "project lead" and possibly your "sub-subsystem
+ maintainers" to pull from it.
+
+ (7) Every once in a while, "git repack" the public repository.
Go back to step (5) and continue working.
+
A recommended work cycle for an "individual developer" who does
not have a "public" repository is somewhat different. It goes
like this:
^ permalink raw reply
* Re: [PATCH] Documentation: update recommended workflow when working with others.
From: randy_dunlap @ 2005-07-16 4:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vslyfo143.fsf@assigned-by-dhcp.cox.net>
On Fri, 15 Jul 2005 20:56:12 -0700 Junio C Hamano wrote:
> Clarify that the hierarchy implied by the recommended workflow
> is only informal.
>
> Refer readers to nice illustration by Rundy Dunlap.
Randy (please)
>
> Separate out the step to "push" to own public repository in the
> workflow.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> Documentation/tutorial.txt | 65 ++++++++++++++++++++++++++++++--------------
> 1 files changed, 44 insertions(+), 21 deletions(-)
>
> 70a7f8c18de2006a500059f3cb23d353250d0a9d
> diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
> --- a/Documentation/tutorial.txt
> +++ b/Documentation/tutorial.txt
> @@ -967,7 +967,19 @@ unpacked in the destination, unless rsyn
> Working with Others
> -------------------
>
> -A recommended work cycle for a "project lead" is like this:
> +Although git is a truly distributed system, it is often
> +convenient to organize your project with an informal hierarchy
> +of developers. Linux kernel development is run this way. There
> +is a nice illustration (page 17, "Merges to Mainline") in Rundy
> +Dunlap's presentation (http://tinyurl.com/a2jdg).
and again. :)
Thanks,
---
~Randy
^ permalink raw reply
* [PATCH] fetch/pull: short-hand notation for remote repositories.
From: Junio C Hamano @ 2005-07-16 7:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507151529590.19183@g5.osdl.org>
Since pull and fetch are done often against the same remote
repository repeatedly, keeping the URL to pull from along with
the name of the head to use in $GIT_DIR/branches/$name makes a
lot of sense. Adopt that convention from Cogito, and try to be
compatible when possible; storing a partial URL and completing
it with a trailing path may not be understood by Cogito.
While we are at it, fix pulling a tag. Earlier, we updated only
refs/tags/$tag without updating FETCH_HEAD, and called
resolve-script using a stale (or absent) FETCH_HEAD.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +
git-fetch-script | 36 ++++++++++++++-----------
git-parse-remote | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
git-pull-script | 19 ++-----------
4 files changed, 104 insertions(+), 32 deletions(-)
create mode 100755 git-parse-remote
431b72ee18b73aac44048ac6c4cb62e0618c6f6e
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script
+ git-branch-script git-parse-remote
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-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,33 +1,39 @@
#!/bin/sh
#
-destination=FETCH_HEAD
-
-merge_repo=$1
-merge_name=${2:-HEAD}
-if [ "$2" = "tag" ]; then
- merge_name="refs/tags/$3"
- destination="$merge_name"
-fi
-
. git-sh-setup-script || die "Not a git archive"
+. git-parse-remote "$@"
+merge_repo="$_remote_repo"
+merge_head="$_remote_head"
+merge_store="$_remote_store"
TMP_HEAD="$GIT_DIR/TMP_HEAD"
case "$merge_repo" in
http://*)
- head=$(wget -q -O - "$merge_repo/$merge_name") || exit 1
- echo Fetching $head using http
- git-http-pull -v -a "$head" "$merge_repo/"
+ head=$(wget -q -O - "$merge_repo/$merge_head") || exit 1
+ echo Fetching "$merge_head" using http
+ git-http-pull -v -a "$merge_head" "$merge_repo/"
;;
rsync://*)
- rsync -L "$merge_repo/$merge_name" "$TMP_HEAD" || exit 1
+ rsync -L "$merge_repo/$merge_head" "$TMP_HEAD" || exit 1
head=$(git-rev-parse TMP_HEAD)
rm -f "$TMP_HEAD"
rsync -avz --ignore-existing "$merge_repo/objects/" "$GIT_OBJECT_DIRECTORY/"
;;
*)
- head=$(git-fetch-pack "$merge_repo" "$merge_name")
+ head=$(git-fetch-pack "$merge_repo" "$merge_head")
;;
esac || exit 1
+
git-rev-parse --verify "$head" > /dev/null || exit 1
-echo "$head" > "$GIT_DIR/$destination"
+
+case "$merge_store" in
+'')
+ echo "$head" > "$GIT_DIR/$merge_store"
+esac &&
+
+# FETCH_HEAD is fed to git-resolve-script which will eventually be
+# passed to git-commit-tree as one of the parents. Make sure we do
+# not give a tag object ID.
+
+git-rev-parse "$head^0" >"$GIT_DIR/FETCH_HEAD"
diff --git a/git-parse-remote b/git-parse-remote
new file mode 100755
--- /dev/null
+++ b/git-parse-remote
@@ -0,0 +1,79 @@
+: To be included in git-pull and git-fetch scripts.
+
+# A remote repository can be specified on the command line
+# in one of the following formats:
+#
+# <repo>
+# <repo> <head>
+# <repo> tag <tag>
+#
+# where <repo> could be one of:
+#
+# a URL (including absolute or local pathname)
+# a short-hand
+# a short-hand followed by a trailing path
+#
+# A short-hand <name> has a corresponding file $GIT_DIR/branches/<name>,
+# whose contents is a URL, possibly followed by a URL fragment #<head>
+# to name the default branch on the remote side to fetch from.
+
+_remote_repo= _remote_store= _remote_head= _remote_name=
+
+case "$1" in
+*:* | /* | ../* | ./* )
+ _remote_repo="$1"
+ ;;
+* )
+ # otherwise, it is a short hand.
+ case "$1" in
+ */*)
+ # a short-hand followed by a trailing path
+ _token=$(expr "$1" : '\([^/]*\)/')
+ _rest=$(expr "$1" : '[^/]*\(/.*\)$')
+ ;;
+ *)
+ _token="$1"
+ _rest=
+ _remote_store="refs/heads/$_token"
+ ;;
+ esac
+ test -f "$GIT_DIR/branches/$_token" ||
+ die "No such remote branch: $_token"
+
+ _remote_repo=$(cat "$GIT_DIR/branches/$_token")"$_rest"
+ ;;
+esac
+
+case "$_remote_repo" in
+*"#"*)
+ _remote_head=`expr "$_remote_repo" : '.*#\(.*\)$'`
+ _remote_repo=`expr "$_remote_repo" : '\(.*\)#'`
+ ;;
+esac
+
+_remote_name=$(echo "$_remote_repo" | sed 's|\.git/*$||')
+
+case "$2" in
+tag)
+ _remote_name="tag '$3' of $_remote_name"
+ _remote_head="refs/tags/$3"
+ _remote_store="$_remote_head"
+ ;;
+?*)
+ # command line specified a head explicitly; do not
+ # store the fetched head as a branch head.
+ _remote_name="head '$2' of $_remote_name"
+ _remote_head="refs/heads/$2"
+ _remote_store=''
+ ;;
+'')
+ case "$_remote_head" in
+ '')
+ _remote_head=HEAD ;;
+ *)
+ _remote_head="refs/heads/$_remote_head"
+ _remote_name="head '$_remote_head' of $_remote_name"
+ ;;
+ esac
+ ;;
+esac
diff --git a/git-pull-script b/git-pull-script
--- a/git-pull-script
+++ b/git-pull-script
@@ -1,23 +1,10 @@
#!/bin/sh
#
. git-sh-setup-script || die "Not a git archive"
+. git-parse-remote "$@"
+merge_name="$_remote_name"
-merge_repo=$1
-
-merge_name=$(echo "$1" | sed 's:\.git/*$::')
-merge_head=HEAD
-type=head
-if [ "$2" = "tag" ]; then
- type=tag
- shift
-fi
-if [ "$2" ]
-then
- merge_name="$type '$2' of $merge_name"
- merge_head="refs/${type}s/$2"
-fi
-
-git-fetch-script "$merge_repo" "$merge_head" || exit 1
+git-fetch-script "$@" || exit 1
git-resolve-script \
"$(cat "$GIT_DIR"/HEAD)" \
^ permalink raw reply
* [PATCH] Documentation: describe short-hand used in fetch/pull.
From: Junio C Hamano @ 2005-07-16 7:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507151529590.19183@g5.osdl.org>
Describe short-hand for remote repository used in fetch/pull.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-fetch-script.txt | 47 ++++++++++++++++++++++++++++++++++++
Documentation/git-pull-script.txt | 16 ++++++++----
Documentation/git.txt | 9 ++++++-
Documentation/pull-fetch-param.txt | 36 ++++++++++++++++++++++++++++
Documentation/tutorial.txt | 28 +++++++++++++++++++++
5 files changed, 130 insertions(+), 6 deletions(-)
create mode 100644 Documentation/git-fetch-script.txt
create mode 100644 Documentation/pull-fetch-param.txt
d4d1afc8c8e8417b8a30ecfc8f5e32be2b47c956
diff --git a/Documentation/git-fetch-script.txt b/Documentation/git-fetch-script.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-fetch-script.txt
@@ -0,0 +1,47 @@
+git-fetch-script(1)
+===================
+v0.1, July 2005
+
+NAME
+----
+git-fetch-script - Download objects and a head from another repository.
+
+
+SYNOPSIS
+--------
+'git-fetch-script' <repository> [ <head> | tag <tag> ]
+
+
+DESCRIPTION
+-----------
+Fetches a named head or a tag from another repository, along
+with the objects necessary to complete that head or tag. The
+head to pull defaults to HEAD if unspecified. The head or tag
+fetched from the remote repository is stored in
+$GIT_DIR/FETCH_HEAD.
+
+When a <tag> is specified, the <tag> fetched from the remote is
+also copied to the local $GIT_DIR/tags/<tag> file. When no
+<head> nor <tag> is specified, and <repository> was specified
+with the short-hand notation (i.e. naming a file under the
+$GIT_DIR/branches directory), the head fetched from the remote
+repository is also copied to the local $GIT_DIR/heads/<repository>
+file.
+
+
+OPTIONS
+-------
+include::pull-fetch-param.txt[]
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
diff --git a/Documentation/git-pull-script.txt b/Documentation/git-pull-script.txt
--- a/Documentation/git-pull-script.txt
+++ b/Documentation/git-pull-script.txt
@@ -4,22 +4,28 @@ v0.1, May 2005
NAME
----
-git-pull-script - Script used by Linus to pull and merge a remote repository
+git-pull-script - Pull and merge from another repository.
SYNOPSIS
--------
-'git-pull-script'
+'git-pull-script' <repository> [ <head> | tag <tag> ]
+
DESCRIPTION
-----------
-This script is used by Linus to pull from a remote repository and perform
-a merge.
+Runs 'git-fetch-script' with the given parameters, then
+'git-resolve-script' to merge the local HEAD and FETCH_HEAD.
+
+
+OPTIONS
+-------
+include::pull-fetch-param.txt[]
Author
------
-Written by Linus Torvalds <torvalds@osdl.org>
+Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
Documentation
--------------
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -121,6 +121,9 @@ The interrogate commands may create file
touch the working file set - but in general they don't
+Synching repositories
+~~~~~~~~~~~~~~~~~~~~~
+
link:git-clone-script.html[git-clone-script]::
Clones a repository into the current repository (user interface)
@@ -128,10 +131,14 @@ link:git-clone-pack.html[git-clone-pack]
Clones a repository into the current repository (engine
for ssh and local transport)
-link:git-pull-script.html[git-pull-script]::
+link:git-fetch-script.html[git-pull-script]::
Pull from a repote repository via various protocols
(user interface).
+link:git-pull-script.html[git-pull-script]::
+ Fetch from and merge with a repote repository via
+ various protocols (user interface).
+
link:git-http-pull.html[git-http-pull]::
Downloads a remote GIT repository via HTTP
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/pull-fetch-param.txt
@@ -0,0 +1,36 @@
+<repository>::
+ The "remote" repository to pull from. One of the
+ following notations can be used to name the repository
+ to pull from:
+
+ Rsync URL
+ rsync://remote.machine/path/to/repo.git/
+
+ HTTP(s) URL
+ http://remote.machine/path/to/repo.git/
+
+ GIT URL
+ git://remote.machine/path/to/repo.git/
+ remote.machine:/path/to/repo.git/
+
+ Local directory
+ /path/to/repo.git/
+
+ In addition to that, as a short-hand, the name of a file
+ in $GIT_DIR/branches directory can be specified; the
+ named file should contain a single line, a URL in one of
+ the above formats, optionally followed by a hash '#' and
+ the name of remote head.
+
+<head>::
+ The remote head name to fetch from. That is, make the
+ objects reachable from the commit recorded in
+ $GIT_DIR/refs/heads/<head> in the remote repository
+ available locally.
+
+tag <tag>::
+ The remote head tag to fetch from. That is, make the
+ objects reachable from the commit recorded in
+ $GIT_DIR/refs/tags/<tag> in the remote repository
+ available locally.
+
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -810,6 +810,34 @@ pull from:
course, you will pay the price of more disk usage to hold
multiple working trees, but disk space is cheap these days. ]
+It is likely that you will be pulling from the same remote
+repository from time to time. As a short hand, you can store
+the remote repository URL in a file under .git/branches/
+directory, like this:
+
+ mkdir -p .git/branches
+ echo rsync://kernel.org/pub/scm/git/git.git/ \
+ >.git/branches/linus
+
+and use the filenae to "git pull" instead of the full URL.
+The contents of a file under .git/branches can even be a prefix
+of a full URL, like this:
+
+ echo rsync://kernel.org/pub/.../jgarzik/
+ >.git/branches/jgarzik
+
+Examples.
+
+ (1) git pull linus
+ (2) git pull linus tag v0.99.1
+ (3) git pull jgarzik/netdev-2.6.git/ e100
+
+the above are equivalent to:
+
+ (1) git pull rsync://kernel.org/pub/scm/git/git.git/ HEAD
+ (2) git pull rsync://kernel.org/pub/scm/git/git.git/ tag v0.99.1
+ (3) git pull rsync://kernel.org/pub/.../jgarzik/netdev-2.6.git e100
+
Publishing your work
--------------------
^ permalink raw reply
* [MERGE] Combine git-tools repository into example-tools/ subdirectory of git
From: Ryan Anderson @ 2005-07-16 7:55 UTC (permalink / raw)
To: git, Linus Torvalds
Linus, it seems, well, odd to me that you maintain two different git
trees.
So I used your example of the gittk merge to move git-tools into the
main git-repository.
Summary of changes:
1) Create an example-tools directory
2) Move all of the git-tools tree, except the outdated cvs2git script
into this directory.
3) Rename dotest to applymbox
4) Minor cleanup inside applymbox of comments to apply to the new name.
Given that I don't think anyone wants to look at the diff of this, with
all the git history involved, I have a git tree up at:
rsync://h4x0r5.com::git-ryan.git/
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH-fix] fetch/pull: short-hand notation for remote repositories.
From: Junio C Hamano @ 2005-07-16 16:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7virzbnruf.fsf_-_@assigned-by-dhcp.cox.net>
The logic to decide when to store fetched head/tag under
$GIT_DIR/refs/, and http transport were broken in the previous
round.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** I see you have already merged my broken one; sorry.
*** Anything written under the influence should be tested as twice
*** as hard than usual before being sent --- Don't drink and
*** develop ;-). *Blush*
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff 8:10
# - 4: Documentation: describe short-hand used in fetch/pull.
# + 6: git-fetch-script: fix thinko in http fetch.
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -12,7 +12,7 @@ case "$merge_repo" in
http://*)
head=$(wget -q -O - "$merge_repo/$merge_head") || exit 1
echo Fetching "$merge_head" using http
- git-http-pull -v -a "$merge_head" "$merge_repo/"
+ git-http-pull -v -a "$head" "$merge_repo/"
;;
rsync://*)
rsync -L "$merge_repo/$merge_head" "$TMP_HEAD" || exit 1
@@ -27,10 +27,10 @@ esac || exit 1
git-rev-parse --verify "$head" > /dev/null || exit 1
-case "$merge_store" in
-'')
+if test "$merge_store"
+then
echo "$head" > "$GIT_DIR/$merge_store"
-esac &&
+fi &&
# FETCH_HEAD is fed to git-resolve-script which will eventually be
# passed to git-commit-tree as one of the parents. Make sure we do
Compilation finished at Sat Jul 16 09:37:07
^ permalink raw reply
* Re: [MERGE] Combine git-tools repository into example-tools/ subdirectory of git
From: Linus Torvalds @ 2005-07-16 17:19 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050716075553.GI20369@mythryan2.michonline.com>
On Sat, 16 Jul 2005, Ryan Anderson wrote:
>
> Linus, it seems, well, odd to me that you maintain two different git
> trees.
Yes.
> So I used your example of the gittk merge to move git-tools into the
> main git-repository.
Fair enough. I was ready to pull your work, but it turns out that the old
git-tools repository had things like directory entries with file mode
100775, so git-fsck-cache complains about it. I've already suppressed
git-fsck-cache on mode 100664 (which exists in both the kernel and git
archives), so I could have just added the other case, but I preferred to
just make git-convert-cache convert it, and then pull in a _converted_
tools archive instead.
[ Side note: I'm actually happy by how git-convert-cache was still 100%
functional. I haven't touched it in a long time, and it's very intimate
with the objects, so the fact that it still worked means that we haven't
screwed anything up in the object format ;]
I did mostly the same things you did, except I also dropped "stripspace",
since I'd already copied it over to git (and it's now installed as
"git-stripspace") earlier. And I just called the subdirectory "tools".
Linus
^ permalink raw reply
* Re: [PATCH-fix] fetch/pull: short-hand notation for remote repositories.
From: Linus Torvalds @ 2005-07-16 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek9yn1f5.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 16 Jul 2005, Junio C Hamano wrote:
>
> *** I see you have already merged my broken one; sorry.
I already noticed the breakage, and fixed that a bit differently.
Feel free to send an updated patch if you prefer your version after my
commits have percolated out..
Linus
^ permalink raw reply
* Barebone Porcelain. Where to stop?
From: Junio C Hamano @ 2005-07-16 17:37 UTC (permalink / raw)
To: git
I have been somewhat disturbed and confused by the fact that the
line between what Porcelain like Cogito does and what we ship as
part of "core GIT" is getting more and more blurred. This was
especially so while I was working on the $GIT_DIR/branches/
patch.
This trend started when "git diff", "git commit" and friends
were added for the sake of usability of the bare Plumbing.
These basic commands are must and I do not have any objection to
have them in the "core GIT" suite, but at the same time I think
the core should not be competing with Porcelains, and feel that
a line should be drawn somewhere [*1*].
I'd like to hear opinions from the list. Personally I think
what we have so far is about right, relative to what the current
crop of Porcelains offer.
This is me speaking as just "an individual developer". Linus as
"the project lead", Pasky as the maintainer of the de-facto
standard Porcelain, and others on the list may have different
opinions. I do not think the core GIT should be making drastic
innovations that Porcelain folks have not asked. In my ideal
world, Porcelains would be the first to innovate in the UI and
use pattern area, and while doing so, would discover something
lacking from the core. The purpose of the core GIT development
should primarily be to fill these needs. Then, once "best
current practices" from Porcelains emerge, the infrastructure to
support them would become a part of core GIT; we might even
start shipping corresponding barebone Porcelain scripts to
codify that BCP using the same support infrastructure as part of
the "core GIT" suite [*2*].
Linus said that the current Plumbing already does all he wants
it to do. I started sharing the same opinion. I am finding
myself using my own Porcelain commands less frequently for doing
basic things, because the barebone Porcelain already fills much
of my needs.
[Footnotes]
*1* Yes, I publicly stated that one of my goals of my
involvement in GIT development was to make choice of Porcelain
more or less irrelevant, and that still stands, which means that
I am in favor of having rich enough barebone Porcelain shipped
with "core GIT". But the problem I am having is now is how rich
is rich enough.
*2* ... and that is how we make the Porcelain less relevant ;-).
^ permalink raw reply
* Last mile to 1.0?
From: Junio C Hamano @ 2005-07-16 17:46 UTC (permalink / raw)
To: git
I do not know what release plan Linus has in mind, and also
expect things to be quieter next week during OLS and kernel
summit, but I think we are getting really really close.
Here are the things I think we would want to see before we hit
1.0:
- Remaining feature enhancements and fixes.
- Anonymous pull from packed archives on remote sites via
non-rsync, non-ssh transport. Many people are behind
corporate firewalls that do not pass anything but outgoing
http(s) and some do not even pass outgoing ssh. The recent
addition of git-daemon by Linus would greatly alleviate the
situation, but we may also end up wanting something HTTP
reachable.
- Documentation.
- Many files under Documentation/ directory have become
stale. I've tried to do one pass of full sweep recently,
but I'd like somebody else to make another pass to make
sure that the usage strings in programs, what the programs
do, and what Documentation says they do match. Also, the
spelling and grammar fixes, which I am very bad at and have
not done any attempt, needs to be done.
Volunteers?
- Are all the files in Documentation/ reachable from git(7)
or otherwise made into a standalone document using asciidoc
by the Makefile? I haven't looked into documentation
generation myself (I use only the text files as they are);
help to update the Makefile by somebody handy with asciidoc
suite is greatly appreciated here.
Volunteers?
- We may want to describe more Best Current Practices, along
the lines of "Working with Others" section in the tutorial.
Please write on your faviorite topic and send patches in
;-))
- Publicity. I would be very happy to see somebody with good
writing and summarizing skills to prepare an article to be
published on LWN.NET to coincide with the 1.0 release. An
update to GIT traffic would also be nice.
^ permalink raw reply
* Re: [PATCH-fix] fetch/pull: short-hand notation for remote repositories.
From: Junio C Hamano @ 2005-07-16 17:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507161032410.19183@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I already noticed the breakage, and fixed that a bit differently.
>
> Feel free to send an updated patch if you prefer your version after my
> commits have percolated out..
As an old timer, I always prefer "case" over "test", so the
version in your tree is actually better to me. Thanks for the
fix.
^ permalink raw reply
* Re: Last mile to 1.0?
From: Eric W. Biederman @ 2005-07-16 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I do not know what release plan Linus has in mind, and also
> expect things to be quieter next week during OLS and kernel
> summit, but I think we are getting really really close.
>
> Here are the things I think we would want to see before we hit
> 1.0:
>
> - Remaining feature enhancements and fixes.
>
> - Anonymous pull from packed archives on remote sites via
> non-rsync, non-ssh transport. Many people are behind
> corporate firewalls that do not pass anything but outgoing
> http(s) and some do not even pass outgoing ssh. The recent
> addition of git-daemon by Linus would greatly alleviate the
> situation, but we may also end up wanting something HTTP
> reachable.
For this we need a cgi script that will generate an appropriate
pack. Although stupid http fetching may have some potential
if we ditch libcurl and use pipelining for http 1.1. Bandwidth
wise that will never equal a custom pack because it will not do
deltas. But in the common case of an incremental pull it should
be able to equal rsync.
Do we want to put some porcelain around, git-fsck-cache --tags?
So we can discover the tag objects in the archive and place
them someplace usable. Jeff Garzik in his howto is still recommending:
> git-pull-script only downloads sha1-indexed object data, and the requested remote head.
> This misses updates to the .git/refs/tags/ and .git/refs/heads/ directories. It is
> advisable to update your kernel .git directories periodically with a full rsync command, to
> make sure you got everything:
>$ cd linux-2.6
>$ rsync -a --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
> .git/
Which feels like something is missing. Given that tags are
sha1-indexed objects we should be pulling them. And I believe you can
have a tag as a parent of a commit, so even with the pack optimized
clients we should be pulling them now.
Eric
^ permalink raw reply
* [PATCH] Cleanup: git-verify-tag-script
From: Eric W. Biederman @ 2005-07-16 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
- Use git-verify-parse to allow sha1 tags references
- When the tag does not verify set an appropriate exit status
- Use git-sh-setup-script to verify the .git directory
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
git-verify-tag-script | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
f0b9fc0d7e2c8a23d73337ffa6907ee597aab53f
diff --git a/git-verify-tag-script b/git-verify-tag-script
--- a/git-verify-tag-script
+++ b/git-verify-tag-script
@@ -1,9 +1,8 @@
#!/bin/sh
-GIT_DIR=${GIT_DIR:-.git}
+. git-sh-setup-script || die "Not a git archive"
-tag=$1
-[ -f "$GIT_DIR/refs/tags/$tag" ] && tag=$(cat "$GIT_DIR/refs/tags/$tag")
+tag=$(git-rev-parse $1) || exit 1
git-cat-file tag $tag > .tmp-vtag || exit 1
-cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag -
+cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1
rm -f .tmp-vtag
^ permalink raw reply
* [PATCH] Install git-verify-tag-script
From: Eric W. Biederman @ 2005-07-16 20:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
b4ef59fcedf0855519fc23b58f9ec0c80e78221c
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script git-parse-remote
+ git-branch-script git-parse-remote git-verify-tag-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 \
^ permalink raw reply
* [PATCH] git-revover-tags-script
From: Eric W. Biederman @ 2005-07-16 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
First pass at a script to dig through .git/objects and find dangling
tags. It likely has a lot of weird limitations, I don't know if it
will work with packs, and the policy it implments is pretty stupid,
but it is a sane start and should keep people from needing to
rsync anything except the .git/objects part of the tree.
The current policy is if a tag's gpg signature can be verified
and if the tag name does not conflict with an existing tag
place it in .git/refs/tags/. So far this only works with
dangling tags so I don't know if these tags will even be pulled
with the pack methods. But since we aren't quite going at
full speed on those yet we should be good.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
Makefile | 3 ++-
git-recover-tags-script | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
create mode 100755 git-recover-tags-script
4b171e71fd6b5de56dd4a93ea203e49115c2caee
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,8 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script git-parse-remote git-verify-tag-script
+ git-branch-script git-parse-remote git-verify-tag-script \
+ git-recover-tags-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-recover-tags-script b/git-recover-tags-script
new file mode 100755
--- /dev/null
+++ b/git-recover-tags-script
@@ -0,0 +1,27 @@
+#!/bin/sh
+# Copyright (c) 2005 Eric Biederman
+
+. git-sh-setup-script || die "Not a git archive"
+
+TMP_TAG=".tmp-tag.$$"
+git-fsck-cache |
+while read status type sha1 rest ; do
+ if [ '(' "$status" == "dangling" ')' -a '(' "$type" == "tag" ')' ] ; then
+ if ! git-verify-tag-script $sha1 ; then
+ echo "Could not verify tag $sha1"
+ else
+ tag=$(git-cat-file tag $sha1 | sed -ne 's/^tag //p')
+ tagger=$(git-cat-file tag $sha1 | sed -ne 's/^tagger //p')
+ if [ ! -e $GIT_DIR/refs/tags/$tag ]; then
+ echo "installing tag $tag tagger $tagger"
+ mkdir -p $GIT_DIR/refs/tags
+ echo "$sha1" > $GIT_DIR/refs/tags/$tag
+ fi
+ fi
+ else
+ if [ "$status" != "dangling" ] ; then
+ echo "$status $type $sha1 $rest";
+ fi
+ fi
+done
+rm -f $TMP_TAG
^ permalink raw reply
* Darcs-Git: upgrading to Git 0.99
From: Juliusz Chroboczek @ 2005-07-16 20:45 UTC (permalink / raw)
To: darcs-devel; +Cc: git
[CC'd to the Git mailling list; please CC any replies to Darcs-Devel]
David, Ian,
I'd like to upgrade the Git code used in Darcs to 0.99 (we're
currently using 0.6). There are two good reasons for that, the first
of which is actually a showstopper:
- the format of Git repositories has changed incompatibly, with a new
kind of thing called the ``pack'' (a very neat performance hack, by
the way); hence, Darcs-Git is unable to read recent Git repos,
unless you use the Git tools to unpack them;
- 0.99 actually exports usable interfaces, which will allow us to use
pristine Git sources in Darcs.
Now I'm wondering how to do that. Currently, I'm using a nasty hack
using the C preprocessor to include just the sources we need in
Darcs. As 0.99 builds a ``libgit.a'', I'd like to use that instead.
There are three ways to do that:
(1) require that the users put a suitable libgit.a in /usr/local/lib
before building Darcs, and distribute a tarball of Git from
darcs.net;
(2) include just the sources needed for libgit.a in Darcs, and have
the Darcs build build a local libgit
(3) as (2), but include all of Git, including their
``user-friendly'' scripts.
Solution (2) will include 33 files totalling 167KB, while (3) is about
a megabyte of source.
My personal favourite is solution (2), as it is simple for both the
users and us. I'm not very keen on (1), as it will cause problems
when the friendly Git folks change their interfaces, but have no
strong dislike towards it if it's what you think is right. (3) is
definitely overkill.
Juliusz
^ permalink raw reply
* [PATCH] git: remove usage of xargs -r, a non-portable gnu extension
From: Bryan Larsen @ 2005-07-16 23:18 UTC (permalink / raw)
To: bryan.larsen; +Cc: junkio, torvalds, Bryan Larsen, git
Remove usage of xargs -r, a non-portable gnu extension.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
git-prune-script | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-prune-script b/git-prune-script
--- a/git-prune-script
+++ b/git-prune-script
@@ -20,6 +20,6 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs -r $dryrun rm -f
+ xargs $dryrun rm -f ""
}
^ permalink raw reply
* [PATCH 2/5] cogito: remove use of cp -a, a non-portable GNU extension
From: Bryan Larsen @ 2005-07-16 23:23 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050716232308.7317.56890.sendpatchset@bryan-larsens-ibook-g4.local>
Remove usage of cp -a, a non-portable gnu extension.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-pull | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -217,7 +217,7 @@ fetch_local () {
[ "$1" = "-i" ] && shift
[ "$1" = "-s" ] && shift
- cp_flags_l="-va"
+ cp_flags_l="-vdpR"
if [ "$1" = "-u" ]; then
cp_flags_l="$cp_flags_l -u$can_hardlink"
suggest_hardlink=
^ permalink raw reply
* [PATCH 0/5] cogito: compatibility with OS X
From: Bryan Larsen @ 2005-07-16 23:23 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
Since Linus and Junio were unhappy with my previous set of patches to
make git and cogito compatible with OS X and other BSD unices, I have
redone my patches to cogito along a similar line.
There is still one outstanding incompatibility: cogito makes use of
cp -u. I have this message from Junio:
> I do not speak for Pasky, but to me "cp -u" sounds just like an
> optimization, so maybe defining CP_U='cp -u' and detect missing
> support at config time and falling back on the simple "cp" would
> be an option?
Pasky, does this seem reasonable? Is there a better way? So far I
have been able to avoid adding the "config.sh" contained in my first
script.
cheers,
Bryan
^ permalink raw reply
* [PATCH 1/5] cogito: remove use of xargs -r, a non-portable GNU extension
From: Bryan Larsen @ 2005-07-16 23:23 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050716232308.7317.56890.sendpatchset@bryan-larsens-ibook-g4.local>
Remove usage of xargs -r, a non-portable gnu extension.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 6 +++---
cg-init | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -25,8 +25,6 @@ USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || usage
-
infoonly=
while optparse; do
if optparse -N; then
@@ -36,6 +34,8 @@ while optparse; do
fi
done
+[ "$ARGS" ] || usage
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
@@ -43,6 +43,6 @@ find "${ARGS[@]}" -type f -print0 > $TMP
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
+cat $TMPFILE | xargs -0 git-update-cache --add ${infoonly} --
rm $TMPFILE
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -55,7 +55,7 @@ if [ "$uri" ]; then
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
+ [ `ls` ] && find * \( -type f -o -type l \) -print0 | xargs -0 cg-add ${infoonly}
cg-commit -C -m"Initial commit" -E ${infoonly}
fi
^ permalink raw reply
* [PATCH 3/5] cogito: try harder to find gnu stat
From: Bryan Larsen @ 2005-07-16 23:23 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050716232308.7317.56890.sendpatchset@bryan-larsens-ibook-g4.local>
Look harder for gnu stat.
Cogito has code to use awk if gnu stat is missing. Look harder
for gnu stat under alternate names such as gstat and gnustat, avoiding
the use of awk if possible.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -229,11 +229,11 @@ fi
# Compatibility hacks:
-# Fortunately none as of now.
-
export BROKEN_MKTEMP=1
del=$($(which mktemp) -t 2>/dev/null) && { rm $del; export BROKEN_MKTEMP=; }
-has_stat=$(which stat 2>/dev/null)
+has_stat=$(which gnustat 2> /dev/null ||
+ which gstat 2> /dev/null ||
+ which stat 2>/dev/null)
[ "$has_stat" ] && $has_stat -c %s / 2>/dev/null >&2 || has_stat=
has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
^ permalink raw reply
* [PATCH 5/5] cogito: remove findutils dependency from Portfile
From: Bryan Larsen @ 2005-07-16 23:24 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050716232308.7317.56890.sendpatchset@bryan-larsens-ibook-g4.local>
Gnu findutils (xargs) is no longer required; remove the dependency.
Gnu coreutils is still required, but only if awk is not installed.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Portfile.in | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Portfile.in b/Portfile.in
--- a/Portfile.in
+++ b/Portfile.in
@@ -14,8 +14,7 @@ long_description The git core, develope
homepage http://kernel.org/pub/software/scm/cogito/
master_sites http://kernel.org/pub/software/scm/cogito/
configure {}
-depends_lib bin:gcp:coreutils
-depends_lib bin:gnuxargs:findutils
+depends_lib bin:gstat:coreutils
build.type gnu
destroot.type gnu
destroot.destdir prefix=${prefix} DESTDIR=${destroot}
^ permalink raw reply
* [PATCH 4/5] cogito: try harder to find gnu date
From: Bryan Larsen @ 2005-07-16 23:24 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050716232308.7317.56890.sendpatchset@bryan-larsens-ibook-g4.local>
Look harder for gnu date, use if available.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -70,7 +70,7 @@ showdate () {
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
[ "$format" ] || format="+%a, %d %b %Y %H:%M:%S $2"
if [ "$has_gnudate" ]; then
- LANG=C date -ud "1970-01-01 UTC + $secs sec" "$format"
+ LANG=C ${has_gnudate} -ud "1970-01-01 UTC + $secs sec" "$format"
else
LANG=C date -u -r $secs "$format"
fi
@@ -236,4 +236,8 @@ has_stat=$(which gnustat 2> /dev/null ||
which gstat 2> /dev/null ||
which stat 2>/dev/null)
[ "$has_stat" ] && $has_stat -c %s / 2>/dev/null >&2 || has_stat=
-has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
+has_gnudate=$(which gnudate 2> /dev/null ||
+ which gdate 2> /dev/null ||
+ which stat 2>/dev/null)
+[ "$has_gnudate" ] &&
+ $has_gnudate -Rud "1970-01-01 UTC" 2> /dev/null >&2 || has_gnudate=
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-17 0:49 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m18y06pphg.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Junio C Hamano <junkio@cox.net> writes:
>>
>> - Anonymous pull from packed archives on remote sites via
>> non-rsync, non-ssh transport. ...
>> ... but we may also end up wanting something HTTP
>> reachable.
>
> For this we need a cgi script that will generate an appropriate
> pack.
I agree that nothing would beat a pack customized for each
puller from the bandwidth point of view. I like the general
idea of git-daemon Linus did and the cgi script you suggest, but
I wonder what the CPU/disk load implications for the server.
^ 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