* Re: maybe I missed the announcement, but...
From: Randal L. Schwartz @ 2011-09-20 14:36 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1316528864.8701.17.camel@centaur.lab.cmartin.tk>
>>>>> "Carlos" == Carlos Martín Nieto <cmn@elego.de> writes:
Carlos> From Junio's latest "What's cooking"[0]
Ahh, the famous "buried lead". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Carlos Martín Nieto @ 2011-09-20 14:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8639frs3bf.fsf@red.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Tue, 2011-09-20 at 07:20 -0700, Randal L. Schwartz wrote:
> dhcp:~ +% host git.kernel.org
> Host git.kernel.org not found: 3(NXDOMAIN)
>
> Is there a replacement?
From Junio's latest "What's cooking"[0]
With maint, master, next, pu and todo:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint and master:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
url = https://github.com/gitster/git
Aren't DVCS wonderful? :)
[0] http://article.gmane.org/gmane.comp.version-control.git/181436
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* maybe I missed the announcement, but...
From: Randal L. Schwartz @ 2011-09-20 14:20 UTC (permalink / raw)
To: git
dhcp:~ +% host git.kernel.org
Host git.kernel.org not found: 3(NXDOMAIN)
Is there a replacement?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* [PATCH v3] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 13:11 UTC (permalink / raw)
To: gitster, git; +Cc: Stefan Naewe
'ls-files' refers to 'update-index' to show how the 'assume unchanged'
bit can be seen. This makes the connection 'bi-directional'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
The commit message in v2 of this got truncated somehow.
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..cb1dd7b 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-ls-files[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH v2] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 12:32 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..cb1dd7b 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-ls-files[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 12:23 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
'ls-files' refers to 'update-index' to show how the 'assume unchanged'
can be seen. This makes the connection 'bi-directional'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..169941a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-update-index[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-update-index[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Jakub Narebski @ 2011-09-20 12:23 UTC (permalink / raw)
To: zapped; +Cc: Johannes Sixt, git
In-Reply-To: <20110920104256.GA11656@zapped.homeip.net>
Shumkin Alexey <zapped@mail.ru> writes:
> [ resent to mailing list ]
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> > Am 9/20/2011 10:07, schrieb Alexey Shumkin:
[...]
> > > +# hooks.emailcharset
> > > +# The charset used in Content-Type header. UTF-8, if not
> > > specified.
> >
> > How can you be sure that the output produced by git log etc. that are
> > used in the script are in the encoding specified by this variable?
> > IOW, wouldn't log.outputencoding be the better choice to use in the
> > Content-Type header?
>
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
>
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
> (I do not know whether it can be changed there but I tested gitweb once long
> time ago)
I have thought that gitweb uses '--encoding=utf8' explicitly, but as I
have checked it uses this only for git-format-patch invocation in
'patch' / 'patches' views. Should be fixed.
--
Jakub Narębski
^ permalink raw reply
* Re: How to see 'assume-unchanged' information
From: Stefan Näwe @ 2011-09-20 12:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8B1jPmkLB8xq86Ji52G=zGn+3K1_meL5K2T-spDpagL6A@mail.gmail.com>
Am 20.09.2011 14:02, schrieb Nguyen Thai Ngoc Duy:
> On Tue, Sep 20, 2011 at 9:36 PM, Stefan Näwe
> <stefan.naewe@atlas-elektronik.com> wrote:
>> Hi there.
>>
>> Is it somehow possible to see which files have the 'assume unchanged'
>> bit set ?
>
> git ls-files -v
Oh..how obvious...
Someone should update the manpage of 'update-index' to refer to 'ls-files'...
Maybe I find some time for that.
Thx,
Stefan
--
----------------------------------------------------------------
/dev/random says: Send $20 and I will double your IQ or no money back.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: How to see 'assume-unchanged' information
From: Nguyen Thai Ngoc Duy @ 2011-09-20 12:02 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org
In-Reply-To: <4E787AD3.2000208@atlas-elektronik.com>
On Tue, Sep 20, 2011 at 9:36 PM, Stefan Näwe
<stefan.naewe@atlas-elektronik.com> wrote:
> Hi there.
>
> Is it somehow possible to see which files have the 'assume unchanged'
> bit set ?
git ls-files -v
--
Duy
^ permalink raw reply
* How to see 'assume-unchanged' information
From: Stefan Näwe @ 2011-09-20 11:36 UTC (permalink / raw)
To: git@vger.kernel.org
Hi there.
Is it somehow possible to see which files have the 'assume unchanged'
bit set ?
Thx,
Stefan
--
----------------------------------------------------------------
/dev/random says: To be, or not to be, those are the parameters.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* [PATCH] contrib/hooks: adapt default Debian install location for contrib hooks
From: Gerrit Pape @ 2011-09-20 11:19 UTC (permalink / raw)
To: git, Junio C Hamano
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 4 ++--
templates/hooks--post-receive.sample | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index fa6d41a..ba077c1 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -11,11 +11,11 @@
# will have put this somewhere standard. You should make this script
# executable then link to it in the repository you would like to use it in.
# For example, on debian the hook is stored in
-# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# /usr/share/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
-# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
+# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
# This hook script assumes it is enabled on the central repository of a
# project, with all users pushing only to it and not between each other. It
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
index 7a83e17..e48346e 100755
--- a/templates/hooks--post-receive.sample
+++ b/templates/hooks--post-receive.sample
@@ -12,4 +12,4 @@
# see contrib/hooks/ for a sample, or uncomment the next line and
# rename the file to "post-receive".
-#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
+#. /usr/share/git-core/contrib/hooks/post-receive-email
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Johannes Sixt @ 2011-09-20 11:10 UTC (permalink / raw)
To: zapped; +Cc: git, Junio C Hamano
In-Reply-To: <20110920104256.GA11656@zapped.homeip.net>
Am 9/20/2011 12:42, schrieb Shumkin Alexey:
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
>> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
>>> +# hooks.emailcharset
>>> +# The charset used in Content-Type header. UTF-8, if not
>>> specified.
>>
>> How can you be sure that the output produced by git log etc. that are
>> used in the script are in the encoding specified by this variable?
>> IOW, wouldn't log.outputencoding be the better choice to use in the
>> Content-Type header?
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
>
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
> (I do not know whether it can be changed there but I tested gitweb once long
> time ago)
> 3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
> with mixed encodings. This fact oblidge us to encode headers
> (as quoted printable at least) and synchronize body message that contain
> repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
> This is a more complicated task for a shell script
> than just specifying Content-Type header (may be git-send-email suits here?)
In this case, it may make sense to have a separate setting, but you should
call git like this:
git -c "i18n.logoutputencoding=$emailcharset" show ...
git -c "i18n.logoutputencoding=$emailcharset" rev-list --pretty ...
-- Hannes
^ permalink raw reply
* Re: Worktree vs. working copy
From: Ramkumar Ramachandra @ 2011-09-20 10:56 UTC (permalink / raw)
To: Carlos Martín Nieto
Cc: git, Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <1316505022.13996.12.camel@bee.lab.cmartin.tk>
Hi Carlos,
Carlos Martín Nieto writes:
> [...]
> $ git grep 'worktree' | wc -l
> 412
> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> 32
> [...]
You might like to refer to a related discussion [1].
[1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
-- Ram
^ permalink raw reply
* Re: Worktree vs. working copy
From: Nguyen Thai Ngoc Duy @ 2011-09-20 10:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Carlos Martín Nieto, git
In-Reply-To: <4E786D7A.8020503@alum.mit.edu>
On Tue, Sep 20, 2011 at 8:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
>> I've noticed that in some places in git.git, the term 'working copy' is
>> used. Mostly it's in git-cvsserver which I guess it's fine, but the
>> git-config man page talks about the 'working copy' in three places.
>>
>> $ git grep 'worktree' | wc -l
>> 412
>> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
>> 32
>
> Please note that the string "worktree" mostly appears in code
> (presumably as variable names) and in the names of options. In text,
> "working tree" is far more common..
And probably the oldest. It was mentioned in the first version of git
glossary back in 2005, da13981, [PATCH] Add GIT glossary.
--
Duy
^ permalink raw reply
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Shumkin Alexey @ 2011-09-20 10:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4E785DC6.80105@viscovery.net>
[ resent to mailing list ]
On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header and charset
> > can be defined with hooks.emailcharset config variable.
>
> Please write full sentences with complete punctuation and capitalization.
> Perhaps you meant to say:
>
> Some email clients (e.g. claws-mail) display the message body
> incorrectly when the charset is not defined explicitly in a
> Content-Type header. Insert a Content-Type header in the message.
>
> The charset can be defined with the config variable
> hooks.emailcharset.
Thanks for the correction. English is not my native language
(although it is not for you, too, I guess :) ).
I read it and take on ear fine but I have no enough practice to write on it.
> > +# hooks.emailcharset
> > +# The charset used in Content-Type header. UTF-8, if not
> > specified.
>
> How can you be sure that the output produced by git log etc. that are
> used in the script are in the encoding specified by this variable?
> IOW, wouldn't log.outputencoding be the better choice to use in the
> Content-Type header?
Yes, you're right, we cannot be sure in UTF-8 encoding of output
and using i18n.logoutputencoding would be a better choice
instead of new config variable.
But at the present
1. post-send-mail uses description file of a repo
2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
(I do not know whether it can be changed there but I tested gitweb once long
time ago)
3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
with mixed encodings. This fact oblidge us to encode headers
(as quoted printable at least) and synchronize body message that contain
repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
This is a more complicated task for a shell script
than just specifying Content-Type header (may be git-send-email suits here?)
So that was a quick solution for me :)
^ permalink raw reply
* Re: Worktree vs. working copy
From: Michael Haggerty @ 2011-09-20 10:39 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1316505022.13996.12.camel@bee.lab.cmartin.tk>
On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
> I've noticed that in some places in git.git, the term 'working copy' is
> used. Mostly it's in git-cvsserver which I guess it's fine, but the
> git-config man page talks about the 'working copy' in three places.
>
> $ git grep 'worktree' | wc -l
> 412
> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> 32
Please note that the string "worktree" mostly appears in code
(presumably as variable names) and in the names of options. In text,
"working tree" is far more common than either:
$ git grep -i 'worktree' -- '*.txt' | wc -l
50
$ git grep -i 'working copy' -- '*.txt' | wc -l
6
$ git grep -i 'working tree' -- '*.txt' | wc -l
330
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Possible timestamp problems with diff-files?
From: Marc Strapetz @ 2011-09-20 10:30 UTC (permalink / raw)
To: git
For our Git client, we are invoking
git diff-files--quiet --ignore-submodules
immediately after a commit of *all* changes. Hence, the expected exit
code would be 0 (because there are no changes). A user has now reported
that for commits with many changes, exit code is sometimes 1. For the
last incident, the commit was started at 15:24:11,820 and finished at
15:24:12,329, diff-files was invoked at 15:24:12,455 and failed with
exit code 1 at 15:24:21,394. A subsequent diff-files succeeded, so I'm
wondering now, if that could be a timestamp problem (maybe related to
the Index)?
Note that there are a couple of threads running in the client itself, so
I guess actual running time of diff-files was much shorter than 9
seconds and chances are that some parts of diff-files were run in the
same second 15:24:12.
System configuration is:
Linux splitter 2.6.38-11-server #48-Ubuntu SMP Fri Jul 29 19:20:32 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
git version 1.7.4.1
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: [PATCH] Prevent users from adding the file that has all-zero SHA-1
From: Nguyen Thai Ngoc Duy @ 2011-09-20 10:13 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0n9kJtUPrpxTmtfH7kVd7CksULjt7bo3cFhOrS_NBVbMw@mail.gmail.com>
2011/9/20 Ramkumar Ramachandra <artagnon@gmail.com>:
> Hi Nguyễn,
>
> Nguyễn Thái Ngọc Duy writes:
>> This particular SHA-1 has special meaning to git, very much like NULL
>> in C. If a user adds a file that has this SHA-1, unexpected things can
>> happen.
>> [...]
>
> Interesting patch. Is it possible to write some sort of testcase?
Naah. I tested it by explicitly clear the result hash, just before it
gets to my changes, then do "git add <blah>".
--
Duy
^ permalink raw reply
* Re: Git 1.7.6: Sparse checkouts do not work with directory exclusions
From: Nguyen Thai Ngoc Duy @ 2011-09-20 10:09 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4E77BC36.7060005@workspacewhiz.com>
On Tue, Sep 20, 2011 at 8:03 AM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> Sometime after Git 1.7.3.2, sparse checkouts stopped working for me. My
> sparse-checkout file looks something like:
>
> *
> !DirA/
> !DirB/
> DirC/
>
> I have restored some lines of code that were removed in November 2010. This
> resolves the sparse checkout issue for me, but my guess is the solution is
> not implemented properly.
>
> Can anyone confirm the issue
Confirmed. It got me wonder why the negated pattern tests did not
catch this. Turns out this works:
/*
!DirA/
!DirB/
DirC
This is my theory why yours does not work: negated patterns !DirA and
!DirB excludes both directories, but git still descends in them
because you may have other patterns that re-include parts of
DirA/DirB, for example:
DirA/DirD
!DirA
When it's in DirA/DirB, "*" tells git to match everything (equivalent
"DirA/*" and "DirB/*"), so it matches all entries in DirA/DirB again,
essentially reverting "!DirA" and "!DirB" effects.
By using "/*" instead of "*", we tell git to just match entries at top
level, not all levels.
I think it makes sense, but it's a bit tricky.
> and describe why those lines were removed?
Quotes from 9e08273: "The commit provided a workaround for matching
directories in index. But it is no longer needed."
--
Duy
^ permalink raw reply
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Johannes Sixt @ 2011-09-20 9:32 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Junio C Hamano
In-Reply-To: <1316506023-5098-1-git-send-email-zapped@mail.ru>
Am 9/20/2011 10:07, schrieb Alexey Shumkin:
> Some email clients (e.g. claws-mail) incorrectly display
> message body when there is no Content-Type header and charset
> explicitly defined.
> So, set explicitly Content-Type header and charset
> can be defined with hooks.emailcharset config variable.
Please write full sentences with complete punctuation and capitalization.
Perhaps you meant to say:
Some email clients (e.g. claws-mail) display the message body
incorrectly when the charset is not defined explicitly in a
Content-Type header. Insert a Content-Type header in the message.
The charset can be defined with the config variable
hooks.emailcharset.
> +# hooks.emailcharset
> +# The charset used in Content-Type header. UTF-8, if not specified.
How can you be sure that the output produced by git log etc. that are used
in the script are in the encoding specified by this variable? IOW,
wouldn't log.outputencoding be the better choice to use in the
Content-Type header?
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Chris Packham @ 2011-09-20 9:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, chriscool, jepler
In-Reply-To: <20110919183408.GB26115@sigill.intra.peff.net>
On 20/09/11 06:34, Jeff King wrote:
> On Mon, Sep 19, 2011 at 09:26:55PM +1200, Chris Packham wrote:
>
>> Using eval causes problems when the URL contains an appropriately
>> escaped ampersand (\&). Dropping eval from the built-in browser
>> invocation avoids the problem.
>>
>> Cc: peff@peff.net
>> Cc: chriscool@tuxfamily.org
>> Cc: jepler@unpythonic.net
>
> Although other projects do use "cc" in the commit message, I think we
> don't usually bother adding this noise in the git project. The cc
> headers in your email are enough.
That's more for git send-email's benefit than anything else. I'm working
on a laptop with a touchpad (and a cat) so the less switching between
editor and MUA the better. Any better suggestions for tracking Cc's for
git send-email?
>> I've replaced my tests With the test suggested by Peff (should I be
>> giving him credit in the copyright line or something?).
>
> For a minor bit of help, usually mentioning the person in the commit
> message (with a "Helped-by", or indicating which parts they contributed
> to) is plenty. Personally, I don't even care much about that. My
> contributions to git are thoroughly documented in the commit history and
> the mailing list at this point. :)
>
> I also find the "Copyright ..." lines in the files to be overkill, too.
> They end up becoming out-of-date as other people work on the file. The
> commit history is the best way to get the right answer, and a comment in
> the file is at best redundant with what's there. But that is just my
> opinion; I don't know that we have a particular policy for such
> things[1].
>
> -Peff
>
> [1] Once upon a time, I think I saw the advice that every file should
> have a copyright notice and mention the license at the top of the file,
> but I don't know that it has ever been tested in court. I suppose the
> distributed tarballs of a particular version would lack the copyright
> attribution, but in that case, my solution would be to generate it from
> the commit history at packaging time.
The example in t/README has has a copyright notice which is why I put
one in but I don't consider the test (or the fix itself) to actually be
copyrightable. If I wasn't creating a new file I wouldn't have bothered
putting anything in (other than the testcase).
^ permalink raw reply
* Re: [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Thomas Rast @ 2011-09-20 8:43 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: Pang Yan Han, git
In-Reply-To: <7vr53c9tlt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thanks, your fix makes a lot more sense.
Agreed. Thanks!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] send-email: Honor multi-part email messages
From: Alexey Shumkin @ 2011-09-20 8:29 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano
"git format-patch --attach/--inline" generates multi-part messages.
Every part of such messages can contain non-ASCII characters with its own
"Content-Type" and "Content-Transfer-Encoding" headers.
But git-send-mail script interprets a patch-file as one-part message
and does not recognize multi-part messages.
So already quoted printable email subject may be encoded as quoted printable
again. Due to this bug email subject looks corrupted in email clients.
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
git-send-email.perl | 5 +++
t/t9001-send-email.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..1abf4a4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1403,12 +1403,17 @@ sub file_has_nonascii {
sub body_or_subject_has_nonascii {
my $fn = shift;
+ my $multipart = 0;
open(my $fh, '<', $fn)
or die "unable to open $fn: $!\n";
while (my $line = <$fh>) {
last if $line =~ /^$/;
+ if ($line =~ /^Content-Type:\s*multipart\/mixed.*$/) {
+ $multipart = 1;
+ }
return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
}
+ return 0 if $multipart;
while (my $line = <$fh>) {
return 1 if $line =~ /[^[:ascii:]]/;
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 579ddb7..151ad35 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1168,4 +1168,70 @@ test_expect_success $PREREQ '--force sends cover letter template anyway' '
test -n "$(ls msgtxt*)"
'
+test_expect_success $PREREQ 'setup multi-part message' '
+cat >multi-part-email-using-8bit <<EOF
+From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
+Message-Id: <bogus-message-id@example.com>
+From: author@example.com
+Date: Sat, 12 Jun 2010 15:53:58 +0200
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?=
+ =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+MIME-Version: 1.0
+Content-Type: multipart/mixed; boundary="------------123"
+
+This is a multi-part message in MIME format.
+--------------1.7.6.3.4.gf71f
+Content-Type: text/plain; charset=UTF-8; format=fixed
+Content-Transfer-Encoding: 8bit
+
+This is a message created with "git format-patch --attach=123"
+---
+ master | 1 +
+ файл | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 master
+ create mode 100644 файл
+
+
+--------------123
+Content-Type: text/x-patch; name="0001-.patch"
+Content-Transfer-Encoding: 8bit
+Content-Disposition: attachment; filename="0001-.patch"
+
+diff --git a/master b/master
+new file mode 100644
+index 0000000..1f7391f
+--- /dev/null
++++ b/master
+@@ -0,0 +1 @@
++master
+diff --git a/файл b/файл
+new file mode 100644
+index 0000000..44e5cfe
+--- /dev/null
++++ b/файл
+@@ -0,0 +1 @@
++содержимое файла
+
+--------------123--
+EOF
+'
+
+test_expect_success $PREREQ 'setup expect' '
+cat >expected <<EOF
+Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=B1=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=20?= =?UTF-8?q?=D1=84=D0=B0=D0=B9=D0=BB?=
+EOF
+'
+
+test_expect_success $PREREQ '--attach/--inline also treats subject' '
+ clean_fake_sendmail &&
+ echo bogus |
+ git send-email --from=author@example.com --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ --8bit-encoding=UTF-8 \
+ multi-part-email-using-8bit >stdout &&
+ grep "Subject" msgtxt1 >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.7.6.3.4.gf71f
^ permalink raw reply related
* [PATCH] format-patch: cover letter does not respect i18n.commitencoding
From: Alexey Shumkin @ 2011-09-20 8:26 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano
When we write a cover letter it is naturally enough to suppose
that we use the same encoding as we do commits in. So make
"format-patch --cover-letter" to use i18n.commitencoding setting
in "Content-Type" header of a cover letter instead of hard-coded "UTF-8".
Especially as cover letter contains shortlog and diffstat of patches
which can contain author names and file names in i18n.commitencoding.
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
builtin/log.c | 4 ++--
log-tree.c | 10 ++++++----
log-tree.h | 3 ++-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 5c2af59..6a4050c 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -769,7 +769,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
struct shortlog log;
struct strbuf sb = STRBUF_INIT;
int i;
- const char *encoding = "UTF-8";
+ const char *encoding = get_commit_output_encoding();
struct diff_options opts;
int need_8bit_cte = 0;
struct commit *commit = NULL;
@@ -806,7 +806,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
}
log_write_email_headers(rev, head, &pp.subject, &pp.after_subject,
- &need_8bit_cte);
+ &need_8bit_cte, get_commit_output_encoding());
for (i = 0; !need_8bit_cte && i < nr; i++)
if (has_non_ascii(list[i]->buffer))
diff --git a/log-tree.c b/log-tree.c
index 39913d7..403aede 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -284,7 +284,8 @@ void get_patch_filename(struct commit *commit, int nr, const char *suffix,
void log_write_email_headers(struct rev_info *opt, struct commit *commit,
const char **subject_p,
const char **extra_headers_p,
- int *need_8bit_cte_p)
+ int *need_8bit_cte_p,
+ const char *encoding)
{
const char *subject = NULL;
const char *extra_headers = opt->extra_headers;
@@ -340,11 +341,12 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
"format.\n"
"--%s%s\n"
"Content-Type: text/plain; "
- "charset=UTF-8; format=fixed\n"
+ "charset=%s; format=fixed\n"
"Content-Transfer-Encoding: 8bit\n\n",
extra_headers ? extra_headers : "",
mime_boundary_leader, opt->mime_boundary,
- mime_boundary_leader, opt->mime_boundary);
+ mime_boundary_leader, opt->mime_boundary,
+ encoding);
extra_headers = subject_buffer;
get_patch_filename(opt->numbered_files ? NULL : commit, opt->nr,
@@ -433,7 +435,7 @@ void show_log(struct rev_info *opt)
if (opt->commit_format == CMIT_FMT_EMAIL) {
log_write_email_headers(opt, commit, &ctx.subject, &extra_headers,
- &ctx.need_8bit_cte);
+ &ctx.need_8bit_cte, get_commit_output_encoding());
} else if (opt->commit_format != CMIT_FMT_USERFORMAT) {
fputs(diff_get_color_opt(&opt->diffopt, DIFF_COMMIT), stdout);
if (opt->commit_format != CMIT_FMT_ONELINE)
diff --git a/log-tree.h b/log-tree.h
index 5c4cf7c..ce0acf7 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -17,7 +17,8 @@ void show_decorations(struct rev_info *opt, struct commit *commit);
void log_write_email_headers(struct rev_info *opt, struct commit *commit,
const char **subject_p,
const char **extra_headers_p,
- int *need_8bit_cte_p);
+ int *need_8bit_cte_p,
+ const char *encoding);
void load_ref_decorations(int flags);
#define FORMAT_PATCH_NAME_MAX 64
--
1.7.6.3.4.gf71f
^ permalink raw reply related
* [PATCH v3 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-20 8:21 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin, Junio C Hamano
In-Reply-To: <7v1uvptjhr.fsf@alter.siamese.dyndns.org>
The following two commands are expected to give the same output to a terminal:
$ git log --oneline --no-color
$ git log --pretty=format:'%h %s'
However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s".
Log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.
The same corruption is true for
$ git diff --submodule=log
and
$ git rev-list --pretty=format:%s HEAD
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
t/t4041-diff-submodule-option.sh | 56 ++++++------
t/t4205-log-pretty-formats.sh | 22 ++++-
t/t6006-rev-list-format.sh | 192 +++++++++++++++++++++++---------------
3 files changed, 164 insertions(+), 106 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index bf9a752..b0cec5e 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2009 Jens Lehmann, based on t7401 by Ping Yin
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Support for verbose submodule differences in git diff
@@ -10,6 +11,7 @@ This test tries to verify the sanity of the --submodule option of git diff.
. ./test-lib.sh
+added=$(printf "\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275")
add_file () {
sm=$1
shift
@@ -19,8 +21,11 @@ add_file () {
echo "$name" > "$name" &&
git add "$name" &&
test_tick &&
- git commit -m "Add $name"
+ msg_added_cp1251=$(echo "Add $name ($added $name)" | iconv -f utf-8 -t cp1251) &&
+ git config i18n.commitEncoding cp1251 &&
+ git commit -m "$msg_added_cp1251"
done >/dev/null
+ git config --unset i18n.commitEncoding
git rev-parse --verify HEAD | cut -c1-7
cd "$owd"
}
@@ -48,28 +53,25 @@ head2=$(add_file sm1 foo3)
test_expect_success 'modified submodule(forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ printf \"Submodule sm1 $head1..$head2:\n\
+ > Add foo3 ($added foo3)\n\
+\" > expected &&
test_cmp expected actual
"
test_expect_success 'modified submodule(forward)' "
git diff --submodule=log >actual &&
- cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ printf \"Submodule sm1 $head1..$head2:\n\
+ > Add foo3 ($added foo3)\n\
+\" > expected &&
test_cmp expected actual
"
test_expect_success 'modified submodule(forward) --submodule' "
git diff --submodule >actual &&
- cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ printf \"Submodule sm1 $head1..$head2:\n\
+ > Add foo3 ($added foo3)\n\
+\" > expected &&
test_cmp expected actual
"
@@ -98,11 +100,10 @@ head3=$(
test_expect_success 'modified submodule(backward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
-Submodule sm1 $head2..$head3 (rewind):
- < Add foo3
- < Add foo2
-EOF
+ printf \"Submodule sm1 $head2..$head3 (rewind):\n\
+ < Add foo3 ($added foo3)\n\
+ < Add foo2 ($added foo2)\n\
+\" > expected &&
test_cmp expected actual
"
@@ -110,13 +111,12 @@ head4=$(add_file sm1 foo4 foo5) &&
head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
test_expect_success 'modified submodule(backward and forward)' "
git diff-index -p --submodule=log HEAD >actual &&
- cat >expected <<-EOF &&
-Submodule sm1 $head2...$head4:
- > Add foo5
- > Add foo4
- < Add foo3
- < Add foo2
-EOF
+ printf \"Submodule sm1 $head2...$head4:\n\
+ > Add foo5 ($added foo5)\n\
+ > Add foo4 ($added foo4)\n\
+ < Add foo3 ($added foo3)\n\
+ < Add foo2 ($added foo2)\n\
+\" > expected &&
test_cmp expected actual
"
@@ -131,10 +131,10 @@ mv sm1-bak sm1
test_expect_success 'typechanged submodule(submodule->blob), --cached' "
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 41fbea9...0000000 (submodule deleted)
+Submodule sm1 $head4...0000000 (submodule deleted)
diff --git a/sm1 b/sm1
new file mode 100644
-index 0000000..9da5fb8
+index 0000000..$head5
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -148,7 +148,7 @@ test_expect_success 'typechanged submodule(submodule->blob)' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
deleted file mode 100644
-index 9da5fb8..0000000
+index $head5..0000000
--- a/sm1
+++ /dev/null
@@ -1 +0,0 @@
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 2ae9faa..9da6835 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -1,6 +1,7 @@
#!/bin/sh
#
# Copyright (c) 2010, Will Palmer
+# Copyright (c) 2011, Alexey Shumkin (+ non-UTF-8 commit encoding tests)
#
test_description='Test pretty formats'
@@ -11,10 +12,13 @@ test_expect_success 'set up basic repos' '
>bar &&
git add foo &&
test_tick &&
- git commit -m initial &&
+ git config i18n.commitEncoding cp1251 &&
+ msg_commit_cp1251=$(printf "initial \320\272\320\276\320\274\320\274\320\270\321\202" | iconv -f utf-8 -t cp1251) &&
+ git commit -m "$msg_commit_cp1251" &&
git add bar &&
test_tick &&
- git commit -m "add bar"
+ git commit -m "add bar" &&
+ git config --unset i18n.commitEncoding
'
test_expect_success 'alias builtin format' '
@@ -38,6 +42,20 @@ test_expect_success 'alias user-defined format' '
test_cmp expected actual
'
+test_expect_success 'alias user-defined tformat with %s (cp1251 encoding)' '
+ git config i18n.logOutputEncoding cp1251 &&
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ git config --unset i18n.logOutputEncoding &&
+ test_cmp expected-s actual-s
+'
+
+test_expect_success 'alias user-defined tformat with %s (utf-8 encoding)' '
+ git log --oneline >expected-s &&
+ git log --pretty="tformat:%h %s" >actual-s &&
+ test_cmp expected-s actual-s
+'
+
test_expect_success 'alias user-defined tformat' '
git log --pretty="tformat:%h" >expected &&
git config pretty.test-alias "tformat:%h" &&
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index d918cc0..8d99635 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -1,13 +1,34 @@
#!/bin/sh
+# Copyright (c) 2009 Jens Lehmann
+# Copyright (c) 2011 Alexey Shumkin (+ non-UTF-8 commit encoding tests)
+
test_description='git rev-list --pretty=format test'
. ./test-lib.sh
test_tick
+added=$(printf "added (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+added_cp1251=$(echo "$added" | iconv -f utf-8 -t cp1251)
+changed=$(printf "changed (\320\264\320\276\320\261\320\260\320\262\320\273\320\265\320\275) foo")
+changed_cp1251=$(echo "$changed" | iconv -f utf-8 -t cp1251)
+
test_expect_success 'setup' '
-touch foo && git add foo && git commit -m "added foo" &&
- echo changed >foo && git commit -a -m "changed foo"
+ touch foo &&
+ git add foo &&
+ git config i18n.commitEncoding cp1251 &&
+ git commit -m "$added_cp1251" &&
+ head1=$(git rev-parse --verify HEAD) &&
+ head1_7=$(echo $head1 | cut -c1-7) &&
+ echo "$changed" > foo &&
+ git commit -a -m "$changed_cp1251" &&
+ head2=$(git rev-parse --verify HEAD) &&
+ head2_7=$(echo $head2 | cut -c1-7) &&
+ tree2=$(git cat-file -p HEAD | grep tree | cut -f 2 -d" ") &&
+ tree2_7=$(echo $tree2 | cut -c1-7) &&
+ head2_parent=$(git cat-file -p HEAD | grep parent | cut -f 2 -d" ") &&
+ head2_parent_7=$(echo $head2_parent | cut -c1-7) &&
+ git config --unset i18n.commitEncoding
'
# usage: test_format name format_string <expected_output
@@ -19,49 +40,49 @@ test_cmp expect.$1 output.$1
"
}
-test_format percent %%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format percent %%h <<EOF
+commit $head2
%h
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
%h
EOF
-test_format hash %H%n%h <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-131a310eb913d107dd3c09a65d1651175898735d
-131a310
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
+test_format hash %H%n%h <<EOF
+commit $head2
+$head2
+$head2_7
+commit $head1
+$head1
+$head1_7
EOF
-test_format tree %T%n%t <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-fe722612f26da5064c32ca3843aa154bdb0b08a0
-fe72261
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format tree %T%n%t <<EOF
+commit $head2
+$tree2
+$tree2_7
+commit $head1
4d5fcadc293a348e88f777dc0920f11e7d71441c
4d5fcad
EOF
-test_format parents %P%n%p <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-86c75cf
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format parents %P%n%p <<EOF
+commit $head2
+$head1
+$head2_parent_7
+commit $head1
EOF
# we don't test relative here
-test_format author %an%n%ae%n%ad%n%aD%n%at <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format author %an%n%ae%n%ad%n%aD%n%at <<EOF
+commit $head2
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
A U Thor
author@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -69,14 +90,14 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format committer %cn%n%ce%n%cd%n%cD%n%ct <<EOF
+commit $head2
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
Thu, 7 Apr 2005 15:13:13 -0700
1112911993
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
C O Mitter
committer@example.com
Thu Apr 7 15:13:13 2005 -0700
@@ -84,86 +105,105 @@ Thu, 7 Apr 2005 15:13:13 -0700
1112911993
EOF
-test_format encoding %e <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format encoding %e <<EOF
+commit $head2
+commit $head1
EOF
-test_format subject %s <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format subject %s <<EOF
+$expected
EOF
-test_format body %b <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format body %b <<EOF
+commit $head2
+commit $head1
EOF
-test_format raw-body %B <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
+expected=$(printf "commit $head2\n\
+$changed\n\
+\n\
+commit $head1\n\
+$added
+")
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+test_format raw-body %B <<EOF
+$expected
EOF
-test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<EOF
+commit $head2
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[31mfoo^[[32mbar^[[34mbaz^[[mxyzzy
EOF
-test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<'EOF'
-commit 131a310eb913d107dd3c09a65d1651175898735d
+test_format advanced-colors '%C(red yellow bold)foo%C(reset)' <<EOF
+commit $head2
^[[1;31;43mfoo^[[m
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head1
^[[1;31;43mfoo^[[m
EOF
-cat >commit-msg <<'EOF'
+iconv -f utf-8 -t cp1251 > commit-msg <<EOF
Test printing of complex bodies
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
EOF
+
test_expect_success 'setup complex body' '
-git config i18n.commitencoding iso8859-1 &&
- echo change2 >foo && git commit -a -F commit-msg
+ git config i18n.commitencoding cp1251 &&
+ echo change2 >foo && git commit -a -F commit-msg &&
+ head3=$(git rev-parse --verify HEAD) &&
+ head3_7=$(echo $head3 | cut -c1-7)
'
-test_format complex-encoding %e <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-iso8859-1
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+test_format complex-encoding %e <<EOF
+commit $head3
+cp1251
+commit $head2
+cp1251
+commit $head1
+cp1251
EOF
-test_format complex-subject %s <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
-Test printing of complex bodies
-commit 131a310eb913d107dd3c09a65d1651175898735d
-changed foo
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-added foo
+# unset commit encoding config
+# otherwise %e does not print encoding value
+# and following test fails
+git config --unset i18n.commitencoding
+
+expected=$(printf "commit $head3\n\
+Test printing of complex bodies\n\
+commit $head2\n\
+$changed\n\
+commit $head1\n\
+$added
+")
+
+test_format complex-subject %s <<EOF
+$expected
EOF
-test_format complex-body %b <<'EOF'
-commit f58db70b055c5718631e5c61528b28b12090cdea
+test_format complex-body %b <<EOF
+commit $head3
This commit message is much longer than the others,
-and it will be encoded in iso8859-1. We should therefore
-include an iso8859 character: ¡bueno!
+and it will be encoded in cp1251. We should therefore
+include an cp1251 character: так вот!
-commit 131a310eb913d107dd3c09a65d1651175898735d
-commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+commit $head2
+commit $head1
EOF
test_expect_success '%x00 shows NUL' '
- echo >expect commit f58db70b055c5718631e5c61528b28b12090cdea &&
+ echo >expect commit $head3 &&
echo >>expect fooQbar &&
git rev-list -1 --format=foo%x00bar HEAD >actual.nul &&
nul_to_q <actual.nul >actual &&
@@ -210,12 +250,12 @@ test_expect_success 'add LF before non-empty (2)' '
test_expect_success 'add SP before non-empty (1)' '
git show -s --pretty=format:"%s% bThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 2
+ test $(wc -w <actual) = 3
'
test_expect_success 'add SP before non-empty (2)' '
git show -s --pretty=format:"%s% sThanks" HEAD^^ >actual &&
- test $(wc -w <actual) = 4
+ test $(wc -w <actual) = 6
'
test_expect_success '--abbrev' '
--
1.7.6.3.4.gf71f
^ 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