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 in more serious
parts of our system. This is to control the exact
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 branches with whom it shar
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 meaningful CR it is safe to
>
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 the "index $old..$new
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
stripping.
[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 permits, so don't be
surpr
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
> >
> > Use `#!/usr/bin/env perl` instead of `#!/usr/bin/perl`,
> > the util "e
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 PM, Peter Dave Hello
> wro
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.
>
> Signed-off-by: Peter Dave Hello
Better, thanks.
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
---
contrib/diff-highlight/diff-highlight | 2 +-
1 file changed, 1 insertion(+), 1 del
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 core.autocrlf or core.eol.
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 in t0027.
Signe
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
> Update diff-highlight
Patches do indeed "update" the project, b
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 a/contrib/diff-highlight/diff-highlight
b/contrib/diff-highlight/diff-highl
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
> ---
I have a mixed feeling about this one, pr
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 exists
> with its own comm
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: Eri
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| 4
diff.h
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 se
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 dcommit (e.g.
"Malformed XML
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 deletions(-)
diff --git a/t/lib-git-svn.sh b/t
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 from Subversion such as
"Fi
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 1b42f45255de5844b7fe8d0c60fea74cd5b9f
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 from stdin are trimme
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() can be replaced by st
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
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 follo
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 no
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 t
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 han
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 purpose of this branches/ f
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 purpos
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 ensu
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 you
>>> just remove t
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 think you've covered ev
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
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
> STRIP_EXTENSION is enab
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
>> > does not work for extracting lines from a
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 manually
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 restricting yourself to BR
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"
> > option to force grep to t
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 work for extracting l
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 extended regular expressions, which do work on
>
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 () {
> > + pe
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
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 "^(author|summary) " > actual &&
>> > + git bl
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 GNU sed:
>
> sed -nEe "/
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),
>
"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, as I understand it)
> ki
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 meant
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 first
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"
> > option to force grep to
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
>>> wrote:
+test_expect_success 'rename threshold is truncated' '
+ git re
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
--- a/Documentation/merge-strategies.txt
+++
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
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 7ae7f83..a459236 100755
--- a/t/t3034-
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 in
--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 insertions(+)
diff --git a/t
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
---
No
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 the
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
> implementations support that. In
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
> implementations support that. In
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 threshold is truncated' '
>>> + git read-tree --reset -u HEAD &&
>>> +
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 follows:
>>
>> 1/5: add --find-renames & --find-renames=
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
> verify that --find-renames= and --rename-threshold=
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 branches separate (no
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 merge-recursive HEAD^ -- HEAD master &&
>> + ch
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. Your git source tree shoul
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 for the summary line to s
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
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
--- a/Documentation/merge-strategies.txt
+++
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
---
merge-recursive.c | 4 +++-
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"
>
> Signed-off-by: Felipe Go
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
---
t/t3034-merge-recursive-rename-options.sh | 48
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 => t3032-merge-recursive-space-options.sh} |
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.
>
> Thanks. However, I also wond
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 uncommited change in the branch(ma
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 insertions(+)
create mode
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 com
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 add an option for "git
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, it is helpful to provide
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, sorry. I did not noti
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 messag
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 insertion(+), 1 deletion(-)
d
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 alway
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 alway
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 tre
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 changelists. These commi
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 a/submodule.c b/submodule.c
index
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 propagate to the children bra
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;;
> find-renames[=];;
> - Turn on rename detection, optiona
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
> threshold (50%) instead of 25%.
92 matches
Mail list logo