* [PATCH] apply: match documentation, usage string and code.
From: Junio C Hamano @ 2005-07-14 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The more recent --apply option was not described.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-apply.txt | 28 ++++++++++++++++------------
apply.c | 4 +++-
2 files changed, 19 insertions(+), 13 deletions(-)
ace792c165ec274a18cedbdc78affea4d87d6c76
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -9,8 +9,7 @@ git-apply - Apply patch on a GIT index f
SYNOPSIS
--------
-'git-apply' [--no-merge] [--stat] [--summary] [--check]
-[--index] [--show-files] [-] [<file>...]
+'git-apply' [--no-merge] [--stat] [--summary] [--check] [--index] [--show-files] [--apply] [<patch>...]
DESCRIPTION
-----------
@@ -19,31 +18,29 @@ and a work tree.
OPTIONS
-------
-<file>...::
- The files to read patch from.
-
--::
- Instead of reading from a file, read from standard input.
+<patch>...::
+ The files to read patch from. '-' can be used to read
+ from the standard input.
--no-merge::
The default mode of operation is the merge behaviour
- which is not quite implemented yet. This flag
- explicitly tells the program not to use the merge
- behaviour.
+ which is not implemented yet. This flag explicitly
+ tells the program not to use the merge behaviour.
--stat::
Instead of applying the patch, output diffstat for the
- input.
+ input. Turns off "apply".
--summary::
Instead of applying the patch, output a condensed
summary of information obtained from git diff extended
headers, such as creations, renames and mode changes.
+ Turns off "apply".
--check::
Instead of applying the patch, see if the patch is
applicable to the current work tree and/or the index
- file and detects errors.
+ file and detects errors. Turns off "apply".
--index::
When --check is in effect, or when applying the patch
@@ -57,6 +54,13 @@ OPTIONS
--show-files::
Show summary of files that are affected by the patch.
+--apply::
+ If you use any of the options marked ``Turns off
+ "apply"'' above, git-apply reads and outputs the
+ information you asked without actually applying the
+ patch. Give this flag after those flags to also apply
+ the patch.
+
Author
------
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -32,7 +32,8 @@ static int summary = 0;
static int check = 0;
static int apply = 1;
static int show_files = 0;
-static const char apply_usage[] = "git-apply [--stat] [--summary] [--check] [--show-files] <patch>";
+static const char apply_usage[] =
+"git-apply [--no-merge] [--stat] [--summary] [--check] [--index] [--apply] [--show-files] <patch>...";
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
@@ -1424,6 +1425,7 @@ int main(int argc, char **argv)
read_stdin = 0;
continue;
}
+ /* NEEDSWORK: this does not do anything at this moment. */
if (!strcmp(arg, "--no-merge")) {
merge_patch = 0;
continue;
^ permalink raw reply
* [PATCH] Remove leftover comment from documentation.
From: Junio C Hamano @ 2005-07-14 3:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The comment was left over from the days when we had a single
huge core-git.txt document. No more.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-write-tree.txt | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
86eab95db201216395a24c02e88136ddbd007ed8
diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -30,19 +30,6 @@ OPTIONS
Normally "git-write-tree" ensures that the objects referenced by the
directory exist in the object database. This option disables this check.
-
-////////////////////////////////////////////////////////////////
-
-Producing man pages and html
-
-To create a set of html pages run:
- perl split-docs.pl -html < core-git.txt
-
-To create a set of man pages run:
- perl split-docs.pl -man < core-git.txt
-
-
-////////////////////////////////////////////////////////////////
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply
* [PATCH] clone-pack: Typofix in the error message.
From: Junio C Hamano @ 2005-07-14 3:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Cleans a small cut-and-paste mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
clone-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
c8db6ce8de9b9fc8a5eab939704eaa1535a0d3f0
diff --git a/clone-pack.c b/clone-pack.c
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -30,7 +30,7 @@ static struct ref *get_remote_refs(int f
if (line[len-1] == '\n')
line[--len] = 0;
if (len < 42 || get_sha1_hex(line, sha1))
- die("git-fetch-pack: protocol error - expected ref descriptor, got '%s､'", line);
+ die("git-clone-pack: protocol error - expected ref descriptor, got '%s､'", line);
refname = line+41;
len = len-40;
if (nr_match && !path_match(refname, nr_match, match))
^ permalink raw reply
* [PATCH] clone-pack and clone-script: documentation and add a missing parameter.
From: Junio C Hamano @ 2005-07-14 3:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
While adding the documentation for these two commands, I noticed
that the name of the program on the other end (git-upload-pack)
is already almost configurable but git-clone-pack lacked command
line parameter parsing to actually use anything but default, so
I introduced --exec= like other remote commands while I was at it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-clone-pack.txt | 60 ++++++++++++++++++++++++++++++++++++
Documentation/git-clone-script.txt | 60 ++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 7 ++++
clone-pack.c | 6 +++-
git-clone-script | 12 ++++++-
5 files changed, 142 insertions(+), 3 deletions(-)
create mode 100644 Documentation/git-clone-pack.txt
create mode 100644 Documentation/git-clone-script.txt
7fffcd07cc6e81c0e50ee4d0f0d32d1aadb243c6
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-clone-pack.txt
@@ -0,0 +1,60 @@
+git-clone-pack(1)
+=================
+v0.1, July 2005
+
+NAME
+----
+git-clone-pack - Clones a repository by receiving packed objects.
+
+
+SYNOPSIS
+--------
+'git-clone-pack' [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>...]
+
+DESCRIPTION
+-----------
+Clones a repository into the current repository by invoking
+'git-upload-pack', possibly on the remote host via ssh, in
+the named repository, and invoking 'git-unpack-objects' locally
+to receive the pack.
+
+OPTIONS
+-------
+-q::
+ Pass '-q' flag to 'git-unpack-objects'; this makes the
+ cloning process less verbose.
+
+--exec=<git-upload-pack>::
+ Use this to specify the path to 'git-upload-pack' on the
+ remote side, if is not found on your $PATH.
+ Installations of sshd ignores the user's environment
+ setup scripts for login shells (e.g. .bash_profile) and
+ your privately installed GIT may not be found on the system
+ default $PATH. Another workaround suggested is to set
+ up your $PATH in ".bashrc", but this flag is for people
+ who do not want to pay the overhead for non-interactive
+ shells by having a lean .bashrc file (they set most of
+ the things up in .bash_profile).
+
+[<host>:]<directory::
+ The (possibly remote) repository to clone from.
+
+<heads>...::
+ The heads to update. This is relative to $GIT_DIR
+ (e.g. "HEAD", "refs/heads/master"). When unspecified,
+ all heads are updated to match the remote repository.
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git-clone-script.txt b/Documentation/git-clone-script.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-clone-script.txt
@@ -0,0 +1,60 @@
+git-clone-script(1)
+===================
+v0.1, July 2005
+
+NAME
+----
+git-clone-script - Clones a repository.
+
+
+SYNOPSIS
+--------
+'git clone' [-l] [-u <upload-pack>] [-q] <repository> <directory>
+
+DESCRIPTION
+-----------
+Clones a repository into a newly created directory.
+
+OPTIONS
+-------
+-l::
+ When the repository to clone from is on a local machine,
+ this flag bypasses normal "git aware" transport
+ mechanism and clones the repository by making a copy of
+ HEAD and everything under objects and refs directories.
+ The files under .git/objects/ directory are hardlinked
+ to save space when possible.
+
+-q::
+ Operate quietly. This flag is passed to "rsync" and
+ "git-clone-pack" commands when given.
+
+-u <upload-pack>::
+ When given, and the repository to clone from is handled
+ by 'git-clone-pack', '--exec=<upload-pack>' is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
+<repository>::
+ The (possibly remote) repository to clone from. It can
+ be an "rsync://host/dir" URL, an "http://host/dir" URL,
+ or [<host>:]/dir notation that is used by 'git-clone-pack'.
+ Currently http transport is not supported.
+
+<directory>::
+ The name of a new directory to be cloned into. It is an
+ error to specify an existing directory.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Junio C Hamano.
+
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -127,6 +127,13 @@ link:git-apply-patch-script.html[git-app
link:git-convert-cache.html[git-convert-cache]::
Converts old-style GIT repository
+link:git-clone-script.html[git-clone-script]::
+ Clones a repository into the current repository (user interface)
+
+link:git-clone-pack.html[git-clone-pack]::
+ Clones a repository into the current repository (engine
+ for ssh and local transport)
+
link:git-http-pull.html[git-http-pull]::
Downloads a remote GIT repository via HTTP
diff --git a/clone-pack.c b/clone-pack.c
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -4,7 +4,7 @@
#include <sys/wait.h>
static int quiet;
-static const char clone_pack_usage[] = "git-clone-pack [host:]directory [heads]*";
+static const char clone_pack_usage[] = "git-clone-pack [-q] [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>]*";
static const char *exec = "git-upload-pack";
struct ref {
@@ -196,6 +196,10 @@ int main(int argc, char **argv)
quiet = 1;
continue;
}
+ if (!strncmp("--exec=", arg, 7)) {
+ exec = arg + 7;
+ continue;
+ }
usage(clone_pack_usage);
}
dest = arg;
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -6,7 +6,7 @@
# Clone a repository into a different directory that does not yet exist.
usage() {
- echo >&2 "* git clone [-l] <repo> <dir>"
+ echo >&2 "* git clone [-l] [-q] [-u <upload-pack>] <repo> <dir>"
exit 1
}
@@ -16,11 +16,16 @@ get_repo_base() {
quiet=
use_local=no
+upload_pack=
while
case "$#,$1" in
0,*) break ;;
*,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-q|*,--quiet) quiet=-q ;;
+ 1,-u|*,--upload-pack) usage ;;
+ *,-u|*,--upload-pack)
+ shift
+ upload_pack="--exec=$2" ;;
*,-*) usage ;;
*) break ;;
esac
@@ -90,6 +95,9 @@ http://*)
exit 1
;;
*)
- cd "$D" && git-clone-pack $quiet "$repo"
+ cd "$D" && case "$upload_pack" in
+ '') git-clone-pack $quiet "$repo" ;;
+ *) git-clone-pack $quiet "$upload_pack" "$repo" ;;
+ esac
;;
esac
^ permalink raw reply
* [PATCH] checkout-cache: add usage string.
From: Junio C Hamano @ 2005-07-14 3:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This adds the usage string to checkout-cache and you can say
"--help" to get it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
checkout-cache.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
0d87d25f9a8ecf6ee8c4bc0c1575f3c03614c339
diff --git a/checkout-cache.c b/checkout-cache.c
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -75,6 +75,9 @@ static int checkout_all(void)
return 0;
}
+static const char *checkout_cache_usage =
+"git-checkout-cache [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
+
int main(int argc, char **argv)
{
int i, force_filename = 0;
@@ -123,6 +126,8 @@ int main(int argc, char **argv)
state.base_dir_len = strlen(state.base_dir);
continue;
}
+ if (arg[0] == '-')
+ usage(checkout_cache_usage);
}
if (state.base_dir_len) {
/* when --prefix is specified we do not
^ permalink raw reply
* [PATCH] cat-file: be consistent in usage string and documentation.
From: Junio C Hamano @ 2005-07-14 3:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Now that we have something called tag object, and a notion of
"tags" stored in .git/refs/tags/ directory, the word "tagname"
has become misleading in the usage string. The documentation
already calls that <type>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cat-file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
61a4ebfb09cee6955f80a863b9651204ba17117a
diff --git a/cat-file.c b/cat-file.c
--- a/cat-file.c
+++ b/cat-file.c
@@ -13,7 +13,7 @@ int main(int argc, char **argv)
unsigned long size;
if (argc != 3 || get_sha1(argv[2], sha1))
- usage("git-cat-file [-t | -s | tagname] <sha1>");
+ usage("git-cat-file [-t | -s | <type>] <sha1>");
if (!strcmp("-t", argv[1]) || !strcmp("-s", argv[1])) {
if (!sha1_object_info(sha1, type,
^ permalink raw reply
* [PATCH] Document two pack push-pull protocols.
From: Junio C Hamano @ 2005-07-14 3:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This documents the two pack push-pull protocols used by the
smart upload-fetch/clone and send/receive commands.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
There currently are these two pack push-pull protocols used for
different purposes. Maybe you invented another today? I have
not looked beyond your log message.
Documentation/pack-protocol.txt | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100644 Documentation/pack-protocol.txt
3a74ad8bd10e958ddbd4d432ad3140abc5464229
diff --git a/Documentation/pack-protocol.txt b/Documentation/pack-protocol.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/pack-protocol.txt
@@ -0,0 +1,38 @@
+There are two Pack push-pull protocols.
+
+upload-pack (S) | fetch/clone-pack (C) protocol:
+
+ # Tell the puller what commits we have and what their names are
+ S: SHA1 name
+ S: ...
+ S: SHA1 name
+ S: # flush -- it's your turn
+ # Tell the pusher what commits we want, and what we have
+ C: want name
+ C: ..
+ C: want name
+ C: have SHA1
+ C: have SHA1
+ C: ...
+ C: # flush -- occasionally ask "had enough?"
+ S: NAK
+ C: have SHA1
+ C: ...
+ C: have SHA1
+ S: ACK
+ C: done
+ S: XXXXXXX -- packfile contents.
+
+send-pack | receive-pack protocol.
+
+ # Tell the pusher what commits we have and what their names are
+ C: SHA1 name
+ C: ...
+ C: SHA1 name
+ C: # flush -- it's your turn
+ # Tell the puller what the pusher has
+ S: old-SHA1 new-SHA1 name
+ S: old-SHA1 new-SHA1 name
+ S: ...
+ S: # flush -- done with the list
+ S: XXXXXXX --- packfile contents.
^ permalink raw reply
* Re: "git daemon"
From: Linus Torvalds @ 2005-07-14 3:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: H. Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0507131946540.17536@g5.osdl.org>
On Wed, 13 Jul 2005, Linus Torvalds wrote:
>
> Anyway, this would be a _wonderful_ interface for read-only updates, ie
> people pulling from my (and other peoples) git repositories.
I guess I should say what the interface is, so that people don't have to
read the sources to find out..
On the server side:
# mark all repositories you want to export with the
# "git-daemon-export-ok" file in the .git directory..
#
# .. and let the port (9418) through any firewalls etc,
# of course
git-daemon >& logfile &
(NOTE! "git-daemon" will not disassociate from any tty's or anything fancy
like that.)
On the client side:
git pull git://servername/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
And you're done.
(or "git clone", for that matter - I just fixed a one-liner that caused
"clone" to not work, so make sure that you have a commit that says 'Fix
the "close before dup" bug in clone-pack too').
If you want to use a different port number (maybe 9418 is some really 133t
port, and google just doesn't know about it), you can give git-daemon a
"--port=x" command line argument, and you can use
git://servername:port/pathname
on the client side. At least that was my intention, I didn't actually test
whether that worked (but the default port has been tested).
Linus
^ permalink raw reply
* "git daemon"
From: Linus Torvalds @ 2005-07-14 2:53 UTC (permalink / raw)
To: Git Mailing List; +Cc: H. Peter Anvin
Guys,
I've written a really simple TCP git daemon that normally listens on
port "DEFAULT_GIT_PORT" aka 9418. It waits for a connection, and will just
execute "git-upload-pack" when it gets one.
It's actually a bit more careful than that, in that there's a magic
request-line that gives the command and what directory to upload, and it
verifies that the directory is ok.
In particular, it verifies that the directory has the magic file
"git-daemon-export-ok", and it will refuse to export any git directory
that hasn't explicitly been marked for export this way.
What I'd ask people to check is how comfortable for example kernel.org
would be to have one machine that runs this kind of service? I've tried
very hard to set it up so that it doesn't have any security issues: the
daemon can be run as "nobody", and it shouldn't ever even write to any
files, although I guess we should do a full check of that.
In fact, it doesn't even really accept any user input except for the list
of SHA1's that you give the upload which denote the "I have these" list.
So I really think it should be hard to fool into doing anything bad, and
the code isn't _that_ complicated, but hey, it's a daemon. They're always
buggy, and there are always security issues.
Anyway, this would be a _wonderful_ interface for read-only updates, ie
people pulling from my (and other peoples) git repositories.
Linus
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Chris Wedgwood @ 2005-07-13 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507131425080.17536@g5.osdl.org>
On Wed, Jul 13, 2005 at 02:33:43PM -0700, Linus Torvalds wrote:
> Hmm.. I don't think it's necessarily wrong, although as you say,
> your editor had better DTRT.
It does. I assume probably everything does but I never really
checked.
> That said, even if your editor doesn't, at least you won't corrupt
> your git archive, although you might have surprising changes creep
> into the other side..
Well, with hard-linked trees and the nastyness I posted I would test
with
cp -Rl tree1 tree2
cd tree2
<hack hack hack>
find ../tree1 -mmin -<n> ... # make sure we didn't mess up original tree
So far this seems to work for me.
> Search-search-search.. Indeed: at least "git-apply" seems to modify
> the file in place.
I probably just luckily never hit this.
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Linus Torvalds @ 2005-07-13 21:33 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Matthias Urlichs, Git Mailing List
In-Reply-To: <20050713211106.GA12047@taniwha.stupidest.org>
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
>
> I would however like to be able to hardlink more than just the
> _object_ directory --- hardlinking the source is quite nice too.
> Might that be considered safe? (I'm of course assuming that editors
> do write + rename when saving their buffers).
Hmm.. I don't think it's necessarily wrong, although as you say, your
editor had better DTRT. That said, even if your editor doesn't, at least
you won't corrupt your git archive, although you might have surprising
changes creep into the other side..
But I've not verified that every git program does the right thing...
Search-search-search.. Indeed: at least "git-apply" seems to modify the
file in place. That may be the only one, though - and should be easily
fixed by adding an "unlink()" (and make it use O_EXCL just to make it
easy to grep to verify that we always use O_EXCL with O_WR.*).
entry.c should also add O_EXCL (it seems to already do the unlink).
Anybody want to go through and verify it? I think we should support
hardlinked source trees if we can do so easily, and it _looks_ like we're
pretty close..
Linus
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames
From: Catalin Marinas @ 2005-07-13 21:26 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Bryan Larsen, git
In-Reply-To: <42D55AC9.4000506@gmail.com>
On Wed, 2005-07-13 at 14:17 -0400, Bryan Larsen wrote:
> Catalin Marinas wrote:
> I would have hoped that emacs py-mode would "do the right thing".
> Anybody know how to make it do what Catalin wants?
It looks like the python-mode in my emacs does the right thing. You
could add something like below in your .emacs file:
(add-hook 'python-mode-hook
#'(lambda ()
(setq indent-tabs-mode nil)))
Otherwise, select the whole buffer and do a "M-x untabify".
> > What's the reason for having 'fin' as well? It doesn't seem to be used
> > (this is found in other parts of the patch as well).
>
> popen does not support bypassing the shell by using vectors of
> arguments. Only popen2 and friends have this capability.
But the manual says that it is not possible to get the exit code of the
child process with popen2 (at least not in python 2.3). You would need
to use the Popen3 and Popen4 classes in the popen2 module.
Does it make that big difference if the commands are invoked via the
shell? I haven't run any tests.
> > I'm not sure whether the GIT guys are happy for us to use this mailing
> > list for StGIT. If the StGIT traffic increases, I will try to create a
> > separate mailing list (maybe using a site like sf.net).
> >
>
> I'd very much like to stay on the same list. By the same logic, cogito
> should have it's own list as well...
I'd like this too and it's probably OK with a low traffic (we'll see if
we receive complaints :-) ).
Catalin
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Linus Torvalds @ 2005-07-13 21:23 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Matthias Urlichs, git
In-Reply-To: <20050713185339.GA9260@taniwha.stupidest.org>
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
>
> How about the following?
>
> echo_to_file() {
> local DEST="$2"
> local count=1
> local RET
>
> # follow symlinks until we run out or end up with something
> # dangling
> while [ -L "$DEST" ] ; do
If you really want to do something like this, then you should do it like
this:
update_head() {
head="$GIT_DIR/HEAD"
newvalue=$(git-rev-parse --verify "$1"^0) || exit
if [ -L "$head" ]; then
head=$(readlink "$head")
case "$head" in
refs/heads/*)
head="$GIT_DIR"/"$head"
;;
*)
exit 1
;;
esac
fi
echo $newvalue > "$head.lock" && rename "$head.lock" "$head"
}
which is at least slightly simpler, and might even work thanks to that.
Your was buggy for several reasons:
- following multiple links is _wrong_, since the next-level link could
actually be a symlink to another tree entirely (if somebody is crazy
enough to use "cp -Rl" to copy trees, then why not "cp -Rs"?)
Ergo: you should only follow a symlink if it points to refs/heads, and
anything else would be a BUG.
- you got relative links wrong.
Now, admittedly the above is totally untested too, so I'll probably have
typos etc in there. But the basic point stands: don't go for complexity.
Go for one _particular_ case.
Linus
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Linus Torvalds @ 2005-07-13 21:05 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Matthias Urlichs, Git Mailing List
In-Reply-To: <20050713204458.GB11403@taniwha.stupidest.org>
On Wed, 13 Jul 2005, Chris Wedgwood wrote:
>
> The complexity I added was to deal with a situation where we have
>
> tree1/
> .git/HEAD -> refs/head/master
>
> and I do "cp -Rl tree1 tree2" giving me:
>
> tree2/
> .git/HEAD -> refs/head/master
>
> and .git/refs/head/master is hardlinked between both trees.
AND THAT IS WRONG.
You shouldn't hardlink whole trees. Git will not guarantee that it breaks
the links.
Right now, if you go a "git commit", and a number of other core git
operations, it will use ">" to overwrite the HEAD. You're screwed.
> > That is COW-safe, but the thing is, it's incredibly painful for many
> > other operations, and I won't guarantee that git in general is
> > always going to be COW-safe wrt all the git files.
>
> What operations is this painful for?
Your script was tens of lines of code, and it was BUGGY.
And now you ask what it's painful for?
Guys, if you want to mess up code, the #1 rule is:
- make complex code to handle insane situations
You're well on your way to do that.
Don't hardlink git trees. It's a bug to do so. It will eventually change
the other git tree.
Hardlink git _object_ directories. That's a totally different thing.
Linus
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Chris Wedgwood @ 2005-07-13 21:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507131402210.17536@g5.osdl.org>
On Wed, Jul 13, 2005 at 02:05:35PM -0700, Linus Torvalds wrote:
> > and .git/refs/head/master is hardlinked between both trees.
>
> AND THAT IS WRONG.
OK, I was more-or-less assuming that 'cp -Rl tree1 tree2' was always a
valid thing to do.
Clearly if it's not then all of this is somewhat moot.
> You shouldn't hardlink whole trees. Git will not guarantee that it
> breaks the links.
I can live with that, until now though I wasn't aware that hardlinked
trees were a bad-thing.
> Your script was tens of lines of code, and it was BUGGY.
Yeah well, I'm a retard.
> Hardlink git _object_ directories. That's a totally different thing.
I was under the misconception that hardlink entire trees was
permissible.
I would however like to be able to hardlink more than just the
_object_ directory --- hardlinking the source is quite nice too.
Might that be considered safe? (I'm of course assuming that editors
do write + rename when saving their buffers).
^ permalink raw reply
* Re: [PATCH] stgit: allow spaces in filenames
From: Jerry Seutter @ 2005-07-13 21:09 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42D55AC9.4000506@gmail.com>
Bryan Larsen wrote:
> Catalin Marinas wrote:
>
>> An additional thing, can you please convert all the tabs to spaces?
>> That's a better convention for a language like Python where you
>> delimit blocks by indentation.
>
>
> I would have hoped that emacs py-mode would "do the right thing".
> Anybody know how to make it do what Catalin wants?
Yeah, the default emacs mode seems to be to Do The Wrong Thing. I have
this in my .emacs, YMMV.
(setq-default indent-tabs-mode nil) ; Don't insert tab characters.
(setq-default tab-width 4) ; If there are tabs, display
; as 4 spaces.
You can set the tab-width to something much larger to make existing tabs
obvious.
Jerry
^ permalink raw reply
* Re: [PATCH (contingency)] Document "curl" requirements.
From: Darrin Thompson @ 2005-07-13 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6juxy97.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-07-13 at 13:11 -0700, Junio C Hamano wrote:
> darrint@progeny.com (Darrin Thompson) writes:
>
> > Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
> > curl's ssl peer verification.
> >
> > Only use curl for http transfers, instead of curl and wget.
>
> I do not mind curl per se, since we already require libcurl for
> http-pull, but it would be nice if we document what external
> software we depend on in one place. Something like this on top
> of what you posted?
I have no problem with it. Do I need to take some action?
--
Darrin
^ permalink raw reply
* [PATCH] diff-stages: support "-u" as a synonym for "-p".
From: Junio C Hamano @ 2005-07-13 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <loom.20050712T224801-163@post.gmane.org>
Just to be consistent, support "-u" as a synonym for "-p" like
everybody else does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-stages.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
ef519b28e8edb19d4a0233152c9497ee807a4f5b
diff --git a/diff-stages.c b/diff-stages.c
--- a/diff-stages.c
+++ b/diff-stages.c
@@ -67,7 +67,7 @@ int main(int ac, const char **av)
const char *arg = av[1];
if (!strcmp(arg, "-r"))
; /* as usual */
- else if (!strcmp(arg, "-p"))
+ else if (!strcmp(arg, "-p") || !strcmp(arg, "-u"))
diff_output_format = DIFF_FORMAT_PATCH;
else if (!strncmp(arg, "-B", 2)) {
if ((diff_break_opt = diff_scoreopt_parse(arg)) == -1)
^ permalink raw reply
* Re: How to get a directory filled with v2.6.11?
From: Linus Torvalds @ 2005-07-13 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvf3ewig0.fsf@assigned-by-dhcp.cox.net>
On Wed, 13 Jul 2005, Junio C Hamano wrote:
>
> I do not think git-cherry would be that useful in this context.
> Nobody upstream is merging things into your development trail,
> started at the private commit you made based on the 2.6.11 tree.
No, the point being that he (or anybody else) could move the commits as
patches, one by one, from his 2.6.11 base to whatever later base that _is_
in the commit history.
It's really the same issue as with cherry-picking: you do commits one at a
time as diffs, see if that diff already exists in the destination stream,
and if not, you try to apply it as a patch and re-commit it with the old
commit message in a new place in history.
Linus
^ permalink raw reply
* [PATCH] git-diff-*: --name-only and --name-only-z.
From: Junio C Hamano @ 2005-07-13 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <loom.20050712T224801-163@post.gmane.org>
Porcelain layers often want to find only names of changed files,
and even with diff-raw output format they end up having to pick
out only the filename. Support --name-only (and --name-only-z
for xargs -0 and cpio -0 users that want to treat filenames with
embedded newlines sanely) flag to help them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-cache.c | 8 ++++++++
diff-files.c | 4 ++++
diff-stages.c | 4 ++++
diff-tree.c | 8 ++++++++
diff.c | 13 ++++++++++++-
diff.h | 2 ++
6 files changed, 38 insertions(+), 1 deletions(-)
ea3228b62de0838cd854ecf503f6f534b0b7e25c
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -223,6 +223,14 @@ int main(int argc, const char **argv)
diff_output_format = DIFF_FORMAT_MACHINE;
continue;
}
+ if (!strcmp(arg, "--name-only")) {
+ diff_output_format = DIFF_FORMAT_NAME;
+ continue;
+ }
+ if (!strcmp(arg, "--name-only-z")) {
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ continue;
+ }
if (!strcmp(arg, "-R")) {
diff_setup_opt |= DIFF_SETUP_REVERSE;
continue;
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -55,6 +55,10 @@ int main(int argc, const char **argv)
; /* no-op */
else if (!strcmp(argv[1], "-z"))
diff_output_format = DIFF_FORMAT_MACHINE;
+ else if (!strcmp(argv[1], "--name-only"))
+ diff_output_format = DIFF_FORMAT_NAME;
+ else if (!strcmp(argv[1], "--name-only-z"))
+ diff_output_format = DIFF_FORMAT_NAME_Z;
else if (!strcmp(argv[1], "-R"))
diff_setup_opt |= DIFF_SETUP_REVERSE;
else if (!strncmp(argv[1], "-S", 2))
diff --git a/diff-stages.c b/diff-stages.c
--- a/diff-stages.c
+++ b/diff-stages.c
@@ -87,6 +87,10 @@ int main(int ac, const char **av)
find_copies_harder = 1;
else if (!strcmp(arg, "-z"))
diff_output_format = DIFF_FORMAT_MACHINE;
+ else if (!strcmp(arg, "--name-only"))
+ diff_output_format = DIFF_FORMAT_NAME;
+ else if (!strcmp(arg, "--name-only-z"))
+ diff_output_format = DIFF_FORMAT_NAME_Z;
else if (!strcmp(arg, "-R"))
diff_setup_opt |= DIFF_SETUP_REVERSE;
else if (!strncmp(arg, "-S", 2))
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -480,6 +480,14 @@ int main(int argc, const char **argv)
find_copies_harder = 1;
continue;
}
+ if (!strcmp(arg, "--name-only")) {
+ diff_output_format = DIFF_FORMAT_NAME;
+ continue;
+ }
+ if (!strcmp(arg, "--name-only-z")) {
+ diff_output_format = DIFF_FORMAT_NAME_Z;
+ continue;
+ }
if (!strcmp(arg, "-z")) {
diff_output_format = DIFF_FORMAT_MACHINE;
continue;
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -818,6 +818,12 @@ static void diff_flush_raw(struct diff_f
putchar(line_termination);
}
+static void diff_flush_name(struct diff_filepair *p,
+ int line_termination)
+{
+ printf("%s%c", p->two->path, line_termination);
+}
+
int diff_unmodified_pair(struct diff_filepair *p)
{
/* This function is written stricter than necessary to support
@@ -978,7 +984,8 @@ void diff_flush(int diff_output_style)
int line_termination = '\n';
int inter_name_termination = '\t';
- if (diff_output_style == DIFF_FORMAT_MACHINE)
+ if (diff_output_style == DIFF_FORMAT_MACHINE ||
+ diff_output_style == DIFF_FORMAT_NAME_Z)
line_termination = inter_name_termination = 0;
for (i = 0; i < q->nr; i++) {
@@ -997,6 +1004,10 @@ void diff_flush(int diff_output_style)
diff_flush_raw(p, line_termination,
inter_name_termination);
break;
+ case DIFF_FORMAT_NAME:
+ case DIFF_FORMAT_NAME_Z:
+ diff_flush_name(p, line_termination);
+ break;
}
}
for (i = 0; i < q->nr; i++)
diff --git a/diff.h b/diff.h
--- a/diff.h
+++ b/diff.h
@@ -59,6 +59,8 @@ extern int diff_queue_is_empty(void);
#define DIFF_FORMAT_MACHINE 1
#define DIFF_FORMAT_PATCH 2
#define DIFF_FORMAT_NO_OUTPUT 3
+#define DIFF_FORMAT_NAME 4
+#define DIFF_FORMAT_NAME_Z 5
extern void diff_flush(int output_style);
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Chris Wedgwood @ 2005-07-13 20:36 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050713200724.GN9915@kiste.smurf.noris.de>
On Wed, Jul 13, 2005 at 10:07:24PM +0200, Matthias Urlichs wrote:
> You lose if the link is relative and the symlink is not in the
> current directory.
Cogito doesn't create such links in my (limited_ experience. Why
would anyone else do that?
> You also lose on systems where the empty filename is synonymous with
> the current directory.
Well, return code from readlink should be tested there.
[...]
> You should remove "DEST first. Otherwise, under Linux, you'll
> magically create the file the symlink points to, which may not be
> what you want to do.
That behavior *is* desirable in this case.
Anyhow, the fact this is so complicated and getting more so makes me
think it's misdirected :-(
^ permalink raw reply
* Re: [RFC PATCH] cogito --- don't overwrite metadata files in place (breaks CoW use)
From: Chris Wedgwood @ 2005-07-13 20:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Urlichs, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507131256490.17536@g5.osdl.org>
On Wed, Jul 13, 2005 at 01:05:02PM -0700, Linus Torvalds wrote:
> This is really complicated, for no good reason.
What should I be doing?
> The _object_ directories should be linked, but it's really wrong to link
> the "refs/" directories and expect them to have COW behaviour.
I'm confused.
This function in only used to update various files, one of which is
.git/HEAD
The complexity I added was to deal with a situation where we have
tree1/
.git/HEAD -> refs/head/master
and I do "cp -Rl tree1 tree2" giving me:
tree2/
.git/HEAD -> refs/head/master
and .git/refs/head/master is hardlinked between both trees.
Cogito will do "echo <foo> > .git/HEAD" which update *both* tree1 and
tree2 which is not what I want. So the idea is to readlink and do the
update using echo + rename to get the CoW semantics I desire.
Yes, weird things happen if you have out-of-treel links but I suspect
if you do that with cogito you've probably lost anyhow.
> I've tried to make most of the git tools write the refs objects
> "safely" too, ie things like "git-receive-pack" (the receiving end
> of a "git-send-pack") will write the new ref to a lock-file and then
> do a "rename()" to set it.
Yes, git is probably fine. Cogito isn't.
> That is COW-safe, but the thing is, it's incredibly painful for many
> other operations, and I won't guarantee that git in general is
> always going to be COW-safe wrt all the git files.
What operations is this painful for?
^ permalink raw reply
* Re: How to get a directory filled with v2.6.11?
From: Junio C Hamano @ 2005-07-13 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507122116280.17536@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That said, whatever you do you will eventually end up with a series of
> commits that are not related to the "normal" commits in the 2.6.12-rc2+
> chain, and since they don't have a common point, git won't be able to
> merge them for you. Git will be able to _track_ them for you, but at some
> point you'll want to probably try to move them forward to the "rest" of
> the git history.
>
> And I'll warn you that that is not going to be entirely trivial, although
> Junio's "cherrypick" scripts should be useful as a way to automate it at
> least to some degree. This is why it would be so much easier if you could
> have started with a 2.6.12-rc2 or other "real" commit ;)
I do not think git-cherry would be that useful in this context.
Nobody upstream is merging things into your development trail,
started at the private commit you made based on the 2.6.11 tree.
I was wondering if adding "graft trail" to merge-base command
would help this situation.
SYNOPSIS
--------
'git-merge-base' ( --graft <commit1> <commit2>)* <commit> <commit>
...
OPTIONS
-------
<commit>::
The two heads being merged.
--graft <commit1> <commit2>::
Treat as if <commit1> is one of the ancestors of
<commit2> when computing the commit ancestry chain.
Can be specified more than once.
Then we could say "--graft v2.6.11 v2.6.12-rc2".
We may want to have a configuration file in .git/ directory (I
think it belongs to .git/objects/ hierarchy, because this is not
per work-tree thing but per project thing) that record this
"graft" relationship.
When we have not-so-stupid [*1*] merge algorithm in place, we
could do even better. Starting from v2.6.11 tree, we can
rebuild (from BKCVS) the development trail up to v2.6.12-rc2,
which is independent from the current kernel development trail
which started at (a different) v2.6.12-rc2. Use the former one
as <commit1>, and the latter one as <commit2>, and the "clever"
merge algorithm would be able to follow across the v2.6.12-rc2
discontiguity and trace the development back to v2.6.11.
[Footnote]
*1* <Pine.LNX.4.58.0507052011440.3570@g5.osdl.org>
So if you want to document that the current automatic merge is stupid,
hey, go wild. It _is_ stupid. It's surprisingly effective, but that may be
because of kernel development patterns and may not be true in other
projects.
^ permalink raw reply
* Re: Is cogito really this inefficient
From: Linus Torvalds @ 2005-07-13 20:28 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050713135052.C6791@flint.arm.linux.org.uk>
On Wed, 13 Jul 2005, Russell King wrote:
>
> This says it all. 1min 22secs to generate a patch from a locally
> modified but uncommitted file.
No, there's something else going on.
Most likely that something forced a total index file re-validation, and
the time you see is every single checked out file having its SHA1
re-computed.
Was this a recently cloned tree, or what was the last operation you did on
that tree before that command? Something must have invalidated the index.
Linus
^ permalink raw reply
* [PATCH (contingency)] Document "curl" requirements.
From: Junio C Hamano @ 2005-07-13 20:11 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <20050713021240.88AAD63780@morimoto.progeny.com>
darrint@progeny.com (Darrin Thompson) writes:
> Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
> curl's ssl peer verification.
>
> Only use curl for http transfers, instead of curl and wget.
I do not mind curl per se, since we already require libcurl for
http-pull, but it would be nice if we document what external
software we depend on in one place. Something like this on top
of what you posted?
------------
Not just libcurl, but now we require curl executable as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/INSTALL b/INSTALL
--- a/INSTALL
+++ b/INSTALL
@@ -41,8 +41,10 @@ Issues of note:
can avoid the bignum support by excising git-rev-list support
for "--merge-order" (by hand).
- - "libcurl". git-http-pull uses this. You can disable building of
- that program if you just want to get started.
+ - "libcurl" and "curl" (executable). git-http-pull and
+ git-fetch-script use them. If you do not use http
+ transfer, you are probabaly OK if you do not have
+ these two.
- "GNU diff" to generate patches. Of course, you don't _have_ to
generate patches if you don't want to, but let's face it, you'll
^ 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