Re: [PATCH] Update diff-highlight

Peter Dave Hello writes: > From: Peter Dave Hello > > Use `#!/usr/bin/env perl` instead of `#!/usr/bin/perl` Even though there are existing examples in contrib/ parts that use this pattern, we try to avoid use of #!/usr/bin/env

Re: interactive rebase results across shared histories

On 21 February 2016 at 13:12, Moritz Neeb wrote: > > On 02/20/2016 11:58 PM, Seb wrote: >> >> I've recently learnt how to consolidate and clean up the master branch's >> commit history. I've squashed/fixuped many commits thinking these would >> propagate to the children

Re: [PATCH v2 3/6] clean: read user input with strbuf_getline()

On 02/22/2016 03:27 AM, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb wrote: >> The inputs that are read are all answers that are given by the user >> when interacting with git on the commandline. As these answers are >> not supposed to contain a

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

On Sun, Feb 21, 2016 at 8:19 PM, Junio C Hamano wrote: > If you are OK with accepting a patch application to a tree with the > same blobs the diff was taken from, then the format-patch output > already has all the necessary information. For each "diff --git" > part, there is

[PATCH v2] git.c: simplify stripping extension of a file in handle_builtin()

The handle_builtin() starts from stripping of command extension if STRIP_EXTENSION is enabled. Actually STRIP_EXTENSION does not used anywhere else. This patch introduces strip_extension() helper to strip STRIP_EXTENSION extension from argv[0] with the strip_suffix() instead of manually

Re: contrib/diff-highlight: stop hard-coding perl location

