* [PATCH v4 1/4] Documentation: fix typos and spelling in git-replace documentation
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
This patch fix a missing "s" at the end of an occurence of
"--no-replace-objects" and, while at it, it also improves spelling
and rendering of the git-replace man page.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 8adc1ef..69f704f 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -17,31 +17,32 @@ DESCRIPTION
Adds a 'replace' reference in `.git/refs/replace/`
The name of the 'replace' reference is the SHA1 of the object that is
-replaced. The content of the replace reference is the SHA1 of the
+replaced. The content of the 'replace' reference is the SHA1 of the
replacement object.
-Unless `-f` is given, the replace reference must not yet exist in
+Unless `-f` is given, the 'replace' reference must not yet exist in
`.git/refs/replace/` directory.
-Replace references will be used by default by all git commands except
-those doing reachability traversal (prune, pack transfer and fsck).
+Replacement references will be used by default by all git commands
+except those doing reachability traversal (prune, pack transfer and
+fsck).
-It is possible to disable use of replacement refs for any command
-using the --no-replace-objects option just after "git".
+It is possible to disable use of replacement references for any
+command using the `--no-replace-objects` option just after 'git'.
-For example if commit "foo" has been replaced by commit "bar":
+For example if commit 'foo' has been replaced by commit 'bar':
------------------------------------------------
-$ git --no-replace-object cat-file commit foo
+$ git --no-replace-objects cat-file commit foo
------------------------------------------------
-show information about commit "foo", while:
+shows information about commit 'foo', while:
------------------------------------------------
$ git cat-file commit foo
------------------------------------------------
-show information about commit "bar".
+shows information about commit 'bar'.
OPTIONS
-------
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 3/4] gitk: add "--no-replace-objects" option
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state, and
"--no-replace-objects" option can be used from the command
line to do so.
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
gitk-git/gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..c586b93 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -128,7 +128,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
+ "--no-replace-objects" {
+ set env(GIT_NO_REPLACE_OBJECTS) "1"
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 4/4] Documentation: replace: talk a little bit about GIT_NO_REPLACE_OBJECTS
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
It may be useful to know that this environment variable can be used
to prevent commands from using replacement refs.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 69f704f..65a0da5 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -44,6 +44,9 @@ $ git cat-file commit foo
shows information about commit 'bar'.
+The 'GIT_NO_REPLACE_OBJECTS' environment variable can be set to
+achieve the same effect as the `--no-replace-objects` option.
+
OPTIONS
-------
-f::
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 2/4] replace: use a GIT_NO_REPLACE_OBJECTS env variable
From: Christian Couder @ 2009-11-22 6:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091122064652.4811.38993.chriscool@tuxfamily.org>
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state, and
the "--no-replace-objects" option can be used from the command
line to do so.
But the effects of this command line option were not propagated
to git commands called by the original command that was passed
this option.
The goal of this patch is to propagate these effects by using
a new GIT_NO_REPLACE_OBJECTS environment variable.
This environment variable is set when the --no-replace-objects
flag is passed to git, and it is read when other environment
variables are read.
It is useful for example for scripts, as the git commands used in
them can now be aware that they must not read replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
cache.h | 1 +
connect.c | 1 +
environment.c | 2 ++
git.c | 3 +++
t/t6050-replace.sh | 17 +++++++++++++++++
5 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 22a06d6..fcdc954 100644
--- a/cache.h
+++ b/cache.h
@@ -374,6 +374,7 @@ static inline enum object_type object_type(unsigned int mode)
#define CONFIG_ENVIRONMENT "GIT_CONFIG"
#define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
#define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
+#define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
#define ATTRIBUTE_MACRO_PREFIX "[attr]"
diff --git a/connect.c b/connect.c
index 839a103..db965c9 100644
--- a/connect.c
+++ b/connect.c
@@ -609,6 +609,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
GIT_WORK_TREE_ENVIRONMENT,
GRAFT_ENVIRONMENT,
INDEX_ENVIRONMENT,
+ NO_REPLACE_OBJECTS_ENVIRONMENT,
NULL
};
conn->env = env;
diff --git a/environment.c b/environment.c
index ed17043..c7ebc54 100644
--- a/environment.c
+++ b/environment.c
@@ -85,6 +85,8 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = git_pathdup("info/grafts");
+ if (read_replace_refs && getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
+ read_replace_refs = 0;
}
int is_bare_repository(void)
diff --git a/git.c b/git.c
index 743ee57..11544cd 100644
--- a/git.c
+++ b/git.c
@@ -89,6 +89,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--no-replace-objects")) {
read_replace_refs = 0;
+ setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "1", 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index d4818b4..203ffdb 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -77,6 +77,11 @@ test_expect_success 'test --no-replace-objects option' '
git --no-replace-objects show $HASH2 | grep "A U Thor"
'
+test_expect_success 'test GIT_NO_REPLACE_OBJECTS env variable' '
+ GIT_NO_REPLACE_OBJECTS=1 git cat-file commit $HASH2 | grep "author A U Thor" &&
+ GIT_NO_REPLACE_OBJECTS=1 git show $HASH2 | grep "A U Thor"
+'
+
cat >tag.sig <<EOF
object $HASH2
type commit
@@ -202,6 +207,18 @@ test_expect_success 'fetch branch with replacement' '
cd ..
'
+test_expect_success 'bisect and replacements' '
+ git bisect start $HASH7 $HASH1 &&
+ test "$S" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ GIT_NO_REPLACE_OBJECTS=1 git bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset &&
+ git --no-replace-objects bisect start $HASH7 $HASH1 &&
+ test "$HASH4" = "$(git rev-parse --verify HEAD)" &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Laszlo Papp @ 2009-11-22 8:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, git
In-Reply-To: <19205.2740.244981.703612@cargo.ozlabs.ibm.com>
On Thu, Nov 19, 2009 at 10:07 AM, Paul Mackerras <paulus@samba.org> wrote:
> Laszlo Papp writes:
>
>> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
>> ---
>> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Is there a patch 1/2 that needs to be applied first, as the subject
> line might imply?
>
> Paul.
>
It's the file of the new hungarian translation, it can be applied
alone without any plus file/patch.
Best Regards,
Laszlo Papp
^ permalink raw reply
* [PATCH] User Manual: Write "Git" instead of "GIT"
From: Björn Gustavsson @ 2009-11-22 9:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In the Table of Contents, there is a notable inconsistency:
first there is "GIT Glossary", followed by "Git Quick Reference"
on the very next line.
Running "grep -c" on user-manual.txt, I find 780 occurrrences of
"git", 37 occurrences of "Git", and 9 occurrences of "GIT".
In general, "git" is the preferred spelling, except at the
beginning of a sentence.
Therefore, change "GIT Glossary" to "Git Glossary" for consistency
with the rest of the document.
Looking at the other eight occurrences of "GIT" I found one other
occurrence that should be changed:
* The mention of "StGIT". Looking at the web pages for "Stacked Git"
at http://www.procode.org/stgit, I only saw the spelling "StGit",
except in http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial,
but that page was last updated in 2006.
The other seven occurrences should not be changed:
* Three occurrences were in the output of 'git show-branch' run
on the git.git repository.
* One occurrence was in the output of 'git cat-file'.
* One occurrence was as part of the file name "GIT-VERSION-GEN".
* Two occurrences were in comments in scripts quoted in a description
of Tony Luck's workflow.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/user-manual.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..27d97b6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2569,7 +2569,7 @@ them again with linkgit:git-am[1].
Other tools
-----------
-There are numerous other tools, such as StGIT, which exist for the
+There are numerous other tools, such as StGit, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
@@ -4275,7 +4275,7 @@ You see, Git is actually the best tool to find out about the source of Git
itself!
[[glossary]]
-GIT Glossary
+Git Glossary
============
include::glossary-content.txt[]
--
1.6.5.3.298.g39add
^ permalink raw reply related
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-22 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v1vjrmfjw.fsf@alter.siamese.dyndns.org>
On Sun, Nov 22, 2009 at 4:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> There are no tests for 'envelope-sender', so I don't think it should
>> be a requirement for this patch to do so....
>
> The fact that the lack of test was pointed out as a problem makes it a
> requirement. Others' earlier mistakes are not an excuse for you to do a
> poor job.
Maybe I should wait until somebody adds the tests to --envelope-sender
before pushing this patch.
> I do use --envelope-sender when sending patches out via msmtp. What
> wonderful things this patch adds am I missing in my current setup?
You need to specify your mail address when setting the variable,
right? I use multiple email addresses, so that when I change it
($EMAIL or user.email) the right one will be used in the envelope. If
I use 'sendemail.envelopesender' I would
need to change it as well.
Another option is to do something like 'sendemail.envelopesender=auto'.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-22 12:37 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <94a0d4530911211159l1fadad0ldb0d760439ceb57@mail.gmail.com>
On Sat, Nov 21, 2009 at 9:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sat, Nov 21, 2009 at 9:36 PM, Jeff King <peff@peff.net> wrote:
>> --envelope-from is IMHO confusingly similar to
>> --envelope-sender. Maybe --use-from-in-envelope would be a better name?
>
> Ok. I don't have any opinion on the name.
I thought a bit more about this, and in the end what we really want is
to add the sender envelope. The most typical case would be to use the
'from' address, but we should be able to override it (we do both by
using --envelope-sender).
So here are other options.
a) --add-envelope: add the sender envelope, by default it would be the
'from' address, but could be overridden by --envelope-sender.
b) --envelope-sender="" or "auto": this would require minimal changes
but looks a bit strange.
Any thoughts?
--
Felipe Contreras
^ permalink raw reply
* git-svn: Fails to drop leading path from empty dir name
From: Björn Steinbrink @ 2009-11-22 13:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi Eric,
the stuff to create empty directories fails to strip leading path
components, e.g. when using
"git svn clone -s svn://whatever/project/trunk".
Instead of creating the empty directory "foo" in the repo root, it
creates "project/trunk/foo".
Ad hoc patch for the test case below.
Björn
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 5948544..9e22089 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
)
'
+test_expect_success 'initialize trunk' '
+ for i in trunk trunk/a trunk/"weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
+
+test_expect_success 'empty directories in trunk exist' '
+ (
+ cd cloned &&
+ for i in trunk/a trunk/"weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH/RFC 0/3] git rerere unresolve file
From: Johannes Sixt @ 2009-11-22 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v6393mfqz.fsf@alter.siamese.dyndns.org>
On Sonntag, 22. November 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > ... But
> > there is no other way to remove an incorrect resolution short of purging
> > the whole rr-cache.
>
> No, no no, no. You do not have to.
Oh, yeah, I know. But even for people who know how to drive plumbing commands,
this:
> "ls -t1 .git/rr-cache/*/thisimage | head"
> would be one way to manually find out which one it is.
does not count as "you can" in my book. ;) It assumes that there are at most a
handful conflicted files. In my case, for example, I have to fix a merge
where there are ~100 conflicted files.
> * Then the user tells rerere that "this is the corrected resolution",
> perhaps
>
> $ git rerere update Documentation/git-commit.txt
>
> This will
>
> - Internally recompute the original conflicted state, i.e. run
> "checkout --conflict=merge Documentation/git-commit.txt" in-core;
>
> - feed it to rerere.c::handle_file() to learn the conflict hash;
>
> - read the user's updated resolution from the work tree, and update
> "postimage" with it.
>
> ...
>
> The "forget" subcommand may be useful, but the real implementation should
> be the first half of the "update", iow, recreate conflict in-core in order
> to compute the conflict hash, and drop existing "postimage", without
> replacing it from the work tree. We should leave it up to the user using
> "checkout --conflict" to reproduce the conflict in the work tree.
Thank you for your elaborate feedback and the guidelines about how to move
forward.
I actually think that 'forget' should be the primary subcommand. Because after
the postimage was purged, the next implicit or explicit 'git rerere' will
record the resolution anyway. I'll see what I can do.
-- Hannes
^ permalink raw reply
* how to suppress progress percentage in git-push
From: bill lam @ 2009-11-22 14:53 UTC (permalink / raw)
To: git
I set crontab to push to another computer for backup. It sent
confirmation email after finished. It looked like
Counting objects: 1
Counting objects: 9, done.
Delta compression using up to 2 threads.
Compressing objects: 20% (1/5)
Compressing objects: 40% (2/5)
Compressing objects: 60% (3/5)
Compressing objects: 80% (4/5)
Compressing objects: 100% (5/5)
Compressing objects: 100% (5/5), done.
Writing objects: 20% (1/5)
Writing objects: 40% (2/5)
Writing objects: 60% (3/5)
Writing objects: 80% (4/5)
Writing objects: 100% (5/5)
Writing objects: 100% (5/5), 549 bytes, done.
Total 5 (delta 3), reused 0 (delta 0)
Often the list of progress % can be a page long. I want output but
not those percentage progress status. Will that be possible?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: How to make git diff-* ignore some patterns?
From: Dirk Süsserott @ 2009-11-22 15:51 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Git Mailing List, git
In-Reply-To: <20091121180738.GA14919@atjola.homenet>
Am 21.11.2009 19:07 schrieb Björn Steinbrink:
> On 2009.11.21 17:40:14 +0100, Dirk Süsserott wrote:
>> is there a way to tell "git diff-index" to ignore some special
>> patterns, such that /^-- Dump completed on .*$/ is NOT recognized as
>> a difference and "git diff-index" returns 0 if that's the only
>> difference?
>
> If you don't mind losing that line, you could use a clean filter via
> .gitattributes:
>
> echo '*.sql filter=mysql_dump' >> .gitattributes
> git config filter.mysql_dump.clean "sed -e '/^-- Dump completed on .*$/d'"
>
> That way, git will filter all *.sql paths through that sed command
> before storing them as blobs, dropping that "Dump completed" line from
> the data stored in the repo.
>
> Björn
>
Thank you Björn and Michael,
Your suggestions were really helpful. I decided to use Björn's 'clean
filter' approach. It works great.
-- Dirk
^ permalink raw reply
* Re: [PATCH] unset GREP_OPTIONS in test-lib.sh
From: René Scharfe @ 2009-11-22 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bert Wesarg, git
In-Reply-To: <7v1vjvebem.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Do we kill that environment variable when we call out to external grep in
> grep.c? If not, we should. An alternative is to teach our internal one
> to also honor it, but I personally do not find it too attractive to mimic
> the design mistake of GREP_OPTIONS myself.
We don't. Here's a patch with a simple test case that makes git grep
unset GREP_OPTIONS before it calls the external grep.
While we're at it, also unset GREP_COLOR and GREP_COLORS in case
colouring is not enabled, to be on the safe side. The presence of
these variables alone is not sufficient to trigger coloured output with
GNU grep, but other implementations may behave differently.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-grep.c | 4 ++++
t/t7002-grep.sh | 5 +++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 01be9bf..9a9e3fc 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -433,7 +433,11 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
if (opt->color_external && strlen(opt->color_external) > 0)
push_arg(opt->color_external);
+ } else {
+ unsetenv("GREP_COLOR");
+ unsetenv("GREP_COLORS");
}
+ unsetenv("GREP_OPTIONS");
hit = 0;
argc = nr;
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae5290a..dd0da6c 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -213,6 +213,11 @@ test_expect_success 'grep -e A --and --not -e B' '
test_cmp expected actual
'
+test_expect_success 'grep should ignore GREP_OPTIONS' '
+ GREP_OPTIONS=-v git grep " mmap bar\$" >actual &&
+ test_cmp expected actual
+'
+
test_expect_success 'grep -f, non-existent file' '
test_must_fail git grep -f patterns
'
--
1.6.5.3
^ permalink raw reply related
* [PATCH] strbuf_add_wrapped_text(): factor out strbuf_add_indented_text()
From: René Scharfe @ 2009-11-22 16:15 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Add a new helper function, strbuf_add_indented_text(), to indent text
without a width limit, and call it from strbuf_add_wrapped_text(). It
respects both indent (applied to the first line) and indent2 (applied to
the rest of the lines); indent2 was ignored by the indent-only path of
strbuf_add_wrapped_text() before the patch.
Two simple test cases are added, one exercising strbuf_add_wrapped_text()
and the other strbuf_add_indented_text().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t4202-log.sh | 21 +++++++++++++++++++++
utf8.c | 26 +++++++++++++++++---------
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1e952ca..779a5ad 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -64,6 +64,27 @@ test_expect_success 'format' '
'
cat > expect << EOF
+ This is
+ the sixth
+ commit.
+ This is
+ the fifth
+ commit.
+EOF
+
+test_expect_success 'format %w(12,1,2)' '
+
+ git log -2 --format="%w(12,1,2)This is the %s commit." > actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'format %w(,1,2)' '
+
+ git log -2 --format="%w(,1,2)This is%nthe %s%ncommit." > actual &&
+ test_cmp expect actual
+'
+
+cat > expect << EOF
804a787 sixth
394ef78 fifth
5d31159 fourth
diff --git a/utf8.c b/utf8.c
index 5c18f0c..01d1869 100644
--- a/utf8.c
+++ b/utf8.c
@@ -298,6 +298,22 @@ static void print_spaces(struct strbuf *buf, int count)
strbuf_write(buf, s, count);
}
+static void strbuf_add_indented_text(struct strbuf *buf, const char *text,
+ int indent, int indent2)
+{
+ if (indent < 0)
+ indent = 0;
+ while (*text) {
+ const char *eol = strchrnul(text, '\n');
+ if (*eol == '\n')
+ eol++;
+ print_spaces(buf, indent);
+ strbuf_write(buf, text, eol - text);
+ text = eol;
+ indent = indent2;
+ }
+}
+
/*
* Wrap the text, if necessary. The variable indent is the indent for the
* first line, indent2 is the indent for all other lines.
@@ -311,15 +327,7 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
const char *bol = text, *space = NULL;
if (width <= 0) {
- /* just indent */
- while (*text) {
- const char *eol = strchrnul(text, '\n');
- if (*eol == '\n')
- eol++;
- print_spaces(buf, indent);
- strbuf_write(buf, text, eol-text);
- text = eol;
- }
+ strbuf_add_indented_text(buf, text, indent, indent2);
return 1;
}
--
1.6.5.3
^ permalink raw reply related
* [PATCH] log --format: document %w
From: René Scharfe @ 2009-11-22 16:15 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
I'm not especially proud of the triple negative in that note. How to say it
better, yet concise?
Documentation/pretty-formats.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 0946202..7ff6a6c 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -135,6 +135,10 @@ The placeholders are:
- '%m': left, right or boundary mark
- '%n': newline
- '%x00': print a byte from a hex code
+- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
+ linkgit:git-shortlog[1]. NOTE: Color placeholders (`%C*`) are not
+ recognized as having no width, so they should not be put into wrapped
+ sections.
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
--
1.6.5.3
^ permalink raw reply related
* [PATCH 0/4] Update documentation of apply
From: Björn Gustavsson @ 2009-11-22 16:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The following patch series improves the documentation of 'git apply'.
Björn Gustavsson (4):
apply: Clarify the description of -z
apply: apply works outside a repository
apply: Use the term "working tree" consistently
apply: Format all options using back-quotes
Documentation/git-apply.txt | 38 ++++++++++++++++++++++----------------
1 files changed, 22 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 1/4] apply: Clarify the description of -z
From: Björn Gustavsson @ 2009-11-22 16:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The description of -z says that a machine-readable format will be
used "when showing the index information". From that description,
it is not at all clear which other option it will modify the
behaviour of. Explicitly state that -z modifies the behavior
of --numstat.
Also correct the description of the "munging" that takes places
in the absence of -z, namely that apart from the characters
mentioned, double quotes are also escaped and that the pathname
will be enclosed in double quotes if any characters are escaped.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/git-apply.txt | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 5ee8c91..4f791ee 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -87,11 +87,13 @@ the information is read from the current index instead.
rejected hunks in corresponding *.rej files.
-z::
- When showing the index information, do not munge paths,
- but use NUL terminated machine readable format. Without
- this flag, the pathnames output will have TAB, LF, and
- backslash characters replaced with `\t`, `\n`, and `\\`,
- respectively.
+ When `--numstat` has been given, do not munge pathnames,
+ but use a NUL-terminated machine-readable format.
++
+Without this flag, each pathname output will have TAB, LF, double quotes,
+and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
+respectively, and the pathname will be enclosed in double quotes if
+any of those replacements occurred.
-p<n>::
Remove <n> leading slashes from traditional diff paths. The
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH 2/4] apply: apply works outside a repository
From: Björn Gustavsson @ 2009-11-22 16:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The documentation for 'git apply' talks about applying a
patch/diff to the index and to the working tree, which seems
to imply that it will not work outside a git repository.
Actually 'git patch' works outside a repository (which can
be useful especially for applying binary or rename patches that
the standard "patch" utility cannot handle), so the documentation
should mention it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/git-apply.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 4f791ee..6857a68 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -23,6 +23,10 @@ DESCRIPTION
Reads supplied 'diff' output and applies it on a git index file
and a work tree.
+'git-apply' can also be used outside a git repository as long
+as no options that require a git repository are given
+(e.g. `--index` or `--cached`).
+
OPTIONS
-------
<patch>...::
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH 3/4] apply: Use the term "working tree" consistently
From: Björn Gustavsson @ 2009-11-22 16:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The documentation for 'git apply' uses both the terms
"work tree" and "working tree". Since the glossary uses
the term "working tree", change all occurrences of
"work tree" to "working tree".
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/git-apply.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 6857a68..8349373 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -21,7 +21,7 @@ SYNOPSIS
DESCRIPTION
-----------
Reads supplied 'diff' output and applies it on a git index file
-and a work tree.
+and a working tree.
'git-apply' can also be used outside a git repository as long
as no options that require a git repository are given
@@ -52,7 +52,7 @@ OPTIONS
--check::
Instead of applying the patch, see if the patch is
- applicable to the current work tree and/or the index
+ applicable to the current working tree and/or the index
file and detects errors. Turns off "apply".
--index::
@@ -60,7 +60,7 @@ OPTIONS
(which is the default when none of the options that
disables it is in effect), make sure the patch is
applicable to what the current index file records. If
- the file to be patched in the work tree is not
+ the file to be patched in the working tree is not
up-to-date, it is flagged as an error. This flag also
causes the index file to be updated.
--
1.6.5.3.298.g39add
^ permalink raw reply related
* [PATCH 4/4] apply: Format all options using back-quotes
From: Björn Gustavsson @ 2009-11-22 16:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Documentation/git-apply.txt | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 8349373..7f863cd 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -38,7 +38,7 @@ OPTIONS
input. Turns off "apply".
--numstat::
- Similar to \--stat, but shows the number of added and
+ Similar to `--stat`, but shows the number of added and
deleted lines in decimal notation and the pathname without
abbreviation, to make it more machine friendly. For
binary files, outputs two `-` instead of saying
@@ -56,7 +56,7 @@ OPTIONS
file and detects errors. Turns off "apply".
--index::
- When --check is in effect, or when applying the patch
+ When `--check` is in effect, or when applying the patch
(which is the default when none of the options that
disables it is in effect), make sure the patch is
applicable to what the current index file records. If
@@ -67,7 +67,7 @@ OPTIONS
--cached::
Apply a patch without touching the working tree. Instead take the
cached data, apply the patch, and store the result in the index
- without using the working tree. This implies '--index'.
+ without using the working tree. This implies `--index`.
--build-fake-ancestor=<file>::
Newer 'git-diff' output has embedded 'index information'
@@ -113,8 +113,8 @@ any of those replacements occurred.
By default, 'git-apply' expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
- applying a diff generated with --unified=0. To bypass these
- checks use '--unidiff-zero'.
+ applying a diff generated with `--unified=0`. To bypass these
+ checks use `--unidiff-zero`.
+
Note, for the reasons stated above usage of context-free patches is
discouraged.
@@ -150,7 +150,7 @@ discouraged.
be useful when importing patchsets, where you want to include certain
files or directories.
+
-When --exclude and --include patterns are used, they are examined in the
+When `--exclude` and `--include` patterns are used, they are examined in the
order they appear on the command line, and the first match determines if a
patch to each path is used. A patch to a path that does not match any
include/exclude pattern is used by default if there is no include pattern
@@ -233,13 +233,13 @@ Submodules
If the patch contains any changes to submodules then 'git-apply'
treats these changes as follows.
-If --index is specified (explicitly or implicitly), then the submodule
+If `--index` is specified (explicitly or implicitly), then the submodule
commits must match the index exactly for the patch to apply. If any
of the submodules are checked-out, then these check-outs are completely
ignored, i.e., they are not required to be up-to-date or clean and they
are not updated.
-If --index is not specified, then the submodule commits in the patch
+If `--index` is not specified, then the submodule commits in the patch
are ignored and only the absence or presence of the corresponding
subdirectory is checked and (if possible) updated.
--
1.6.5.3.298.g39add
^ permalink raw reply related
* Re: [PATCH] send-email: new 'add-envelope' option
From: Junio C Hamano @ 2009-11-22 16:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530911220403w7238dab7saf18830a89f2add5@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> I do use --envelope-sender when sending patches out via msmtp. What
>> wonderful things this patch adds am I missing in my current setup?
>
> You need to specify your mail address when setting the variable, right?
> I use multiple email addresses, so that when I change it ($EMAIL or
> user.email) the right one will be used in the envelope. If I use
> 'sendemail.envelopesender' I would need to change it as well.
Ahh, I see. The above would be a good addition to the documentation part
of the patch.
^ permalink raw reply
* Re: [PATCH] log --format: document %w
From: Junio C Hamano @ 2009-11-22 17:10 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <4B0963A3.4060804@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> I'm not especially proud of the triple negative in that note. How to say it
> better, yet concise?
> +- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
> + linkgit:git-shortlog[1]. NOTE: Color placeholders (`%C*`) are not
> + recognized as having no width, so they should not be put into wrapped
> + sections.
"The code miscounts the width of '%C*' color placeholders"?
Perhaps somebody in the codepath leading to pick_one_utf8_char() in utf8.c
can be made aware of them?
utf8_width() is called from many places (has one caller outside utf8.c as
well). It is given a pointer to a pointer that points at the current
position in a string, and is responsible for picking up one logical letter
advancing the given pointer to skip over that letter, and returning the
display width of that one letter. The function wants the string to be
encoded in utf-8 and signals by putting NULL in the pointer when it
detects the input string is not.
Picking up one logical letter is done by pick_one_utf8_char(), which is a
nicely written generic "We are at the character boundary of a potentially
multi-byte utf-8 string; pick the first character" implementation, and we
wouldn't want to contaminate that with escape sequence logic---we might
want to reuse it in other codepaths where we have no reason to expect any
escape sequences.
So perhaps we can introduce is_esc_sequence(s, r, w) that
- returns true if we are at the beginning of an esc-sequence;
- skips the sequence just like utf8_width() does with s and r; and
- counts the width of the sequence and returns it in *w
The implementation of the is_esc_sequence() could be to only detect the
color sequence (if the sequence has things like cursor-position control
then we are already lost, as calling "utf8_width()" on such a string does
not make much sense anyway) and report zero-width.
I dunno.
diff --git a/utf8.c b/utf8.c
index 5c18f0c..d45e75f 100644
--- a/utf8.c
+++ b/utf8.c
@@ -241,7 +241,12 @@ invalid:
*/
int utf8_width(const char **start, size_t *remainder_p)
{
- ucs_char_t ch = pick_one_utf8_char(start, remainder_p);
+ ucs_char_t ch;
+ int w;
+
+ if (is_esc_sequence(start, remainder_p, &w))
+ return w;
+ ch = pick_one_utf8_char(start, remainder_p);
if (!*start)
return 0;
return git_wcwidth(ch);
^ permalink raw reply related
* Re: [PATCH 1/4] apply: Clarify the description of -z
From: Junio C Hamano @ 2009-11-22 17:28 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B09648E.5060203@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> The description of -z says that a machine-readable format will be
> used "when showing the index information". From that description,
> it is not at all clear which other option it will modify the
> behaviour of. Explicitly state that -z modifies the behavior
> of --numstat.
>
> Also correct the description of the "munging" that takes places
> in the absence of -z, namely that apart from the characters
> mentioned, double quotes are also escaped and that the pathname
> will be enclosed in double quotes if any characters are escaped.
>
> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
> ---
> Documentation/git-apply.txt | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
> index 5ee8c91..4f791ee 100644
> --- a/Documentation/git-apply.txt
> +++ b/Documentation/git-apply.txt
> @@ -87,11 +87,13 @@ the information is read from the current index instead.
> rejected hunks in corresponding *.rej files.
>
> -z::
> - When showing the index information, do not munge paths,
> - but use NUL terminated machine readable format. Without
> - this flag, the pathnames output will have TAB, LF, and
> - backslash characters replaced with `\t`, `\n`, and `\\`,
> - respectively.
I think diff-format.txt has the same description; could you please update
that to be in sync?
^ permalink raw reply
* Re: [PATCH 3/4] apply: Use the term "working tree" consistently
From: Junio C Hamano @ 2009-11-22 17:28 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B0964C5.7040501@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> The documentation for 'git apply' uses both the terms "work tree" and
> "working tree". Since the glossary uses the term "working tree", change
> all occurrences of "work tree" to "working tree".
Consistency is good.
I'd personally vote for fixing it the other way around starting from the
glossary, though.
^ permalink raw reply
* Re: [PATCH 2/4] apply: apply works outside a repository
From: Junio C Hamano @ 2009-11-22 17:28 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B0964A1.2040302@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> The documentation for 'git apply' talks about applying a
> patch/diff to the index and to the working tree, which seems
> to imply that it will not work outside a git repository.
Thanks. I think the headline should also be reworded. It currently
reads:
Apply a patch on a git index file and/or a working tree
but historically and still in real life practices, when you use apply (as
opposed to am), you apply primarily to the files and optionally to the
index, so this should read something like:
Apply a patch to files and/or to the index
We could say "to files in the work tree", but that would give a wrong
impression that the files we talk about must be in a directory that is
part of the work tree of some repository, so it probably is better without
it.
The same comment applies to the beginning of the DESCRIPTION section. I
actually think your added text should reword the current two-liner there,
instead of being added at the bottom. Here is my attempt.
Reads supplied diff output (iow "a patch"), and applies it to files.
With --index (--cache) options, the patch is also (only) applied to
the index respectively. Without these options, the command applies
the patch only to files, and does not require them to be in a git
repository.
^ 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