* [PATCH] Fix spelling mistakes in user manual
From: Shawn Bohrer @ 2007-12-05 4:25 UTC (permalink / raw)
To: git; +Cc: gitster, Shawn Bohrer
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
---
Documentation/user-manual.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 93a47b4..f2b4206 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,7 +1994,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
Normally whenever a branch head in a public repository is modified, it
-is modified to point to a descendent of the commit that it pointed to
+is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
(See <<problems-with-rewriting-history>>.)
@@ -2921,7 +2921,7 @@ As you can see, a commit is defined by:
- a tree: The SHA1 name of a tree object (as defined below), representing
the contents of a directory at a certain point in time.
- parent(s): The SHA1 name of some number of commits which represent the
- immediately prevoius step(s) in the history of the project. The
+ immediately previous step(s) in the history of the project. The
example above has one parent; merge commits may have more than
one. A commit with no parents is called a "root" commit, and
represents the initial revision of a project. Each project must have
@@ -3242,7 +3242,7 @@ to replace them by hand. Back up your repository before attempting this
in case you corrupt things even more in the process.
We'll assume that the problem is a single missing or corrupted blob,
-which is sometimes a solveable problem. (Recovering missing trees and
+which is sometimes a solvable problem. (Recovering missing trees and
especially commits is *much* harder).
Before starting, verify that there is corruption, and figure out where
--
1.5.3.6
^ permalink raw reply related
* [PATCH] Documentation: describe -w/--web option to "git-help".
From: Christian Couder @ 2007-12-05 5:09 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Also explain that "git instaweb" may use "web.browser" config
variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-help.txt | 21 +++++++++++++++++++--
Documentation/git-instaweb.txt | 3 +++
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index c94e27b..ac9e15d 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -7,7 +7,7 @@ git-help - display help information about git
SYNOPSIS
--------
-'git help' [-a|--all|-i|--info] [COMMAND]
+'git help' [-a|--all|-i|--info|-w|--web] [COMMAND]
DESCRIPTION
-----------
@@ -29,7 +29,6 @@ former is internally converted into the latter.
OPTIONS
-------
-a|--all::
-
Prints all the available commands on the standard output. This
option superseeds any other option.
@@ -37,6 +36,24 @@ OPTIONS
Use the 'info' program to display the manual page, instead of
the 'man' program that is used by default.
+-w|--web::
+ Use a web browser to display the HTML manual page, instead of
+ the 'man' program that is used by default.
++
+The web browser can be specified using the configuration variable
+'help.browser', or 'web.browser' if the former is not set. If none of
+these config variables is set, the 'git-browse-help' script (called by
+'git-help') will pick a suitable default.
++
+You can explicitly provide a full path to your prefered browser by
+setting the configuration variable 'browser.<tool>.path'. For example,
+you can configure the absolute path to firefox by setting
+'browser.firefox.path'. Otherwise, 'git-browse-help' assumes the tool
+is available in PATH.
++
+Note that the script tries, as much as possible, to display the HTML
+page in a new tab on an already opened browser.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and the git-list
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index 735008c..d2ce779 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -71,6 +71,9 @@ You may specify configuration in your .git/config
-----------------------------------------------------------------------
+If the configuration variable 'instaweb.browser' is not set,
+'web.browser' will be used instead if it is defined.
+
Author
------
Written by Eric Wong <normalperson@yhbt.net>
--
1.5.3.6.1993.g154f-dirty
^ permalink raw reply related
* Re: [PATCH] t9600: require cvsps 2.1 to perform tests
From: Junio C Hamano @ 2007-12-05 5:44 UTC (permalink / raw)
To: Jeff King; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <20071205010202.GA4713@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Dec 04, 2007 at 09:39:59AM -0800, Junio C Hamano wrote:
>
>> You are right about "we may be depending on what 2.1 has other than
>> -A". Will apply as-is.
>>
>> Thanks, both.
>>
>> The primary reason I asked about '\[-A\]' was what will happen if
>> somebody uses 2.2.
>
> Yes, it would be nice to be able to easily check >2.1. GNU expr seems to
> handle this ok:
>
> $ expr 2.2 '>' 2.1
> 1
> $ expr 2.0 '>' 2.1
> 0
>
> but POSIX seems to mention only integers and string comparison (though
> if all are of the form "x.y", string comparison works). I have no idea
> how portable this is.
Yeah, but it is the same thing -- we know 2.1 works, we do not know if
2.2 will break things for us ;-)
We'll worry about it when somebody with 2.2 complains.
^ permalink raw reply
* How to jump between two repositories ...
From: g2 @ 2007-12-05 5:59 UTC (permalink / raw)
To: git
Hello all,
I am currently working on some code at the office that I also want to
work with at home. Seems like a good candidate for git. So I created a
repository at work and did a "git clone" at home. I've run into some
strange behaviour that I don't understand and would appreciate if
someone can clarify for me.
Imagine this scenario. At work:
git init
edit test.c
git add test.c
git commit
Then at home:
git clone <work git url>
edit test.c
git commit -a
git push
At this point, I wanted to push my changes back to my work repository
so I can continue work the next day. So at home, I did a git push. I
expect that my work repository has the newest material, but I find
that when I do "git status" at work the next day, it tells me that my
test.c is "modified" and has already staged it for commit. I need to
do a "git reset" followed by "git checkout" to update my work folder
to the latest stuff.
Totally different from my expectation of the repository knowing that
it is out of date and then kindly suggesting that I should do a "git
update" of some sort. What piece of understanding am I missing to
properly "get" what is going on here, and how am I supposed to
properly work with this setup?
Thanks for any help.
Gerald.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Shawn O. Pearce @ 2007-12-05 6:11 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
g2 <gerald.gutierrez@gmail.com> wrote:
> At this point, I wanted to push my changes back to my work repository
> so I can continue work the next day. So at home, I did a git push. I
> expect that my work repository has the newest material, but I find
> that when I do "git status" at work the next day, it tells me that my
> test.c is "modified" and has already staged it for commit. I need to
> do a "git reset" followed by "git checkout" to update my work folder
> to the latest stuff.
Oddly enough, this question is asked so frequently that it is
answered in the GitFaq on the GitWiki:
http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
--
Shawn.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: J. Bruce Fields @ 2007-12-05 6:14 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
On Tue, Dec 04, 2007 at 09:59:57PM -0800, g2 wrote:
> Hello all,
>
> I am currently working on some code at the office that I also want to work
> with at home. Seems like a good candidate for git. So I created a
> repository at work and did a "git clone" at home. I've run into some
> strange behaviour that I don't understand and would appreciate if someone
> can clarify for me.
>
> Imagine this scenario. At work:
> git init
> edit test.c
> git add test.c
> git commit
>
> Then at home:
> git clone <work git url>
> edit test.c
> git commit -a
> git push
You'll be much happier at this point if you ssh into work and then git
pull from home....
> At this point, I wanted to push my changes back to my work repository so I
> can continue work the next day. So at home, I did a git push. I expect that
> my work repository has the newest material, but I find that when I do "git
> status" at work the next day, it tells me that my test.c is "modified" and
> has already staged it for commit. I need to do a "git reset" followed by
> "git checkout" to update my work folder to the latest stuff.
>
> Totally different from my expectation of the repository knowing that it is
> out of date and then kindly suggesting that I should do a "git update" of
> some sort. What piece of understanding am I missing to properly "get" what
> is going on here, and how am I supposed to properly work with this setup?
Git doesn't support pushing to any branch that's checked out somewhere.
--b.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Väinö Järvelä @ 2007-12-05 6:20 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <C6AF7922-B2F7-42EB-B5DD-25353BC0AF2A@gmail.com>
On Dec 5, 2007, at 07:59, g2 wrote:
> I am currently working on some code at the office that I also want
> to work with at home. Seems like a good candidate for git. So I
> created a repository at work and did a "git clone" at home. I've run
> into some strange behaviour that I don't understand and would
> appreciate if someone can clarify for me.
>
> Imagine this scenario. At work:
> git init
> edit test.c
> git add test.c
> git commit
>
> Then at home:
> git clone <work git url>
> edit test.c
> git commit -a
> git push
>
> At this point, I wanted to push my changes back to my work
> repository so I can continue work the next day. So at home, I did a
> git push. I expect that my work repository has the newest material,
> but I find that when I do "git status" at work the next day, it
> tells me that my test.c is "modified" and has already staged it for
> commit. I need to do a "git reset" followed by "git checkout" to
> update my work folder to the latest stuff.
Did you clone a bare repository and push to it?
Here is an excerpt from Git User's Manual:
"Note that the target of a "push" is normally a bare repository. You
can also push to a repository that has a checked-out working tree, but
the working tree will not be updated by the push. This may lead to
unexpected results if the branch you push to is the currently checked-
out branch!"
So to push to your work repository, you should create an intermediary
repository between the work and home repositories. You can create it
by running:
$ git clone --bare /git/work/ /git/work.git/
Then you clone normally from the bare repository and pushing to it
works fine. After you have pushed your changes to the bare repository,
you'll have to pull them to the work repository to get the updates,
just like you would do with any public repository.
Another option would be to pull from your home repository to the work
repository, if you can access your home computer from the work computer.
--
Väinö
^ permalink raw reply
* Re: How to jump between two repositories ...
From: g2 @ 2007-12-05 6:44 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: git
In-Reply-To: <3DD4D3BA-67B3-4AFC-AD24-799384D54408@pp.inet.fi>
What I am gathering from this is that I can use git in two ways: 1) as
"just another svn" bare git repository, or 2) only pull and don't
push, because push causes confusion. I'd be happy to only ever use
pull, but I have one machine behind a firewall and can't pull. I can
push to a bare git repository like the svn model, but then I would
just use svn. What's the value of "push" then?
On 4-Dec-07, at 10:20 PM, Väinö Järvelä wrote:
> On Dec 5, 2007, at 07:59, g2 wrote:
>
>> I am currently working on some code at the office that I also want
>> to work with at home. Seems like a good candidate for git. So I
>> created a repository at work and did a "git clone" at home. I've
>> run into some strange behaviour that I don't understand and would
>> appreciate if someone can clarify for me.
>>
>> Imagine this scenario. At work:
>> git init
>> edit test.c
>> git add test.c
>> git commit
>>
>> Then at home:
>> git clone <work git url>
>> edit test.c
>> git commit -a
>> git push
>>
>> At this point, I wanted to push my changes back to my work
>> repository so I can continue work the next day. So at home, I did a
>> git push. I expect that my work repository has the newest material,
>> but I find that when I do "git status" at work the next day, it
>> tells me that my test.c is "modified" and has already staged it for
>> commit. I need to do a "git reset" followed by "git checkout" to
>> update my work folder to the latest stuff.
>
> Did you clone a bare repository and push to it?
>
> Here is an excerpt from Git User's Manual:
> "Note that the target of a "push" is normally a bare repository. You
> can also push to a repository that has a checked-out working tree,
> but the working tree will not be updated by the push. This may lead
> to unexpected results if the branch you push to is the currently
> checked-out branch!"
>
> So to push to your work repository, you should create an
> intermediary repository between the work and home repositories. You
> can create it by running:
> $ git clone --bare /git/work/ /git/work.git/
>
> Then you clone normally from the bare repository and pushing to it
> works fine. After you have pushed your changes to the bare
> repository, you'll have to pull them to the work repository to get
> the updates, just like you would do with any public repository.
>
> Another option would be to pull from your home repository to the
> work repository, if you can access your home computer from the work
> computer.
>
> --
> Väinö
>
^ permalink raw reply
* Re: [PATCH] Include diff options in the git-log manpage
From: Junio C Hamano @ 2007-12-05 6:45 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071204122859.GQ31750@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Nov 01, 2007 at 03:57:40PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> Recently I wanted to see what git log -M does but actually I was not able to
>> find it in the manpage, finally figured out that all the diff options are
>> missing from here.
>>
>> Removing -p as it's already in diff-options.txt.
>
> could you please have a look at this patch? this also fixes the "-C is
> missing from man git-log" issue which was reported on IRC today.
Have you proofread the whole output after your patch?
* It makes it say "--raw ... this is the default", while for "git log"
no diff output is the default.
* Also it says "-p ... (see section on generating patches)"; there is
no such section.
This can be a possible fixup on top of your patch. It has potential to
affect other documentation pages that includes the files touched. I
have formatted log, diff and format-patch before your patch and after
your patch plus this patch, and eyeballed the difference, but please
double check.
---
Documentation/diff-format.txt | 159 +--------------------------------
Documentation/diff-generate-patch.txt | 161 +++++++++++++++++++++++++++++++++
Documentation/diff-options.txt | 2 +
Documentation/git-log.txt | 2 +
4 files changed, 166 insertions(+), 158 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 9709c35..2c3a4c4 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -83,161 +83,4 @@ Note that 'combined diff' lists only files which were modified from
all parents.
-Generating patches with -p
---------------------------
-
-When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
-with a '-p' option, or "git diff" without the '--raw' option, they
-do not produce the output described above; instead they produce a
-patch file. You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
-What the -p option produces is slightly different from the traditional
-diff format.
-
-1. It is preceded with a "git diff" header, that looks like
- this:
-
- diff --git a/file1 b/file2
-+
-The `a/` and `b/` filenames are the same unless rename/copy is
-involved. Especially, even for a creation or a deletion,
-`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
-+
-When rename/copy is involved, `file1` and `file2` show the
-name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
-
-2. It is followed by one or more extended header lines:
-
- old mode <mode>
- new mode <mode>
- deleted file mode <mode>
- new file mode <mode>
- copy from <path>
- copy to <path>
- rename from <path>
- rename to <path>
- similarity index <number>
- dissimilarity index <number>
- index <hash>..<hash> <mode>
-
-3. TAB, LF, double quote and backslash characters in pathnames
- are represented as `\t`, `\n`, `\"` and `\\`, respectively.
- If there is need for such substitution then the whole
- pathname is put in double quotes.
-
-The similarity index is the percentage of unchanged lines, and
-the dissimilarity index is the percentage of changed lines. It
-is a rounded down integer, followed by a percent sign. The
-similarity index value of 100% is thus reserved for two equal
-files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
-
-
-combined diff format
---------------------
-
-"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
-'--cc' option to produce 'combined diff', which looks like this:
-
-------------
-diff --combined describe.c
-index fabadb8,cc95eb0..4866510
---- a/describe.c
-+++ b/describe.c
-@@@ -98,20 -98,12 +98,20 @@@
- return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
- }
-
-- static void describe(char *arg)
- -static void describe(struct commit *cmit, int last_one)
-++static void describe(char *arg, int last_one)
- {
- + unsigned char sha1[20];
- + struct commit *cmit;
- struct commit_list *list;
- static int initialized = 0;
- struct commit_name *n;
-
- + if (get_sha1(arg, sha1) < 0)
- + usage(describe_usage);
- + cmit = lookup_commit_reference(sha1);
- + if (!cmit)
- + usage(describe_usage);
- +
- if (!initialized) {
- initialized = 1;
- for_each_ref(get_name);
-------------
-
-1. It is preceded with a "git diff" header, that looks like
- this (when '-c' option is used):
-
- diff --combined file
-+
-or like this (when '--cc' option is used):
-
- diff --c file
-
-2. It is followed by one or more extended header lines
- (this example shows a merge with two parents):
-
- index <hash>,<hash>..<hash>
- mode <mode>,<mode>..<mode>
- new file mode <mode>
- deleted file mode <mode>,<mode>
-+
-The `mode <mode>,<mode>..<mode>` line appears only if at least one of
-the <mode> is different from the rest. Extended headers with
-information about detected contents movement (renames and
-copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
-
-3. It is followed by two-line from-file/to-file header
-
- --- a/file
- +++ b/file
-+
-Similar to two-line header for traditional 'unified' diff
-format, `/dev/null` is used to signal created or deleted
-files.
-
-4. Chunk header format is modified to prevent people from
- accidentally feeding it to `patch -p1`. Combined diff format
- was created for review of merge commit changes, and was not
- meant for apply. The change is similar to the change in the
- extended 'index' header:
-
- @@@ <from-file-range> <from-file-range> <to-file-range> @@@
-+
-There are (number of parents + 1) `@` characters in the chunk
-header for combined diff format.
-
-Unlike the traditional 'unified' diff format, which shows two
-files A and B with a single column that has `-` (minus --
-appears in A but removed in B), `+` (plus -- missing in A but
-added to B), or `" "` (space -- unchanged) prefix, this format
-compares two or more files file1, file2,... with one file X, and
-shows how X differs from each of fileN. One column for each of
-fileN is prepended to the output line to note how X's line is
-different from it.
-
-A `-` character in the column N means that the line appears in
-fileN but it does not appear in the result. A `+` character
-in the column N means that the line appears in the last file,
-and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
-In the above example output, the function signature was changed
-from both files (hence two `-` removals from both file1 and
-file2, plus `++` to mean one line that was added does not appear
-in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with ` +`).
-
-When shown by `git diff-tree -c`, it compares the parents of a
-merge commit with the merge result (i.e. file1..fileN are the
-parents). When shown by `git diff-files -c`, it compares the
-two unresolved merge parents with the working tree file
-(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").
+include::diff-generate-patch.txt[]
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
new file mode 100644
index 0000000..029c5f2
--- /dev/null
+++ b/Documentation/diff-generate-patch.txt
@@ -0,0 +1,161 @@
+Generating patches with -p
+--------------------------
+
+When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+with a '-p' option, "git diff" without the '--raw' option, or
+"git log" with the "-p" option, they
+do not produce the output described above; instead they produce a
+patch file. You can customize the creation of such patches via the
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
+What the -p option produces is slightly different from the traditional
+diff format.
+
+1. It is preceded with a "git diff" header, that looks like
+ this:
+
+ diff --git a/file1 b/file2
++
+The `a/` and `b/` filenames are the same unless rename/copy is
+involved. Especially, even for a creation or a deletion,
+`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
++
+When rename/copy is involved, `file1` and `file2` show the
+name of the source file of the rename/copy and the name of
+the file that rename/copy produces, respectively.
+
+2. It is followed by one or more extended header lines:
+
+ old mode <mode>
+ new mode <mode>
+ deleted file mode <mode>
+ new file mode <mode>
+ copy from <path>
+ copy to <path>
+ rename from <path>
+ rename to <path>
+ similarity index <number>
+ dissimilarity index <number>
+ index <hash>..<hash> <mode>
+
+3. TAB, LF, double quote and backslash characters in pathnames
+ are represented as `\t`, `\n`, `\"` and `\\`, respectively.
+ If there is need for such substitution then the whole
+ pathname is put in double quotes.
+
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
+
+
+combined diff format
+--------------------
+
+"git-diff-tree", "git-diff-files" and "git-diff" can take '-c' or
+'--cc' option to produce 'combined diff'. For showing a merge commit
+with "git log -p", this is the default format.
+A 'combined diff' format looks like this:
+
+------------
+diff --combined describe.c
+index fabadb8,cc95eb0..4866510
+--- a/describe.c
++++ b/describe.c
+@@@ -98,20 -98,12 +98,20 @@@
+ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
+ }
+
+- static void describe(char *arg)
+ -static void describe(struct commit *cmit, int last_one)
+++static void describe(char *arg, int last_one)
+ {
+ + unsigned char sha1[20];
+ + struct commit *cmit;
+ struct commit_list *list;
+ static int initialized = 0;
+ struct commit_name *n;
+
+ + if (get_sha1(arg, sha1) < 0)
+ + usage(describe_usage);
+ + cmit = lookup_commit_reference(sha1);
+ + if (!cmit)
+ + usage(describe_usage);
+ +
+ if (!initialized) {
+ initialized = 1;
+ for_each_ref(get_name);
+------------
+
+1. It is preceded with a "git diff" header, that looks like
+ this (when '-c' option is used):
+
+ diff --combined file
++
+or like this (when '--cc' option is used):
+
+ diff --c file
+
+2. It is followed by one or more extended header lines
+ (this example shows a merge with two parents):
+
+ index <hash>,<hash>..<hash>
+ mode <mode>,<mode>..<mode>
+ new file mode <mode>
+ deleted file mode <mode>,<mode>
++
+The `mode <mode>,<mode>..<mode>` line appears only if at least one of
+the <mode> is different from the rest. Extended headers with
+information about detected contents movement (renames and
+copying detection) are designed to work with diff of two
+<tree-ish> and are not used by combined diff format.
+
+3. It is followed by two-line from-file/to-file header
+
+ --- a/file
+ +++ b/file
++
+Similar to two-line header for traditional 'unified' diff
+format, `/dev/null` is used to signal created or deleted
+files.
+
+4. Chunk header format is modified to prevent people from
+ accidentally feeding it to `patch -p1`. Combined diff format
+ was created for review of merge commit changes, and was not
+ meant for apply. The change is similar to the change in the
+ extended 'index' header:
+
+ @@@ <from-file-range> <from-file-range> <to-file-range> @@@
++
+There are (number of parents + 1) `@` characters in the chunk
+header for combined diff format.
+
+Unlike the traditional 'unified' diff format, which shows two
+files A and B with a single column that has `-` (minus --
+appears in A but removed in B), `+` (plus -- missing in A but
+added to B), or `" "` (space -- unchanged) prefix, this format
+compares two or more files file1, file2,... with one file X, and
+shows how X differs from each of fileN. One column for each of
+fileN is prepended to the output line to note how X's line is
+different from it.
+
+A `-` character in the column N means that the line appears in
+fileN but it does not appear in the result. A `+` character
+in the column N means that the line appears in the last file,
+and fileN does not have that line (in other words, the line was
+added, from the point of view of that parent).
+
+In the above example output, the function signature was changed
+from both files (hence two `-` removals from both file1 and
+file2, plus `++` to mean one line that was added does not appear
+in either file1 nor file2). Also two other lines are the same
+from file1 but do not appear in file2 (hence prefixed with ` +`).
+
+When shown by `git diff-tree -c`, it compares the parents of a
+merge commit with the merge result (i.e. file1..fileN are the
+parents). When shown by `git diff-files -c`, it compares the
+two unresolved merge parents with the working tree file
+(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
+"their version").
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e4af393..d0154bb 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -6,7 +6,9 @@
ifndef::git-format-patch[]
ifndef::git-diff[]
+ifndef::git-log[]
:git-diff-core: 1
+endif::git-log[]
endif::git-diff[]
endif::git-format-patch[]
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 4b1b982..5920d17 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -27,6 +27,7 @@ OPTIONS
include::pretty-options.txt[]
+:git-log: 1
include::diff-options.txt[]
-<n>::
@@ -77,6 +78,7 @@ include::diff-options.txt[]
include::pretty-formats.txt[]
+include::diff-generate-patch.txt[]
Examples
--------
^ permalink raw reply related
* [BUG] "git clean" does not pay attention to its parameters
From: Nanako Shiraishi @ 2007-12-05 6:54 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: git
In a repository with LaTeX documents, I tried to see what *.aux files are left behind after formatting, by running "git clean -n" with the latest git (1.5.3.7-1005-gdada0c1):
% git clean -n '*.aux'
This however showed more than just '*.aux' files. With the released version 1.5.3.6, the output is correctly limited to the files that match the pattern.
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Steven Grimm @ 2007-12-05 6:57 UTC (permalink / raw)
To: g2; +Cc: Väinö Järvelä, git
In-Reply-To: <33CB0252-20C7-4AF2-AEB3-2EAC20ED830B@gmail.com>
On Dec 4, 2007, at 10:44 PM, g2 wrote:
> What I am gathering from this is that I can use git in two ways: 1)
> as "just another svn" bare git repository, or 2) only pull and don't
> push, because push causes confusion. I'd be happy to only ever use
> pull, but I have one machine behind a firewall and can't pull. I can
> push to a bare git repository like the svn model, but then I would
> just use svn. What's the value of "push" then?
You can push. Just don't push to a checked-out branch. I do exactly
what you're describing and it works fine. It looks something like this:
server% git checkout mybranch
server% edit somefile.c
server% git commit
laptop% git checkout mybranch
laptop% git pull
(with a pull configuration that pulls server's mybranch into
laptop's)
laptop% edit somefile.c
laptop% git commit
laptop% git push server mybranch:laptop/mybranch
server% git checkout mybranch
server% git rebase laptop/mybranch
Presto, ready to go. The trick is to push into a branch that's
different from the one that's checked out, then rebase on top of that
on the remote side after the push.
Yeah, it'd be nicer if you could just push to the checked-out branch
directly (and there are hooks to let you do that) but this is only
slightly awkward and it's easy once you've done it a few times.
-Steve
^ permalink raw reply
* Re: [PATCH] git-checkout --push/--pop
From: Junio C Hamano @ 2007-12-05 6:59 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Matthieu Moy, Salikh Zakirov, git
In-Reply-To: <200712042204.lB4M4SVB002260@mi1.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> This introduces a branch-stack mechanism to record branch switching in $GIT_DIR/BRANCH_STACK file. If you are switching to another branch and plan to come back to the original branch soon, add '--push' option to record your current branch.
> When you want to come back, 'git checkout --pop' will switch back to the branch recorded at the top of the stack, while popping it.
>
> Signed-off-by: しらいしななこ <nanako3@bluebottle.com>
Hmph, is this in response to my "I am not sympathtic to 'I have to
remember'"?
Funnily enough, I often find myself almost typing pushd/popd when
switching branches, so in that sense "git checkout" to switch branches
does have some similarity to the notion of pushing and popping.
Matthieu, is this something that forgetful people would find useful?
Having said that, I think there are other push/pop people wanted from
you. Hint, hint...
^ permalink raw reply
* fetch_refs_via_pack() discards status?
From: Junio C Hamano @ 2007-12-05 7:01 UTC (permalink / raw)
To: Daniel Barkalow, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <7v3aunqvha.fsf_-_@gitster.siamese.dyndns.org>
The code calls fetch_pack() to get the list of refs it fetched, and
discards refs and always returns 0 to signal success.
But builtin-fetch-pack.c::fetch_pack() has error cases. The function
returns NULL if error is detected (shallow-support side seems to choose
to die but I suspect that is easily fixable to error out as well).
Shouldn't fetch_refs_via_pack() propagate that error to the caller?
---
transport.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 50db980..048df1f 100644
--- a/transport.c
+++ b/transport.c
@@ -655,7 +655,7 @@ static int fetch_refs_via_pack(struct transport *transport,
free(heads);
free_refs(refs);
free(dest);
- return 0;
+ return (refs ? 0 : -1);
}
static int git_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags)
^ permalink raw reply related
* Re: [PATCH] hg-to-git: handle an empty dir in hg by combining git commits
From: Junio C Hamano @ 2007-12-05 7:01 UTC (permalink / raw)
To: Mark Drago; +Cc: stelian, git
In-Reply-To: <7vd4tq41zt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Mark Drago <markdrago@gmail.com> writes:
>
>> This patch will detect that there are no changes to commit (using git-status),
>> and will not perform the commit, but will instead combine the log messages of
>> that (non-)commit with the next commit.
>
> I think a better approach would be to implement --no-tree-change-is-ok
> option to git-commit, strictly for use by foreign scm interface scripts
> like yours. It does not usually make sense to record a commit that has
> the exact same tree as its sole parent commit and that is why git-commit
> prevents you from making that mistake, but when data from foreign scm is
> involved, it is a different story. We are equipped to represent such a
> (perhaps insane, perhaps by mistake, or perhaps done on purpose) change
> and it is better to represent it bypassing the safety valve for native
> use.
So I did "git commit --allow-empty". With that, perhaps the following
will fix the issue?
I won't be commiting this myself until I hear a positive Ack.
---
contrib/hg-to-git/hg-to-git.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 7a1c3e4..9befb92 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -211,7 +211,7 @@ for cset in range(int(tip) + 1):
os.system('git-ls-files -x .hg --deleted | git-update-index --remove --stdin')
# commit
- os.system(getgitenv(user, date) + 'git-commit -a -F %s' % filecomment)
+ os.system(getgitenv(user, date) + 'git commit --allow-empty -a -F %s' % filecomment)
os.unlink(filecomment)
# tag
^ permalink raw reply related
* Re: [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
From: Junio C Hamano @ 2007-12-05 7:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Guillaume Seguin
In-Reply-To: <200712010247.25107.jnareb@gmail.com>
I have these two patches still in my mailbox, unapplied:
[PATCH] gitweb: disambiguate heads and tags withs the same name
[PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
I am wondering if they should be part of 1.5.4. They look Ok but it is
not very easy to pick up what the real breakage it is trying to fix from
Perl gibberish.
Can we have tests (not just "we do not spit out anything to stderr") for
gitweb so that each patch can demonstrate the existing breakage, to make
judging easier?
^ permalink raw reply
* Re: Cosmetic git-am interactive bug
From: Junio C Hamano @ 2007-12-05 7:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4755A836.1050408@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> The use of the older one-line summary led me to believe that it had
> not committed my changelog edits. Looking at the result, however,
> proved that the commit changelog was my new, corrected version.
I knew about this for quite some time but it was a very low priority for
me. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/git-am.sh b/git-am.sh
index 2e40708..339d863 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -117,6 +117,10 @@ It does not apply to blobs recorded in its index."
unset GITHEAD_$his_tree
}
+reread_subject () {
+ git stripspace <"$1" | sed -e 1q
+}
+
prec=4
dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary=
resolvemsg= resume=
@@ -376,6 +380,7 @@ do
[aA]*) action=yes interactive= ;;
[nN]*) action=skip ;;
[eE]*) git_editor "$dotest/final-commit"
+ SUBJECT=$(reread_subject "$dotest/final-commit")
action=again ;;
[vV]*) action=again
LESS=-S ${PAGER:-less} "$dotest/patch" ;;
^ permalink raw reply related
* [PATCH] Open external merge tool with original file extensions for all three files
From: Pini Reznik @ 2007-12-05 7:19 UTC (permalink / raw)
To: git; +Cc: Pini Reznik
Before this fix conflicted files were open in external merge tool with temporal extensions like REMOTE.$$ and LOCAL.$$.
This way meld was unable to recognize these files and syntax highlighting feature was unusable.
Signed-off-by: Pini Reznik <pinir@expand.com>
---
git-mergetool.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 5587c5e..2f31fa2 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -152,10 +152,11 @@ merge_file () {
exit 1
fi
- BACKUP="$path.BACKUP.$$"
- LOCAL="$path.LOCAL.$$"
- REMOTE="$path.REMOTE.$$"
- BASE="$path.BASE.$$"
+ ext="$$$(expr "$path" : '.*\(\.[^/]*\)$')"
+ BACKUP="$path.BACKUP.$ext"
+ LOCAL="$path.LOCAL.$ext"
+ REMOTE="$path.REMOTE.$ext"
+ BASE="$path.BASE.$ext"
mv -- "$path" "$BACKUP"
cp -- "$BACKUP" "$path"
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Open external merge tool with original file extensions for all three files
From: Junio C Hamano @ 2007-12-05 7:24 UTC (permalink / raw)
To: Pini Reznik; +Cc: git, Theodore Ts'o
In-Reply-To: <1196839153-31084-1-git-send-email-pinir@expand.com>
Pini Reznik <pinir@expand.com> writes:
> Before this fix conflicted files were open in external merge tool with temporal extensions like REMOTE.$$ and LOCAL.$$.
> This way meld was unable to recognize these files and syntax highlighting feature was unusable.
>
>
> Signed-off-by: Pini Reznik <pinir@expand.com>
I have to wonder if it is fashionable to use overlooooong lines on this
list today... Please linewrap commit log message.
Ted, you added meld from the beginning to git-mergetool. Does the patch
look good?
> ---
> git-mergetool.sh | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 5587c5e..2f31fa2 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -152,10 +152,11 @@ merge_file () {
> exit 1
> fi
>
> - BACKUP="$path.BACKUP.$$"
> - LOCAL="$path.LOCAL.$$"
> - REMOTE="$path.REMOTE.$$"
> - BASE="$path.BASE.$$"
> + ext="$$$(expr "$path" : '.*\(\.[^/]*\)$')"
> + BACKUP="$path.BACKUP.$ext"
> + LOCAL="$path.LOCAL.$ext"
> + REMOTE="$path.REMOTE.$ext"
> + BASE="$path.BASE.$ext"
I realize '.*\(\.[^./]*\)$' might have been better, as the above
expression as written will slurp ".b.c" as ext from "foo.b.c", but
probably for "merger knows the file type with file extension" purpose,
it does not make a difference.
^ permalink raw reply
* Re: How to jump between two repositories ...
From: Väinö Järvelä @ 2007-12-05 7:32 UTC (permalink / raw)
To: g2; +Cc: git
In-Reply-To: <33CB0252-20C7-4AF2-AEB3-2EAC20ED830B@gmail.com>
On Dec 5, 2007, at 08:44, g2 wrote:
> What I am gathering from this is that I can use git in two ways: 1)
> as "just another svn" bare git repository, or 2) only pull and don't
> push, because push causes confusion. I'd be happy to only ever use
> pull, but I have one machine behind a firewall and can't pull. I can
> push to a bare git repository like the svn model, but then I would
> just use svn. What's the value of "push" then?
I guess the value over svn, is in the excellent tools that Git
provides (such as rebase, bisect and merging). And that you can
develop offline and still retain the individual commits.
And you could use Steven Grimms solution, but I guess with that, you
need to be careful to not leave your servers working tree on any of
your laptop/ branch if you might push to one.
--
Väinö
^ permalink raw reply
* Re:* [BUG] "git clean" does not pay attention to its parameters
From: Junio C Hamano @ 2007-12-05 7:55 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Shawn Bohrer, git
In-Reply-To: <200712050654.lB56scKk000311@mi0.bluebottle.com>
Nanako Shiraishi <nanako3@bluebottle.com> writes:
> In a repository with LaTeX documents, I tried to see what *.aux files are left behind after formatting, by running "git clean -n" with the latest git (1.5.3.7-1005-gdada0c1):
>
> % git clean -n '*.aux'
>
> This however showed more than just '*.aux' files. With the released version 1.5.3.6, the output is correctly limited to the files that match the pattern.
Yuck. People actually use git-clean?
But thanks for reporting.
Comparing the corresponding part from builtin-ls-files.c and what
builtin-clean.c does, it does look broken.
Does this patch help? I am not sure why the directory side of the code
is written that way, but I have a suspicion that "was a directory
explicitly given as one of the pathspec" check is also bogus, although I
did not touch that part.
-- >8 --
[PATCH] git-clean: Honor pathspec.
git-clean "*.rej" should attempt to look at only paths that match
pattern "*.rej", but rewrite to C broke it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-clean.c | 31 ++++++++++++++++++++-----------
1 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/builtin-clean.c b/builtin-clean.c
index 56ae4eb..7dd901e 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -27,13 +27,14 @@ static int git_clean_config(const char *var, const char *value)
int cmd_clean(int argc, const char **argv, const char *prefix)
{
- int j;
+ int i;
int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, baselen = 0, config_set = 0;
struct strbuf directory;
struct dir_struct dir;
const char *path, *base;
static const char **pathspec;
+ char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet),
OPT__DRY_RUN(&show_only),
@@ -85,12 +86,17 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
read_directory(&dir, path, base, baselen, pathspec);
strbuf_init(&directory, 0);
- for (j = 0; j < dir.nr; ++j) {
- struct dir_entry *ent = dir.entries[j];
- int len, pos, specs;
+ if (pathspec) {
+ for (i = 0; pathspec[i]; i++)
+ ; /* nothing */
+ seen = xmalloc();
+ }
+
+ for (i = 0; i < dir.nr; i++) {
+ struct dir_entry *ent = dir.entries[i];
+ int len, pos;
struct cache_entry *ce;
struct stat st;
- char *seen;
/*
* Remove the '/' at the end that directory
@@ -114,15 +120,13 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
int matched_path = 0;
strbuf_addstr(&directory, ent->name);
if (pathspec) {
- for (specs =0; pathspec[specs]; ++specs)
- /* nothing */;
- seen = xcalloc(specs, 1);
- /* Check if directory was explictly passed as
- * pathspec. If so we want to remove it */
+ /*
+ * Check if directory was explictly passed as
+ * pathspec. If so we want to remove it.
+ */
if (match_pathspec(pathspec, ent->name, ent->len,
baselen, seen))
matched_path = 1;
- free(seen);
}
if (show_only && (remove_directories || matched_path)) {
printf("Would remove %s\n", directory.buf);
@@ -138,6 +142,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
}
strbuf_reset(&directory);
} else {
+ if (pathspec &&
+ !match_pathspec(pathspec, ent->name, ent->len,
+ baselen, seen))
+ continue; /* excluded */
if (show_only) {
printf("Would remove %s\n", ent->name);
continue;
@@ -147,6 +155,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
unlink(ent->name);
}
}
+ free(seen);
strbuf_release(&directory);
return 0;
--
1.5.3.7-2115-geb804
^ permalink raw reply related
* Re: [PATCH] Do not rely on the exit status of "unset" for unset variables
From: H.Merijn Brand @ 2007-12-05 8:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0712042242310.27959@racer.site>
On Tue, 4 Dec 2007 22:45:16 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> From: H.Merijn Brand <h.m.brand@xs4all.nl>
>
> POSIX says that exit status "0" means that "unset" successfully unset
> the variable. However, it is kind of ambiguous if an environment
> variable which was not set could be successfully unset.
>
> At least the default shell on HP-UX insists on reporting an error in
please, for now make that HP-UX 11.11 and older. I'll check if it also
fails in 11.23/IPF.
On 11.11 HP C-ANSI-C cannot be used either.
And I have to remove "#include <sys/select.h>" from pager.c on HP-UX, I
forgot to tell. With the Makefile change in place, building with 64bit
gcc,
--8<--- skip this part if you're not interested in 64bit builds on HP-UX
On 64bit gcc on HP-UX, there is no strtoull (). Nowhere! strtoul () is
the same there. But this is only in the 64bit world, so NO_STRTOULL can
not be set to YesPlease unconditionally. When I also set NO_STRTOUMAX,
I get shiploads of warnings like:
CC commit.o
In file included from cache.h:4,
from commit.c:1:
git-compat-util.h:166:1: warning: "strtoumax" redefined
In file included from git-compat-util.h:62,
from cache.h:4,
from commit.c:1:
/usr/include/inttypes.h:527:1: warning: this is the location of the previous
definition
And that is NOT your fault, as this include file has defines like
** When compiling in ILP32 mode long long will be used for the 64-bit data
** types. This will cause compilation errors if 64-bit data types are
** requested and the compiler in use does not support them.
#define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)
#define strtoumax(__a, __b, __c) __strtoull(__a, __b, __c)
and that is not guarded with something like
/* LP64 takes precedence */
#if (defined(__STDC_EXT__) || defined(_INCLUDE_LONGLONG))
&& !defined(__LP64__)
so I ended up replacing all strtoumax () to strtoul () in git-fast-import.c
Then I end up with the same error as on 11.00.
-->8---
> such a case, so just ignore the exit status of "unset".
>
> [Dscho: extended the patch to git-submodule.sh, as Junio realized that
> this is the only other place where we check the exit status of "unset".]
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Tue, 4 Dec 2007, Junio C Hamano wrote:
>
> > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> >
> > > On Tue, 4 Dec 2007 15:39:47 +0000 (GMT), Johannes Schindelin
> > > ...
> > > I found it! unset returns false
> > > ...
> > > I must leave now.
> >
> > Thanks, you two.
> >
> > I do not see "unset VAR... &&" outside t0001 test, but there are
> > instances of "unset VAR... &&" in git-submodule implementations
> > as well.
> >
> > In short, not too many places to fix.
>
> You're right. I grepped for "unset" in t/*.sh, but that catches
> only false positives other than t0001.
>
> Merijn, maybe you want to have your sign-off in the commit
> message?
Feel free to do so, I don't really care.
Will you also be looking into the install issue?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Building git-1.5.3.7 on HP-UX 11.00
From: H.Merijn Brand @ 2007-12-05 8:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andreas Ericsson, git, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0712042245440.27959@racer.site>
On Tue, 4 Dec 2007 22:46:30 +0000 (GMT), Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 4 Dec 2007, H.Merijn Brand wrote:
>
> > * FAIL 17: non-match
> > git config --get nextsection.nonewline !for
> > * FAIL 18: non-match value
> > test wow = $(git config --get nextsection.nonewline !for)
>
> Can you investigate further with "-i -v" and/or "-x"? Could be the
> exclamation mark...
* expecting success: git config --get nextsection.nonewline !for
* FAIL 17: non-match
git config --get nextsection.nonewline !for
+ git config nextsection.NoNewLine wow2 for me for me$
+ cat
+ 1> expect 0< /var/tmp/sh4066.13
+ test_expect_success multivar cmp .git/config expect
* expecting success: cmp .git/config expect
* ok 16: multivar
+ test_expect_success non-match git config --get nextsection.nonewline !for
* expecting success: git config --get nextsection.nonewline !for
* FAIL 17: non-match
git config --get nextsection.nonewline !for
> Ciao,
> Dscho
>
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Documentation: add a new man page for "git-help" and -i|--info option.
From: Väinö Järvelä @ 2007-12-05 8:19 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071204064429.1b5007b2.chriscool@tuxfamily.org>
[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]
Patch attached to fix header error in this patch.
(Attached because Mail.app mangles inline patches)
--
Väinö
On Dec 4, 2007, at 07:44, Christian Couder wrote:
> Option -i|--info for "git-help" is documented only in the new
> "git-help.txt" man page, but this new man page is referenced
> from the "--help" option documentation in the "git.txt" man page.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Documentation/git-help.txt | 53 +++++++++++++++++++++++++++++++++++
> +++++++++
> Documentation/git.txt | 11 ++++++--
> 2 files changed, 61 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/git-help.txt
>
> This is a first documentation patch in my git-help
> improvement series.
>
> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
> new file mode 100644
> index 0000000..232daae
> --- /dev/null
> +++ b/Documentation/git-help.txt
> @@ -0,0 +1,53 @@
> +git-help(1)
> +======
> +
> +NAME
> +----
> +git-help - display help information about git
> +
> +SYNOPSIS
> +--------
> +'git help' [-a|--all|-i|--info] [COMMAND]
> +
> +DESCRIPTION
> +-----------
> +
> +With no options and no COMMAND given, the synopsis of the 'git'
> +command and a list of the most commonly used git commands are printed
> +on the standard output.
> +
> +If the option '--all' or '-a' is given, then all available commands
> are
> +printed on the standard output.
> +
> +If a git command is named, a manual page for that command is brought
> +up. The 'man' program is used by default for this purpose, but this
> +can be overriden by other options.
> +
> +Note that 'git --help ...' is identical as 'git help ...' because the
> +former is internally converted into the latter.
> +
> +OPTIONS
> +-------
> +-a|--all::
> +
> + Prints all the available commands on the standard output. This
> + option superseeds any other option.
> +
> +-i|--info::
> + Use the 'info' program to display the manual page, instead of
> + the 'man' program that is used by default.
> +
> +Author
> +------
> +Written by Junio C Hamano <gitster@pobox.com> and the git-list
> +<git@vger.kernel.org>.
> +
> +Documentation
> +-------------
> +Initial documentation was part of the gitlink:git[7] man page.
> +Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
> +little. Maintenance is done by the git-list <git@vger.kernel.org>.
> +
> +GIT
> +---
> +Part of the gitlink:git[7] suite
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 5460201..f8d1eef 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -100,9 +100,14 @@ OPTIONS
>
> --help::
> Prints the synopsis and a list of the most commonly used
> - commands. If a git command is named this option will bring up
> - the man-page for that command. If the option '--all' or '-a' is
> - given then all available commands are printed.
> + commands. If the option '--all' or '-a' is given then all
> + available commands are printed. If a git command is named this
> + option will bring up the manual page for that command.
> +
> + Other options are available to control how the manual page is
> + displayed. See gitlink:git-help[1] for more information,
> + because 'git --help ...' is converted internally into 'git
> + help ...'.
>
> --exec-path::
> Path to wherever your core git programs are installed.
> --
> 1.5.3.6.1993.g154f-dirty
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: 0001-Fixed-git-help.txt-header-error.patch --]
[-- Type: application/octet-stream, Size: 738 bytes --]
From 6d9fa82be1074a9fe6bf3fad36a838c1142966ca Mon Sep 17 00:00:00 2001
From: =?utf-8?q?V=C3=A4in=C3=B6=20J=C3=A4rvel=C3=A4?= <v@pp.inet.fi>
Date: Wed, 5 Dec 2007 10:05:48 +0200
Subject: [PATCH] Fixed git-help.txt header error
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
Documentation/git-help.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index 232daae..c94e27b 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -1,5 +1,5 @@
git-help(1)
-======
+===========
NAME
----
--
1.5.3.7.2115.geb80
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply related
* Re: [PATCH] Documentation: add a new man page for "git-help" and -i|--info option.
From: Wincent Colaiuta @ 2007-12-05 8:27 UTC (permalink / raw)
To: Väinö Järvelä; +Cc: Christian Couder, Junio Hamano, git
In-Reply-To: <178B37CE-9B28-4CE2-B8A0-FCA28CF85E12@pp.inet.fi>
El 5/12/2007, a las 9:19, Väinö Järvelä escribió:
> Patch attached to fix header error in this patch.
>
> (Attached because Mail.app mangles inline patches)
I'm a Mail.app user as well. Any reason why you can't use "git send-
email"? It's very useful.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Documentation: add a new man page for "git-help" and -i|--info option.
From: Väinö Järvelä @ 2007-12-05 8:33 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Christian Couder, Junio Hamano, git
In-Reply-To: <B4734D40-9EE8-4B96-9426-FF5974F8488E@wincent.com>
On Dec 5, 2007, at 10:27, Wincent Colaiuta wrote:
> El 5/12/2007, a las 9:19, Väinö Järvelä escribió:
>
>> Patch attached to fix header error in this patch.
>>
>> (Attached because Mail.app mangles inline patches)
>
> I'm a Mail.app user as well. Any reason why you can't use "git send-
> email"? It's very useful.
I didn't remember that send-email had "--in-reply-to" parameter, and I
thought it would be cleaner to send as a reply. Thus I used Mail.app.
--
Väinö
^ 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