Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

2017-04-29 Thread Torsten Bögershausen 



On 30/04/17 00:28, René Scharfe wrote:

Am 29.04.2017 um 23:00 schrieb Torsten Bögershausen:

This fails here under Mac OS:
commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15
Author: René Scharfe 
Date:   Mon Apr 24 19:33:34 2017 +0200

 archive-zip: support files bigger than 4GB

---
Parts of t5004.log, hope this is helpful:

"$GIT_UNZIP" -t many-big.zip

Archive:  many-big.zip
warning [many-big.zip]:  577175 extra bytes at beginning or within zipfile
   (attempting to process anyway)
error [many-big.zip]:  start of central directory not found;
   zipfile corrupt.
   (please check that you have transferred or created the zipfile in the
   appropriate BINARY mode and that you have compiled UnZip properly)
not ok 12 - zip archive bigger than 4GB
#   
#   # build string containing 65536 characters


Which version of unzip do you have (unzip -v, look for ZIP64_SUPPORT)?
It seems that (some version of?) OS X ships with an older unzip which
can't handle big files:

   
https://superuser.com/questions/114011/extract-large-zip-file-50-gb-on-mac-os-x

Is the following check (zip archive with files bigger than 4GB) skipped,
e.g. because ZIPINFO is missing?  Otherwise I would expect it to fail as
well.

René



Sorry, I was not looking careful enough, the macro `$GIT_UNZIP`
gave the impression that an unzip provided by Git (or the Git test framework) 
was used :-(


$ which unzip
/usr/bin/unzip

$ unzip -v
UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1) for Unix 
on Aug  1 2015.


UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
[decryption, version 2.9 of 05 May 2000]

UnZip and ZipInfo environment options:
   UNZIP:  [none]
UNZIPOPT:  [none]
 ZIPINFO:  [none]
  ZIPINFOOPT:  [none]

---
And here is the longer log:
not ok 12 - zip archive bigger than 4GB
#
#   # build string containing 65536 characters
# 
s=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef &&
# 
s=$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s &&
# 
s=$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s &&

#
#   # create blob with a length of 65536 + 1 bytes
#   blob=$(echo $s | git hash-object -w --stdin) &&
#
#   # create tree containing 65500 entries of that blob
#   for i in $(test_seq 1 65500)
#   do
#   echo "100644 blob $blob $i"
#   done >tree &&
#   tree=$(git mktree big.lst &&
grep $size big.lst

ok 13 # skip zip archive with files bigger than 4GB (missing ZIPINFO of 
EXPENSIVE,UNZIP,ZIPINFO)


# failed 1 among 13 test(s)
1..13

Re: [PATCHv2 0/3] Make diff plumbing commands respect the indentHeuristic.

2017-04-29 Thread Michael Haggerty 
On 04/29/2017 02:40 PM, Jeff King wrote:
> On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote:
> 
>> v2: Fixed up the commit messages and added tests.
>>
>> Marc Branchaud (2):
>>   diff: make the indent heuristic part of diff's basic configuration
>>   diff: have the diff-* builtins configure diff before initializing
>> revisions
>>
>> Stefan Beller (1):
>>   diff: enable indent heuristic by default
> 
> Thanks, these look fine to me. I'd like to get an ACK from Michael, in
> case he had some other reason for omitting them from git_diff_ui_config
> (from my recollection, it's probably just a mix of conservatism and
> following what the compaction heuristic had done).

That's exactly right. The only discussion I remember about broadening
the scope of diff options was with regards to `blame` [1]. I don't
really have enough overview of these configuration topics to have much
an opinion.

Michael

[1]
http://public-inbox.org/git/xmqqtwebwhbg@gitster.mtv.corp.google.com/

Re: [PATCH 1/5] add SWAP macro

2017-04-29 Thread Jeff King 
On Sat, Apr 29, 2017 at 08:16:17PM +0200, René Scharfe wrote:

> > I dunno. I could go either way. Or we could leave it as-is, and let
> > valgrind find the problem. That has zero run-time cost, but of course
> > nobody bothers to run valgrind outside of the test suite, so the inputs
> > are not usually very exotic.
> 
> It would be  problematic on platforms where memcpy has to erase the
> destination before writing new values (I don't know any example).
> 
> We could use two temporary buffers.  The object code is the same with
> GCC around 5 and Clang 3.2 or higher -- at least for prio-queue.c.

Hmm, yeah, that's an easy solution that covers the overlap case, too. If
the generated code is the same, that seems like it might not be bad (I
am a little sad how complex this simple swap operation is getting,
though).

> > Yes, the overlap case is probably an actual bug. Detecting it is a bit
> > harder, but definitely possible. I hate to pay the run-time cost for it,
> > but I wonder if a compiler could optimize it out.
> 
> How is it possible to arrive at such a situation?  We'd need two objects
> of the same size (we check that in SWAP) and one of them would start
> inside of the other one, i.e. the pointer difference between them would
> be a fraction of 1.  So the type system would have to be tricked into
> it, right?

Yeah, I guess it would be pretty odd. I was thinking of swapping a
struct and one of its components, but that fail the size equality check.
And anyway that would be a silly thing to do in the first place, so it's
probably not worth thinking too much about.

> It may be my laziness speaking, but do we really need such a check?  If
> someone constructs interleaving objects then they'd need to implement
> the necessary checks themselves IMHO.

Yeah, I think we can live without it. I was mostly trying to think
through whether there were worse cases than the one we saw. But you've
convinced me that there probably aren't.

> > > The line in question is this one:
> > > 
> > >   for (i = 0; i <= (j = (queue->nr - 1) - i); i++)
> > > 
> > > Assignment in the middle?  Hmm.  Why not do it like this?
> > > 
> > >   for (i = 0, j = queue->nr - 1; i < j; i++, j--)
> > > 
> > > Looks less complicated to me.
> > 
> > Yes, see my other reply. :)
> 
> Ah, so that's where I stole it from. ;)  Perhaps my source amnesia was
> in part caused by confusion about your reasoning there: The code does A,
> B would be better, so let's do C.  Wait, what? :)

My reasoning was that there's a bug, and the patch does the minimal fix.
I don't mind making a readability improvement on top, but the two are
orthogonal. I.e., you could still write:

  for (i = 0, j = queue->nr - 1; i <= j; i++, j--)

which is more readable but still buggy. :)

-Peff

Bug: wrong documentation for git-fast-import's option command

2017-04-29 Thread Tomi Belan 
The man page of git-fast-import says the syntax is "'option' SP
 LF". But this is wrong, and commands like that will be
silently ignored.

fast-import.c only parses commands starting with "option git ", and
ignores others starting with "option ". See
https://github.com/git/git/blob/027a3b943b444a3e3a76f9a89803fc10245b858f/fast-import.c#L3487-L3490
.

The correct syntax is e.g. "option git stats" or "option git
big-file-threshold=123". The docs should say "'option' SP 'git' SP
 LF" or maybe even "'option' SP 'git' SP  ('='
)? LF" (similarly to the docs for feature), and explain this
is meant to allow other consumers of the fast import format.

