* Re: [PATCH] git.c: add --index-file command-line option.
From: Manlio Perillo @ 2012-12-15 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vliczrttq.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 15/12/2012 20:36, Junio C Hamano ha scritto:
> [...]
>>>> Unlike other environment variables (e.g. GIT_WORK_TREE,
>>>> GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
>>>> environment variable using the command line.
>>>
>>> Is this necessary? I'd prefer to see a better reason than "just
>>> because others have it".
>>
>> A long running program will be able to tell git to use an alternate
>> index file, without having to modify its own environment,...
>
> Hrm, isn't that the single-shot environment export syntax
>
> GIT_INDEX_FILE=foo git blah
>
> is for? Is there a real-world need for this?
>
This works with a shell.
I'm using Python to write a custom git command.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDM8yQACgkQscQJ24LbaUTftQCbBC7D9P7Sqlr9GzWuCIcIHPf2
aQcAn13+d4trLZS4izGvZtoaopMav4nV
=vfb6
-----END PGP SIGNATURE-----
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1-rc2
From: Junio C Hamano @ 2012-12-15 20:54 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v1.8.1-rc2 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
0a65a3d203b8d6e320f15abb040e1137e333c967 git-1.8.1.rc2.tar.gz
e6bc111686e6864cc3f078b9523ef1057a7fff8f git-htmldocs-1.8.1.rc2.tar.gz
2c97472ae861454ff445868c40b49db66fa09f50 git-manpages-1.8.1.rc2.tar.gz
Also the following public repositories all have a copy of the v1.8.1-rc2
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.1 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this, and
"git push" will warn about the upcoming change until you set this
variable in this release.
"git branch --set-upstream" is deprecated and may be removed in a
relatively distant future. "git branch [-u|--set-upstream-to]" has
been introduced with a saner order of arguments to replace it.
Updates since v1.8.0
--------------------
UI, Workflows & Features
* Command-line completion scripts for tcsh and zsh have been added.
* A new remote-helper interface for Mercurial has been added to
contrib/remote-helpers.
* We used to have a workaround for a bug in ancient "less" that
causes it to exit without any output when the terminal is resized.
The bug has been fixed in "less" version 406 (June 2007), and the
workaround has been removed in this release.
* Some documentation pages that used to ship only in the plain text
format are now formatted in HTML as well.
* "git-prompt" scriptlet (in contrib/completion) can be told to paint
pieces of the hints in the prompt string in colors.
* A new configuration variable "diff.context" can be used to
give the default number of context lines in the patch output, to
override the hardcoded default of 3 lines.
* When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling. This can be disabled with the
advice.statusHints configuration variable.
* "git config --get" used to diagnose presence of multiple
definitions of the same variable in the same configuration file as
an error, but it now applies the "last one wins" rule used by the
internal configuration logic. Strictly speaking, this may be an
API regression but it is expected that nobody will notice it in
practice.
* "git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
* "git format-patch" learned the "--notes=<ref>" option to give
notes for the commit after the three-dash lines in its output.
* "git log --grep=<pcre>" learned to honor the "grep.patterntype"
configuration set to "perl".
* "git replace -d <object>" now interprets <object> as an extended
SHA-1 (e.g. HEAD~4 is allowed), instead of only accepting full hex
object name.
* "git rm $submodule" used to punt on removing a submodule working
tree to avoid losing the repository embedded in it. Because
recent git uses a mechanism to separate the submodule repository
from the submodule working tree, "git rm" learned to detect this
case and removes the submodule working tree when it is safe to do so.
* "git send-email" used to prompt for the sender address, even when
the committer identity is well specified (e.g. via user.name and
user.email configuration variables). The command no longer gives
this prompt when not necessary.
* "git send-email" did not allow non-address garbage strings to
appear after addresses on Cc: lines in the patch files (and when
told to pick them up to find more recipients), e.g.
Cc: Stable Kernel <stable@k.org> # for v3.2 and up
The command now strips " # for v3.2 and up" part before adding the
remainder of this line to the list of recipients.
* "git submodule add" learned to add a new submodule at the same
path as the path where an unrelated submodule was bound to in an
existing revision via the "--name" option.
* "git submodule sync" learned the "--recursive" option.
* "diff.submodule" configuration variable can be used to give custom
default value to the "git diff --submodule" option.
* "git symbolic-ref" learned the "-d $symref" option to delete the
named symbolic ref, which is more intuitive way to spell it than
"update-ref -d --no-deref $symref".
Foreign Interface
* "git cvsimport" can be told to record timezones (other than GMT)
per-author via its author info file.
* The remote helper interface to interact with subversion
repositories (one of the GSoC 2012 projects) has been merged.
* The documentation for git(1) was pointing at a page at an external
site for the list of authors that no longer existed. The link has
been updated to point at an alternative site.
Performance, Internal Implementation, etc.
* Compilation on Cygwin with newer header files are supported now.
* A couple of low-level implementation updates on MinGW.
* The logic to generate the initial advertisement from "upload-pack"
(i.e. what is invoked by "git fetch" on the other side of the
connection) to list what refs are available in the repository has
been optimized.
* The logic to find set of attributes that match a given path has
been optimized.
* Use preloadindex in "git diff-index" and "git update-index", which
has a nice speedup on systems with slow stat calls (and even on
Linux).
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.0
------------------
Unless otherwise noted, all the fixes since v1.8.0 in the maintenance
track are contained in this release (see release notes to them for
details).
* The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.
* The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a
BEL output.
* "git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle
it. Work it around by passing a temporary empty file.
* "git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* "git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM
instead.
* Update "remote tracking branch" in the documentation to
"remote-tracking branch".
* "git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* The refs/replace hierarchy was not mentioned in the
repository-layout docs.
* Various rfc2047 quoting issues around a non-ASCII name on the
From: line in the output from format-patch have been corrected.
* Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptor to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
A workaround has been added for this.
* For a fetch refspec (or the result of applying wildcard on one),
we always want the RHS to map to something inside "refs/"
hierarchy, but the logic to check it was not exactly right.
(merge 5c08c1f jc/maint-fetch-tighten-refname-check later to maint).
* "git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* Some HTTP servers ask for auth only during the actual packing phase
(not in ls-remote phase); this is not really a recommended
configuration, but the clients used to fail to authenticate with
such servers.
(merge 2e736fd jk/maint-http-half-auth-fetch later to maint).
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* Syntax highlighting in "gitweb" was not quite working.
* RSS feed from "gitweb" had a xss hole in its title output.
* "git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* "git checkout -b foo" while on an unborn branch did not say
"Switched to a new branch 'foo'" like other cases.
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
----------------------------------------------------------------
Changes since v1.8.1-rc1 are as follows:
Anders Kaseorg (1):
git-prompt: Document GIT_PS1_DESCRIBE_STYLE
Erik Faye-Lund (7):
mingw: correct exit-code for SIGALRM's SIG_DFL
mingw: make fgetc raise SIGINT if apropriate
compat/terminal: factor out echo-disabling
compat/terminal: separate input and output handles
mingw: reuse tty-version of git_terminal_prompt
mingw: get rid of getpass implementation
mingw_rmdir: do not prompt for retry when non-empty
Jeff King (1):
remote-testsvn: fix unitialized variable
Junio C Hamano (5):
git(1): remove a defunct link to "list of authors"
Git 1.8.0.2
git-prompt.sh: update PROMPT_COMMAND documentation
git(1): show link to contributor summary page
Git 1.8.1-rc2
Manlio Perillo (1):
git.txt: add missing info about --git-dir command-line option
Marc Khouzam (1):
Add file completion to tcsh git completion.
Matthew Daley (1):
Fix sizeof usage in get_permutations
Max Horn (6):
git-remote-helpers.txt: document invocation before input format
git-remote-helpers.txt: document missing capabilities
git-remote-helpers.txt: minor grammar fix
git-remote-helpers.txt: rearrange description of capabilities
git-remote-helpers.txt: clarify command <-> capability correspondences
git-remote-helpers.txt: clarify options & ref list attributes
Stefano Lattarini (1):
Makefile: whitespace style fixes in macro definitions
Sébastien Loriot (1):
Documentation/git-stash.txt: add a missing verb
Thomas Ackermann (1):
Renumber list in api-command.txt
^ permalink raw reply
* Re: [PATCH v2 0/7] Allow git log to use mailmap file
From: Junio C Hamano @ 2012-12-15 20:18 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1355594754-27589-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Implement the feature suggested by Rich Mindwinter and Junio C Hamano
> (and following his advices)
>
>
>
> Allows git show/log commands to map author and committer
> names and emails using the mailmap file.
>
> Updates related to this second series:
> - All tests are successful after each patch
> - Use split_ident_line in shortlog.c
> - Documentation has been added to git-log.txt
> - Test has been added to check that we use the file
> - Lots of improvements in the way strbufs are used
> - New interface to map_user()
> - Bunch of other fixes
The updated map_user() and its users look much nicer now. Applying
your patches with "git am --whitespace=error" spots a few style
violations, though.
> git glog --committer/--author is still not looking for mailmap user
> names.
I think we should stop using the header grep mechanism for these and
instead keep two separate grep expressions in struct rev_info and
use them in revision.c::commit_match(). The unification of header
filter and message grep filter done in 2d10c55 (git log: Unify
header_filter and message_filter into one., 2006-09-20) may not have
been a good idea.
Thanks.
^ permalink raw reply
* Re: [PATCH] Makefile: detect when PYTHON_PATH changes
From: Christian Couder @ 2012-12-15 20:09 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vehirustv.fsf@alter.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] Makefile: detect when PYTHON_PATH changes
Date: Sat, 15 Dec 2012 09:29:48 -0800
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> @@ -2636,6 +2636,18 @@ GIT-GUI-VARS: FORCE
>> fi
>> endif
>>
>> +### Detect Python interpreter path changes
>> +ifndef NO_PYTHON
>> +TRACK_VARS = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)')
>> +
>> +GIT-PYTHON-VARS: FORCE
>> + @VARS='$(TRACK_VARS)'; \
>> + if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
>> + echo 1>&2 " * new Python interpreter location"; \
>> + echo "$$VARS" >$@; \
>> + fi
>> +endif
>
> Do we have the same issue when you decide to use /usr/local/bin/sh
> after building with /bin/sh set to SHELL_PATH?
>
> - If yes, I presume that there will be follow-up patches to this
> one, for SHELL_PATH, PERL_PATH, and TCLTK_PATH (there may be
> other languages but I didn't bother to check). How would the use
> of language agnostic looking TRACK_VARS variable in this patch
> affect such follow-up patches?
Actually, just above the above hunk, there is:
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
GIT-GUI-VARS: FORCE
@VARS='$(TRACK_VARS)'; \
if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
echo 1>&2 " * new Tcl/Tk interpreter location"; \
echo "$$VARS" >$@; \
fi
endif
But you are right, TRACK_VARS should probably be something like
TRACK_TCLTK when used for TCLTK and TRACK_PYTHON when used for Python.
By the way it looks like GIT-GUI-VARS is not used, so perhaps the
detection of Tck/Tk interpreter path changes above could be removed.
(The detection is done in git-gui/Makefile too.)
About shell, there is the following:
SCRIPT_DEFINES = $(SHELL_PATH_SQ):$(DIFF_SQ):$(GIT_VERSION):\
$(localedir_SQ):$(NO_CURL):$(USE_GETTEXT_SCHEME):$(SANE_TOOL_PATH_SQ):\
$(gitwebdir_SQ):$(PERL_PATH_SQ)
and then
GIT-SCRIPT-DEFINES: FORCE
@FLAGS='$(SCRIPT_DEFINES)'; \
if test x"$$FLAGS" != x"`cat $@ 2>/dev/null`" ; then \
echo 1>&2 " * new script parameters"; \
echo "$$FLAGS" >$@; \
fi
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh GIT-SCRIPT-DEFINES
$(QUIET_GEN)$(cmd_munge_script) && \
chmod +x $@+ && \
mv $@+ $@
$(SCRIPT_LIB) : % : %.sh GIT-SCRIPT-DEFINES
$(QUIET_GEN)$(cmd_munge_script) && \
mv $@+ $@
So it looks to me that at least for SHELL_PATH, things are done
properly.
> - If no (in other words, if we rebuild shell-scripted porcelains
> when SHELL_PATH changes), wouldn't it be better to see how it is
> done and hook into the same mechanism?
You would like me to just add $(PYTHON_PATH_SQ) in SCRIPT_DEFINES and
then use GIT-SCRIPT-DEFINES instead of GIT-PYTHON-VARS to decide if
python scripts should be rebuilt?
> - If no, and if the approach taken in this patch is better than the
> one used to rebuild shell scripts (it may limit the scope of
> rebuilding when path changes, or something, but again, I didn't
> bother to check),
Yeah, I think it is better because it limits the scope of rebuilding,
and because nothing is done for Python, while there are some
mechanisms in place for other languages.
> then again follow-up patches to this one to
> describe dependencies to build scripts in other languages in a
> similar way to this patch would come in the future. The same
> question regarding TRACK_VARS applies in this case.
I agree about TRACK_VARS. About other languages, I will have another
look, but it seems that they already have what they need.
> By the way, "1>&2" is easier to read if written as just ">&2", I
> think.
Ok I will change this.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] README: Git is released under the GPLv2, not just "the GPL"
From: Stefano Lattarini @ 2012-12-15 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhannrtot.fsf@alter.siamese.dyndns.org>
On 12/15/2012 08:39 PM, Junio C Hamano wrote:
> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
>
>> On 12/15/2012 07:35 PM, Junio C Hamano wrote:
>>> ...
>>> -Git is an Open Source project covered by the GNU General Public License.
>>> +Git is an Open Source project covered by the GNU General Public
>>> +License version 2 (some parts of it are under different licenses).
>>>
>> Maybe you could be even more explicit ans state "some parts of it are
>> under different licenses, compatible with the GPLv2". But maybe this
>> is just overkill?
>
> I personally do not think it is an overkill; because this "clarify
> that we are version 2", followed by "not everything is, but as a
> whole it is still GPLv2" is in the end about covering our ass, it is
> better to be as clear as possible without making it into a novel.
>
Well, if you put it this way :-) I agree that it's better be safe
than be sorry.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH] README: Git is released under the GPLv2, not just "the GPL"
From: Junio C Hamano @ 2012-12-15 19:39 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <50CCCE0A.40305@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> On 12/15/2012 07:35 PM, Junio C Hamano wrote:
>> ...
>> -Git is an Open Source project covered by the GNU General Public License.
>> +Git is an Open Source project covered by the GNU General Public
>> +License version 2 (some parts of it are under different licenses).
>>
> Maybe you could be even more explicit ans state "some parts of it are
> under different licenses, compatible with the GPLv2". But maybe this
> is just overkill?
I personally do not think it is an overkill; because this "clarify
that we are version 2", followed by "not everything is, but as a
whole it is still GPLv2" is in the end about covering our ass, it is
better to be as clear as possible without making it into a novel.
^ permalink raw reply
* Re: [PATCH] git.c: add --index-file command-line option.
From: Junio C Hamano @ 2012-12-15 19:36 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50CCC73B.3070802@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> Il 15/12/2012 19:02, Junio C Hamano ha scritto:
>> Manlio Perillo <manlio.perillo@gmail.com> writes:
>>
>>> Unlike other environment variables (e.g. GIT_WORK_TREE,
>>> GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
>>> environment variable using the command line.
>>
>> Is this necessary? I'd prefer to see a better reason than "just
>> because others have it".
>
> A long running program will be able to tell git to use an alternate
> index file, without having to modify its own environment,...
Hrm, isn't that the single-shot environment export syntax
GIT_INDEX_FILE=foo git blah
is for? Is there a real-world need for this?
^ permalink raw reply
* Re: [PATCH 1/2] Make lock local to fetch_pack
From: Junio C Hamano @ 2012-12-15 19:31 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Matt Kraai
In-Reply-To: <7vtxrnrwer.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matt Kraai <kraai@ftbfs.org> writes:
>
>> From: Matt Kraai <matt.kraai@amo.abbott.com>
>>
>> lock is only used by fetch_pack, so move it into that function.
>>
>> Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com>
>> ---
>> fetch-pack.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> Eh, did you base your patch on something older than 2d4177c (Make
> fetch-pack a builtin with an internal API, 2007-09-10)???
Ah, nevermind. I see we refactored this out recently but that is
still in flight.
^ permalink raw reply
* [PATCH] mailmap.c: Fix a sparse warning
From: Ramsay Jones @ 2012-12-15 19:25 UTC (permalink / raw)
To: apelisse; +Cc: Junio C Hamano, GIT Mailing-list
In particular, sparse issues an "Using plain integer as NULL pointer"
warning (line 214), since an integer zero is passed as the second
actual argument in a strbuf_detach() call. The expected type for
this parameter is 'size_t *'. In order to suppress the warning, we
simply pass a NULL pointer constant instead.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Antoine,
When you re-roll your mailmap patches (branch 'ap/log-mailmap') could
you please squash this into commit a09b6cd9 ("mailmap: Remove buffer
length limit in map_user", 11-12-2012).
Thanks!
ATB,
Ramsay Jones
mailmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mailmap.c b/mailmap.c
index e636278..0608eb3 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -211,7 +211,7 @@ int map_user(struct string_list *map,
for (i = 0; i < end_of_email - email; i++)
strbuf_addch(&buf, tolower(email[i]));
strbuf_addch(&buf, 0);
- mailbuf = strbuf_detach(&buf, 0);
+ mailbuf = strbuf_detach(&buf, NULL);
debug_mm("map_user: map '%s' <%s>\n", name, mailbuf);
item = string_list_lookup(map, mailbuf);
--
1.8.0
^ permalink raw reply related
* [PATCH 1/1] tests: Allow customization of how say_color() prints
From: Ramsay Jones @ 2012-12-15 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Since commit 7bc0911d ("test-lib: Fix say_color () not to interpret
\a\b\c in the message", 11-10-2012), the "--no-color" version of
say_color() has been using the (bash builtin) printf function, rather
than echo, to print the testsuite output. Due to an intermittent (and
rare) failure of the printf builtin function on some older versions
of cygwin, this leads to several (currently 7) test failures.
In order the fix the test failures, we provide a means to customize
the function used by say_color() to print the output. The function
is customized using GIT_TEST_PRINT[_LN] variables, which are set by
default to keep the current behaviour unchanged, but may used from
(say) the config.mak file to re-instate the use of echo. This could
be done by adding the following to config.mak:
GIT_TEST_PRINT=echo -nE
GIT_TEST_PRINT_LN=echo -E
export GIT_TEST_PRINT GIT_TEST_PRINT_LN
Note that the GIT_TEST_PRINT variable is used in the "--color" version
of say_color(), and does not provide the line termination character.
In contrast, the GIT_TEST_PRINT_LN variable is used by the "--no-color"
version of say_color() and does provide the line termination.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Makefile | 6 ++++++
t/test-lib.sh | 13 +++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 736ecd4..4f7803e 100644
--- a/Makefile
+++ b/Makefile
@@ -2603,6 +2603,12 @@ GIT-BUILD-OPTIONS: FORCE
ifdef GIT_TEST_OPTS
@echo GIT_TEST_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_OPTS)))'\' >>$@
endif
+ifdef GIT_TEST_PRINT
+ @echo GIT_TEST_PRINT=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_PRINT)))'\' >>$@
+endif
+ifdef GIT_TEST_PRINT_LN
+ @echo GIT_TEST_PRINT_LN=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_PRINT_LN)))'\' >>$@
+endif
ifdef GIT_TEST_CMP
@echo GIT_TEST_CMP=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_CMP)))'\' >>$@
endif
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..9dcf3c1 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -202,6 +202,15 @@ do
esac
done
+if test -z "$GIT_TEST_PRINT"
+then
+ GIT_TEST_PRINT="printf %s"
+fi
+if test -z "$GIT_TEST_PRINT_LN"
+then
+ GIT_TEST_PRINT_LN="printf %s\n"
+fi
+
if test -n "$color"
then
say_color () {
@@ -221,7 +230,7 @@ then
test -n "$quiet" && return;;
esac
shift
- printf "%s" "$*"
+ $GIT_TEST_PRINT "$*"
tput sgr0
echo
)
@@ -230,7 +239,7 @@ else
say_color() {
test -z "$1" && test -n "$quiet" && return
shift
- printf "%s\n" "$*"
+ $GIT_TEST_PRINT_LN "$*"
}
fi
--
1.8.0
^ permalink raw reply related
* [PATCH] t3070: Disable some failing fnmatch tests
From: Ramsay Jones @ 2012-12-15 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, GIT Mailing-list
The failing tests make use of a POSIX character class, '[:xdigit:]'
in this case, which some versions of the fnmatch() library function
do not support. In the spirit of commit f1cf7b79 ("t3070: disable
unreliable fnmatch tests", 15-10-2012), we disable the fnmatch() half
of these tests.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Junio,
This is against next (branch 'nd/wildmatch'). As an alternative solution,
I could build with NO_FNMATCH, since the compat version does support the
POSIX charater classes.
ATB,
Ramsay Jones
t/t3070-wildmatch.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 3155eab..d5bafef 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -120,9 +120,9 @@ match 0 x '1' '[[:digit:][:upper:][:spaci:]]'
match 1 x ' ' '[[:digit:][:upper:][:space:]]'
match 0 x '.' '[[:digit:][:upper:][:space:]]'
match 1 x '.' '[[:digit:][:punct:][:space:]]'
-match 1 1 '5' '[[:xdigit:]]'
-match 1 1 'f' '[[:xdigit:]]'
-match 1 1 'D' '[[:xdigit:]]'
+match 1 x '5' '[[:xdigit:]]'
+match 1 x 'f' '[[:xdigit:]]'
+match 1 x 'D' '[[:xdigit:]]'
match 1 x '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
match 1 x '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
match 1 x '.' '[^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]]'
--
1.8.0
^ permalink raw reply related
* [PATCH 0/1] cygwin test failures due to printf
From: Ramsay Jones @ 2012-12-15 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
Hi Junio,
Sorry for being a bit tardy on this; I noticed these test failures
on cygwin close to the start of this cycle, just before I went
into hospital, but have only just got around to looking into it...
In particular, the following tests fail: t0021, t0030, t1410, t3032,
t3304, t3404 and t4132. [The list of failing tests is not actually
all that interesting, because the fault is not actually with the
tests!]
These failures are provoked by commit 7bc0911d ("test-lib: Fix say_color ()
not to interpret \a\b\c in the message", 11-10-2012).
If we look at t0021 as a representative, then:
$ ./t0021-conversion.sh
ok 1 - setup
ok 2 - check
ok 3 - expanded_in_repo
5 [sig] sh 2388 C:\cygwin\bin\sh.exe: *** fatal error - called with threadlist_ix -1
./test-lib.sh: line 207: 2388 Hangup \
( TERM=$ORIGINAL_TERM; export TERM; case "$1" in
error)
tput bold; tput setaf 1
;;
skip)
tput bold; tput setaf 4
;;
warn)
tput bold; tput setaf 3
;;
pass)
tput setaf 2
;;
info)
tput setaf 3
;;
*)
test -n "$quiet" && return
;;
esac; shift; printf "%s" "$*"; tput sgr0; echo )
ok 4 - filter shell-escaped filenames
ok 5 - required filter success
ok 6 - required filter smudge failure
ok 7 - required filter clean failure
# passed all 7 test(s)
1..7
$
We see that the "--color" version of say_color(), despite the bash builtin
printf function crashing the shell (sh.exe is actually bash for me), passes
just fine. Note that the message passed to say_color() is printed before
the shell is aborted (via SIGHUP), but that the "tput sgr0; echo" has been
skipped. This results in the occasional line of output in the wrong colour.
This has been happening for several years and, given that there are no
adverse consequences (ignoring the additional error message spew), I have
been happy to ignore this problem. :D
Note that the "--no-color" version of say_color() did not have this problem
since it used echo, rather than printf, until commit 7bc0911d ...
$ ./t0021-conversion.sh --no-color
ok 1 - setup
ok 2 - check
ok 3 - expanded_in_repo
6 [sig] sh 2740 C:\cygwin\bin\sh.exe: *** fatal error - called with threadlist_ix -1
Hangup
$
Note that, unlike the "--color" version of say_color(), the printf call is
not contained within a sub-shell. Indeed, a simple solution to this problem
would be to execute the body of the function from within a "(...)" sub-shell.
This actually works, since the extra error message spew does not cause a
TAP syntax error to confuse 'prove'. However, I would never suggest this
as a solution, given that it already takes over 3 hours to run the tests...
Also, note that another solution is to call the external version of printf
(e.g. via /usr/bin/printf) but, again, I would not suggest adding to the
fork-exec load by replacing a call to a shell builtin with an external
program...
Note that:
$ cygcheck /bin/sh.exe
C:/cygwin/bin/sh.exe
C:/cygwin/bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll
C:/cygwin/bin\cygintl-8.dll
C:/cygwin/bin\cygiconv-2.dll
C:/cygwin/bin\cygreadline6.dll
C:/cygwin/bin\cygncurses-8.dll
C:\WINDOWS\system32\USER32.dll
C:\WINDOWS\system32\GDI32.dll
$
$ strings /bin/cygwin1.dll | grep 'called with'
called with threadlist_ix %d
called with invalid value %d
openlog called with (%s, %d, %d)
$
So, the error message is coming from the cygwin dll (no surprise there).
I have a fairly recent source snapshot of cygwin, but this message or the
code that uses it is not present. In order to debug this further, I would
need to find the source code for the version I am using (1.5.22). This does
not excite me too much. ;-)
As a simpler solution, the patch which follows allows me to customize
the function used to do the output. This allows me to revert to using
echo and, as a bonus, fixes the "--color" version of say_color() at the
same time.
I admit that I find this solution a bit ugly, but it has (at least) two
virtues:
1. it works!
2. it's not as ugly as some other solutions I had tried. :-P
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] README: Git is released under the GPLv2, not just "the GPL"
From: Stefano Lattarini @ 2012-12-15 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v38z7tb7q.fsf@alter.siamese.dyndns.org>
On 12/15/2012 07:35 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
>>
>>> And this is clearly stressed by Linus in the COPYING file. So make it
>>> clear in the README as well, to avoid possible misunderstandings.
>>>
>>> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
>>> ---
>>
>> I have nothing against this patch, but I am curious if you saw any
>> misunderstandings in the real world, or if you are merely trying to
>> avoid "possible" ones.
>>
Only playing safe against "possible" misunderstandings, especially
now that the GPLv3 has taken root and has supplanted the v2 in several
projects (e.g., Perl, and obviously most GNU packages).
>>> README | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/README b/README
>>> index d2690ec..c50e6f4 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an
>>> unusually rich command set that provides both high-level operations
>>> and full access to internals.
>>>
>>> -Git is an Open Source project covered by the GNU General Public License.
>>> -It was originally written by Linus Torvalds with help of a group of
>>> -hackers around the net. It is currently maintained by Junio C Hamano.
>>> +Git is an Open Source project covered by the GNU General Public License
>>> +(version 2). It was originally written by Linus Torvalds with help
>>> +of a group of hackers around the net. It is currently maintained by
>>> +Junio C Hamano.
>>>
>>> Please read the file INSTALL for installation instructions.
>
> The project as a whole is GPLv2, and inclusion of pieces licensed
> under different but compatible terms does not change it, but we may
> want to do this instead.
>
> I am just one of the "group of hackers around the net" in the
> context of this overview, so I think it is OK to drop that
> "currently maintained by" bit. The audience of this document does
> not have to find out and interact with the maintainer.
>
> diff --git a/README b/README
> index d2690ec..c365e3c 100644
> --- a/README
> +++ b/README
> @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an
> unusually rich command set that provides both high-level operations
> and full access to internals.
>
> -Git is an Open Source project covered by the GNU General Public License.
> +Git is an Open Source project covered by the GNU General Public
> +License version 2 (some parts of it are under different licenses).
>
Maybe you could be even more explicit ans state "some parts of it are
under different licenses, compatible with the GPLv2". But maybe this
is just overkill?
> It was originally written by Linus Torvalds with help of a group of
> -hackers around the net. It is currently maintained by Junio C Hamano.
> +hackers around the net.
>
> Please read the file INSTALL for installation instructions.
>
Thanks,
Stefano
^ permalink raw reply
* Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed
From: Jan Engelhardt @ 2012-12-15 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phil Hord, Philippe Vaucher, git, Christian Couder
In-Reply-To: <7vhaqb4bvb.fsf@alter.siamese.dyndns.org>
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote:
>
>I said that "git reset --keep" started out as an ugly workaround for
>the lack of "git checkout -B $current_branch". Now we have it, so
>we can afford to make "reset --keep" less prominently advertised in
>our tool set. As I already said back then, "reset --soft" also has
>outlived its usefulness when "commit --amend" came, so that leaves
>only these modes of "reset":
Soft is still useful, partway. Consider patch splitting (where easily
possible):
$ git add foo.c bar.c
$ git commit -m foo,bar
[other commits]
$ git rebase -i FOOBARCOMMIT^
[mark foo,bar for edit]
$ git reset --soft HEAD^
$ git reset bar.c
$ git commit -m foo
$ git add bar.c
$ git commit -m bar
$ git rebase --continue
^ permalink raw reply
* Re: [PATCH] git.c: add --index-file command-line option.
From: Manlio Perillo @ 2012-12-15 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpq2btcqp.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 15/12/2012 19:02, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> Unlike other environment variables (e.g. GIT_WORK_TREE,
>> GIT_NAMESPACE), it was not possible to set the GIT_INDEX_FILE
>> environment variable using the command line.
>
> Is this necessary? I'd prefer to see a better reason than "just
> because others have it".
A long running program will be able to tell git to use an alternate
index file, without having to modify its own environment, or having to
use execvpe (I assume this is the reason why it is possible to specify
GIT_WORK_TREE from command line).
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAlDMxzsACgkQscQJ24LbaUSzEQCYymkZa6JrT42OzigRfDgc5Hss
gwCgjIzs1b0hEyu1WAgDgCir9XalDN8=
=GtMF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 1/2] Make lock local to fetch_pack
From: Junio C Hamano @ 2012-12-15 18:40 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, Matt Kraai
In-Reply-To: <1355510300-31541-2-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> From: Matt Kraai <matt.kraai@amo.abbott.com>
>
> lock is only used by fetch_pack, so move it into that function.
>
> Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com>
> ---
> fetch-pack.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Eh, did you base your patch on something older than 2d4177c (Make
fetch-pack a builtin with an internal API, 2007-09-10)???
^ permalink raw reply
* Re: [PATCH 0/2] Port to QNX
From: Junio C Hamano @ 2012-12-15 18:38 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1355510300-31541-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> This series ports Git to QNX. It builds on both QNX 6.3.2 and QNX
> 6.5.0. The test suite does not pass. Unless the corresponding
> software is installed, the following arguments must be passed to Make:
>
> NO_CURL=1 NO_GETTEXT=1 NO_OPENSSL=1 NO_PERL=1 NO_PYTHON=1 NO_TCLTK=1
>
> [1/2]: Make lock local to fetch_pack
>
> QNX 6.3.2's unistd.h declares a function named lock, which causes
> fetch-pack.c to fail to compile if lock has file-scope. Since it's
> only used in a single function, move it therein.
>
> [2/2]: Port to QNX
I do not mind queuing this on 'pu' but do you want to see your
ftbfs.org address in the commit objects, or the other one that you
are not using to interact with us?
^ permalink raw reply
* Re: [PATCH] README: Git is released under the GPLv2, not just "the GPL"
From: Junio C Hamano @ 2012-12-15 18:35 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <7vhanntchw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
>
>> And this is clearly stressed by Linus in the COPYING file. So make it
>> clear in the README as well, to avoid possible misunderstandings.
>>
>> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
>> ---
>
> I have nothing against this patch, but I am curious if you saw any
> misunderstandings in the real world, or if you are merely trying to
> avoid "possible" ones.
>
>> README | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/README b/README
>> index d2690ec..c50e6f4 100644
>> --- a/README
>> +++ b/README
>> @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an
>> unusually rich command set that provides both high-level operations
>> and full access to internals.
>>
>> -Git is an Open Source project covered by the GNU General Public License.
>> -It was originally written by Linus Torvalds with help of a group of
>> -hackers around the net. It is currently maintained by Junio C Hamano.
>> +Git is an Open Source project covered by the GNU General Public License
>> +(version 2). It was originally written by Linus Torvalds with help
>> +of a group of hackers around the net. It is currently maintained by
>> +Junio C Hamano.
>>
>> Please read the file INSTALL for installation instructions.
The project as a whole is GPLv2, and inclusion of pieces licensed
under different but compatible terms does not change it, but we may
want to do this instead.
I am just one of the "group of hackers around the net" in the
context of this overview, so I think it is OK to drop that
"currently maintained by" bit. The audience of this document does
not have to find out and interact with the maintainer.
diff --git a/README b/README
index d2690ec..c365e3c 100644
--- a/README
+++ b/README
@@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.
-Git is an Open Source project covered by the GNU General Public License.
+Git is an Open Source project covered by the GNU General Public
+License version 2 (some parts of it are under different licenses).
It was originally written by Linus Torvalds with help of a group of
-hackers around the net. It is currently maintained by Junio C Hamano.
+hackers around the net.
Please read the file INSTALL for installation instructions.
--
1.8.1.rc1.148.gfac1be9
^ permalink raw reply related
* Re: FW: Git log --graph doesn't output color when redirected
From: Junio C Hamano @ 2012-12-15 18:30 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Srb, Michal, git@vger.kernel.org
In-Reply-To: <20121215101659.GB21577@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Dec 15, 2012 at 10:23:10AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Thu, Dec 13, 2012 at 8:13 PM, Jeff King <peff@peff.net> wrote:
>> > If you are using --format="%C(red)" or similar placeholders,
>> > they are the odd duck by not respecting the auto-color mode.
>>
>> But they should, shouldn't they? Just asking. I may do it to when I
>> revive nd/pretty-placeholder-with-color-option.
>
> If I were designing --format today, I would certainly say so. The only
> thing holding me back would be backwards compatibility. We could get
> around that by introducing a new placeholder like %c(color) that behaves
> like %C(color), except respects the --color flag.
I think the %c(color) thing is a good way to go if we want to pursue
this.
Another possibility without wasting one more special letter would be
to allow %C(auto,red), perhaps like this (untested):
pretty.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git i/pretty.c w/pretty.c
index dba6828..77cf826 100644
--- i/pretty.c
+++ w/pretty.c
@@ -960,12 +960,19 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
switch (placeholder[0]) {
case 'C':
if (placeholder[1] == '(') {
- const char *end = strchr(placeholder + 2, ')');
+ const char *begin = placeholder + 2;
+ const char *end = strchr(begin, ')');
char color[COLOR_MAXLEN];
+
if (!end)
return 0;
- color_parse_mem(placeholder + 2,
- end - (placeholder + 2),
+ if (!memcmp(begin, "auto,", 5)) {
+ if (!want_color(GIT_COLOR_AUTO))
+ return 0;
+ begin += 5;
+ }
+ color_parse_mem(begin,
+ end - begin,
"--pretty format", color);
strbuf_addstr(sb, color);
return end - placeholder + 1;
^ permalink raw reply related
* Re: [PATCH] Documentation: don't link to example mail addresses
From: John Keeping @ 2012-12-15 18:24 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121215172018.GA18696@sigill.intra.peff.net>
On Sat, Dec 15, 2012 at 12:20:18PM -0500, Jeff King wrote:
> On Sat, Dec 15, 2012 at 03:03:15PM +0000, John Keeping wrote:
>> Mail addresses in documentation are converted into mailto: hyperlinks in
>> the HTML output and footnotes in man pages. This isn't desirable for
>> cases where the address is used as an example and is not valid.
>>
>> Particularly annoying is the example "jane@laptop.(none)" which appears
>> in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:
>>
>> 1. jane@laptop
>> mailto:jane@laptop
>
> Thanks, this is definitely worth fixing.
>
>> Fix this by quoting example mail addresses with "$$", preventing
>> Asciidoc from processing them.
>>
>> In the case of mailmap.txt, render the address monospaced so that it
>> matches the block examples surrounding that paragraph.
>
> I think I'd just render them monospace everywhere. We are very
> inconsistent about which form of quotes we use in the documentation (I
> think because most of the developers read the source directly and not
> the rendered asciidoc). And then we don't have to worry about the "$$"
> construct (and IMHO it makes the source much more readable, and marking
> the address as a literal looks good in the output, too).
I agree that the source is more readable as monospaced, but I think we
need to keep the quotes around the text in git-tag(1) and probably
git-fast-import(1) so that it is differentiated from the surrounding
text in the man page output.
I just tried this and got strange results. Taking the example in
git-tag(1):
...of the form ``Your Name <your@email.address>''
I tried this to preserve the quotes and make the entire quoted text
monospaced (I don't think we want to have just the email address
monospaced):
...of the form ```Your Name <your@email.address>`''
which had the desired effect - smart quotes and everything inside
rendered monospaced - BUT the email address is hyperlinked!
Switching the smart Asciidoc double quotes (``...'') for "normal" double
quotes ("...") produces the desired result, but IMHO doesn't look quite
as good (on the other hand it looks like there are many more use of
"..." than ``...'' in the Git documentation).
[While searching, the only other example I could find is in
git-commit(1) where `A U Thor <author@example.com>` is rendered
monospaced without quotes, but I think this hurts readability in the man
page output - expect a follow-up patch if we resolve this in the
direction of having quotes and monospaced text.]
At this point I've exhausted my Asciidoc knowledge and I'm not entirely
happy with any of these options. Suggestions?
John
^ permalink raw reply
* Re: [PATCH] README: Git is released under the GPLv2, not just "the GPL"
From: Junio C Hamano @ 2012-12-15 18:07 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <966a27bab02e7deb41ad2268800bfd4a53279a8f.1355499408.git.stefano.lattarini@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> And this is clearly stressed by Linus in the COPYING file. So make it
> clear in the README as well, to avoid possible misunderstandings.
>
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
> ---
I have nothing against this patch, but I am curious if you saw any
misunderstandings in the real world, or if you are merely trying to
avoid "possible" ones.
> README | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/README b/README
> index d2690ec..c50e6f4 100644
> --- a/README
> +++ b/README
> @@ -19,9 +19,10 @@ Git is a fast, scalable, distributed revision control system with an
> unusually rich command set that provides both high-level operations
> and full access to internals.
>
> -Git is an Open Source project covered by the GNU General Public License.
> -It was originally written by Linus Torvalds with help of a group of
> -hackers around the net. It is currently maintained by Junio C Hamano.
> +Git is an Open Source project covered by the GNU General Public License
> +(version 2). It was originally written by Linus Torvalds with help
> +of a group of hackers around the net. It is currently maintained by
> +Junio C Hamano.
>
> Please read the file INSTALL for installation instructions.
^ permalink raw reply
* Re: [PATCH] For git-subtree, when installing docs (make install-doc), create man1 folder first.
From: Junio C Hamano @ 2012-12-15 18:07 UTC (permalink / raw)
To: Jesper L. Nielsen; +Cc: git, David A. Greene
In-Reply-To: <1355429376-4192-1-git-send-email-lyager@gmail.com>
"Jesper L. Nielsen" <lyager@gmail.com> writes:
> From: "Jesper L. Nielsen" <lyager@gmail.com>
>
> Hi..
>
> I installed Git subtree and discovered that the if the man1dir doesn't exist the man-page for Git Subtree is just called man1.
>
> So, small patch to create the folder first in the Makefile. Hope everything is right with the patch and submitting of the patch.
>
> Best Regards
> Jesper
>
> Signed-off-by: Jesper L. Nielsen <lyager@gmail.com>
> ---
> contrib/subtree/Makefile | 1 +
> 1 file changed, 1 insertion(+)
This is a good first step in the right direction, I think.
Shouldn't the install targets take DESTDIR into account like the
main Makefile does, though?
As to the patch submission, everything below "---" line looks sane,
but please check how others write commit log messages by browsing a
handful of entries in "git log --no-merges" output and notice the
difference (the details are found in Documentation/SubmittingPatches).
Thanks.
> diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
> index 05cdd5c..a341cf4 100644
> --- a/contrib/subtree/Makefile
> +++ b/contrib/subtree/Makefile
> @@ -35,6 +35,7 @@ install: $(GIT_SUBTREE)
> install-doc: install-man
>
> install-man: $(GIT_SUBTREE_DOC)
> + mkdir -p $(man1dir)
> $(INSTALL) -m 644 $^ $(man1dir)
>
> $(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
^ permalink raw reply
* [PATCH v2 6/7] log: Add --use-mailmap option
From: Antoine Pelisse @ 2012-12-15 18:05 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1355594754-27589-1-git-send-email-apelisse@gmail.com>
Add the --use-mailmap option to log commands. It allows
to display names from mailmap file when displaying logs,
whatever the format used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
Documentation/git-log.txt | 5 +++++
builtin/log.c | 9 ++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 585dac4..a99be97 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -47,6 +47,11 @@ OPTIONS
Print out the ref name given on the command line by which each
commit was reached.
+--use-mailmap::
+ Use mailmap file to map author and committer names and email
+ to canonical real names and email addresses. See
+ linkgit:git-shortlog[1].
+
--full-diff::
Without this flag, "git log -p <path>..." shows commits that
touch the specified paths, and diffs about the same specified
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..d2bd8ce 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -22,6 +22,7 @@
#include "branch.h"
#include "streaming.h"
#include "version.h"
+#include "mailmap.h"
/* Set a default date-time format for git log ("log.date" config variable) */
static const char *default_date_mode = NULL;
@@ -94,11 +95,12 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
struct rev_info *rev, struct setup_revision_opt *opt)
{
struct userformat_want w;
- int quiet = 0, source = 0;
+ int quiet = 0, source = 0, mailmap = 0;
const struct option builtin_log_options[] = {
OPT_BOOLEAN(0, "quiet", &quiet, N_("suppress diff output")),
OPT_BOOLEAN(0, "source", &source, N_("show source")),
+ OPT_BOOLEAN(0, "use-mailmap", &mailmap, N_("Use mail map file")),
{ OPTION_CALLBACK, 0, "decorate", NULL, NULL, N_("decorate options"),
PARSE_OPT_OPTARG, decorate_callback},
OPT_END()
@@ -136,6 +138,11 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
if (source)
rev->show_source = 1;
+ if (mailmap) {
+ rev->mailmap = xcalloc(1, sizeof(struct string_list));
+ read_mailmap(rev->mailmap, NULL);
+ }
+
if (rev->pretty_given && rev->commit_format == CMIT_FMT_RAW) {
/*
* "log --pretty=raw" is special; ignore UI oriented
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 5/7] pretty: Use mailmap to display username and email
From: Antoine Pelisse @ 2012-12-15 18:05 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1355594754-27589-1-git-send-email-apelisse@gmail.com>
Use the mailmap information to display the correct
username and email address in all log commands.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
pretty.c | 48 ++++++++++++++++++++++++++++--------------------
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/pretty.c b/pretty.c
index d05c675..fbf87b7 100644
--- a/pretty.c
+++ b/pretty.c
@@ -387,6 +387,8 @@ void pp_user_info(const struct pretty_print_context *pp,
const char *what, struct strbuf *sb,
const char *line, const char *encoding)
{
+ struct strbuf name;
+ struct strbuf mail;
struct ident_split ident;
int linelen, namelen;
char *line_end, *date;
@@ -408,42 +410,48 @@ void pp_user_info(const struct pretty_print_context *pp,
if (split_ident_line(&ident, line, linelen))
return;
- namelen = ident.mail_end - ident.name_begin + 1;
+ strbuf_init(&mail, 0);
+ strbuf_init(&name, 0);
+
+ strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
+ strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
+
+ if (pp->mailmap)
+ map_user(pp->mailmap, &mail, &name);
+
+ namelen = name.len + mail.len + 3; /* ' ' + '<' + '>' */
time = strtoul(ident.date_begin, &date, 10);
tz = strtol(date, NULL, 10);
if (pp->fmt == CMIT_FMT_EMAIL) {
- int display_name_length;
-
- display_name_length = ident.name_end - ident.name_begin;
-
strbuf_addstr(sb, "From: ");
- if (needs_rfc2047_encoding(line, display_name_length, RFC2047_ADDRESS)) {
- add_rfc2047(sb, line, display_name_length,
- encoding, RFC2047_ADDRESS);
+ if (needs_rfc2047_encoding(name.buf, name.len, RFC2047_ADDRESS)) {
+ add_rfc2047(sb, name.buf, name.len,
+ encoding, RFC2047_ADDRESS);
max_length = 76; /* per rfc2047 */
- } else if (needs_rfc822_quoting(line, display_name_length)) {
+ } else if (needs_rfc822_quoting(name.buf, name.len)) {
struct strbuf quoted = STRBUF_INIT;
- add_rfc822_quoted("ed, line, display_name_length);
+ add_rfc822_quoted("ed, name.buf, name.len);
strbuf_add_wrapped_bytes(sb, quoted.buf, quoted.len,
-6, 1, max_length);
strbuf_release("ed);
} else {
- strbuf_add_wrapped_bytes(sb, line, display_name_length,
- -6, 1, max_length);
+ strbuf_add_wrapped_bytes(sb, name.buf, name.len,
+ -6, 1, max_length);
}
- if (namelen - display_name_length + last_line_length(sb) > max_length) {
+ if (namelen - name.len + last_line_length(sb) > max_length)
strbuf_addch(sb, '\n');
- if (!isspace(ident.name_end[0]))
- strbuf_addch(sb, ' ');
- }
- strbuf_add(sb, ident.name_end, namelen - display_name_length);
- strbuf_addch(sb, '\n');
+
+ strbuf_addf(sb, " <%s>\n", mail.buf);
} else {
- strbuf_addf(sb, "%s: %.*s%.*s\n", what,
+ strbuf_addf(sb, "%s: %.*s%s <%s>\n", what,
(pp->fmt == CMIT_FMT_FULLER) ? 4 : 0,
- " ", namelen, line);
+ " ", name.buf, mail.buf);
}
+
+ strbuf_release(&mail);
+ strbuf_release(&name);
+
switch (pp->fmt) {
case CMIT_FMT_MEDIUM:
strbuf_addf(sb, "Date: %s\n", show_date(time, tz, pp->date_mode));
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 7/7] test: Add test for --use-mailmap option
From: Antoine Pelisse @ 2012-12-15 18:05 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1355594754-27589-1-git-send-email-apelisse@gmail.com>
The new option '--use-mailmap' can be used to make
sure that mailmap file is used to convert name
when running log commands.
The test is simple and checks that the Author line
is correctly replaced when running log.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
t/t4203-mailmap.sh | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6..db043dc 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -239,6 +239,20 @@ test_expect_success 'Log output (complex mapping)' '
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: CTO <cto@company.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Other Author <other@author.xx>
+Author: Other Author <other@author.xx>
+Author: Some Dude <some@dude.xx>
+Author: A U Thor <author@example.com>
+EOF
+test_expect_success 'Log output with --use-mailmap' '
+ git log --use-mailmap | grep Author >actual &&
+ test_cmp expect actual
+'
+
# git blame
cat >expect <<\EOF
^OBJI (A U Thor DATE 1) one
--
1.7.9.5
^ permalink raw reply related
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