* Re: [PATCH] gitk: Add "Refs" menu
From: Paul Mackerras @ 2005-10-11 12:17 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1128559088.32103.8.camel@dv>
Pavel Roskin writes:
> This patch adds "Refs" menu to gitk. It makes all branches, tags and
> other ref objects appear as menu items. Selecting one of the items
> selects the corresponding line in the view.
Sorry I haven't responded before - I have got way behind with my email
due to a vacation and to concentrating on the merge of the ppc32 and
ppc64 kernel sources. It will probably be a bit longer before I can
get to look at this.
Thanks,
Paul.
^ permalink raw reply
* [PATCH] Adapt tutorial to cygwin and add test case
From: Johannes Schindelin @ 2005-10-11 11:35 UTC (permalink / raw)
To: git, junkio
Lacking reliable symlinks, the instructions in the tutorial did not work
in a cygwin setup. Also, a few outputs were not correct.
This patch fixes these, and adds a test case which follows the
instructions of the tutorial (except git-clone, -fetch and -push, which I
have not done yet).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/tutorial.txt | 71 ++++++++++++++------
t/t1200-tutorial.sh | 160 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 212 insertions(+), 19 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 19da3e2..7148da4 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -51,7 +51,9 @@ your new project. You will now have a `.
inspect that with `ls`. For your new empty project, it should show you
three entries, among other things:
- - a symlink called `HEAD`, pointing to `refs/heads/master`
+ - a symlink called `HEAD`, pointing to `refs/heads/master` (if your
+ platform does not have native symlinks, it is a file containing the
+ line "ref: refs/heads/master")
+
Don't worry about the fact that the file that the `HEAD` link points to
doesn't even exist yet -- you haven't created the commit that will
@@ -227,6 +229,7 @@ which will spit out
------------
diff --git a/hello b/hello
+index 557db03..263414f 100644
--- a/hello
+++ b/hello
@@ -1 +1,2 @@
@@ -289,13 +292,14 @@ also wants to get a commit message
on its standard input, and it will write out the resulting object name for the
commit to its standard output.
-And this is where we start using the `.git/HEAD` file. The `HEAD` file is
+And this is where we create the `.git/refs/heads/master` file. This file is
supposed to contain the reference to the top-of-tree, and since that's
exactly what `git-commit-tree` spits out, we can do this all with a simple
shell pipeline:
------------------------------------------------
-echo "Initial commit" | git-commit-tree $(git-write-tree) > .git/HEAD
+echo "Initial commit" | \
+ git-commit-tree $(git-write-tree) > .git/refs/heads/master
------------------------------------------------
which will say:
@@ -691,7 +695,9 @@ other point in the history than the curr
just telling `git checkout` what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
- git checkout -b mybranch earlier-commit
+------------
+git checkout -b mybranch earlier-commit
+------------
and it would create the new branch `mybranch` at the earlier commit,
and check out the state at that time.
@@ -699,17 +705,29 @@ and check out the state at that time.
You can always just jump back to your original `master` branch by doing
- git checkout master
+------------
+git checkout master
+------------
(or any other branch-name, for that matter) and if you forget which
branch you happen to be on, a simple
- ls -l .git/HEAD
+------------
+ls -l .git/HEAD
+------------
-will tell you where it's pointing. To get the list of branches
-you have, you can say
+will tell you where it's pointing (Note that on platforms with bad or no
+symlink support, you have to execute
- git branch
+------------
+cat .git/HEAD
+------------
+
+instead). To get the list of branches you have, you can say
+
+------------
+git branch
+------------
which is nothing more than a simple script around `ls .git/refs/heads`.
There will be asterisk in front of the branch you are currently on.
@@ -717,7 +735,9 @@ There will be asterisk in front of the b
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
- git branch <branchname> [startingpoint]
+------------
+git branch <branchname> [startingpoint]
+------------
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
@@ -843,7 +863,6 @@ $ git show-branch master mybranch
! [mybranch] Some work.
--
+ [master] Merged "mybranch" changes.
-+ [master~1] Some fun.
++ [mybranch] Some work.
------------------------------------------------
@@ -870,8 +889,10 @@ Now, let's pretend you are the one who d
to the `master` branch. Let's go back to `mybranch`, and run
resolve to get the "upstream changes" back to your branch.
- git checkout mybranch
- git resolve HEAD master "Merge upstream changes."
+------------
+git checkout mybranch
+git resolve HEAD master "Merge upstream changes."
+------------
This outputs something like this (the actual commit object names
would be different)
@@ -1087,13 +1108,17 @@ i.e. `<project>.git`. Let's create such
project `my-git`. After logging into the remote machine, create
an empty directory:
- mkdir my-git.git
+------------
+mkdir my-git.git
+------------
Then, make that directory into a git repository by running
`git init-db`, but this time, since its name is not the usual
`.git`, we do things slightly differently:
- GIT_DIR=my-git.git git-init-db
+------------
+GIT_DIR=my-git.git git-init-db
+------------
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
@@ -1117,7 +1142,9 @@ Your "public repository" is now ready to
Come back to the machine you have your private repository. From
there, run this command:
- git push <public-host>:/path/to/my-git.git master
+------------
+git push <public-host>:/path/to/my-git.git master
+------------
This synchronizes your public repository to match the named
branch head (i.e. `master` in this case) and objects reachable
@@ -1127,7 +1154,9 @@ As a real example, this is how I update
repository. Kernel.org mirror network takes care of the
propagation to other publicly visible machines:
- git push master.kernel.org:/pub/scm/git/git.git/
+------------
+git push master.kernel.org:/pub/scm/git/git.git/
+------------
Packing your repository
@@ -1140,7 +1169,9 @@ not so convenient to transport over the
immutable once they are created, there is a way to optimize the
storage by "packing them together". The command
- git repack
+------------
+git repack
+------------
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in `.git/objects/??/`
@@ -1164,7 +1195,9 @@ Our programs are always perfect ;-).
Once you have packed objects, you do not need to leave the
unpacked objects that are contained in the pack file anymore.
- git prune-packed
+------------
+git prune-packed
+------------
would remove them for you.
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
new file mode 100644
index 0000000..35db799
--- /dev/null
+++ b/t/t1200-tutorial.sh
@@ -0,0 +1,160 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Test git-rev-parse with different parent options'
+
+. ./test-lib.sh
+
+echo "Hello World" > hello
+echo "Silly example" > example
+
+git-update-index --add hello example
+
+test_expect_success 'blob' "test blob = \"$(git-cat-file -t 557db03)\""
+
+test_expect_success 'blob 557db03' "test \"Hello World\" = \"$(git-cat-file blob 557db03)\""
+
+echo "It's a new day for git" >>hello
+cat > diff.expect << EOF
+diff --git a/hello b/hello
+index 557db03..263414f 100644
+--- a/hello
++++ b/hello
+@@ -1 +1,2 @@
+ Hello World
++It's a new day for git
+EOF
+git-diff-files -p > diff.output
+test_expect_success 'git-diff-files -p' 'cmp diff.expect diff.output'
+git diff > diff.output
+test_expect_success 'git diff' 'cmp diff.expect diff.output'
+
+tree=$(git-write-tree 2>/dev/null)
+
+test_expect_success 'tree' "test 8988da15d077d4829fc51d8544c097def6644dbb = $tree"
+
+output="$(echo "Initial commit" | git-commit-tree $(git-write-tree) 2>&1 > .git/refs/heads/master)"
+
+test_expect_success 'commit' "test 'Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb' = \"$output\""
+
+git-diff-index -p HEAD > diff.output
+test_expect_success 'git-diff-index -p HEAD' 'cmp diff.expect diff.output'
+
+git diff HEAD > diff.output
+test_expect_success 'git diff HEAD' 'cmp diff.expect diff.output'
+
+#rm hello
+#test_expect_success 'git-read-tree --reset HEAD' "git-read-tree --reset HEAD ; test \"hello: needs update\" = \"$(git-update-index --refresh)\""
+
+cat > whatchanged.expect << EOF
+diff-tree VARIABLE (from root)
+Author: VARIABLE
+Date: VARIABLE
+
+ Initial commit
+
+diff --git a/example b/example
+new file mode 100644
+index 0000000..f24c74a
+--- /dev/null
++++ b/example
+@@ -0,0 +1 @@
++Silly example
+diff --git a/hello b/hello
+new file mode 100644
+index 0000000..557db03
+--- /dev/null
++++ b/hello
+@@ -0,0 +1 @@
++Hello World
+EOF
+
+git-whatchanged -p --root | \
+ sed -e "1s/^\(.\{10\}\).\{40\}/\1VARIABLE/" \
+ -e "2,3s/^\(.\{8\}\).*$/\1VARIABLE/" \
+> whatchanged.output
+test_expect_success 'git-whatchanged -p --root' 'cmp whatchanged.expect whatchanged.output'
+
+git tag my-first-tag
+test_expect_success 'git tag my-first-tag' 'cmp .git/refs/heads/master .git/refs/tags/my-first-tag'
+
+# TODO: test git-clone
+
+git checkout -b mybranch
+test_expect_success 'git checkout -b mybranch' 'cmp .git/refs/heads/master .git/refs/heads/mybranch'
+
+cat > branch.expect <<EOF
+ master
+* mybranch
+EOF
+
+git branch > branch.output
+test_expect_success 'git branch' 'cmp branch.expect branch.output'
+
+git checkout mybranch
+echo "Work, work, work" >>hello
+git commit -m 'Some work.' hello
+
+git checkout master
+
+echo "Play, play, play" >>hello
+echo "Lots of fun" >>example
+git commit -m 'Some fun.' hello example
+
+test_expect_failure 'git resolve now fails' 'git resolve HEAD mybranch "Merge work in mybranch"'
+
+cat > hello << EOF
+Hello World
+It's a new day for git
+Play, play, play
+Work, work, work
+EOF
+
+git commit -m 'Merged "mybranch" changes.' hello
+
+cat > show-branch.expect << EOF
+* [master] Merged "mybranch" changes.
+ ! [mybranch] Some work.
+--
++ [master] Merged "mybranch" changes.
+++ [mybranch] Some work.
+EOF
+
+git show-branch master mybranch > show-branch.output
+test_expect_success 'git show-branch' 'cmp show-branch.expect show-branch.output'
+
+git checkout mybranch
+
+cat > resolve.expect << EOF
+Updating from VARIABLE to VARIABLE.
+ example | 1 +
+ hello | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+EOF
+
+git resolve HEAD master "Merge upstream changes." | \
+ sed -e "1s/[0-9a-f]\{40\}/VARIABLE/g" > resolve.output
+test_expect_success 'git resolve' 'cmp resolve.expect resolve.output'
+
+cat > show-branch2.expect << EOF
+! [master] Merged "mybranch" changes.
+ * [mybranch] Merged "mybranch" changes.
+--
+++ [master] Merged "mybranch" changes.
+EOF
+
+git show-branch master mybranch > show-branch2.output
+test_expect_success 'git show-branch' 'cmp show-branch2.expect show-branch2.output'
+
+# TODO: test git fetch
+
+# TODO: test git push
+
+test_expect_success 'git repack' 'git repack'
+test_expect_success 'git prune-packed' 'git prune-packed'
+test_expect_failure '-> only packed objects' 'find -type f .git/objects/[0-9a-f][0-9a-f]'
+
+test_done
+
^ permalink raw reply related
* Re: [PATCH] Support custom build options in config.mak
From: Johannes Schindelin @ 2005-10-11 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7astr27.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 11 Oct 2005, Junio C Hamano wrote:
> With this patch, you can store the configuration options like
> NO_CURL=YesPlease or NO_OPENSSL=YesPlease into a file named
> Make, and I typically do this:
>
> [...]
:-)
^ permalink raw reply
* Re: [PATCH] Support custom build options in config.mak
From: Junio C Hamano @ 2005-10-11 8:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510110948170.19774@wbgn013.biozentrum.uni-wuerzburg.de>
With this patch, you can store the configuration options like
NO_CURL=YesPlease or NO_OPENSSL=YesPlease into a file named
Make, and I typically do this:
$ ./Make CFLAGS='-O1 -Wal -g' clean test install
My "Make" file looks like this:
$ cat Make
#!/bin/sh
PATH=/usr/bin:/bin
LANG=C
LC_CTYPE=C
export PATH LANG LC_CTYPE
make bindir=$HOME/bin/Linux \
PYTHON_PATH=/usr/bin/python2.4 \
CFLAGS="${CFLAGS-'-O1 -Wall -g'}" \
WITH_SEND_EMAIL=YesPlease "$@"
Nothing-to-sign-off-by: Junio C Hamano <junkio@cox.net>
---
0 files changed.
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this patch, it is possible to store configuration options like
> NO_CURL=YesPlease or NO_OPENSSL=YesPlease into a file named
> config.mak, which will be included in the Makefile.
IOW, I'll have to think about its merit ;-)
^ permalink raw reply
* [PATCH] Support custom build options in config.mak
From: Johannes Schindelin @ 2005-10-11 7:49 UTC (permalink / raw)
To: git, junkio
With this patch, it is possible to store configuration options like
NO_CURL=YesPlease or NO_OPENSSL=YesPlease into a file named
config.mak, which will be included in the Makefile.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
applies-to: 1abfad3540e705eb33e589a8e8cf2be781c89030
94ca33678ce4f582d9bcbaa7baf9223e026c0b13
diff --git a/Makefile b/Makefile
index ea4332b..4e2fa7e 100644
--- a/Makefile
+++ b/Makefile
@@ -213,6 +213,10 @@ ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
+ifneq (,$(wildcard config.mak))
+include config.mak
+endif
+
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not want -R.
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Junio C Hamano @ 2005-10-11 7:37 UTC (permalink / raw)
To: Paul Eggert; +Cc: git
In-Reply-To: <87mzlgh8xa.fsf@penguin.cs.ucla.edu>
Paul Eggert <eggert@CS.UCLA.EDU> writes:
> The convention I had been thinking of adding is to have GNU diff
> use shell-quoting style, e.g.,
>
> 'three
> o'\''clock'
>
> to represent a file name with a newline and an apostrophe in it.
> This sort of file name can be cut and pasted into the shell.
> The quoting could be used with any file name containing a
> troublesome character.
>
> Perhaps another quoting style would be better.
A patch header (both "diff --git" line and ---/+++ lines) I've
been considering, and have in the proposed updates branch, looks
something like this:
diff --git a/def\nghi/pqr b/dee/pqr
similarity index 72%
rename from def\nghi/pqr
rename to dee/pqr
index 9ee055c..243fbbc 100644
--- a/def\nghi/pqr
+++ b/dee/pqr
@@ -1 +1,3 @@
Fri Oct 7 23:19:04 PDT 2005
+foo
+foo
If we can keep things on one line, that would help parsing the
stuff very simple, but more importantly, it is easier to see
what's happening. The pattern is the same whether you have
funny pathnames or not, and that helps the human consumer.
Adjusting the "git diff" output to the style the GNU diff with
your shell quoting style would produce something like this:
diff --git 'a/def
ghi/pqr' b/dee/pqr
similarity index 72%
rename from 'def
ghi/pqr'
rename to dee/pqr
index 9ee055c..243fbbc 100644
--- 'a/def
ghi/pqr'
+++ b/dee/pqr
@@ -1 +1,3 @@
Fri Oct 7 23:19:04 PDT 2005
+foo
+foo
Which, while it is possible to make tools parse them, is very
distracting for humans to read and review. Yes, LF is quoted,
but it still breaks the line, disrupting the pattern we are used
to see. If you are talking about a funny file, whose name is
"a\ndiff --git a/b/c", your diff would look like this:
diff --git 'a/
diff --git a/b/c' 'b/
diff --git a/b/c'
index 9ee055c..243fbbc 100644
--- 'a/
diff --git a/b/c'
+++ 'b/
diff --git a/b/c'
@@ -1 +1,3 @@
Fri Oct 7 23:19:04 PDT 2005
+foo
+foo
We are used to tell the "less" command to do "/^diff --git .*"
while reviewing patches. The shell quoting, while I admit I
learned its beauty from you, is a disaster for human consumption.
For diff output quoting purposes, LF is the only thing that
matters, as you mentioned in another message to me. Our parsing
side ("GNU patch" counterpart) checks two pathnames on "diff
--git" line and makes sure what follows a/ and b/ are consistent
(that is, they should be identical, or each are the same as
"rename from" and "rename to"), so there is no ambiguity. But
again for human consumption purposes, we cannot easily tell SP
and TAB apart by just reading, and a TAB is so unusual character
to have in pathname (as opposed to SP which is not that
uncommon), we may be better off making them visible.
Quoting TAB incidentally has an added benefit, which you as GNU
diff/patch person would probably not care too much about. Our
other tools sometimes need to show two paths in one record, and
TAB is used as the field separator between two paths (LF is the
record separator). The tools do have '-z' mode to let us use
anything but NUL in the pathname, and carefully written scripts
tend to run them with '-z' flag and use Perl or Python to parse
paths out, but it would be nicer if we did not always have to.
For example, the 'git commit' command prepares the log editor
with the status information about changes being committed, and
needs to mention paths. This is purely for human consumption,
and showing something like:
# Type commit message to this file. Lines that start
# with '#' are ignored.
#
# Updated but not checked in:
# (will commit)
#
# new file: ab\n\tc/mno
# modified: abc/mno
# renamed: def\nghi/pqr -> dee/pqr
...
is perfectly readable for human users, and can be done without
running the tool in '-z' mode, if the tool output is quoted with
'\n' and '\t' convention -- the parsing and formatting side can
just split the field with TAB and show them, without worrying
about an embedded LF making the rest of the pathname spilling
over to the next line. And once we start teaching the user we
represent funny characters in their paths this way, it becomes
nicer to be consistent in the diff output as well.
^ permalink raw reply
* Re: [PATCH] Convert usage of GIT and Git into git
From: Christian Meder @ 2005-10-11 5:52 UTC (permalink / raw)
To: James Cloos; +Cc: git
In-Reply-To: <m3ll10iqm9.fsf@lugabout.cloos.reno.nv.us>
On Tue, 2005-10-11 at 01:12 -0400, James Cloos wrote:
> ,----
> | -manager, and you'll thus be happy with almost anything else. Git,
> | +manager, and you'll thus be happy with almost anything else. git,
> `----
>
> An initial majuscule should still be used at the start of a sentence, yes?
Personally I think that 'Git' looks ugly compared to 'git'. But that's
the call of Junio and/or Linus. I'll change the manpages accordingly.
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: [PATCH] Convert usage of GIT and Git into git
From: Adrien Beau @ 2005-10-11 6:27 UTC (permalink / raw)
To: git, James Cloos, Christian Meder
In-Reply-To: <m3ll10iqm9.fsf@lugabout.cloos.reno.nv.us>
On 10/11/05, James Cloos <cloos@jhcloos.com> wrote:
> ,----
> | -manager, and you'll thus be happy with almost anything else. Git,
> | +manager, and you'll thus be happy with almost anything else. git,
> `----
>
> An initial majuscule should still be used at the start of a sentence, yes?
I do think so.
^ permalink raw reply
* Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames
From: Paul Eggert @ 2005-10-11 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Fitzsimons, Alex Riesen, git, Kai Ruemmler
In-Reply-To: <7vu0frpxs1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Although 'GNU patch' has --quoting-style flag, it seems to be
> used only on its output side
Yes, that's right.
The convention I had been thinking of adding is to have GNU diff
use shell-quoting style, e.g.,
'three
o'\''clock'
to represent a file name with a newline and an apostrophe in it.
This sort of file name can be cut and pasted into the shell.
The quoting could be used with any file name containing a
troublesome character.
Perhaps another quoting style would be better.
An issue I hadn't really had time to think about is the character
encoding of file names. E.g., suppose one file system uses UTF-8
encoding for Japanese file names, and another file system uses EUC-JP.
I suppose it would be nice to handle this problem too. Perhaps GNU
'diff' could standardize on using UTF-8 in its file names, regardless
of what the underlying file system uses. Another option is to pass
the bytes of the file name through, no matter what. This might
require a runtime flag to diff, or to patch, or both.
^ permalink raw reply
* Re: [PATCH] git-fetch --tags: deal with tags with spaces in them.
From: Junio C Hamano @ 2005-10-11 6:04 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff (CatalystIT)
In-Reply-To: <7virw4zlod.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "git-fetch --tags" can get confused with tags with spaces in their names,
> it used to use shell IFS to split the list of tags and also used curl
> which insists the URL to be escaped. Fix it so it can work with Martin's
> moodle repository http://locke.catalyst.net.nz/git/moodle.git/.
The one I sent to the list was buggy and broke usual multi-head
fetches, and what I have in the proposed updates branch is a
replacement one.
We cannot still do arbitrary reference names, but at least now
we allow spaces in them. But I am not sure if this is a good
change.
Do we in general want to support references with [^-a-zA-Z0-9.]
in them? Most notably spaces?
The current replacement patch implies that .git/remotes/
short-cut file format now has a slight incompatible change. You
cannot have more than one refspec on single Pull: line. I used
to have:
Pull: master:ko-master +pu:ko-pu maint:ko-maint
but these should now be split into multiple lines, like this:
Pull: master:ko-master
Pull: +pu:ko-pu
Pull: maint:ko-maint
The latter format, one refpair per line, has always been
supported, BTW.
Opinions?
^ permalink raw reply
* Re: [PATCH] Convert usage of GIT and Git into git
From: James Cloos @ 2005-10-11 5:12 UTC (permalink / raw)
To: git; +Cc: Christian Meder
In-Reply-To: <1128979592.7097.38.camel@localhost>
,----
| -manager, and you'll thus be happy with almost anything else. Git,
| +manager, and you'll thus be happy with almost anything else. git,
`----
An initial majuscule should still be used at the start of a sentence, yes?
-JimC
--
James H. Cloos, Jr. <cloos@jhcloos.com>
^ permalink raw reply
* [PATCH] git-fetch --tags: deal with tags with spaces in them.
From: Junio C Hamano @ 2005-10-11 5:07 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git
In-Reply-To: <7vzmpgznfj.fsf_-_@assigned-by-dhcp.cox.net>
"git-fetch --tags" can get confused with tags with spaces in their names,
it used to use shell IFS to split the list of tags and also used curl
which insists the URL to be escaped. Fix it so it can work with Martin's
moodle repository http://locke.catalyst.net.nz/git/moodle.git/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> But in general, we should avoid spaces in reference names.
> Scripts have problem with them. For example, "git-fetch
> --tags" currently cannot handle it. If people cared deeply
> enough maybe they can rewrite parts of it in Perl and send me
> a patch ;-).
And as usual, I end up being "people", but I did not use
Perl ;-). Only lightly tested but it should fetch tags from
your repository. I did not want to keep slurping those 70MB
and 16MB packs, so I cheated by creating a small repository
with funky tag names locally while testing.
git-fetch.sh | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
applies-to: 5db8c58bc7403c7b076dea420133e6e890835e1a
c1a4b1dd71e23d877dfbf04a2ac8b1c238fc5eb4
diff --git a/git-fetch.sh b/git-fetch.sh
index d398866..b3f3782 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,10 @@
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+LF='
+'
+IFS="$LF"
+
tags=
append=
force=
@@ -170,11 +174,14 @@ esac
reflist=$(get_remote_refs_for_fetch "$@")
if test "$tags"
then
- taglist=$(git-ls-remote --tags "$remote" | awk '{ print "."$2":"$2 }')
+ taglist=$(git-ls-remote --tags "$remote" |
+ sed -e '
+ s/^[^ ]* //
+ s/.*/&:&/')
if test "$#" -gt 1
then
# remote URL plus explicit refspecs; we need to merge them.
- reflist="$reflist $taglist"
+ reflist="$reflist$LF$taglist"
else
# No explicit refspecs; fetch tags only.
reflist=$taglist
@@ -183,7 +190,7 @@ fi
for ref in $reflist
do
- refs="$refs $ref"
+ refs="$refs$LF$ref"
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
@@ -204,7 +211,7 @@ do
remote_name=$(expr "$ref" : '\([^:]*\):')
local_name=$(expr "$ref" : '[^:]*:\(.*\)')
- rref="$rref $remote_name"
+ rref="$rref$LF$remote_name"
# There are transports that can fetch only one head at a time...
case "$remote" in
@@ -212,11 +219,9 @@ do
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
- head=$(curl -nsf $curl_extra_args "$remote/$remote_name") &&
- expr "$head" : "$_x40\$" >/dev/null ||
- die "Failed to fetch $remote_name from $remote"
echo >&2 Fetching "$remote_name from $remote" using http
- git-http-fetch -v -a "$head" "$remote/" || exit
+ ref_name=`expr "$remote_name" : 'refs/\(.*\)'`
+ git-http-fetch -v -a "$ref_name" "$remote/" || exit
;;
rsync://*)
TMP_HEAD="$GIT_DIR/TMP_HEAD"
---
0.99.8.GIT
^ permalink raw reply related
* Quote reference names while fetching with curl.
From: Junio C Hamano @ 2005-10-11 4:29 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git
In-Reply-To: <7v4q7p927d.fsf@assigned-by-dhcp.cox.net>
curl_escape ought to do this, but we should not let it quote slashes
(nobody said refs/tags can have subdirectories), so we roll our own
safer version. With this, the last part of git-clone that used to fail
now works, which reads:
$ git-http-fetch -v -a -w 'tags/MOODLE_15_MERGED **INVALID**' \
'tags/MOODLE_15_MERGED **INVALID**' \
http://locke.catalyst.net.nz/git/moodle.git/
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> I do not speak curl, but I wonder if we should be quoting
> these funky characters like SP and asterisk in the URL when we
> make that request, or it is what the library does for us.
>
> Hmph. Interesting. I just tried.
>
> $ curl 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
>
> gives an error page "404 Not Found", while
>
> $ wget -O - -o /dev/null 'http://locke.catalyst.net.nz/git/moodle.git/refs/tags/MOODLE_15_MERGED **INVALID**'
>
> works fine and gives 2ddfec0dfd0cffd4892af9aaf48ee29c40c7ada3
> back. So we do need to fix things up somewhat in our scripts as
> well.
>
> Anyway, I think I know the problems 'git-clone' would have had
> if you tried to clone it with it (not cg-clone which I do not
> know much about), and luckily it is only towards the end (after
> fetching most of the heads, but hitting the first funky tag).
> We should be able to fix this relatively easily.
With this patch on top of the parallel transfer http-fetch in
proposed updates branch, git-clone successfully cloned your
repository.
But in general, we should avoid spaces in reference names.
Scripts have problem with them. For example, "git-fetch
--tags" currently cannot handle it. If people cared deeply
enough maybe they can rewrite parts of it in Perl and send me
a patch ;-).
Anyway, I _do_ care about the really core part (i.e. things
written in C, roughly speaking), so this patch will likely
make into "master" branch.
http-fetch.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 49 insertions(+), 8 deletions(-)
applies-to: 4ac37eb1d8cf308455b69828c5df8f64634b5789
1d32c9c017af915a390693021938ae8c56f33007
diff --git a/http-fetch.c b/http-fetch.c
index e537591..acae805 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -969,9 +969,56 @@ int fetch(unsigned char *sha1)
alt->base);
}
+static inline int needs_quote(int ch)
+{
+ switch (ch) {
+ case '/': case '-':
+ case 'A'...'Z':
+ case 'a'...'z':
+ case '0'...'9':
+ return 0;
+ default:
+ return 1;
+ }
+}
+
+static inline int hex(int v)
+{
+ if (v < 10) return '0' + v;
+ else return 'A' + v - 10;
+}
+
+static char *quote_ref_url(const char *base, const char *ref)
+{
+ const char *cp;
+ char *dp, *qref;
+ int len, baselen, ch;
+
+ baselen = strlen(base);
+ len = baselen + 6; /* "refs/" + NUL */
+ for (cp = ref; (ch = *cp) != 0; cp++, len++)
+ if (needs_quote(ch))
+ len += 2; /* extra two hex plus replacement % */
+ qref = xmalloc(len);
+ memcpy(qref, base, baselen);
+ memcpy(qref + baselen, "refs/", 5);
+ for (cp = ref, dp = qref + baselen + 5; (ch = *cp) != 0; cp++) {
+ if (needs_quote(ch)) {
+ *dp++ = '%';
+ *dp++ = hex((ch >> 4) & 0xF);
+ *dp++ = hex(ch & 0xF);
+ }
+ else
+ *dp++ = ch;
+ }
+ *dp = 0;
+
+ return qref;
+}
+
int fetch_ref(char *ref, unsigned char *sha1)
{
- char *url, *posn;
+ char *url;
char hex[42];
struct buffer buffer;
char *base = alt->base;
@@ -981,13 +1028,7 @@ int fetch_ref(char *ref, unsigned char *
buffer.buffer = hex;
hex[41] = '\0';
- url = xmalloc(strlen(base) + 6 + strlen(ref));
- strcpy(url, base);
- posn = url + strlen(base);
- strcpy(posn, "refs/");
- posn += 5;
- strcpy(posn, ref);
-
+ url = quote_ref_url(base, ref);
slot = get_active_slot();
curl_easy_setopt(slot->curl, CURLOPT_FILE, &buffer);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] cg-tag - add support for longer commit messages
From: Martin Langhoff @ 2005-10-11 2:45 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Added an -m switch that points to a filename which contains a (potentially
long) tag message.
Bugs: Could alternatively be implemented via STDIN.
---
cg-tag | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
c9ed29a0eb1529a47af75a4193375edf9e892fdb
diff --git a/cg-tag b/cg-tag
--- a/cg-tag
+++ b/cg-tag
@@ -23,7 +23,7 @@
# This is most usually the ID of the commit to tag. Tagging
# other objects than commits is possible, but rather "unusual".
-USAGE="cg-tag [-d DESCRIPTION] [-s [-k KEYNAME]] TAG_NAME [OBJECT_ID]"
+USAGE="cg-tag [-d DESCRIPTION] [-m MSGFILE ] [-s [-k KEYNAME]] TAG_NAME [OBJECT_ID]"
. ${COGITO_LIB}cg-Xlib || exit 1
@@ -37,6 +37,8 @@ while optparse; do
keyname="$OPTARG"
elif optparse -d=; then
description="$OPTARG"
+ elif optparse -m=; then
+ msgfile="$OPTARG"
else
optfail
fi
@@ -72,6 +74,13 @@ if [ "$description" ]; then
echo >>"$tagdir/tag"
echo "$description" >>"$tagdir/tag"
fi
+if [ "$msgfile" ]; then
+ if [ ! -r $msgfile ]; then
+ rm -rf "$tagdir"
+ die "error signing the tag: cannot read $msgfile"
+ fi
+ cat $msgfile >>"$tagdir/tag"
+fi
if [ "$sign" ]; then
echo >>"$tagdir/tag"
if ! gpg ${keyname:+--default-key "$keyname"} -bsa "$tagdir/tag"; then
^ permalink raw reply
* GIT 0.99.8c
From: Junio C Hamano @ 2005-10-11 0:38 UTC (permalink / raw)
To: git
Among some cosmetic fixes, contains one important fix by Robert
Fitzsimmons to unconfuse git-ls-tree. When two identical blobs
or trees were contained in a tree, the earlier code mislabeled
them in the output.
^ permalink raw reply
* [PATCH] Remove empty directories after read-tree -u.
From: Junio C Hamano @ 2005-10-11 0:35 UTC (permalink / raw)
To: git
This fixes everybody's favorite gripe that switching branche with
'git checkout' leaves empty directories.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
read-tree.c | 31 ++++++++++++++++++++++++++++++-
1 files changed, 30 insertions(+), 1 deletions(-)
applies-to: 0c8b9e1023f9c5fbaaa7151bcc105783b98c9f10
340e4f88c083b0692e6554b1c2c27fd43c7cc8d3
diff --git a/read-tree.c b/read-tree.c
index 5fdf58d..6a456ae 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -237,6 +237,35 @@ static void reject_merge(struct cache_en
ce->name);
}
+/* Unlink the last component and attempt to remove leading
+ * directories, in case this unlink is the removal of the
+ * last entry in the directory -- empty directories are removed.
+ */
+static void unlink_entry(char *name)
+{
+ char *cp, *prev;
+
+ if (unlink(name))
+ return;
+ prev = NULL;
+ while (1) {
+ int status;
+ cp = strrchr(name, '/');
+ if (prev)
+ *prev = '/';
+ if (!cp)
+ break;
+
+ *cp = 0;
+ status = rmdir(name);
+ if (status) {
+ *cp = '/';
+ break;
+ }
+ prev = cp;
+ }
+}
+
static void check_updates(struct cache_entry **src, int nr)
{
static struct checkout state = {
@@ -250,7 +279,7 @@ static void check_updates(struct cache_e
struct cache_entry *ce = *src++;
if (!ce->ce_mode) {
if (update)
- unlink(ce->name);
+ unlink_entry(ce->name);
continue;
}
if (ce->ce_flags & mask) {
---
0.99.8.GIT
^ permalink raw reply related
* Re: Add ".git/config" file parser
From: Linus Torvalds @ 2005-10-10 22:12 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <434AE209.60605@zytor.com>
On Mon, 10 Oct 2005, H. Peter Anvin wrote:
>
> A suggestion: if you make your basic types (integer, string, boolean)
> recognizable by the parser, you can present them in that way. This pretty
> much means strings will have to always be double-quoted, but that avoids a
> bunch of ambiguities.
Well, the parser is already pretty unambiguous, purely by virtue of being
stupid as hell.
In particular, the only thing quoting does is to actually make whitespace
meaningful, and as a way to allow comments inside strings (otherwise a "#"
or ";" is always a "comment starts here" marker).
Outside of quotes, any whitespace will just collapse to a single space
(and be removed from beginning and end).
And quite frankly, always keeping the things as strings just makes things
so much easier and the interfaces very simple. And if/when you want to
turn the string into a boolean or a regular integer, there are two helper
functions that do exactly that, so it's not very hard.
I considered using some "smart" parser (ie using something like
flex/bison), but the thing is, I didn't want smart. I personally think
it's a lot more important for the file format to be _nice_, and there I
think it's fine if
[diff]
external=/usr/local/bin/gnu-diff
doesn't need quotes, even if it's obviously a string. Simplicity is a
virtue (both in parsing and in the "language" parsed).
In fact, even the example I had - with a space and an argument - doesn't
need quotes (since the single space will be collapsed to a single space),
I just put that as an example.
Side note: the design is meant to allow different programs to share the
same config file without having to know about each others config
variables. Anything they don't recognize is just ignored. The downside is
that if you mistype an option name, nobody will recognize it, and nobody
will complain either.
That was one of the reasons for the "scoping". It not only allows grouping
of variables, but it means that the "git-diff-xyz" family of programs
might decide that they'll report anything that starts with "diff." but
that they don't understand as a warning (but preferably not error, since
it might be a newer option that an older version of git just doesn't
understand).
Linus
^ permalink raw reply
* Re: Add ".git/config" file parser
From: H. Peter Anvin @ 2005-10-10 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510101446180.14597@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 10 Oct 2005, Linus Torvalds wrote:
>
>> ; core variables
>> [core]
>> ; Don't trust file modes
>> filemode = false
>>
>> ; Our diff algorithm
>> [diff]
>> external = "/usr/local/bin/gnu-diff -u"
>> renames = true
>>
>>which parses into two variables: "core.filemode" is associated with the
>>string "false", and "diff.external" gets the appropriate quoted value.
>
> _Three_ variables. Duh. I added the "renames" thing later, as I was
> looking at what kinds of default flags the "git-diff-xyz" family might be
> interested in having.
>
A suggestion: if you make your basic types (integer, string, boolean)
recognizable by the parser, you can present them in that way. This
pretty much means strings will have to always be double-quoted, but that
avoids a bunch of ambiguities.
-hpa
^ permalink raw reply
* Re: Add ".git/config" file parser
From: Linus Torvalds @ 2005-10-10 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510101415080.14597@g5.osdl.org>
On Mon, 10 Oct 2005, Linus Torvalds wrote:
>
> ; core variables
> [core]
> ; Don't trust file modes
> filemode = false
>
> ; Our diff algorithm
> [diff]
> external = "/usr/local/bin/gnu-diff -u"
> renames = true
>
> which parses into two variables: "core.filemode" is associated with the
> string "false", and "diff.external" gets the appropriate quoted value.
_Three_ variables. Duh. I added the "renames" thing later, as I was
looking at what kinds of default flags the "git-diff-xyz" family might be
interested in having.
Linus
^ permalink raw reply
* Re: openbsd version?
From: Junio C Hamano @ 2005-10-10 21:42 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git, Randal L. Schwartz
In-Reply-To: <20051010210007.GJ8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> I think you mean
>
> $ git-update-ref refs/heads/mybranch mybranch^
Of course you are right. Thanks.
^ permalink raw reply
* Add ".git/config" file parser
From: Linus Torvalds @ 2005-10-10 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510101120410.14597@g5.osdl.org>
This is a first cut at a very simple parser for a git config file.
The format of the file is a simple ini-file like thing, with simple
variable/value pairs. You can (and should) make the variables have a
simple single-level scope, ie a valid file looks something like this:
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
; Don't trust file modes
filemode = false
; Our diff algorithm
[diff]
external = "/usr/local/bin/gnu-diff -u"
renames = true
which parses into two variables: "core.filemode" is associated with the
string "false", and "diff.external" gets the appropriate quoted value.
Right now we only react to one variable: "core.filemode" is a boolean that
decides if we should care about the 0100 (user-execute) bit of the stat
information. Even that is just a parsing demonstration - this doesn't
actually implement that st_mode compare logic itself.
Different programs can react to different config options, although they
should always fall back to calling "git_default_config()" on any config
option name that they don't recognize.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
Ok, so it's stupid. But quite frankly, I think the Windows ini-file format
is a hell of a lot more readable than something over-engineered like XML
files or other crap.
The interface is really easy to use, imho. You can do things like
static int enable_renames = 0;
static int my_options(const char *var, const char *value)
{
if (!strcmp("diff.renames", var)) {
enable_renames = git_config_bool(var, value);
return 0;
}
/*
* Put other local option parsing for this program
* here ..
*/
/* Fall back on the default ones */
return git_default_config(var, value);
}
and then in the "main()" routine you just do
git_config(my_options);
at the top (or, more precisely, just after the "git_setup_directory()" if
you have one).
And as usual, it's not like this has gotten a whole lot of testing.
Flames, comments, whatever? The code is actually written so that the
config file parsing should really be pretty neutral. It doesn't even have
any git-specific in it, except for the naming and the actual initial
"fopen()" pathname used, I think.
---
diff --git a/Makefile b/Makefile
index a201187..e8b46f1 100644
--- a/Makefile
+++ b/Makefile
@@ -158,7 +158,7 @@ LIB_OBJS = \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
- tag.o tree.o usage.o $(DIFF_OBJS)
+ tag.o tree.o usage.o config.o $(DIFF_OBJS)
LIBS = $(LIB_FILE)
LIBS += -lz
diff --git a/cache.h b/cache.h
index 5987d4c..0571282 100644
--- a/cache.h
+++ b/cache.h
@@ -178,6 +178,8 @@ extern int hold_index_file_for_update(st
extern int commit_index_file(struct cache_file *);
extern void rollback_index_file(struct cache_file *);
+extern int trust_executable_bit;
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
@@ -372,4 +374,10 @@ extern int gitfakemunmap(void *start, si
#endif
+typedef int (*config_fn_t)(const char *, const char *);
+extern int git_default_config(const char *, const char *);
+extern int git_config(config_fn_t fn);
+extern int git_config_int(const char *, const char *);
+extern int git_config_bool(const char *, const char *);
+
#endif /* CACHE_H */
diff --git a/config.c b/config.c
new file mode 100644
index 0000000..f3c4fa4
--- /dev/null
+++ b/config.c
@@ -0,0 +1,222 @@
+#include <ctype.h>
+
+#include "cache.h"
+
+#define MAXNAME (256)
+
+static FILE *config_file;
+static int config_linenr;
+static int get_next_char(void)
+{
+ int c;
+ FILE *f;
+
+ c = '\n';
+ if ((f = config_file) != NULL) {
+ c = fgetc(f);
+ if (c == '\n')
+ config_linenr++;
+ if (c == EOF) {
+ config_file = NULL;
+ c = '\n';
+ }
+ }
+ return c;
+}
+
+static char *parse_value(void)
+{
+ static char value[1024];
+ int quote = 0, comment = 0, len = 0, space = 0;
+
+ for (;;) {
+ int c = get_next_char();
+ if (len >= sizeof(value))
+ return NULL;
+ if (c == '\n') {
+ if (quote)
+ return NULL;
+ value[len] = 0;
+ return value;
+ }
+ if (comment)
+ continue;
+ if (isspace(c) && !quote) {
+ space = 1;
+ continue;
+ }
+ if (space) {
+ if (len)
+ value[len++] = ' ';
+ space = 0;
+ }
+ if (c == '\\') {
+ c = get_next_char();
+ switch (c) {
+ case '\n':
+ continue;
+ case 't':
+ c = '\t';
+ break;
+ case 'b':
+ c = '\b';
+ break;
+ case 'n':
+ c = '\n';
+ break;
+ return NULL;
+ }
+ value[len++] = c;
+ continue;
+ }
+ if (c == '"') {
+ quote = 1-quote;
+ continue;
+ }
+ if (!quote) {
+ if (c == ';' || c == '#') {
+ comment = 1;
+ continue;
+ }
+ }
+ value[len++] = c;
+ }
+}
+
+static int get_value(config_fn_t fn, char *name, unsigned int len)
+{
+ int c;
+ char *value;
+
+ /* Get the full name */
+ for (;;) {
+ c = get_next_char();
+ if (c == EOF)
+ break;
+ if (!isalnum(c))
+ break;
+ name[len++] = tolower(c);
+ if (len >= MAXNAME)
+ return -1;
+ }
+ name[len] = 0;
+ while (c == ' ' || c == '\t')
+ c = get_next_char();
+
+ value = NULL;
+ if (c != '\n') {
+ if (c != '=')
+ return -1;
+ value = parse_value();
+ if (!value)
+ return -1;
+ }
+ return fn(name, value);
+}
+
+static int get_base_var(char *name)
+{
+ int baselen = 0;
+
+ for (;;) {
+ int c = get_next_char();
+ if (c == EOF)
+ return -1;
+ if (c == ']')
+ return baselen;
+ if (!isalnum(c))
+ return -1;
+ if (baselen > MAXNAME / 2)
+ return -1;
+ name[baselen++] = tolower(c);
+ }
+}
+
+static int git_parse_file(config_fn_t fn)
+{
+ int comment = 0;
+ int baselen = 0;
+ static char var[MAXNAME];
+
+ for (;;) {
+ int c = get_next_char();
+ if (c == '\n') {
+ /* EOF? */
+ if (!config_file)
+ return 0;
+ comment = 0;
+ continue;
+ }
+ if (comment || isspace(c))
+ continue;
+ if (c == '#' || c == ';') {
+ comment = 1;
+ continue;
+ }
+ if (c == '[') {
+ baselen = get_base_var(var);
+ if (baselen <= 0)
+ break;
+ var[baselen++] = '.';
+ var[baselen] = 0;
+ continue;
+ }
+ if (!isalpha(c))
+ break;
+ var[baselen] = c;
+ if (get_value(fn, var, baselen+1) < 0)
+ break;
+ }
+ die("bad config file line %d", config_linenr);
+}
+
+int git_config_int(const char *name, const char *value)
+{
+ if (value && *value) {
+ char *end;
+ int val = strtol(value, &end, 0);
+ if (!*end)
+ return val;
+ }
+ die("bad config value for '%s'", name);
+}
+
+int git_config_bool(const char *name, const char *value)
+{
+ if (!value)
+ return 1;
+ if (!*value)
+ return 0;
+ if (!strcasecmp(value, "true"))
+ return 1;
+ if (!strcasecmp(value, "false"))
+ return 0;
+ return git_config_int(name, value) != 0;
+}
+
+int git_default_config(const char *var, const char *value)
+{
+ /* This needs a better name */
+ if (!strcmp(var, "core.filemode")) {
+ trust_executable_bit = git_config_bool(var, value);
+ return 0;
+ }
+
+ /* Add other config variables here.. */
+ return 0;
+}
+
+int git_config(config_fn_t fn)
+{
+ int ret;
+ FILE *f = fopen(git_path("config"), "r");
+
+ ret = -1;
+ if (f) {
+ config_file = f;
+ config_linenr = 1;
+ ret = git_parse_file(fn);
+ fclose(f);
+ }
+ return ret;
+}
diff --git a/diff-files.c b/diff-files.c
index 5e59832..96d2c7f 100644
--- a/diff-files.c
+++ b/diff-files.c
@@ -38,6 +38,7 @@ int main(int argc, const char **argv)
const char *prefix = setup_git_directory();
int entries, i;
+ git_config(git_default_config);
diff_setup(&diff_options);
while (1 < argc && argv[1][0] == '-') {
if (!strcmp(argv[1], "-q"))
diff --git a/diff-tree.c b/diff-tree.c
index b2d74eb..2203fa5 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -408,6 +408,7 @@ int main(int argc, const char **argv)
unsigned char sha1[2][20];
const char *prefix = setup_git_directory();
+ git_config(git_default_config);
nr_sha1 = 0;
diff_setup(&diff_options);
diff --git a/read-cache.c b/read-cache.c
index d2aebdd..c7f3b26 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -5,6 +5,7 @@
*/
#include "cache.h"
+int trust_executable_bit = 1;
struct cache_entry **active_cache = NULL;
unsigned int active_nr = 0, active_alloc = 0, active_cache_changed = 0;
^ permalink raw reply related
* Re: openbsd version?
From: Junio C Hamano @ 2005-10-10 21:31 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86ek6tcdou.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> <sarcasm>Undocumented secret switches. Nice.</sarcasm> No wonder
> I couldn't find it.
Sorry. This is taken from the log message from the commit that
introduced the switch.
git-branch -d <branch>: delete unused branch.
The new flag '-d' lets you delete a branch. For safety, it does not
lets you delete the branch you are currently on, nor a branch that
has been fully merged into your current branch.
The credit for the safety check idea goes to Daniel Barkalow.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There should be a document in Documentation/howto/ to describe
how to find the commit that introduced a particular feature.
What I did to find the above is this:
1. Look at git-branch.sh and notice that there is this line:
echo >&2 "usage: $(basename $0)"' [-d <branch>] | [<branch> [start-point]]
Make an educated guess that this line, especially the
"[-d <branch>]" part, must have changed when the feature was
added (that is, pre-modification file would not have had "[-d
<branch>]" in it, but post-modification file would).
2. Find such a change with pickaxe (-S):
$ git whatchanged -S'[-d <branch>]' git-branch.sh
By mentioning this, I do not mean to say that you could have
figuired this out yourself -- the above sequence is useful for
somebody who knows the code already to do archaeology; IOW you
still need to know what to look for, so the above procedure
would not have helped at all even if you knew about pickaxe.
> Do these also flush any related object files? Or do I need git-fsck still?
The latter. I think there should be a general description in
the tutorial to advice the user to run git-fsck-objects every
once in a while, while mentioning that there is no need to do it
too often -- disk space is cheap and the time you spend waiting
for fsck-objects to finish tends to be more expensive.
^ permalink raw reply
* [PATCH] The synopsis of the manpages should use the hyphenated version
From: Christian Meder @ 2005-10-10 21:27 UTC (permalink / raw)
To: git
The synopsis of the manpages should use the hyphenated version of the git
commands. Adapt the remaining offenders.
Signed-off-by: Christian Meder <chris@absolutegiganten.org>
---
Documentation/git-clone.txt | 2 +-
Documentation/git-commit.txt | 2 +-
Documentation/git-log.txt | 2 +-
Documentation/git-resolve.txt | 2 +-
Documentation/git-shortlog.txt | 2 +-
Documentation/git-show-branch.txt | 2 +-
Documentation/git-status.txt | 2 +-
Documentation/git-whatchanged.txt | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
77acd127869d3d2dbab69b85c6cf2e501af8d13f
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -8,7 +8,7 @@ git-clone - Clones a repository.
SYNOPSIS
--------
-'git clone' [-l [-s]] [-q] [-n] [-u <upload-pack>] <repository> <directory>
+'git-clone' [-l [-s]] [-q] [-n] [-u <upload-pack>] <repository> <directory>
DESCRIPTION
-----------
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -7,7 +7,7 @@ git-commit - Record your changes
SYNOPSIS
--------
-'git commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] [-e] <file>...
+'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>] [-e] <file>...
DESCRIPTION
-----------
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -8,7 +8,7 @@ git-log - Show commit logs
SYNOPSIS
--------
-'git log' <option>...
+'git-log' <option>...
DESCRIPTION
-----------
diff --git a/Documentation/git-resolve.txt b/Documentation/git-resolve.txt
--- a/Documentation/git-resolve.txt
+++ b/Documentation/git-resolve.txt
@@ -8,7 +8,7 @@ git-resolve - Merge two commits
SYNOPSIS
--------
-'git resolve' <current> <merged> <message>
+'git-resolve' <current> <merged> <message>
DESCRIPTION
-----------
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -8,7 +8,7 @@ git-shortlog - Summarize 'git log' outpu
SYNOPSIS
--------
-'git log --pretty=short | git shortlog'
+'git-log --pretty=short | git shortlog'
DESCRIPTION
-----------
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -7,7 +7,7 @@ git-show-branch - Show branches and thei
SYNOPSIS
--------
-'git show-branch [--all] [--heads] [--tags] [--more=<n> | --list | --independent | --merge-base] <reference>...'
+'git-show-branch [--all] [--heads] [--tags] [--more=<n> | --list | --independent | --merge-base] <reference>...'
DESCRIPTION
-----------
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -8,7 +8,7 @@ git-status - Show working tree status.
SYNOPSIS
--------
-'git status'
+'git-status'
DESCRIPTION
-----------
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -8,7 +8,7 @@ git-whatchanged - Show logs with differe
SYNOPSIS
--------
-'git whatchanged' <option>...
+'git-whatchanged' <option>...
DESCRIPTION
-----------
^ permalink raw reply
* [PATCH] Convert usage of GIT and Git into git
From: Christian Meder @ 2005-10-10 21:26 UTC (permalink / raw)
To: git
Convert usage of GIT and Git into git.
Signed-off-by: Christian Meder <chris@absolutegiganten.org>
---
Documentation/cvs-migration.txt | 14 +++++++-------
Documentation/diff-format.txt | 2 +-
Documentation/diffcore.txt | 2 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 8 ++++----
Documentation/git-clone-pack.txt | 2 +-
Documentation/git-convert-objects.txt | 4 ++--
Documentation/git-cvsimport.txt | 4 ++--
Documentation/git-daemon.txt | 2 +-
Documentation/git-fetch-pack.txt | 2 +-
Documentation/git-fsck-objects.txt | 10 +++++-----
Documentation/git-http-fetch.txt | 4 ++--
Documentation/git-local-fetch.txt | 4 ++--
Documentation/git-pack-objects.txt | 2 +-
Documentation/git-peek-remote.txt | 2 +-
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-verify-pack.txt | 4 ++--
Documentation/git.txt | 10 +++++-----
Documentation/glossary.txt | 2 +-
Documentation/hooks.txt | 2 +-
Documentation/pull-fetch-param.txt | 2 +-
Documentation/repository-layout.txt | 4 ++--
Documentation/tutorial.txt | 18 +++++++++---------
24 files changed, 55 insertions(+), 55 deletions(-)
2cfc19a4c9c2d66b642b0968df917938d182fd20
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -1,4 +1,4 @@
-Git for CVS users
+git for CVS users
=================
Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
@@ -7,7 +7,7 @@ you are reading this file means that you
already.
The thing about CVS is that it absolutely sucks as a source control
-manager, and you'll thus be happy with almost anything else. Git,
+manager, and you'll thus be happy with almost anything else. git,
however, may be a bit 'too' different (read: "good") for your taste, and
does a lot of things differently.
@@ -15,7 +15,7 @@ One particular suckage of CVS is very ha
basically a tool for tracking 'file' history, while git is a tool for
tracking 'project' history. This sometimes causes problems if you are
used to doing very strange things in CVS, in particular if you're doing
-things like making branches of just a subset of the project. Git can't
+things like making branches of just a subset of the project. git can't
track that, since git never tracks things on the level of an individual
file, only on the whole project level.
@@ -32,7 +32,7 @@ and notes on converting from CVS to git.
Second: CVS has the notion of a "repository" as opposed to the thing
that you're actually working in (your working directory, or your
-"checked out tree"). Git does not have that notion at all, and all git
+"checked out tree"). git does not have that notion at all, and all git
working directories 'are' the repositories. However, you can easily
emulate the CVS model by having one special "global repository", which
people can synchronize with. See details later, but in the meantime
@@ -49,7 +49,7 @@ gone through the git tutorial, and gener
how to commit stuff etc in git) is to create a git'ified version of your
CVS archive.
-Happily, that's very easy indeed. Git will do it for you, although git
+Happily, that's very easy indeed. git will do it for you, although git
will need the help of a program called "cvsps":
http://www.cobite.com/cvsps/
@@ -135,7 +135,7 @@ technically possible, and there are at l
there that can be used to get equivalent information (see the git
mailing list archives for details).
-Git has a couple of alternatives, though, that you may find sufficient
+git has a couple of alternatives, though, that you may find sufficient
or even superior depending on your use. One is called "git-whatchanged"
(for obvious reasons) and the other one is called "pickaxe" ("a tool for
the software archeologist").
@@ -208,7 +208,7 @@ show anything for commits that do not to
Also, in the original context, the same statement might have
appeared at first in a different file and later the file was
renamed to "a-file.c". CVS annotate would not help you to go
-back across such a rename, but GIT would still help you in such
+back across such a rename, but git would still help you in such
a situation. For that, you can give the -C flag to
git-diff-tree, like this:
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -106,7 +106,7 @@ For a path that is unmerged, 'GIT_EXTERN
parameter, <path>.
-Git specific extension to diff format
+git specific extension to diff format
-------------------------------------
What -p option produces is slightly different from the
diff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt
--- a/Documentation/diffcore.txt
+++ b/Documentation/diffcore.txt
@@ -250,7 +250,7 @@ pattern. Filepairs that match a glob pa
in the file are output before ones that match a later line, and
filepairs that do not match any glob pattern are output last.
-As an example, typical orderfile for the core GIT probably
+As an example, typical orderfile for the core git probably
would look like this:
------------------------------------------------
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -3,7 +3,7 @@ git-apply(1)
NAME
----
-git-apply - Apply patch on a GIT index file and a work tree
+git-apply - Apply patch on a git index file and a work tree
SYNOPSIS
diff --git a/Documentation/git-archimport.txt b/Documentation/git-archimport.txt
--- a/Documentation/git-archimport.txt
+++ b/Documentation/git-archimport.txt
@@ -3,7 +3,7 @@ git-archimport(1)
NAME
----
-git-archimport - Import an Arch repository into GIT
+git-archimport - Import an Arch repository into git
SYNOPSIS
@@ -40,14 +40,14 @@ incremental imports.
MERGES
------
-Patch merge data from Arch is used to mark merges in GIT as well. GIT
+Patch merge data from Arch is used to mark merges in git as well. git
does not care much about tracking patches, and only considers a merge when a
branch incorporates all the commits since the point they forked. The end result
-is that GIT will have a good idea of how far branches have diverged. So the
+is that git will have a good idea of how far branches have diverged. So the
import process does lose some patch-trading metadata.
Fortunately, when you try and merge branches imported from Arch,
-GIT will find a good merge base, and it has a good chance of identifying
+git will find a good merge base, and it has a good chance of identifying
patches that have been traded out-of-sequence between the branches.
OPTIONS
diff --git a/Documentation/git-clone-pack.txt b/Documentation/git-clone-pack.txt
--- a/Documentation/git-clone-pack.txt
+++ b/Documentation/git-clone-pack.txt
@@ -28,7 +28,7 @@ OPTIONS
remote side, if it is not found on your $PATH.
Installations of sshd ignore 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
+ 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
diff --git a/Documentation/git-convert-objects.txt b/Documentation/git-convert-objects.txt
--- a/Documentation/git-convert-objects.txt
+++ b/Documentation/git-convert-objects.txt
@@ -3,7 +3,7 @@ git-convert-objects(1)
NAME
----
-git-convert-objects - Converts old-style GIT repository
+git-convert-objects - Converts old-style git repository
SYNOPSIS
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Converts old-style GIT repository to the latest format
+Converts old-style git repository to the latest format
Author
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
'git-cvsimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ]
[ -d <CVSROOT> ] [ -p <options-for-cvsps> ]
- [ -C <GIT_repository> ] [ -i ] [ -k ]
+ [ -C <git_repository> ] [ -i ] [ -k ]
[ -s <subst> ] [ -m ] [ -M regex ] [ <CVS_module> ]
@@ -30,7 +30,7 @@ OPTIONS
are supported.
-C <target-dir>::
- The GIT repository to import to. If the directory doesn't
+ The git repository to import to. If the directory doesn't
exist, it will be created. Default is the current directory.
-i::
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -3,7 +3,7 @@ git-daemon(1)
NAME
----
-git-daemon - A really simple server for GIT repositories.
+git-daemon - A really simple server for git repositories.
SYNOPSIS
--------
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -34,7 +34,7 @@ OPTIONS
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
+ 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
diff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt
--- a/Documentation/git-fsck-objects.txt
+++ b/Documentation/git-fsck-objects.txt
@@ -41,22 +41,22 @@ index file and all SHA1 references in .g
($GIT_DIR/objects), making sure that it is consistent and
complete without referring to objects found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
- nor packed GIT archives found in $GIT_DIR/objects/pack;
+ nor packed git archives found in $GIT_DIR/objects/pack;
cannot be used with --full.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
- and in packed GIT archives found in $GIT_DIR/objects/pack
+ and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools; cannot be used with --standalone.
--strict::
Enable more strict checking, namely to catch a file mode
recorded with g+w bit set, which was created by older
- versions of GIT. Existing repositories, including the
- Linux kernel, GIT itself, and sparse repository have old
+ versions of git. Existing repositories, including the
+ Linux kernel, git itself, and sparse repository have old
objects that triggers this check, but it is recommended
to check new projects with this flag.
@@ -80,7 +80,7 @@ Any corrupt objects you will have to fin
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
-evil person, and the end result might be crap. Git is a revision
+evil person, and the end result might be crap. git is a revision
tracking system, not a quality assurance system ;)
Extracted Diagnostics
diff --git a/Documentation/git-http-fetch.txt b/Documentation/git-http-fetch.txt
--- a/Documentation/git-http-fetch.txt
+++ b/Documentation/git-http-fetch.txt
@@ -3,7 +3,7 @@ git-http-fetch(1)
NAME
----
-git-http-fetch - Downloads a remote GIT repository via HTTP
+git-http-fetch - Downloads a remote git repository via HTTP
SYNOPSIS
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Downloads a remote GIT repository via HTTP.
+Downloads a remote git repository via HTTP.
-c::
Get the commit objects.
diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
--- a/Documentation/git-local-fetch.txt
+++ b/Documentation/git-local-fetch.txt
@@ -3,7 +3,7 @@ git-local-fetch(1)
NAME
----
-git-local-fetch - Duplicates another GIT repository on a local system
+git-local-fetch - Duplicates another git repository on a local system
SYNOPSIS
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Duplicates another GIT repository on a local system.
+Duplicates another git repository on a local system.
OPTIONS
-------
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -30,7 +30,7 @@ transport by their peers.
Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
-enables GIT to read from such an archive.
+enables git to read from such an archive.
OPTIONS
diff --git a/Documentation/git-peek-remote.txt b/Documentation/git-peek-remote.txt
--- a/Documentation/git-peek-remote.txt
+++ b/Documentation/git-peek-remote.txt
@@ -22,7 +22,7 @@ OPTIONS
remote side, if it is not found on your $PATH. Some
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
+ 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
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -91,7 +91,7 @@ what is called an 'extended SHA1' syntax
* A symbolic ref name. E.g. 'master' typically means the commit
object referenced by $GIT_DIR/refs/heads/master. If you
happen to have both heads/master and tags/master, you can
- explicitly say 'heads/master' to tell GIT which one you mean.
+ explicitly say 'heads/master' to tell git which one you mean.
* A suffix '^' to a revision parameter means the first parent of
that commit object. '^<n>' means the <n>th parent (i.e.
diff --git a/Documentation/git-show-index.txt b/Documentation/git-show-index.txt
--- a/Documentation/git-show-index.txt
+++ b/Documentation/git-show-index.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reads given idx file for packed GIT archive created with
+Reads given idx file for packed git archive created with
git-pack-objects command, and dumps its contents.
The information it outputs is subset of what you can get from
diff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt
--- a/Documentation/git-verify-pack.txt
+++ b/Documentation/git-verify-pack.txt
@@ -3,7 +3,7 @@ git-verify-pack(1)
NAME
----
-git-verify-pack - Validate packed GIT archive files.
+git-verify-pack - Validate packed git archive files.
SYNOPSIS
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reads given idx file for packed GIT archive created with
+Reads given idx file for packed git archive created with
git-pack-objects command and verifies idx file and the
corresponding pack file.
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -146,7 +146,7 @@ gitlink:git-var[1]::
Displays a git logical variable
gitlink:git-verify-pack[1]::
- Validates packed GIT archive files
+ Validates packed git archive files
The interrogate commands may create files - and you can force them to
touch the working file set - but in general they don't
@@ -163,11 +163,11 @@ gitlink:git-fetch-pack[1]::
Updates from a remote repository.
gitlink:git-http-fetch[1]::
- Downloads a remote GIT repository via HTTP
+ Downloads a remote git repository via HTTP
Previously this command was known as git-http-pull.
gitlink:git-local-fetch[1]::
- Duplicates another GIT repository on a local system
+ Duplicates another git repository on a local system
Previously this command was known as git-local-pull.
gitlink:git-peek-remote[1]::
@@ -322,7 +322,7 @@ gitlink:git-archimport[1]::
Previously this command was known as git-archimport-script.
gitlink:git-convert-objects[1]::
- Converts old-style GIT repository
+ Converts old-style git repository
Previously this command was known as git-convert-cache.
gitlink:git-cvsimport[1]::
@@ -360,7 +360,7 @@ gitlink:git-count-objects[1]::
Previously this command was known as git-count-objects-script.
gitlink:git-daemon[1]::
- A really simple server for GIT repositories.
+ A really simple server for git repositories.
gitlink:git-get-tar-commit-id[1]::
Extract commit ID from an archive created using git-tar-tree.
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -1,5 +1,5 @@
object::
- The unit of storage in GIT. It is uniquely identified by
+ The unit of storage in git. It is uniquely identified by
the SHA1 of its contents. Consequently, an object can not
be changed.
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -1,4 +1,4 @@
-Hooks used by GIT
+Hooks used by git
=================
Hooks are little scripts you can place in `$GIT_DIR/hooks`
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -6,7 +6,7 @@
===============================================================
- 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/
+- git URL: git://remote.machine/path/to/repo.git/
or remote.machine:/path/to/repo.git/
- Local directory: /path/to/repo.git/
===============================================================
diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
--- a/Documentation/repository-layout.txt
+++ b/Documentation/repository-layout.txt
@@ -1,4 +1,4 @@
-GIT repository layout
+git repository layout
=====================
You may find these things in your git repository (`.git`
@@ -119,7 +119,7 @@ info/grafts::
info/exclude::
This file, by convention among Porcelains, stores the
exclude pattern list. `git status` looks at it, but
- otherwise it is not looked at by any of the core GIT
+ otherwise it is not looked at by any of the core git
commands.
remotes::
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -160,7 +160,7 @@ you'll have to use the object name, not
git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
where the `-t` tells `git-cat-file` to tell you what the "type" of the
-object is. Git will tell you that you have a "blob" object (ie just a
+object is. git will tell you that you have a "blob" object (ie just a
regular file), and you can see the contents with
git-cat-file "blob" 557db03
@@ -377,7 +377,7 @@ come from the working tree or not.
This is not hard to understand, as soon as you realize that git simply
never knows (or cares) about files that it is not told about
-explicitly. Git will never go *looking* for files to compare, it
+explicitly. git will never go *looking* for files to compare, it
expects you to tell it what the files are, and that's what the index
is there for.
================
@@ -543,7 +543,7 @@ name for the state at that point.
Copying repositories
--------------------
-Git repositories are normally totally self-sufficient, and it's worth noting
+git repositories are normally totally self-sufficient, and it's worth noting
that unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally *is* the
working tree, with the local git information hidden in the `.git`
@@ -950,7 +950,7 @@ This transport is the same as SSH transp
both ends on the local machine instead of running other end on
the remote machine via `ssh`.
-GIT Native::
+git Native::
`git://remote.machine/path/to/repo.git/`
+
This transport was designed for anonymous downloading. Like SSH
@@ -971,13 +971,13 @@ necessary objects. Because of this beha
sometimes also called 'commit walkers'.
+
The 'commit walkers' are sometimes also called 'dumb
-transports', because they do not require any GIT aware smart
-server like GIT Native transport does. Any stock HTTP server
+transports', because they do not require any git aware smart
+server like git Native transport does. Any stock HTTP server
would suffice.
+
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
-usefulness when GIT Native and SSH transports were introduced,
+usefulness when git Native and SSH transports were introduced,
and not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `resolve` that
@@ -1081,7 +1081,7 @@ done only once.
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
-Your private repository's GIT directory is usually `.git`, but
+Your private repository's git directory is usually `.git`, but
your public repository is often named after the project name,
i.e. `<project>.git`. Let's create such a public repository for
project `my-git`. After logging into the remote machine, create
@@ -1089,7 +1089,7 @@ an empty directory:
mkdir my-git.git
-Then, make that directory into a GIT repository by running
+Then, make that directory into a git repository by running
`git init-db`, but this time, since its name is not the usual
`.git`, we do things slightly differently:
^ permalink raw reply
* Re: openbsd version?
From: Daniel Barkalow @ 2005-10-10 21:31 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <86y851aydl.fsf@blue.stonehenge.com>
On Mon, 10 Oct 2005, Randal L. Schwartz wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> <sarcasm>Undocumented secret switches. Nice.</sarcasm> No wonder
> >> I couldn't find it.
>
> Johannes> <optimism>Maybe he who found the documentation lacking is going to fix
> Johannes> it?</optimism>
>
> I'd be happy to do that. But as a tech writer, I know that it's
> insane to not work at least from an implementor's rough draft, to at
> least understand the intent of a mechanism, if not the precise design.
> There's no implementor's rough draft here, so I can't help.
The mailing list thread on the subject is at:
http://www.gelato.unsw.edu.au/archives/git/0509/8902.html
(That's the middle of the thread, when the patch was actually written.
There's discussion before and after if you need more info.)
You can actually get a pretty good explanation of features, once you know
they exist at all, by looking for the discussion on the list. This tends
to at least give you the person who did the patch explaining how to use it
to the person who wanted the feature. And it'll also tell you who the
implementor was, so you can bug the right person directly. :)
What does get written about a feature generall ends up in the commit
message for the commit that adds it, so that's another good place to look.
(In this case, it's missing a "not" and description of an option, so it's
quite rough as a draft.)
In this case:
"git branch -d <name>" deletes a branch with that name; but it checks
that you're not on that branch, and it checks that that branch doesn't
have any commits which aren't merged into the current branch.
"git branch -D <name>" deletes a branch, and skips the second check.
-Daniel
*This .sig left intentionally blank*
^ 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