Looks like this bug existed since the option command was added in
9c8398f in 2009. Am I the first one who tried to use it? ;-)

Cheers,

Tomi

Re: git loses a commit after reordering.

2017-04-29 Thread Kevin Daudt 
On Thu, Apr 27, 2017 at 10:43:16AM +0300, Nikita Orlov wrote:
> Hello, my name is Nikita (male).
> 
> Could you explain this (subject) is a bug or a feature?
> 
> [snip]
> 
> "Some independent changes 1" is missed and its changes are missed as well.
> 
> I tried to move another commit to a farther distance below but there was 
> still only one missed commit.
> 
> Could you explain it?
> 
> Thank you in advance and sorry for my English.
> 
> Best, Nikita

[man git-rebase][0] mentions this under the bug section:

> The todo list presented by --preserve-merges --interactive does not
> represent the topology of the revision graph. Editing commits and
> rewording their commit messages should work fine, but attempts to
> reorder commits tend to produce counterintuitive results.

Not sure if this is the case here, but it at least confirms that rebase
--preserve-merges was not meant to reorder commits.

See [this][1] thread for more background on this limitation.

[0]:https://git-scm.com/docs/git-rebase#_bugs
[1]:https://public-inbox.org/git/1mtveu4.19lvgi1c0hmham%25li...@haller-berlin.de/

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

2017-04-29 Thread René Scharfe 
Am 29.04.2017 um 23:00 schrieb Torsten Bögershausen:
> This fails here under Mac OS:
> commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15
> Author: René Scharfe 
> Date:   Mon Apr 24 19:33:34 2017 +0200
> 
>  archive-zip: support files bigger than 4GB
> 
> ---
> Parts of t5004.log, hope this is helpful:
> 
> "$GIT_UNZIP" -t many-big.zip
> 
> Archive:  many-big.zip
> warning [many-big.zip]:  577175 extra bytes at beginning or within zipfile
>(attempting to process anyway)
> error [many-big.zip]:  start of central directory not found;
>zipfile corrupt.
>(please check that you have transferred or created the zipfile in the
>appropriate BINARY mode and that you have compiled UnZip properly)
> not ok 12 - zip archive bigger than 4GB
> # 
> # # build string containing 65536 characters

Which version of unzip do you have (unzip -v, look for ZIP64_SUPPORT)?
It seems that (some version of?) OS X ships with an older unzip which
can't handle big files:

   
https://superuser.com/questions/114011/extract-large-zip-file-50-gb-on-mac-os-x

Is the following check (zip archive with files bigger than 4GB) skipped,
e.g. because ZIPINFO is missing?  Otherwise I would expect it to fail as
well.

René

Re: git with ssh won't pull submodule

2017-04-29 Thread Erik Haller 
Ah. I was able to get it to work with the ssh protocol and a relative
path. Thank you for your help.

On Fri, Apr 28, 2017 at 8:45 AM, Chris Packham  wrote:
> Hi Erik,
>
> On Fri, Apr 28, 2017 at 11:25 AM, Erik Haller  wrote:
>> Getting the following error for a submodule when using git/ssh:
>>
>> $ git clone --recursive ssh://incense:/home/erik/git/nacl.git
>> Cloning into 'nacl'...
>> remote: Counting objects: 32, done.
>> remote: Compressing objects: 100% (25/25), done.
>> remote: Total 32 (delta 5), reused 0 (delta 0)
>> Receiving objects: 100% (32/32), 16.50 KiB | 0 bytes/s, done.
>> Resolving deltas: 100% (5/5), done.
>> Submodule 'vendor/golang.org/x/crypto'
>> (file:///home/erik/git/github.com/golang/crypto.git) registered for
>> path 'vendor/golang.org/x/crypto'
>
> This is the problem. The .gitmodules entry in nacl.git uses an
> absolute path (or URI in this case) for the submodule. Git does
> exactly what it should and tries to clone it.
>
> The solution to this is to use a relative path[1] in .gitmodules
> (either edit it by hand or do git rm & git submodule add). Note that
> by using a relative path it assumes that the parent and submodule
> repositories are hosted in the same location (which may or may not be
> true for your use-case).
>
> --
> [1] - see the 3rd paragraph for the add command in
> https://git-scm.com/docs/git-submodule
>
>> Cloning into '/home/erik/go/src/nacl/vendor/golang.org/x/crypto'...
>> fatal: '/home/erik/git/github.com/golang/crypto.git' does not appear
>> to be a git repository
>> fatal: Could not read from remote repository.
>>
>> Please make sure you have the correct access rights
>> and the repository exists.
>> fatal: clone of 'file:///home/erik/git/github.com/golang/crypto.git'
>> into submodule path
>> '/home/erik/go/src/nacl/vendor/golang.org/x/crypto' failed
>> Failed to clone 'vendor/golang.org/x/crypto'. Retry scheduled
>> Cloning into '/home/erik/go/src/nacl/vendor/golang.org/x/crypto'...
>> fatal: '/home/erik/git/github.com/golang/crypto.git' does not appear
>> to be a git repository
>> fatal: Could not read from remote repository.
>>
>> Please make sure you have the correct access rights
>> and the repository exists.
>> fatal: clone of 'file:///home/erik/git/github.com/golang/crypto.git'
>> into submodule path
>> '/home/erik/go/src/nacl/vendor/golang.org/x/crypto' failed
>> Failed to clone 'vendor/golang.org/x/crypto' a second time, aborting
>>
>>
>> The git clone --recursive file:///home/erik/git/nacl.git works fine
>> and pulls the submodule "crypto.git". Any ideas?
>>
>> - The crypto.git is a valid repo.
>> - I have the correct permissions.
>> - The crypto.git repo is a git --mirror repo.
>>
>>
>> git version: 2.11.0
>> system: linux debian/testing

Re: [PATCH v3 0/5] archive-zip: support files and archives bigger than 4GB

2017-04-29 Thread Torsten Bögershausen 
On 2017-04-24 19:22, René Scharfe wrote:
> The first patch adds (expensive) tests, the next two are cleanups which
> set the stage for the remaining two to actually implement zip64 support
> for offsets and file sizes.
> 
> Half of the series had been laying around for months, half-finished and
> forgotten because I got distracted by the holiday season. :-/
> 
>   archive-zip: add tests for big ZIP archives
>   archive-zip: use strbuf for ZIP directory
>   archive-zip: write ZIP dir entry directly to strbuf
>   archive-zip: support archives bigger than 4GB
>   archive-zip: support files bigger than 4GB
> 
>  archive-zip.c   | 211 
> 
>  t/t5004-archive-corner-cases.sh |  45 +
>  t/t5004/big-pack.zip| Bin 0 -> 7373 bytes
>  3 files changed, 172 insertions(+), 84 deletions(-)
>  create mode 100644 t/t5004/big-pack.zip
> 
This fails here under Mac OS:
commit 4cdf3f9d84568da72f1dcade812de7a42ecb6d15
Author: René Scharfe 
Date:   Mon Apr 24 19:33:34 2017 +0200

archive-zip: support files bigger than 4GB

---
Parts of t5004.log, hope this is helpful:

"$GIT_UNZIP" -t many-big.zip

Archive:  many-big.zip
warning [many-big.zip]:  577175 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [many-big.zip]:  start of central directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)
not ok 12 - zip archive bigger than 4GB
#   
#   # build string containing 65536 characters