[please don't top-post on this list] On Mon, Feb 22, 2016 at 1:49 AM, Peter Dave Hello wrote: > Thank you, is there anything I should do? Or I should just wait? Best is to wait for other review comments, particularly from Junio. Reviewers work at their own pace as time

Re: contrib/diff-highlight: stop hard-coding perl location

Hi Eric, Thank you, is there anything I should do? Or I should just wait? Best, Peter 2016/2/22 下午1:56於 "Eric Sunshine" 寫道： > > On Mon, Feb 22, 2016 at 12:54 AM, Peter Dave Hello > wrote: > > From: Peter Dave Hello > >

Re: [PATCH] Update diff-highlight

Hello Eric, Thanks for your review and prompt reply, this is my first PR to git, I'll try to update it to follow the conventions. Best, Peter -- Now you can follow me on twitter or GitHub :D 2016-02-22 12:49 GMT+08:00 Eric Sunshine : > On Sun, Feb 21, 2016 at 11:14

Re: contrib/diff-highlight: stop hard-coding perl location

On Mon, Feb 22, 2016 at 12:54 AM, Peter Dave Hello wrote: > From: Peter Dave Hello > > Use `#!/usr/bin/env perl` instead of `#!/usr/bin/perl`, > the util "env" can help located the "perl", > so that it can work on FreeBSD and other platforms. > >

contrib/diff-highlight: stop hard-coding perl location

From: Peter Dave Hello Use `#!/usr/bin/env perl` instead of `#!/usr/bin/perl`, the util "env" can help located the "perl", so that it can work on FreeBSD and other platforms. Signed-off-by: Peter Dave Hello ---

Re: [PATCH 1/1] convert.c: correct attr_action

On Mon, Feb 22, 2016 at 12:11 AM, wrote: > Commit "convert.c: refactor crlf_action" unified the crlf_handling > and introdused a bug for "git ls-files --eol". s/introdused/introduced/ > The "text" attribute was shown as "text eol=lf" or "text eol=crlf", > depending on

[PATCH 1/1] convert.c: correct attr_action

From: Torsten Bögershausen Commit "convert.c: refactor crlf_action" unified the crlf_handling and introdused a bug for "git ls-files --eol". The "text" attribute was shown as "text eol=lf" or "text eol=crlf", depending on core.autocrlf or core.eol. Correct this and add test cases

Re: [PATCH] Update diff-highlight

On Sun, Feb 21, 2016 at 11:14 PM, Peter Dave Hello wrote: > From: Peter Dave Hello This "From:" line looks suspiciously incorrect. If anything, you'd probably want to drop the line altogether or use: From: Peter Dave Hello

[PATCH] Update diff-highlight

From: Peter Dave Hello Use `#!/usr/bin/env perl` instead of `#!/usr/bin/perl` So that it can works on FreeBSD. --- contrib/diff-highlight/diff-highlight | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

Xiaolong Ye writes: > It would be helpful for maintainers or reviewers to know the base tree > info of the patches created by git format-patch. Teach git format-patch > a --base-tree-info option to record these info. > > Signed-off-by: Xiaolong Ye >

Re: interactive rebase results across shared histories

On Sun, 21 Feb 2016 14:08:44 -0500, Eric Sunshine wrote: [...] > What you're probably missing is that you can't actually edit commits > in Git. Instead, what you think of as "editing" actually creates a new > commit with its own commit-ID, and the original commit still

[PATCH] tests: remove unused full-svn-test target

git-svn has not supported GIT_SVN_NO_OPTIMIZE_COMMITS for the "set-tree" sub-command in 9 years since commit 490f49ea5899 ("git-svn: remove optimized commit stuff for set-tree"). So remove this target to avoid confusion. ref: http://mid.gmane.org/56c9b7b7.7030...@f2.dion.ne.jp Signed-off-by:

[RFC/PATCH 1/1] format-patch: add an option to record base tree info

It would be helpful for maintainers or reviewers to know the base tree info of the patches created by git format-patch. Teach git format-patch a --base-tree-info option to record these info. Signed-off-by: Xiaolong Ye --- builtin/log.c | 18 ++ diff.c

[RFC/PATCH 0/1] Add an option to git-format-patch to record base tree info

Hi, I am a developer of 0-Day kernel test infrastructure(It is a service and test framework for automated regression-testing that intercepts linux kernel development at its early stages [1]), and as proposed by developers in ksummit-discuss, we have implemented a framework to test all patches

[PATCH v4 2/3] git-svn: enable "svn.pathnameencoding" on dcommit

From: Kazutoshi Satoda Without the initialization of $self->{pathnameencoding}, conversion in repo_path() is always skipped as $self->{pathnameencoding} is undefined even if "svn.pathnameencoding" is configured. The lack of conversion results in mysterious failure of

[PATCH v4 1/3] git-svn: hoist out utf8 prep from t9129 to lib-git-svn

We will be reusing this in t9115. Suggested-by: Kazutoshi Satoda Signed-off-by: Eric Wong --- t/lib-git-svn.sh | 12 t/t9129-git-svn-i18n-commitencoding.sh | 12 +--- 2 files changed, 13 insertions(+), 11

[PATCH v4 3/3] git-svn: apply "svn.pathnameencoding" before URL encoding

From: Kazutoshi Satoda The conversion from "svn.pathnameencoding" to UTF-8 should be applied first, and then URL encoding should be applied on the resulting UTF-8 path. The reversed order of these transforms (used before this fix) makes non-UTF-8 URL which causes error

[PATCH v4 0/3] git-svn: svn.pathnameencoding for dcommit

The following changes since commit 0233b800c838ddda41db318ee396320b3c21a560: Merge branch 'maint' (2016-02-17 10:14:39 -0800) are available in the git repository at: git://bogomips.org/git-svn.git ks/svn-pathnameencoding-4 for you to fetch changes up to

Re: [PATCH v2 4/6] notes: read copied notes with strbuf_getline()

On Sun, Feb 21, 2016 at 8:16 PM, Moritz Neeb wrote: > The notes are copied from stdin. They should only contain SHA1s... Not > spaces. CR could be there, because the file/the data from stdin could > have been written via an editor that adds them. > > The notes that are copied

Re: [PATCH v2 3/6] clean: read user input with strbuf_getline()

On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb wrote: > The inputs that are read are all answers that are given by the user > when interacting with git on the commandline. As these answers are > not supposed to contain a meaningful CR it is safe to > replace strbuf_getline_lf()

[PATCH v2 3/6] clean: read user input with strbuf_getline()

The inputs that are read are all answers that are given by the user when interacting with git on the commandline. As these answers are not supposed to contain a meaningful CR it is safe to replace strbuf_getline_lf() can be replaced by strbuf_getline(). Before the user input was trimmed to remove

[PATCH v2 1/6] quote: remove leading space in sq_dequote_step

Because sq_quote_argv adds a leading space (which is expected in trace.c), sq_dequote_step should remove this space again, such that the operations of quoting and dequoting are inverse of each other. This patch is preparing the way to remove some excessive trimming operation in bisect in the

[PATCH v2 4/6] notes: read copied notes with strbuf_getline()

The notes are copied from stdin. They should only contain SHA1s... Not spaces. CR could be there, because the file/the data from stdin could have been written via an editor that adds them. The notes that are copied from stdin are trimmed with strbuf_rtrim() after splitting by ' '. There is thus

Re: [PATCH 1/5] bisect: read bisect paths with strbuf_getline()

On 02/15/2016 06:05 AM, Junio C Hamano wrote: > As to bisect pathspec, while I do not think it is sensible to change > it in the middle of bisection, I do not think it would cause the > bisect command to produce an incorrect result if you did so. You > would be changing the definition of what is

[PATCH v2 6/6] wt-status: read rebase todolist with strbuf_getline()

In read_rebase_todolist() the files $GIT_DIR/rebase-merge/done and $GIT_DIR/rebase-merge/git-rebase-todo are read to collect status information. The access to this file should always happen via git rebase, e.g. via "git rebase -i" or "git rebase --edit-todo". We can assume, that this interface

[PATCH v2 5/6] remote: read $GIT_DIR/branches/* with strbuf_getline()

The line read from the branch file is directly trimmed after reading with strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf() can be replaced by its CRLF counterpart. Signed-off-by: Moritz Neeb --- To be honest, I did not yet fully understand the

[PATCH v2 0/6] replacing strbuf_getline_lf() by strbuf_getline() on trimmed input

This series deals with strbuf_getline_lf() in certain codepaths: Those, where the input that is read, is/was trimmed before doing anything that could possibly expect a CR character. Those places can be assumed to be "text" input, where a CR never would be a meaningful control character. The

[PATCH v2 2/6] bisect: read bisect paths with strbuf_getline()

The file BISECT_NAMES is written by "git rev-parse --sq-quote" via sq_quote_argv() when starting a bisection. It can contain pathspecs to narrow down the search. When reading it back, it should be expected that sq_dequote_to_argv_array() is able to parse this file. In fact, the previous commit

Re: [PATCH 1/5] bisect: read bisect paths with strbuf_getline()

On 02/15/2016 06:05 AM, Junio C Hamano wrote: > Moritz Neeb writes: > >>> You would also want to think about the necessity of strbuf_trim() >>> here. Now strbuf_getline() would trim the trailing CR, would we >>> still need to call strbuf_trim() here? The code will break if

Re: [PATCH] GSoC Micoproject: Hunt down signed int flags

On Sun, Feb 21, 2016 at 6:22 PM, Moritz Neeb wrote: > Thanks for your patch. Just to let you know, this will be my first > review, but I hope it will be helpful anyway. I will mostly review your > commit text. First some general remarks: Thanks for taking on this review. I

Re: [PATCH] daemon.c: mark a file-local symbol as static

On 21/02/16 23:25, Jeff King wrote: > On Sun, Feb 21, 2016 at 05:33:38PM +, Ramsay Jones wrote: > >> If you need to re-roll your 'jk/tighten-alloc' branch, could you >> please squash this into the relevant patch. (ie. "convert manual >> allocations to argv_array"). > > Thanks, will do. You

Re: [PATCH] git.c: simplify striping extension of a file in handle_builtin()

On Sat, Feb 20, 2016 at 9:27 AM, Alexander Kuleshov wrote: > git.c: simplify striping extension of a file in handle_builtin() s/striping/stripping/g (Note the '/g' above.) The patch itself looks okay. > The handle_builtin() starts from striping of command extension if

Re: [PATCH 2/2] t9200: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 6:43 PM, John Keeping wrote: > On Sun, Feb 21, 2016 at 04:15:31PM -0500, Eric Sunshine wrote: >> On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: >> > GNU grep 2.23 detects the input used in this test as binary data so it >> >

Re: [PATCH] credential-cache--daemon: Change to root dir on startup

On Sun, Feb 21, 2016 at 07:51:37PM +1300, Jon Griffiths wrote: > Stop the daemon from preventing umount of the directory it > was started in. > > Without this change the daemon prevents umount because it > it holds open its cwd. If it starts in a directory we want > to unmount we have to

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 6:41 PM, John Keeping wrote: > On Sun, Feb 21, 2016 at 06:19:14PM -0500, Jeff King wrote: >> On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote: >> > These tests all crash and burn with BSD sed (including Mac OS X) since >> > you're not

Re: [PATCH 2/2] t9200: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 04:15:31PM -0500, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: > > GNU grep 2.23 detects the input used in this test as binary data so it > > does not work for extracting lines from a file. We could add the "-a" > >

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 06:19:14PM -0500, Jeff King wrote: > On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote: > > > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: > > > GNU grep 2.23 detects the input used in this test as binary data so it > > > does not

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 6:31 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >> These tests all crash and burn with BSD sed (including Mac OS X) since >> you're not restricting yourself to BRE (basic regular expressions). >> You _could_ request

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 06:31:08PM -0500, Eric Sunshine wrote: > > Something like the patch below works for me. I think we could make it > > shorter by using $PERLIO to get the raw behavior, but using binmode will > > work even on ancient versions of perl. > > > > +filter_blame () { > > +

Re: Please document git-http-backend/Apache timeout interactions

On Sun, Feb 21, 2016 at 03:29:56PM -0800, Junio C Hamano wrote: > This feels 70% like "how to configure your Apache server when you > run site that is contacted by a client that is slow to talk?", that > is not necessarily specific to Git. It's specific to Git in the sense that Git seemingly as a

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 6:19 PM, Jeff King wrote: > On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote: >> On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: >> > - git blame --incremental file | \ >> > - egrep

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

Eric Sunshine writes: > These tests all crash and burn with BSD sed (including Mac OS X) since > you're not restricting yourself to BRE (basic regular expressions). > You _could_ request extended regular expressions, which do work on > those platforms, as well as with

Re: [PATCH 04/21] harden REALLOC_ARRAY and xcalloc against size_t overflow

On Sat, Feb 20, 2016 at 10:32:00PM +0100, René Scharfe wrote: > >-#define REALLOC_ARRAY(x, alloc) (x) = xrealloc((x), (alloc) * sizeof(*(x))) > >+#define ALLOC_ARRAY(x, alloc) (x) = xmalloc(st_mult((alloc), sizeof(*(x > >+#define REALLOC_ARRAY(x, alloc) (x) = xrealloc((x), st_mult((alloc), >

Re: Please document git-http-backend/Apache timeout interactions

"Steinar H. Gunderson" writes: > I am running git-http-backend behind Apache as suggested in > git-http-backend(1). However, what it fails to mention is that > git-fetch-pack seemingly can be very slow in sending its request. > Consequently, mod_reqtimeout (on by default,

Re: [PATCH] daemon.c: mark a file-local symbol as static

On Sun, Feb 21, 2016 at 05:33:38PM +, Ramsay Jones wrote: > If you need to re-roll your 'jk/tighten-alloc' branch, could you > please squash this into the relevant patch. (ie. "convert manual > allocations to argv_array"). Thanks, will do. You notice these with sparse, as I recall? I've

Re: [PATCH] GSoC Micoproject: Hunt down signed int flags

Thanks for your patch. Just to let you know, this will be my first review, but I hope it will be helpful anyway. I will mostly review your commit text. First some general remarks: The text you are submitting with you email is directly used as commit message (the email subject as well, as the

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: > > GNU grep 2.23 detects the input used in this test as binary data so it > > does not work for extracting lines from a file. We could add the "-a" > >

Re: [PATCH 3/5] merge-recursive: test rename threshold option

Eric Sunshine writes: > On Sun, Feb 21, 2016 at 1:55 PM, Felipe Gonçalves Assis > wrote: >> On 21 February 2016 at 14:52, Eric Sunshine wrote: >>> On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis >>>

[PATCH v2 1/5] merge-strategies.txt: fix typo

Signed-off-by: Felipe Gonçalves Assis --- Documentation/merge-strategies.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index ff359b6..2eb92b9 100644 ---

[PATCH v2 2/5] t3034: add rename threshold tests

10ae752 (merge-recursive: option to specify rename threshold, 2010-09-27) introduced this feature but did not include any tests. The tests use the new option --find-renames, which replaces the then introduced and now deprecated option --rename-threshold. Also update name and description of t3032

[PATCH v2 3/5] t3034: test option to disable renames

Signed-off-by: Felipe Gonçalves Assis --- t/t3034-merge-recursive-rename-options.sh | 28 1 file changed, 28 insertions(+) diff --git a/t/t3034-merge-recursive-rename-options.sh b/t/t3034-merge-recursive-rename-options.sh index

[PATCH v2 0/5] Tests and fixes for merge-recursive rename options

This is a reorganisation of the previous series, bundling the test for the fix along with the commit itself, as suggested by Eric. It also includes many fixes and improvements pointed out by the same reviewer, whom I thank. The typo fix is the same as before. In "add rename threshold tests", I

[PATCH v2 4/5] t3034: test deprecated interface

--find-renames= and --rename-threshold= should be aliases. Signed-off-by: Felipe Gonçalves Assis --- Now includes tests with invalid arguments to --rename-threshold= t/t3034-merge-recursive-rename-options.sh | 42 +++ 1 file changed, 42

[PATCH v2 5/5] merge-recursive: find-renames resets threshold

Make the find-renames option follow the behaviour in git-diff, where it resets the threshold when none is given. So, for instance, "--find-renames=25 --find-renames" should result in the default threshold (50%) instead of 25%. Add corresponding test. Signed-off-by: Felipe Gonçalves Assis

Please document git-http-backend/Apache timeout interactions

Hi, I am running git-http-backend behind Apache as suggested in git-http-backend(1). However, what it fails to mention is that git-fetch-pack seemingly can be very slow in sending its request. Consequently, mod_reqtimeout (on by default, as I understand it) kicks in as an anti-DoS measure, and

Re: [PATCH 2/2] t9200: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: > GNU grep 2.23 detects the input used in this test as binary data so it > does not work for extracting lines from a file. We could add the "-a" > option to force grep to treat the input as text, but not all >

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote: > GNU grep 2.23 detects the input used in this test as binary data so it > does not work for extracting lines from a file. We could add the "-a" > option to force grep to treat the input as text, but not all >

Re: [PATCH 3/5] merge-recursive: test rename threshold option

On Sun, Feb 21, 2016 at 1:55 PM, Felipe Gonçalves Assis wrote: > On 21 February 2016 at 14:52, Eric Sunshine wrote: >> On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis >> wrote: >>> +test_expect_success 'rename

Re: [PATCH 5/5] merge-recursive: test more consistent interface

On Sun, Feb 21, 2016 at 2:55 PM, Felipe Gonçalves Assis wrote: > On 21 February 2016 at 15:40, Eric Sunshine wrote: >> Taking the above and review comments from earlier patches into >> account, it might make sense to re-order the series as

Re: [PATCH 5/5] merge-recursive: test more consistent interface

On 21 February 2016 at 15:40, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis > wrote: >> merge-recursive: test more consistent interface > > The real meat of this patch (it seems) is that you're adding tests to >

Re: interactive rebase results across shared histories

On Sun, Feb 21, 2016 at 12:25 PM, Seb wrote: > The scenario is much simpler; imagine master has a longer history behind > the point where the topic branch started: > > A---B---C topic >/ > *---D---E---F---G master > > And we want to keep both

Re: [PATCH 3/5] merge-recursive: test rename threshold option

On 21 February 2016 at 14:52, Eric Sunshine wrote: > On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis > wrote: >> merge-recursive: test rename threshold option > >> + git read-tree --reset -u HEAD && >> + test_must_fail git

Re: GSoC 2016: Microproject

Mehul Jain writes: > Earlier when I was testing the master branch on my pc, I used "make" > in \t directory, which lead to failure of test #2, #3 in > t5539-fetch-http-shallow.sh . > Afterwards I switched to sudo mode and ran the make command again. Never ever do that.

Re: [PATCH 5/5] merge-recursive: test more consistent interface

On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis wrote: > merge-recursive: test more consistent interface The real meat of this patch (it seems) is that you're adding tests to verify that --find-renames= and --rename-threshold= are aliases, so it might make sense

[PATCH] GSoC Micoproject: Hunt down signed int flags

This is patch is for a suggested micro project for GSoC 2016; namely, that of searching for a field of a struct that is of signed integral type and used as a collection of multiple bits, and converting it to an unsigned type if the MSB isn’t used in any special way. Two structs, `pattern` defined

[PATCH 2/5] merge-strategies.txt: fix typo

Signed-off-by: Felipe Gonçalves Assis --- Documentation/merge-strategies.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index ff359b6..2eb92b9 100644 ---

[PATCH 1/5] merge-recursive: find-renames resets threshold

Make the find-renames option follow the behaviour in git-diff, where it resets the threshold when none is given. So, for instance, "--find-renames=25 --find-renames" should result in the default threshold (50%) instead of 25%. Signed-off-by: Felipe Gonçalves Assis ---

Re: [PATCH 4/5] merge-recursive: test option to disable renames

On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis wrote: > Also update name and description of tests for consistency: > "merge-recursive options" -> "merge-recursive space options" > "merge-recursive rename threshold" -> "merge-recursive rename options" >

[PATCH 5/5] merge-recursive: test more consistent interface

Update basic tests to use the new option find-renames instead of rename-threshold. Add tests to verify that rename-threshold= behaves as a synonym for find-renames=. Test that find-renames resets threshold. Signed-off-by: Felipe Gonçalves Assis ---

[PATCH 4/5] merge-recursive: test option to disable renames

Also update name and description of tests for consistency: "merge-recursive options" -> "merge-recursive space options" "merge-recursive rename threshold" -> "merge-recursive rename options" Signed-off-by: Felipe Gonçalves Assis --- ...ons.sh =>

Re: [PULL] svn pathnameencoding for git svn dcommit

On 2016/02/21 8:37 +0900, Eric Wong wrote: > Kazutoshi Satoda wrote: ... >> Setting LC_ALL=C.UTF-8 in the test 11-12 made them pass on Cygwin. >> Same change made the previous version also pass. Please find the patch >> in the attached output of git format-patch. > >

Re: GSoC 2016: Microproject

On Sun, Feb 21, 2016 at 10:25 AM, Matthieu Moy wrote: > Please, don't top-post on this list. I apologize for top-posting on the list. > Are you sure that 1) you have no uncommitted change and 2) you have > compiled what you have in your tree? 1) Yes, I have no

[PATCH 3/5] merge-recursive: test rename threshold option

Commit 10ae7526bebb505ba01f76ec97d5f7b5e0e5 introduced this feature, but did not include any tests. This commit fixes this. Signed-off-by: Felipe Gonçalves Assis --- t/t3034-merge-recursive-rename-threshold.sh | 146 1 file changed, 146

[PATCH 0/5] Tests and fixes for merge-recursive rename options

This builds on the work in 1b47ad160b55f50a7a98c180e18d80f0f8f17a67 (merge-recursive: more consistent interface, 2016-02-17). Add tests for the merge-recursive rename options, as suggested by Eric Sunshine. Also fixes an inconsistency in the behaviour of find-renames and a typo. The first two

Re: GSoC 2016: Microproject

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller wrote: > Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right > place as judging from the file name of the tests. I checked out both of the files and made following observations - 1) As I'm going to

Re: [PATCH 3/5] merge-recursive: test rename threshold option

On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis wrote: > merge-recursive: test rename threshold option Maybe rephrase this as: t3034: add rename threshold tests > Commit 10ae7526bebb505ba01f76ec97d5f7b5e0e5 introduced this feature, In commit messages,

Re: [PATCH v5 0/3] merge-recursive: option to disable renames

On 21 February 2016 at 04:40, Junio C Hamano wrote: > Yikes, your previous round is already in 'next', so could you make > this series an incremental on top of what is already queued up to > 1b47ad16 (merge-recursive: more consistent interface, 2016-02-17)? > > Thanks. > Oh,

Re: [PATCH v5 0/3] merge-recursive: option to disable renames

Yikes, your previous round is already in 'next', so could you make this series an incremental on top of what is already queued up to 1b47ad16 (merge-recursive: more consistent interface, 2016-02-17)? Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

[PATCH] daemon.c: mark a file-local symbol as static

Signed-off-by: Ramsay Jones --- Hi Jeff, If you need to re-roll your 'jk/tighten-alloc' branch, could you please squash this into the relevant patch. (ie. "convert manual allocations to argv_array"). Thanks! ATB, Ramsay Jones daemon.c | 2 +- 1 file changed, 1

[PATCH 1/2] t8005: avoid grep on non-ASCII data

GNU grep 2.23 detects the input used in this test as binary data so it does not work for extracting lines from a file. We could add the "-a" option to force grep to treat the input as text, but not all implementations support that. Instead, use sed to extract the desired lines since it will

[PATCH 2/2] t9200: avoid grep on non-ASCII data

GNU grep 2.23 detects the input used in this test as binary data so it does not work for extracting lines from a file. We could add the "-a" option to force grep to treat the input as text, but not all implementations support that. Instead, use sed to extract the desired lines since it will

[PATCH 0/2] Fix test failures with GNU grep 2.23

On Fri, Feb 19, 2016 at 02:33:10PM -0500, Jeff King wrote: > On Fri, Feb 19, 2016 at 07:23:11PM +, John Keeping wrote: > > > I suspect that any grep that lacks "-a" also lacks binary file handling > > that will break these tests. I found a Solaris grep that doesn't > > support "-a" and it

Re: [PATCH] git-p4.py: Make submit working on bare repository

Amadeusz Żołnowski writes: > To submit changes from master branch to Perforce, new commits should be > based on a remote branch p4/master: > > (1) > E'---F' master > / > A---B---C---D p4/master > > Commits from A to D map to Perforce

[PATCH] submodule: don't use an integer as a NULL pointer

Signed-off-by: Ramsay Jones --- Hi Stefan, If you need to re-roll your 'sb/submodule-init' branch, could you please squash this into the relevant patch. Thanks! ATB, Ramsay Jones submodule.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: interactive rebase results across shared histories

On Sun, 21 Feb 2016 03:12:49 +0100, Moritz Neeb wrote: > Hi Seb, > On 02/20/2016 11:58 PM, Seb wrote: >> Hello, >> I've recently learnt how to consolidate and clean up the master >> branch's commit history. I've squashed/fixuped many commits thinking >> these would

Re: [PATCH 2/5] merge-strategies.txt: fix typo

On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis wrote: > Signed-off-by: Felipe Gonçalves Assis > --- > diff --git a/Documentation/merge-strategies.txt > b/Documentation/merge-strategies.txt > @@ -86,8 +86,8 @@ no-renames;; >

Re: [PATCH 1/5] merge-recursive: find-renames resets threshold

On Sun, Feb 21, 2016 at 10:09 AM, Felipe Gonçalves Assis wrote: > Make the find-renames option follow the behaviour in git-diff, where it > resets the threshold when none is given. So, for instance, > "--find-renames=25 --find-renames" should result in the default >