Re: [PATCH v5 0/2] bisect--helper: rewrite of check-term-format()

2016-05-07 Thread Junio C Hamano
Pranit Bauva writes: > I completely missed your point and you want me to go the Eric Sunshine's way? I am neutral. When I read your response to Eric's "top down" suggestion, I didn't quite get much more than "I started going this way, and I do not want to change to the

Re: t6044 broken on pu

2016-05-07 Thread Junio C Hamano
Torsten Bögershausen writes: > That's true, but the test passes anyway. You can also remove the body of the test and replace it with "true" and say "the test passes anyway". Changing the test to use a file with only one line is irresponsible, if you do not know the nature of

Re: [PATCH] Git/SVN: die when there is no commit metadata

2016-05-07 Thread Eric Wong
Christian Couder wrote: > Signed-off-by: Christian Couder Thanks Christian, Signed-off-by: Eric Wong ...And pushed to my svn/bad-ref branch for Junio. (I don't think I'll have other git-svn-related changes immediately

Re: [PATCH v16 0/7] config commit verbose

2016-05-07 Thread Ævar Arnfjörð Bjarmason
On Sat, May 7, 2016 at 7:32 AM, Jeff King wrote: > On Fri, May 06, 2016 at 08:33:15AM -0700, Junio C Hamano wrote: > >> > Then I replied: >> > >> >However, that doesn't mean that we have to spread this badly chosen >> >name from options to config variables, does it? I

Force-with-lease and new branches

2016-05-07 Thread John Keeping
I've noticed a slightly annoying behaviour of git-push's --force-with-lease option around branch creation. I'd like to be able to do: git push --force-with-lease origin refs/heads/jk/* to push out a load of topic branches safely in case I've switched client machines and forgotten to

Config for git-blame flags -w, -M, and -C?

2016-05-07 Thread Joe Lencioni
git-blame has a few options are useful when working with commits that only modify whitespace (-w), move code within the file (-M), or move code between files (-C). It would be nice if there was a way to configure git so these options could be enabled by default when running `git blame`. I suppose

Re: t6044 broken on pu

2016-05-07 Thread Torsten Bögershausen
On 2016-05-07 14.19, Andreas Schwab wrote: > Torsten Bögershausen writes: > >> The "seq" is not understood by all shells, >> using printf fixes this, >> >> index 20a3ffe..48d964e 100755 >> --- a/t/t6044-merge-unrelated-index-changes.sh >> +++

t6392 broken on pu (Mac OS X)

2016-05-07 Thread Torsten Bögershausen
These tests fail here under Mac OS, they pass under Linux: commit ff3d9b660a4b6e9d3eeb664ce1febe717adff737 I haven't had a chance to dig further. expecting success: git for-each-ref --format="%(if)%(authorname)%(then)%(authorname): %(refname)%(end)" >actual && cat >expect <<-\EOF

回复:[PATCH] utf8: fix duplicate words of "the"

2016-05-07 Thread 李三0159
Good job.Cleaner now. I found these typos by aspell, and duplicate words by grep -rnIE '\b(\w+)\s+\1\b' :) Thanks! -- 发件人:Junio C Hamano 发送时间:2016年5月7日(星期六) 02:30 收件人:李三0159 抄 送:Jeff King

Re: [RFC PATCH] gc --auto: don't lie about running in background on Windows

2016-05-07 Thread SZEDER Gábor
Quoting Junio C Hamano : SZEDER Gábor writes: Arguably this helper function could be just a simple variable. I opted for a function because: - I preferred a single '#ifdef NO_POSIX_GOODIES', and putting a static variable so near to EOF felt just

Re: t6044 broken on pu

2016-05-07 Thread Ramsay Jones
On 07/05/16 14:15, Ramsay Jones wrote: > > > On 07/05/16 13:19, Andreas Schwab wrote: >> Torsten Bögershausen writes: >> >>> The "seq" is not understood by all shells, >>> using printf fixes this, >>> >>> index 20a3ffe..48d964e 100755 >>> ---

Re: [PATCH v3 1/2] rev-parse tests: add tests executed from a subdirectory

2016-05-07 Thread Mike Rappazzo
On Fri, May 6, 2016 at 6:10 PM, Junio C Hamano wrote: > Michael Rappazzo writes: > >> t1500-rev-parse contains envrionment leaks (changing dir without >> changing back, setting config variables, etc). Add a test to clean this >> up up so that future tests

Re: t6044 broken on pu

2016-05-07 Thread Ramsay Jones
On 07/05/16 13:19, Andreas Schwab wrote: > Torsten Bögershausen writes: > >> The "seq" is not understood by all shells, >> using printf fixes this, >> >> index 20a3ffe..48d964e 100755 >> --- a/t/t6044-merge-unrelated-index-changes.sh >> +++

Re: [PATCH v5 0/2] bisect--helper: rewrite of check-term-format()

2016-05-07 Thread Pranit Bauva
On Sat, May 7, 2016 at 3:45 AM, Junio C Hamano wrote: > Pranit Bauva writes: > >> A very interesting fact to note: >> I made a mistake by dropping of the first argument 'term' in the function >> one_of() and compiled and the test suite passed fully

Re: t6044 broken on pu