Re: Bug: Git rename does not work if folder naming was changed from lower to upper case on OSX

2017-04-29 Thread Kevin Daudt 
On Sat, Apr 29, 2017 at 12:47:13PM +0200, Robert Eisele wrote:
> Hi,
> 
> after having committed folders with lower case naming, I decided to rename
> them to upper-case names. Expecting git to detect them as renamings, it
> started a new parallel hierarchy with new files, which I had to add/commit.
> 
> It was a kinda strange behavior, which I fixed by rename the folder to
> something completely different, commit and rename the folder again to the
> desired value.
> 
> Is this an actual desired behavior or is it a bug?
> 
> Robert
> 

Note that git does not store that files are renamed. So a remove + add
is the same as a rename in git. Only git status shows it when you for
example use git mv directly, but this information is lost on commit.
Instead of storing it get relies on detecting what (parts of ) files got
renamed, copied etc.

[PATCH v1] travis-ci: handle Git for Windows CI status "failed" explicitly

2017-04-29 Thread Lars Schneider 
Git for Windows CI returns "completed: failed" if a build or test
failure happened. This case was processed as "Unhandled status".
Handle the case explicitly.

Signed-off-by: Lars Schneider 
---

Notes:
Base Ref: next
Web-Diff: https://github.com/larsxschneider/git/commit/57840905a5
Checkout: git fetch https://github.com/larsxschneider/git 
travisci/win-fail-v1 && git checkout 57840905a5

 ci/run-windows-build.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh
index e043440799..1bb3a021ee 100755
--- a/ci/run-windows-build.sh
+++ b/ci/run-windows-build.sh
@@ -61,7 +61,8 @@ do
case "$STATUS" in
inProgress|postponed|notStarted) sleep 10   ;; # continue
 "completed: succeeded") RESULT="success"; break;; # success
-   *) echo "Unhandled status: $STATUS";   break;; # failure
+   "completed: failed")   break;; # failure
+   *) echo "Unhandled status: $STATUS";   break;; # unknown
esac
 done
 

base-commit: 1ea7e62026c5dde4d8be80b2544696fc6aa70121
-- 
2.12.2

[PATCH v1] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

2017-04-29 Thread Lars Schneider 
The Git for Windows CI web app sometimes returns HTTP errors of
"502 bad gateway" or "503 service unavailable" [1]. Wait a little and
retry the request if this happens.

[1] 
https://docs.microsoft.com/en-in/azure/app-service-web/app-service-web-troubleshoot-http-502-http-503

Signed-off-by: Lars Schneider 
---

Hi,

this should make the Git for Windows build a bit more stable. We saw
a few 502's recently. E.g. https://travis-ci.org/git/git/jobs/226669324

I did not add any checks to avoid an endless loop because TravisCI would
shutdown the worker if there is no output for more than 10min. Therefore
I think we don't need to handle this case ourselves.

Cheers,
Lars

Notes:
Base Ref: next
Web-Diff: https://github.com/larsxschneider/git/commit/b57ebf31ab
Checkout: git fetch https://github.com/larsxschneider/git 
travisci/win-retry-v1 && git checkout b57ebf31ab

 ci/run-windows-build.sh | 12 
 1 file changed, 12 insertions(+)

diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh
index e043440799..7a9aa9c6a7 100755
--- a/ci/run-windows-build.sh
+++ b/ci/run-windows-build.sh
@@ -15,6 +15,8 @@ COMMIT=$2
 gfwci () {
local CURL_ERROR_CODE HTTP_CODE
exec 3>&1
+   while test -z $HTTP_CODE
+   do
HTTP_CODE=$(curl \
-H "Authentication: Bearer $GFW_CI_TOKEN" \
--silent --retry 5 --write-out '%{HTTP_CODE}' \
@@ -22,6 +24,16 @@ gfwci () {
"https://git-for-windows-ci.azurewebsites.net/api/TestNow?$1; \
)
CURL_ERROR_CODE=$?
+   # The GfW CI web app sometimes returns HTTP errors of
+   # "502 bad gateway" or "503 service unavailable".
+   # Wait a little and retry if it happens. More info:
+   # 
https://docs.microsoft.com/en-in/azure/app-service-web/app-service-web-troubleshoot-http-502-http-503
+   if test $HTTP_CODE -eq 502 || test $HTTP_CODE -eq 503
+   then
+   sleep 10
+   HTTP_CODE=
+   fi
+   done
if test $CURL_ERROR_CODE -ne 0
then
return $CURL_ERROR_CODE

base-commit: 1ea7e62026c5dde4d8be80b2544696fc6aa70121
--
2.12.2

Re: [PATCH 1/5] add SWAP macro

2017-04-29 Thread René Scharfe 

Am 28.04.2017 um 23:49 schrieb Jeff King:

On Fri, Apr 28, 2017 at 07:04:51PM +0200, René Scharfe wrote:


What should:

SWAP(foo[i], foo[j]);

do when i == j? With this code, it ends up calling

memcpy([i], [j], ...);

which can cause valgrind to complain about overlapping memory. I suspect
in practice that noop copies are better off than partial overlaps, but I
think it does still violate the standard.

Is it worth comparing the pointers and bailing early?


Hmm, so swapping a value with itself can be a useful thing to do?
Otherwise an assert would be more appropriate.


No, I doubt that it's useful, and it's probably a sign of a bug
elsewhere. But it's likely a _harmless_ bug, so it may be irritating to
die when we hit it rather than continuing.

I dunno. I could go either way. Or we could leave it as-is, and let
valgrind find the problem. That has zero run-time cost, but of course
nobody bothers to run valgrind outside of the test suite, so the inputs
are not usually very exotic.


It would be  problematic on platforms where memcpy has to erase the
destination before writing new values (I don't know any example).

We could use two temporary buffers.  The object code is the same with
GCC around 5 and Clang 3.2 or higher -- at least for prio-queue.c.

With GCC 4.9.2 (that's what Debian stable currently has) the result is
actually slightly better with two buffers because a 128-bit move starts
to get used (https://godbolt.org/g/18HQDQ).


Swapping with *partial* overlap sounds tricky, or even evil.  If
we want to support that for some reason we'd have to use memmove
in the middle.  But that would still corrupt at least one of the
objects, wouldn't it?


Yes, the overlap case is probably an actual bug. Detecting it is a bit
harder, but definitely possible. I hate to pay the run-time cost for it,
but I wonder if a compiler could optimize it out.


How is it possible to arrive at such a situation?  We'd need two objects
of the same size (we check that in SWAP) and one of them would start
inside of the other one, i.e. the pointer difference between them would
be a fraction of 1.  So the type system would have to be tricked into
it, right?

How *would* we detect overlaps?  The obvious checks (a+len<=b||b+len<=a)
are undefined if applied to objects that don't belong to the same array.
And members of the same array would not overlap to begin with..

It may be my laziness speaking, but do we really need such a check?  If
someone constructs interleaving objects then they'd need to implement
the necessary checks themselves IMHO.


The line in question is this one:

for (i = 0; i <= (j = (queue->nr - 1) - i); i++)

Assignment in the middle?  Hmm.  Why not do it like this?

for (i = 0, j = queue->nr - 1; i < j; i++, j--)

Looks less complicated to me.


Yes, see my other reply. :)


Ah, so that's where I stole it from. ;)  Perhaps my source amnesia was
in part caused by confusion about your reasoning there: The code does A,
B would be better, so let's do C.  Wait, what? :)

René

Re: [PATCH] githooks.txt: clarify push hooks are always executed in $GIT_DIR

2017-04-29 Thread Ævar Arnfjörð Bjarmason 
On Sat, Apr 29, 2017 at 2:28 PM, Simon Ruderich  wrote:
> Listing the specific hooks might feel verbose but without it the
> reader is left to wonder which hooks are triggered during the
> push. Something which is not immediately obvious when only trying
> to find out where the hook is executed.
>
> Signed-off-by: Simon Ruderich 
> ---
>  Documentation/githooks.txt | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> On Mon, Apr 10, 2017 at 01:13:15PM +0200, Ęvar Arnfjörš Bjarmason wrote:
>> [snip]
>>
>> Can we say as we do now that:
>>
>> * All hooks regardless of type in bare repos execute in the bare repo
>> * If you have a working tree hooks use that
>>
>> But add:
>>
>> * Working trees are ignored by any hooks invoked on your behalf during a 
>> push.
>
> Hello,
>
> Maybe like this? I reordered the cases as it felt more natural
> that the general case is first and followed by the one with the
> exception.
>
>> Some ad-hoc testing reveals that this rule also goes for the
>> push-to-checkout hook. Should it? Wouldn't it be more useful if it
>> broke the pattern, since it's dealing with the working tree on the
>> other side? Junio?
>
> I added push-to-checkout to the patch. Changing the behavior will
> break backwards compatibility so I think that's a no-go.
>
> Regards
> Simon
>
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 32343ae29..706091a56 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -22,8 +22,10 @@ changed via the `core.hooksPath` configuration variable 
> (see
>  linkgit:git-config[1]).
>
>  Before Git invokes a hook, it changes its working directory to either
> -the root of the working tree in a non-bare repository, or to the
> -$GIT_DIR in a bare repository.
> +$GIT_DIR in a bare repository or the root of the working tree in a non-bare
> +repository. An exception are hooks triggered during a push ('pre-receive',
> +'update', 'post-receive', 'post-update', 'push-to-checkout') which are always
> +executed in $GIT_DIR.
>
>  Hooks can get their arguments via the environment, command-line
>  arguments, and stdin. See the documentation for each hook below for

This looks good to me. Thanks for working on this.

[PATCH/RFC 1/1] t0027: Some tests are not expensive

2017-04-29 Thread tboegi 
From: Torsten Bögershausen 

The purpose of t0027 is to test all CRLF related conversions at
"git checkout" and "git add".

Running t0027 under Git for Windows takes 3-4 minutes, so the whole script
had been marked as "EXPENSIVE".

The source code for "Git for Windows" overrides this since 2014:
"t0027 is marked expensive, but really, for MinGW we want to run these
tests always."

Recent "stress" tests show that t0025 if flaky, reported by Lars Schneider,
larsxschnei...@gmail.com

All tests from t0025 are covered in t0027 as well, so that t0025 can be
retired later.

Split the tests in t0027 into 2 groups: expensive and not expensive.
Expensive are all tests which check the CRLF conversion warnings and
all tests which activate the Git internal "ident" filter.

All other test are now run under all platforms, which allows to remove
the flaky t0025 in the next commit.

The execution time for the non-expansive part is 6..8 seconds under Linux,
and 32 seconds under Mac Os X.

Running the "expensive" version roughly doubles the time.

And in case you ask, things are not going significantly faster using a SSD
instead of a spinning disk.

Signed-off-by: Torsten Bögershausen 
PS: The removal of t0025 is not included (yet)
---
 t/t0027-auto-crlf.sh | 100 ++-
 1 file changed, 59 insertions(+), 41 deletions(-)

diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 90db54c..2c5aff6 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -4,10 +4,12 @@ test_description='CRLF conversion all combinations'
 
 . ./test-lib.sh
 
-if ! test_have_prereq EXPENSIVE
+if ! test_have_prereq EXPENSIVE && ! test_have_prereq MINGW
 then
-   skip_all="EXPENSIVE not set"
-   test_done
+   say "# EXPENSIVE or MINGW not set, skipping ident and warning tests"
+else
+   EXPENSIVE0027=t
+   export EXPENSIVE0027
 fi
 
 compare_files () {
@@ -95,11 +97,14 @@ commit_check_warn () {
git -c core.autocrlf=$crlf add $fname 2>"${pfx}_$f.err"
done &&
git commit -m "core.autocrlf $crlf" &&
-   check_warning "$lfname" ${pfx}_LF.err &&
-   check_warning "$crlfname" ${pfx}_CRLF.err &&
-   check_warning "$lfmixcrlf" ${pfx}_CRLF_mix_LF.err &&
-   check_warning "$lfmixcr" ${pfx}_LF_mix_CR.err &&
-   check_warning "$crlfnul" ${pfx}_CRLF_nul.err
+   if test "$EXPENSIVE0027" = t
+   then
+   check_warning "$lfname" ${pfx}_LF.err &&
+   check_warning "$crlfname" ${pfx}_CRLF.err &&
+   check_warning "$lfmixcrlf" ${pfx}_CRLF_mix_LF.err &&
+   check_warning "$lfmixcr" ${pfx}_LF_mix_CR.err &&
+   check_warning "$crlfnul" ${pfx}_CRLF_nul.err
+   fi
 }
 
 commit_chk_wrnNNO () {
@@ -122,24 +127,27 @@ commit_chk_wrnNNO () {
git -c core.autocrlf=$crlf add $fname 2>"${pfx}_$f.err"
done
 
-   test_expect_success "commit NNO files crlf=$crlf attr=$attr LF" '
-   check_warning "$lfwarn" ${pfx}_LF.err
-   '
-   test_expect_success "commit NNO files attr=$attr aeol=$aeol crlf=$crlf 
CRLF" '
-   check_warning "$crlfwarn" ${pfx}_CRLF.err
-   '
-
-   test_expect_success "commit NNO files attr=$attr aeol=$aeol crlf=$crlf 
CRLF_mix_LF" '
-   check_warning "$lfmixcrlf" ${pfx}_CRLF_mix_LF.err
-   '
-
-   test_expect_success "commit NNO files attr=$attr aeol=$aeol crlf=$crlf 
LF_mix_cr" '
-   check_warning "$lfmixcr" ${pfx}_LF_mix_CR.err
-   '
-
-   test_expect_success "commit NNO files attr=$attr aeol=$aeol crlf=$crlf 
CRLF_nul" '
-   check_warning "$crlfnul" ${pfx}_CRLF_nul.err
-   '
+   if test "$EXPENSIVE0027" = t
+   then
+   test_expect_success "commit NNO files crlf=$crlf attr=$attr LF" 
'
+   check_warning "$lfwarn" ${pfx}_LF.err
+   '
+   test_expect_success "commit NNO files attr=$attr aeol=$aeol 
crlf=$crlf CRLF" '
+   check_warning "$crlfwarn" ${pfx}_CRLF.err
+   '
+
+   test_expect_success "commit NNO files attr=$attr aeol=$aeol 
crlf=$crlf CRLF_mix_LF" '
+   check_warning "$lfmixcrlf" ${pfx}_CRLF_mix_LF.err
+   '
+
+   test_expect_success "commit NNO files attr=$attr aeol=$aeol 
crlf=$crlf LF_mix_cr" '
+   check_warning "$lfmixcr" ${pfx}_LF_mix_CR.err
+   '
+
+   test_expect_success "commit NNO files attr=$attr aeol=$aeol 
crlf=$crlf CRLF_nul" '
+   check_warning "$crlfnul" ${pfx}_CRLF_nul.err
+   '
+   fi
 }
 
 stats_ascii () {
@@ -250,21 +258,24 @@ checkout_files () {
fi
done
 
-   test_expect_success "ls-files --eol attr=$attr $ident aeol=$aeol 
core.autocrlf=$crlf core.eol=$ceol" '
-   test_when_finished "rm expect actual" &&
-

Re: Bug: Git rename does not work if folder naming was changed from lower to upper case on OSX

2017-04-29 Thread Torsten Bögershausen 




after having committed folders with lower case naming, I decided to rename them
to upper-case names. Expecting git to detect them as renamings, it started a
new parallel hierarchy with new files, which I had to add/commit.

It was a kinda strange behavior, which I fixed by rename the folder to
something completely different, commit and rename the folder again to the
desired value.

Is this an actual desired behavior or is it a bug?


It is expected (but may be unexpected), I hope these hints are not too harsh:
You can blame the vendor of the OS,
who decided to design a file system which ignores the case of files.
(Or yourself, because you use it)
(Or yourself, because you can install a HFS+ partition under OSX which
is NOT case insensitive, but few people seem to know about this or use it)
(harsh mode off)

The correct way to rename a file under Git is to use Git:

git init
Initialized empty Git repository in /private/tmp/ttt/.git/
user@Mac:/tmp/ttt>mkdir dir1
user@Mac:/tmp/ttt>echo File >dir1/file
user@Mac:/tmp/ttt>git add dir1/file
user@Mac:/tmp/ttt>git commit -m "add dir1/file"
[master (root-commit) 14d3862] add dir1/file
 1 file changed, 1 insertion(+)
 create mode 100644 dir1/file
user@Mac:/tmp/ttt>git mv dir1/file DIR1/FILE
user@Mac:/tmp/ttt>git commit  "mv dir1/file DIR1/FILE"
user@Mac:/tmp/ttt>git ls-files
DIR1/FILE




Robert

[PATCH 4/3] add--interactive: drop diff.indentHeuristic handling

2017-04-29 Thread Jeff King 
On Sat, Apr 29, 2017 at 08:40:52AM -0400, Jeff King wrote:

> On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote:
> 
> > v2: Fixed up the commit messages and added tests.
> > 
> > Marc Branchaud (2):
> >   diff: make the indent heuristic part of diff's basic configuration
> >   diff: have the diff-* builtins configure diff before initializing
> > revisions
> > 
> > Stefan Beller (1):
> >   diff: enable indent heuristic by default
> 
> Thanks, these look fine to me. I'd like to get an ACK from Michael, in
> case he had some other reason for omitting them from git_diff_ui_config
> (from my recollection, it's probably just a mix of conservatism and
> following what the compaction heuristic had done).

We can also do this simplification on top (once the other test problems
are fixed, of course).

-- >8 --
Subject: add--interactive: drop diff.indentHeuristic handling

Now that diff.indentHeuristic is handled automatically by the plumbing
commands, there's no need to propagate it manually.

Signed-off-by: Jeff King 
---
I actually wonder if diff.algorithm should go into git_diff_basic_config
by the same rationale as the rest of this series.

 git-add--interactive.perl | 4 
 1 file changed, 4 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 709a5f6ce..79d675b5b 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -46,7 +46,6 @@ my ($diff_new_color) =
 my $normal_color = $repo->get_color("", "reset");
 
 my $diff_algorithm = $repo->config('diff.algorithm');
-my $diff_indent_heuristic = $repo->config_bool('diff.indentheuristic');
 my $diff_filter = $repo->config('interactive.difffilter');
 
 my $use_readkey = 0;
@@ -730,9 +729,6 @@ sub parse_diff {
if (defined $diff_algorithm) {
splice @diff_cmd, 1, 0, "--diff-algorithm=${diff_algorithm}";
}
-   if ($diff_indent_heuristic) {
-   splice @diff_cmd, 1, 0, "--indent-heuristic";
-   }
if (defined $patch_mode_revision) {
push @diff_cmd, get_diff_reference($patch_mode_revision);
}
-- 
2.13.0.rc1.407.g644207685

Re: [PATCHv2 0/3] Make diff plumbing commands respect the indentHeuristic.

2017-04-29 Thread Jeff King 
On Sat, Apr 29, 2017 at 08:40:52AM -0400, Jeff King wrote:

> On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote:
> 
> > v2: Fixed up the commit messages and added tests.
> > 
> > Marc Branchaud (2):
> >   diff: make the indent heuristic part of diff's basic configuration
> >   diff: have the diff-* builtins configure diff before initializing
> > revisions
> > 
> > Stefan Beller (1):
> >   diff: enable indent heuristic by default
> 
> Thanks, these look fine to me. I'd like to get an ACK from Michael, in
> case he had some other reason for omitting them from git_diff_ui_config
> (from my recollection, it's probably just a mix of conservatism and
> following what the compaction heuristic had done).

Sorry, I spoke too soon. The third one needs a few test adjustments
squashed in to pass the tests.

The fixes below for t4061 are pretty obvious, but the one in t4051 is
anything but. What happens is that we have a function:

  int dummy();
  {
 some body
  }

and modify it to look like:

  int dummy();
  int dummy();
  {
 some body
  }

and we expect that this counts as making a change to the function for
the purposes of -W. But with the indent heuristic, instead of saying "we
added an extra line after the first dummy()", we say "we added an extra
dummy() before the function". Which is perfectly reasonable.

I don't think duplicating the line is important to the test, as opposed
to making any random change.  But we can't just change a line in the
body itself, because the point of the test is making sure -W shows the
whole function. And the function is short enough that a change in the
body would show the whole thing via context anyway. So I opted to make
the change at the same spot, but make the diff less ambiguous.

diff --git a/t/t4051-diff-function-context.sh b/t/t4051-diff-function-context.sh
index 6154acb45..5f46c0341 100755
--- a/t/t4051-diff-function-context.sh
+++ b/t/t4051-diff-function-context.sh
@@ -72,7 +72,7 @@ test_expect_success 'setup' '
 
# overlap function context of 1st change and -u context of 2nd change
grep -v "delete me from hello" <"$dir/hello.c" >file.c &&
-   sed 2p <"$dir/dummy.c" >>file.c &&
+   sed "2aextra line" <"$dir/dummy.c" >>file.c &&
commit_and_tag changed_hello_dummy file.c &&
 
git checkout initial &&
diff --git a/t/t4061-diff-indent.sh b/t/t4061-diff-indent.sh
index 13d3dc96a..56d7d7760 100755
--- a/t/t4061-diff-indent.sh
+++ b/t/t4061-diff-indent.sh
@@ -153,7 +153,7 @@ test_expect_success 'prepare' '
 '
 
 test_expect_success 'diff: ugly spaces' '
-   git diff old new -- spaces.txt >out &&
+   git diff --no-indent-heuristic old new -- spaces.txt >out &&
compare_diff spaces-expect out
 '
 
@@ -183,7 +183,7 @@ test_expect_success 'diff: --indent-heuristic with 
--histogram' '
 '
 
 test_expect_success 'diff: ugly functions' '
-   git diff old new -- functions.c >out &&
+   git diff --no-indent-heuristic old new -- functions.c >out &&
compare_diff functions-expect out
 '
 
@@ -193,7 +193,7 @@ test_expect_success 'diff: nice functions with 
--indent-heuristic' '
 '
 
 test_expect_success 'blame: ugly spaces' '
-   git blame old..new -- spaces.txt >out-blame &&
+   git blame --no-indent-heuristic old..new -- spaces.txt >out-blame &&
compare_blame spaces-expect out-blame
 '

Re: [PATCHv2 0/3] Make diff plumbing commands respect the indentHeuristic.

2017-04-29 Thread Jeff King 
On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote:

> v2: Fixed up the commit messages and added tests.
> 
> Marc Branchaud (2):
>   diff: make the indent heuristic part of diff's basic configuration
>   diff: have the diff-* builtins configure diff before initializing
> revisions
> 
> Stefan Beller (1):
>   diff: enable indent heuristic by default

Thanks, these look fine to me. I'd like to get an ACK from Michael, in
case he had some other reason for omitting them from git_diff_ui_config
(from my recollection, it's probably just a mix of conservatism and
following what the compaction heuristic had done).

-Peff

[PATCH] githooks.txt: clarify push hooks are always executed in $GIT_DIR

2017-04-29 Thread Simon Ruderich 
Listing the specific hooks might feel verbose but without it the
reader is left to wonder which hooks are triggered during the
push. Something which is not immediately obvious when only trying
to find out where the hook is executed.

Signed-off-by: Simon Ruderich 
---
 Documentation/githooks.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

On Mon, Apr 10, 2017 at 01:13:15PM +0200, Ævar Arnfjörð Bjarmason wrote:
> [snip]
>
> Can we say as we do now that:
>
> * All hooks regardless of type in bare repos execute in the bare repo
> * If you have a working tree hooks use that
>
> But add:
>
> * Working trees are ignored by any hooks invoked on your behalf during a push.

Hello,

Maybe like this? I reordered the cases as it felt more natural
that the general case is first and followed by the one with the
exception.

> Some ad-hoc testing reveals that this rule also goes for the
> push-to-checkout hook. Should it? Wouldn't it be more useful if it
> broke the pattern, since it's dealing with the working tree on the
> other side? Junio?

I added push-to-checkout to the patch. Changing the behavior will
break backwards compatibility so I think that's a no-go.

Regards
Simon

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 32343ae29..706091a56 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -22,8 +22,10 @@ changed via the `core.hooksPath` configuration variable (see
 linkgit:git-config[1]).
 
 Before Git invokes a hook, it changes its working directory to either
-the root of the working tree in a non-bare repository, or to the
-$GIT_DIR in a bare repository.
+$GIT_DIR in a bare repository or the root of the working tree in a non-bare
+repository. An exception are hooks triggered during a push ('pre-receive',
+'update', 'post-receive', 'post-update', 'push-to-checkout') which are always
+executed in $GIT_DIR.
 
 Hooks can get their arguments via the environment, command-line
 arguments, and stdin. See the documentation for each hook below for
-- 
2.11.0

-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[PATCH] send-email: new option to walkaround email server limits

2017-04-29 Thread xiaoqiang zhao 
Some email server(e.g. smtp.163.com) limits a fixed number emails to be send per
session(connection) and this will lead to a send faliure.
With --split  option, a auto reconnection will occur when number of sended
email reaches  and the problem is solved.

Signed-off-by: xiaoqiang zhao 
---
 git-send-email.perl | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index eea0a517f..0de9b7058 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -81,6 +81,8 @@ git send-email --dump-aliases
  This setting forces to use one of the 
listed mechanisms.
 --smtp-debug<0|1>  * Disable, enable Net::SMTP debug.
 
+--split   * send \$num message per connection.
+
   Automating:
 --identity* Use the sendemail. options.
 --to-cmd  * Email To: via ` \$patch_path`
@@ -153,6 +155,7 @@ my $have_email_valid = eval { require Email::Valid; 1 };
 my $have_mail_address = eval { require Mail::Address; 1 };
 my $smtp;
 my $auth;
+my $send_count = 0;
 
 # Regexes for RFC 2047 productions.
 my $re_token = qr/[^][()<>@,;:\\"\/?.= \000-\037\177-\377]+/;
@@ -186,6 +189,7 @@ my $format_patch;
 my $compose_filename;
 my $force = 0;
 my $dump_aliases = 0;
+my $split = 0;
 
 # Handle interactive edition of files.
 my $multiedit;
@@ -358,6 +362,7 @@ $rc = GetOptions(
"force" => \$force,
"xmailer!" => \$use_xmailer,
"no-xmailer" => sub {$use_xmailer = 0},
+   "split=i" => \$split,
 );
 
 usage() if $help;
@@ -1158,10 +1163,15 @@ sub smtp_host_string {
 # (smtp_user was not specified), and 0 otherwise.
 
 sub smtp_auth_maybe {
-   if (!defined $smtp_authuser || $auth) {
+   if (!defined $smtp_authuser || $send_count != 0) {
return 1;
}
 
+   if ($auth && $send_count == 0) {
+   print "Auth use saved password. \n";
+   return !!$smtp->auth($smtp_authuser, $smtp_authpass);
+   }
+
# Workaround AUTH PLAIN/LOGIN interaction defect
# with Authen::SASL::Cyrus
eval {
@@ -1187,6 +1197,7 @@ sub smtp_auth_maybe {
'password' => $smtp_authpass
}, sub {
my $cred = shift;
+   $smtp_authpass = $cred->{'password'};
 
if ($smtp_auth) {
my $sasl = Authen::SASL->new(
@@ -1442,6 +1453,15 @@ EOF
}
}
 
+   $send_count++;
+   if ($send_count == $split) {
+   $smtp->quit;
+   $smtp = undef;
+   $send_count = 0;
+   print "Reconnect SMTP server required. \n";
+
+   }
+
return 1;
 }
 
-- 
2.11.0

Bug: Git rename does not work if folder naming was changed from lower to upper case on OSX

2017-04-29 Thread Robert Eisele 

Hi,

after having committed folders with lower case naming, I decided to 
rename them to upper-case names. Expecting git to detect them as 
renamings, it started a new parallel hierarchy with new files, which I 
had to add/commit.


It was a kinda strange behavior, which I fixed by rename the folder to 
something completely different, commit and rename the folder again to 
the desired value.


Is this an actual desired behavior or is it a bug?

Robert

Re: [PATCH] t7400: add BSLASHPSPEC prerequisite to 'add with \\ in path'

2017-04-29 Thread Johannes Schindelin 
Hi,

On Sat, 29 Apr 2017, Johannes Sixt wrote:

> Am 29.04.2017 um 02:15 schrieb Ramsay Jones:
> >
> > On 28/04/17 20:54, Johannes Sixt wrote:
> > > Am 28.04.2017 um 05:09 schrieb Junio C Hamano:
> > > > Ramsay Jones  writes:
> > > >
> > > > > Commit cf9e55f494 ("submodule: prevent backslash expantion in
> > > > > submodule
> > > > > names", 07-04-2017) added a test which creates a git repository with
> > > > > some backslash characters in the name. This test cannot work on
> > > > > windows,
> > > > > since the backslash is used as the directory separator. In order to
> > > > > suppress this test on cygwin, MinGW and Git for Windows, we add the
> > > > > BSLASHPSPEC prerequisite. (see also commits 6fd1106aa4 and
> > > > > c51c0da222).
> > >
> > > First, let me say that meaning of BSLASHPSPEC was
> > > "keeps backslaches in pathspec arguments" originally,
> > > but it apparently changed meaning since then.
> >
> > Indeed. I started to give some of the history in the commit message, but
> > it was nearly 3am, so I punted with the 'see also commits 6fd1106aa4 and
> > c51c0da222' ... ;-)
> >
> > > t7400.20 does not fail for the MinGW port because the
> > > test case only operates on the file system, but never
> > > checks whether an entry 'sub\with\backslash' is present
> > > in the index.
> >
> > Ah, OK. I only looked at my (64-bit) MSYS2 build, which fails
> > exactly the same as cygwin. Hmm, wait, let me just rebuild on
> > MinGW64 ... indeed it passes (well it passes t7400.20, but it
> > fails on t7400.11, 61, 63, 87 and 89)!
> 
> I don't observe these failures. Are you using a vanila MSYS2 environment?

Please note that the "vanilla MSYS2 environment" is *not* expected to pass
the test suite when compiling in MINGW mode. In fact, it is expected to
fail.

In 2015, I made a couple of changes to the MSYS2 runtime in preparation
for the big bump to Git for Windows 2.x (which switched from the old MSys
environment to the new MSYS2 environment), and released Git for Windows
2.5.0 with a heavily patched msys-2.0.dll. My hope was that those changes
would be welcome in the MSYS2 project, but well, they kinda weren't. So I
was forced to abandon my original plan to contribute all of those fixes to
"upstream MSYS2".

To see the changes I (and others) made:


https://github.com/git-for-windows/msys2-runtime/compare/master%5E%7B/Start.the.merging.rebase%7D...master

I even started collecting the exact tests that are failing with the
vanilla MSYS2 runtime vs Git for Windows' fork, when I still had hopes
that we could test things with AppVeyor (but the builds were already too
slow, we hit the timeout even before trying to run the tests, so I gave up
on that front):

REM MSYS2's runtime does not carry Git for Windows' tweaks yet, so these
tests cannot pass:
set GIT_SKIP_TESTS='t0003 t0006 t0024 t1100 t1400 t1402 t1501 t1504 
t1506
t1508 t1513 t3001 t3070 t3200 t3301 t3400 t3404 t3513 t3703 t4116 t4150
t4208 t4211 t5000 t5001 t5002 t5004 t5500 t5601 t5602 t5603 t5801 t6006
t6018 t6041 t6130 t6132 t6300 t7201 t7400 t7501 t7502 t8002 t8006 t9001
t9350 t9700 t9903'

The reason I did this was to avoid having to spend time in the CI job to
replace the vanilla MSYS2 runtime with Git for Windows' forked one (and
AppVeyor offers a -- rarely updated -- version of MSYS2 in its build
agents out of the box).

I might have dug deeper in order to skip only specific test cases, but as
AppVeyor was already a dead end...

Ciao,
Dscho

[PATCH] i18n: remove i18n from tag reflog message

2017-04-29 Thread Jean-Noel Avila 
The building of the reflog message is using strbuf, which is not
friendly with internationalization frameworks. No other reflog
messages are translated right now and switching all the messages to
i18n would require a major rework of the way the messages are built.

Signed-off-by: Jean-Noel Avila 
---
 builtin/tag.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index 222404522..bdf1e88e9 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -309,7 +309,7 @@ static void create_reflog_msg(const unsigned char *sha1, 
struct strbuf *sb)
if (rla) {
strbuf_addstr(sb, rla);
} else {
-   strbuf_addstr(sb, _("tag: tagging "));
+   strbuf_addstr(sb, "tag: tagging ");
strbuf_add_unique_abbrev(sb, sha1, DEFAULT_ABBREV);
}
 
@@ -317,14 +317,14 @@ static void create_reflog_msg(const unsigned char *sha1, 
struct strbuf *sb)
type = sha1_object_info(sha1, NULL);
switch (type) {
default:
-   strbuf_addstr(sb, _("object of unknown type"));
+   strbuf_addstr(sb, "object of unknown type");
break;
case OBJ_COMMIT:
if ((buf = read_sha1_file(sha1, , )) != NULL) {
subject_len = find_commit_subject(buf, _start);
strbuf_insert(sb, sb->len, subject_start, subject_len);
} else {
-   strbuf_addstr(sb, _("commit object"));
+   strbuf_addstr(sb, "commit object");
}
free(buf);
 
@@ -332,13 +332,13 @@ static void create_reflog_msg(const unsigned char *sha1, 
struct strbuf *sb)
strbuf_addf(sb, ", %s", show_date(c->date, 0, 
DATE_MODE(SHORT)));
break;
case OBJ_TREE:
-   strbuf_addstr(sb, _("tree object"));
+   strbuf_addstr(sb, "tree object");
break;
case OBJ_BLOB:
-   strbuf_addstr(sb, _("blob object"));
+   strbuf_addstr(sb, "blob object");
break;
case OBJ_TAG:
-   strbuf_addstr(sb, _("other tag object"));
+   strbuf_addstr(sb, "other tag object");
break;
}
strbuf_addch(sb, ')');
-- 
2.12.0

Dear Friend,

2017-04-29 Thread victoryaran...@ono.com 



--
Dear Friend,

I am soliciting your partnership to relocation $12 .5 Million to your 
country for investment on my behalf and you will be entitled to 30% of 
the sum once the transaction is successful made, please indicate your 
interest if you are capable so that i will send you details of the 
transaction.

Thanks with my best regards. 
Miss Aisha Gaddafi
--

Re: [L10N] Kickoff of translation for Git 2.13.0 round 1

2017-04-29 Thread Jean-Noël AVILA 
Le dimanche 23 avril 2017, 10:49:27 CEST Jiang Xin a écrit :
> Hi,
> 
> Git v2.13.0-rc0 has been released, and it's time to start new round of git
> l10n. This time there are 96 updated messages need to be translated since
> last update:
> 
> l10n: git.pot: v2.13.0 round 1 (96 new, 37 removed)
> 
> Generate po/git.pot from v2.13.0-rc0 for git v2.13.0 l10n round 1.
> 
> Signed-off-by: Jiang Xin 
> 
> You can get it from the usual place:
> 
> https://github.com/git-l10n/git-po/
> 
> As how to update your XX.po and help to translate Git, please see
> "Updating a XX.po file" and other sections in “po/README" file.
> 
> --
> Jiang Xin


In builtin/tag.c, the newly added function 'create_reflog_msg' is a sentence 
lego that is not fitted for internationalization.

Thanks

Re: [PATCH] t7400: add BSLASHPSPEC prerequisite to 'add with \\ in path'

2017-04-29 Thread Johannes Sixt 

Am 29.04.2017 um 02:15 schrieb Ramsay Jones:



On 28/04/17 20:54, Johannes Sixt wrote:

Am 28.04.2017 um 05:09 schrieb Junio C Hamano:

Ramsay Jones  writes:


Commit cf9e55f494 ("submodule: prevent backslash expantion in submodule
names", 07-04-2017) added a test which creates a git repository with
some backslash characters in the name. This test cannot work on windows,
since the backslash is used as the directory separator. In order to
suppress this test on cygwin, MinGW and Git for Windows, we add the
BSLASHPSPEC prerequisite. (see also commits 6fd1106aa4 and c51c0da222).


First, let me say that meaning of BSLASHPSPEC was
"keeps backslaches in pathspec arguments" originally,
but it apparently changed meaning since then.


Indeed. I started to give some of the history in the commit message, but
it was nearly 3am, so I punted with the 'see also commits 6fd1106aa4 and
c51c0da222' ... ;-)


t7400.20 does not fail for the MinGW port because the
test case only operates on the file system, but never
checks whether an entry 'sub\with\backslash' is present
in the index.


Ah, OK. I only looked at my (64-bit) MSYS2 build, which fails
exactly the same as cygwin. Hmm, wait, let me just rebuild on
MinGW64 ... indeed it passes (well it passes t7400.20, but it
fails on t7400.11, 61, 63, 87 and 89)!


I don't observe these failures. Are you using a vanila MSYS2 
environment? The exact failure modes would be interesting, if you want 
to hear "Ah, Git for Windows does this and that to make this work". ;)



I assume the test fails right at 'git init' under Cygwin?


Indeed. Also on MSYS2 (exactly as on cygwin):

ramsay@satellite  MSYS $ ./t7400-submodule-basic.sh -i -v

...

ok 19 - submodule add with ./, /.. and // in path

expecting success:
test_when_finished "rm -rf parent sub\\with\\backslash" &&

# Initialize a repo with a backslash in its name
git init sub\\with\\backslash &&
touch sub\\with\\backslash/empty.file &&
git -C sub\\with\\backslash add empty.file &&
git -C sub\\with\\backslash commit -m "Added empty.file" &&

# Add that repository as a submodule
git init parent &&
git -C parent submodule add ../sub\\with\\backslash

fatal: cannot mkdir sub\with\backslash: No such file or directory
not ok 20 - submodule add with \\ in path
#
#   test_when_finished "rm -rf parent sub\\with\\backslash" &&
#
#   # Initialize a repo with a backslash in its name
#   git init sub\\with\\backslash &&
#   touch sub\\with\\backslash/empty.file &&
#   git -C sub\\with\\backslash add empty.file &&
#   git -C sub\\with\\backslash commit -m "Added empty.file" &&
#
#   # Add that repository as a submodule
#   git init parent &&
#   git -C parent submodule add ../sub\\with\\backslash
#
ramsay@satellite  MSYS $

ramsay@satellite  MSYS $ cd trash\ directory.t7400-submodule-basic/

ramsay@satellite  MSYS $ ls
a   addtest/ empty   expect-head   head   head-sha1  untracked
actual  addtest-ignore/  expect  expect-heads  heads  t  z

ramsay@satellite  MSYS $ git init sub\\with\\backslash
fatal: cannot mkdir sub\with\backslash: No such file or directory

ramsay@satellite  MSYS $ mkdir -p sub\\with


OK: git init calls mkdir("sub\\with\\backslash"), which does not create 
the missing directories automatically. Therefore, this mkdir helps. In 
the next call, the OS functions behind mkdir simply take the backslashes 
as directory separators:




ramsay@satellite  MSYS $ git init sub\\with\\backslash
Initialized empty Git repository in /home/ramsay/git/t/trash 
directory.t7400-submodule-basic/sub/with/backslash/.git/

ramsay@satellite  MSYS $ touch sub\\with\\backslash/empty.file
ramsay@satellite  MSYS $ git -C sub\\with\\backslash add empty.file
ramsay@satellite  MSYS $ git -C sub\\with\\backslash commit -m "Added 
empty.file"
[master (root-commit) 6fde90b] Added empty.file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 empty.file

ramsay@satellite  MSYS $ git init parent
Initialized empty Git repository in /home/ramsay/git/t/trash 
directory.t7400-submodule-basic/parent/.git/

ramsay@satellite  MSYS $ git -C parent submodule add ../sub\\with\\backslash
Cloning into '/home/ramsay/git/t/trash 
directory.t7400-submodule-basic/parent/sub/with/backslash'...
done.
fatal: Not a git repository: /home/ramsay/git/t/trash 
directory.t7400-submodule-basic/parent/sub\with\backslash/../.git/modules/sub/with/backslash


MSYS git does not know that the backslash is a directory separator. 
Hence, it constructs a path with only a single .. component thinking 
that this walks above sub\with\backslash to end up in parent/; but the 
underlying OS operation interprets the backslashes as directory 
separator and ends up in parent/sub\with\. Of coures, no .git directory 
is at this point, hence the failure.


MinGW