2016-05-07 Thread Andreas Schwab
Torsten Bögershausen writes: > The "seq" is not understood by all shells, > using printf fixes this, > > index 20a3ffe..48d964e 100755 > --- a/t/t6044-merge-unrelated-index-changes.sh > +++ b/t/t6044-merge-unrelated-index-changes.sh > @@ -20,7 +20,7 @@ test_description="merges

Re: [PATCH 80/83] run-command: make dup_devnull() non static

2016-05-07 Thread Johannes Schindelin
Hi Chris, On Sat, 7 May 2016, Christian Couder wrote: > On Fri, May 6, 2016 at 5:34 PM, Johannes Schindelin > wrote: > > > > On Fri, 6 May 2016, Christian Couder wrote: > > > >> On Thu, May 5, 2016 at 10:07 PM, Johannes Sixt wrote: > >> > Am

t6044 broken on pu

2016-05-07 Thread Torsten Bögershausen
The "seq" is not understood by all shells, using printf fixes this, index 20a3ffe..48d964e 100755 --- a/t/t6044-merge-unrelated-index-changes.sh +++ b/t/t6044-merge-unrelated-index-changes.sh @@ -20,7 +20,7 @@ test_description="merges with unrelated index changes" # Commit E: renames

Re: [PATCH 80/83] run-command: make dup_devnull() non static

2016-05-07 Thread Christian Couder
Hi Dscho, On Fri, May 6, 2016 at 5:34 PM, Johannes Schindelin wrote: > Hi Chris, > > On Fri, 6 May 2016, Christian Couder wrote: > >> On Thu, May 5, 2016 at 10:07 PM, Johannes Sixt wrote: >> > Am 05.05.2016 um 11:50 schrieb Christian Couder: >> >> >>

Re: [PATCH] pathspec: remove check_path_for_gitlink

2016-05-07 Thread Duy Nguyen
On Sat, May 7, 2016 at 2:18 AM, Stefan Beller wrote: > On Fri, May 6, 2016 at 12:02 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> On Fri, May 6, 2016 at 3:30 AM, Duy Nguyen wrote: On Fri, May 6, 2016

[PATCH] Git/SVN: die when there is no commit metadata

2016-05-07 Thread Christian Couder
When passing a bad --trunk option to `git svn clone`, like for example the same URL that we are cloning: C:\Windows\system32>git svn clone https://mycompany.svn.beanstalkapp.com/myproject --no-metadata -A c:\temp\svn_to_git_users.txt

[PATCH v2 2/2] mingw: remove unnecessary definition

2016-05-07 Thread Johannes Schindelin
For some reason, the definition of the MINGW version of `mark_as_git_dir()` slipped into this developer's patch series to support building Git for Windows. As the `mark_as_git_dir()` function is not needed at all anymore (it was used originally to support the core.hideDotFiles = gitDirOnly

[PATCH v2 1/2] mingw: introduce the 'core.hideDotFiles' setting

2016-05-07 Thread Johannes Schindelin
On Unix (and Linux) it is common that files and directories whose names start with a dot are not shown by default. This convention is used by Git: the .git/ directory should be left alone by regular users, and only accessed through Git itself. On Windows, no such convention exists. Instead, there

[PATCH v2 0/2] Support marking .git/ (or all files) as hidden on Windows

2016-05-07 Thread Johannes Schindelin
Windows does not share Unix' convention that files and directories whose names start with a dot are hidden. Hence `.git/`, for example, is in plain view, and caused quite a bit of trouble: some users wanted to peek inside and did not understand what it contains, others modified files. There was a

Re: [PATCH] mingw: introduce the 'core.hideDotFiles' setting

2016-05-07 Thread Johannes Schindelin
Hi Junio, On Fri, 6 May 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> I agree with the goal of the change, but I am having a hard time > >> justifying this addition. Primarily because I do not understand the > >> need for this. > >> > >> In

[PATCH v9 3/6] convert: unify the "auto" handling of CRLF

2016-05-07 Thread tboegi
From: Torsten Bögershausen Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this

[PATCH v9 2/6] convert.c: stream and early out

2016-05-07 Thread tboegi
From: Torsten Bögershausen When statistics are done for the autocrlf handling, the search in the content can be stopped, if e.g - a search for binary is done, and a NUL character is found - a search for CRLF is done, and the first CRLF is found. Similar when statistics for binary

[PATCH v9 4/6] convert.c: more safer crlf handling with text attribute

2016-05-07 Thread tboegi
From: Torsten Bögershausen A follow-up after a discussion how to fix the flaky execution of t0025, gmane/$284352. This patch extends the work done in commit c480539: "Make it work also for un-normalized repositories". Make sure that CRLF can be converted round trip, or don't

[PATCH v9 5/6] t6038; use crlf on all platforms

2016-05-07 Thread tboegi
From: Torsten Bögershausen t6038 uses different code, dependig if NATIVE_CRLF is set ot not. When the native line endings are LF, merge.renormalize is not tested very well. Change the test to always use CRLF by setting core.eol=crlf. After doing so, the test fails: rm

[PATCH v9 0/6] convert-eol-autocrlf, old 5..10 now 1..6

2016-05-07 Thread tboegi
From: Torsten Bögershausen Changes since v8: As discussed earlier, 1..4 should be broken out into tb/autocrlf-fix or so. 1..4 are not part of this series any more. The old 10/10 is now 6/6. It is replaced by "ce_compare_data() checks for a sha1 of a path" It now