From: Lars Schneider
The TravisCI macOS build is broken because homebrew (a macOS depedency
manager) changed its internal directory structure [1]. This is a problem
because we modify the Perforce dependencies in the homebrew repository
before installing them.
Fix it by asking homebrew for its pa
On Tue, Sep 20, 2016 at 08:15:55PM +0100, John Keeping wrote:
> > BTW, here is the callstack inlined from the crashreport:
> >
> > bsystem_platform.dylib 0x7fff840db41c
> > _platform_strchr$VARIANT$Haswell + 28
> > 1 git 0x00010ba1d3f4 ident_def
On Tue, Sep 20, 2016 at 6:30 AM, Junio C Hamano wrote:
> * nd/checkout-disambiguation (2016-09-09) 4 commits
> - fixup! checkout.txt: document a common case that ignores ambiguation rules
> - checkout: fix ambiguity check in subdir
> - checkout.txt: document a common case that ignores ambiguati
In the Subject: s/the //
Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com:
> From: Lars Schneider
>
> The TravisCI macOS build is broken because homebrew (a macOS depedency
s/depedency/dependency/
> manager) changed its internal directory structure [1]. This is a problem
> because we mo
On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote:
> diff --git a/mailinfo.c b/mailinfo.c
> index e19abe3..6a7c2f2 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -54,6 +54,50 @@ static void parse_bogus_from(struct mailinfo *mi, const
> struct strbuf *line)
> get_sane_name(&mi->
v2 requires jk/setup-sequence-update so I could kill my workaround
patch and avoid conflicts in t0001. And:
- 1/3 has a few missing words back in its commit message
- 2/3, which was 3/3 in v1, no longer has the ugly hacky
get_first_git_dir()
- 3/3 is a new tiny code improvement after the new
Since original_git_dir is a copy of real_path(git_dir), let's reuse it
and avoid calling real_path() more than necessary.
The xstrdup() is removed too because original_git_dir is already a copy,
and we're not going to free git_link in this code probably forever.
Signed-off-by: Nguyễn Thái Ngọc Du
When 'git init' is called from a linked worktree, we treat '.git'
dir (which is $GIT_COMMON_DIR/worktrees/something) as the main
'.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
in there. It does not harm anything (*) but it is still wrong.
Since 'git init' calls set_git_di
When "git init" is called with GIT_WORK_TREE environment set, we want to
keep this worktree's location in core.worktree so the user does not have
to set the environment again and again. See ef6f0af (git-init: set
core.worktree if GIT_WORK_TREE is specified - 2007-07-04)
We detect that by this logi
The Content-Type is application/xhtml+xml, not application/xhtm+xml.
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33d701d..9473daf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1616,7 +1616,7
Change the minimum length of a commit we'll link to from 8 to 7.
This arbitrary minimum length of 8 was introduced in
v1.4.4.2-151-gbfe2191, but as seen in e.g. v1.7.4-1-gdce9648 the
default abbreviation length is 7.
It's still possible to reference SHA1s down to 4 characters in length,
see v1.7.
Change the log formatting function to know about "git describe" output
like v2.8.0-4-g867ad08 in addition to just plain 867ad08.
This also fixes a micro-regression in my change of the minimum SHA1
length from 8 to 7, which is that dated tags like
hadoop-20160921-113441-20-g094fb7d w
On Tue, 20 Sep 2016 19:15:33 -0400
Jeff King wrote:
> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
>
> > Hi, starting from 2.10.0 I noticed that when using git log
> > --oneline, if commits are signed with GPG, now the signatures are
> > printed too, and it takes 3 lines fo
DEAR FRIEND,
How are you together with your family and business hope all is well. I know
that this message will come to you as a surprise. I Hope that you will not
expose or betray this trust and confident that I am about to repose on you for
our mutual benefit of our both families. I need y
Hello Dscho,
W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał:
> On Fri, 9 Sep 2016, Jakub Narębski wrote:
[...]
>> When preserving merges, there are (as far as I understand it), two
>> problems:
>> - what it means to preserve changes (which change to pick,
>>that is what is the mainl
I think this behaviour contradicts the manual which strongly links
ls-tree to ls(1):
?0[steffen@wales ]$ ls NEWSS
ls: cannot access 'NEWSS': No such file or directory
?2[steffen@wales ]$ git ls-tree --name-only master NEWSS
> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote:
>
> In the Subject: s/the //
>
> Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com:
>> From: Lars Schneider
>>
>> The TravisCI macOS build is broken because homebrew (a macOS depedency
>
> s/depedency/dependency/
Than
W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more
important is "ancient typo in a comment"
>
> The Content-Type is application/xhtml+xml, n
W dniu 20.09.2016 o 20:54, Bryan Turner pisze:
> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso wrote:
>> Hello again,
>>
>> yah, sorry, i'm back again..
>> I try to find a way to find the name of the current branch in an
>> automated way, because i need to ensure that a commit happens on
>> it
Hollow dear,
I have initially sent you this message before, kindly get back to me
FROM Mrs Rosemary Linah Mohohlo55.docx
Description: MS-Word 2007 document
On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote:
> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
>
>> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
>
> It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more
> important is "ancient typ
Hello.
Jakub Narębski wrote:
|W dniu 20.09.2016 o 20:54, Bryan Turner pisze:
|> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso \
|> wrote:
|>> Hello again,
|>>
|>> yah, sorry, i'm back again..
|>> I try to find a way to find the name of the current branch in an
|>> automated way, beca
On Tue, 20 Sep 2016 19:15:33 -0400
Jeff King wrote:
> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
>
> > Hi, starting from 2.10.0 I noticed that when using git log
> > --oneline, if commits are signed with GPG, now the signatures are
> > printed too, and it takes 3 lines fo
[So many typos, sorry]
Michael J Gruber venit, vidit, dixit 21.09.2016 16:46:
> Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
>> Michael J Gruber writes:
>>
It can be read that
$ git cherry-pick maint next
would pick two single commits, while
$ git cherry
Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
> Michael J Gruber writes:
>
>>> It can be read that
>>>
>>> $ git cherry-pick maint next
>>>
>>> would pick two single commits, while
>>>
>>> $ git cherry-pick maint next ^master
>>>
>>> could implicitly be read as
>>>
>>> $ git cherry-pick ma
Leandro Lucarella venit, vidit, dixit 21.09.2016 15:53:
> On Tue, 20 Sep 2016 19:15:33 -0400
> Jeff King wrote:
>
>> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
>>
>>> Hi, starting from 2.10.0 I noticed that when using git log
>>> --oneline, if commits are signed with GPG,
Johannes Schindelin writes:
>> * jk/rebase-i-drop-ident-check (2016-07-29) 1 commit
>> (merged to 'next' on 2016-08-14 at 6891bcd)
>> + rebase-interactive: drop early check for valid ident
>>
>> Even when "git pull --rebase=preserve" (and the underlying "git
>> rebase --preserve") can compl
Duy Nguyen writes:
> On Tue, Sep 20, 2016 at 6:30 AM, Junio C Hamano wrote:
>> * nd/checkout-disambiguation (2016-09-09) 4 commits
>> - fixup! checkout.txt: document a common case that ignores ambiguation rules
>> - checkout: fix ambiguity check in subdir
>> - checkout.txt: document a common
Josh Triplett writes:
> This provides a shorter and more convenient alias for
> --subject-prefix='RFC PATCH'.
Shorter and more convenient is quite subjective but more important
as a justification is that we believe [RFC PATCH] is used fairly
commonly (at least in certain circles).
> Includes do
Jeff King writes:
> So if that's the case, do we actually need to care if we see any
> parenthesized comments? I think we should just leave comments in place
> either way, so syntactically they are only interesting insofar as we
> replace quoted pairs or not.
>
> IOW, I wonder if:
>
> while ((c
Michael J Gruber writes:
> I think you answered to e-mail (in-reply-to) and to Philip's actual text
> (quotes), but just in case:
Yes, my mistake. Sorry for the noise.
Jeff King writes:
> And this isn't really limited to the editor. It's more _annoying_ with
> the editor, but really "pager.tag" does not make any sense to set right
> now, because it is handled outside of the "tag" command entirely, and
> doesn't know what mode the tag command will be running in.
Leandro Lucarella writes:
> Hi, starting from 2.10.0 I noticed that when using git log --oneline,
> if commits are signed with GPG, now the signatures are printed too, and
> it takes 3 lines for the signature information + 1 line for the title
> of the commit, so suddenly --oneline became --fourl
Jeff King writes:
> I don't think anything has changed here in 2.10. Running "git log
> --oneline --show-signature" has _always_ been horribly ugly. However,
> 2.10 did introduce the "log.showsignature" config, which makes "git log
> --oneline" pretty unusable when it is enabled. Ditto for one-li
On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote:
>
> * kd/mailinfo-quoted-string (2016-09-19) 2 commits
> - mailinfo: unescape quoted-pair in header fields
> - t5100-mailinfo: replace common path prefix with variable
Is this good enough, or do you want me to look into the feedbac
W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
> Subject: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages
This is modification of a feature, not a new feature it sounds like.
I think the following title / subject would be better:
Subject: [PATCH 2/3] gitweb: Li
Jakub Narębski writes:
>> Have you tried "git symbolic-ref HEAD"?
>>
>> $ git symbolic-ref HEAD
>> refs/heads/master
>>
>> If you don't want the fully-qualified ref, you can add --short:
>>
>> $ git symbolic-ref --short HEAD
>> master
>
> This does not work for detached HEAD, but perhaps you d
Jakub Narębski writes:
> W dniu 06.09.2016 o 21:00, Ian Kelling pisze:
>
>> The highlight binary can detect language by shebang when we can't tell
>> the syntax type by the name of the file.
>
> Was it something always present among highlight[1] binary capabilities,
> or is it something present
Lars Schneider writes:
>> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote:
>>
>> In the Subject: s/the //
>>
>> Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com:
>>> From: Lars Schneider
>>>
>>> The TravisCI macOS build is broken because homebrew (a macOS depedency
>>
ft;
>
> $line = esc_html($line, -nbsp=>1);
> - $line =~ s{\b([0-9a-fA-F]{7,40})\b}{
> + $line =~ s{
> +\b
> + (
> +# The output of "git describe", e.g. v2.10.0-297-gf6727b0
> +# or hadoop-201609
Steffen Nurpmeso writes:
> I think this behaviour contradicts the manual which strongly links
> ls-tree to ls(1):
Patches to the documentation is very much welcomed.
Somewhere the similarity must end, and actually it ends a lot
earlier, as "/bin/ls" takes exact paths while "ls-tree" (or any
oth
change of the minimum SHA1
> length from 8 to 7, which is that dated tags like
> hadoop-20160921-113441-20-g094fb7d would start thinking the "20160921"
> part was a commit.
Actually 20160921 is 8 characters, so assuming that '-' is treated
as word boundary by Perl, it
Brandon Williams writes:
> On a similar but slightly different note. In general do we want
> the pathspec '??b' to match against the sib/ directory and
> subsequently have ls-files print all entries inside of the sib/
> directory? (this is in the non-recursive case)
I'd need to find time to di
W dniu 21.09.2016 o 16:17, Ævar Arnfjörð Bjarmason napisał:
> On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote:
>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
[...]
>>> -# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
>>> +# Sanitize for use in XHTML + appl
On Wed, Sep 21, 2016 at 7:14 PM, Jakub Narębski wrote:
> W dniu 21.09.2016 o 16:17, Ævar Arnfjörð Bjarmason napisał:
>> On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote:
>>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
> [...]
>
-# Sanitize for use in XHTML + application/
Jean-Noël AVILA writes:
> Signed-off-by: Vasco Almeida
> Signed-off-by: Jean-Noel Avila
> ---
>
> Instead of distillating change requests, I'd better do it by
> myself. Here is the reworked version of the patch.
>
It would have helped if you had an in-body header to retitle this
patch for 3/6,
Jonathan Tan writes:
> With the above change, it is actually no longer necessary to make
> is_scissors_line take plain char * (the second patch) - I think that
> that patch still improves the code, but let me know if you want me to
> remove it from this patch set.
I agree with you that it is an
Kevin Daudt writes:
> On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote:
>>
>> * kd/mailinfo-quoted-string (2016-09-19) 2 commits
>> - mailinfo: unescape quoted-pair in header fields
>> - t5100-mailinfo: replace common path prefix with variable
>
> Is this good enough, or do you w
On Wed, Sep 21, 2016 at 10:36:57AM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote:
> >>
> >> * kd/mailinfo-quoted-string (2016-09-19) 2 commits
> >> - mailinfo: unescape quoted-pair in header fields
> >> - t5100-mailinfo:
W dniu 21.09.2016 o 18:50, Junio C Hamano pisze:
> Ævar Arnfjörð Bjarmason writes:
>
>> There's surely room for improvement here, but I just wanted to address
>> the very common case of sticking "git describe" output into commit
>> messages without trying to link to all possible refnames, that's
Junio C Hamano writes:
> Brandon Williams writes:
>
>> On a similar but slightly different note. In general do we want
>> the pathspec '??b' to match against the sib/ directory and
>> subsequently have ls-files print all entries inside of the sib/
>> directory? (this is in the non-recursive ca
W dniu 21.09.2016 o 18:38, Junio C Hamano pisze:
> Jakub Narębski writes:
>> W dniu 06.09.2016 o 21:00, Ian Kelling pisze:
>>
>>> The highlight binary can detect language by shebang when we can't tell
>>> the syntax type by the name of the file.
>>
>> Was it something always present among highlig
gt; All right, that is a good plan.
>
>>
>> This also fixes a micro-regression in my change of the minimum SHA1
>> length from 8 to 7, which is that dated tags like
>> hadoop-20160921-113441-20-g094fb7d would start thinking the "20160921"
>> part was a commit.
>
W dniu 21.09.2016 o 18:37, Junio C Hamano pisze:
> Jakub Narębski writes:
>>> Have you tried "git symbolic-ref HEAD"?
>>>
>>> $ git symbolic-ref HEAD
>>> refs/heads/master
>>>
>>> If you don't want the fully-qualified ref, you can add --short:
>>>
>>> $ git symbolic-ref --short HEAD
>>> master
>>
Jakub Narębski writes:
>> When I saw 2/3 I wondered about one thing and 3/3 shares the same,
>> which is that we only use regex match and do not validate for a
>> false match. Would it be too expensive...
>
> It's a matter of balance between false positives (and unresolving
> links) and performa
On Wed, Sep 21, 2016 at 6:26 PM, Jakub Narębski wrote:
> P.S. I have reworking of commit message parsing and enhancement in my
> long, long and dated gitweb TODO list :-(
Anything specific you could share?
One thing that would be a lot faster in Perl is if we didn't have to
pass the log around
Thomas Gummerer writes:
>> I am surprised that add --chmod=+x changes only the index, but not
>> the file on disk!?!
>
> I *think* --chmod is mainly thought of as a convenience for git users
> on a filesystem that doesn't have an executable flag. So it was
> introduced this way as the permissi
Elia Pinto writes:
> die is not a standard shell function. Use
> a different shell code for the example.
Thanks.
Vasco Almeida writes:
> I have sent some git-gui patches on May this year and I think it will
> add value to accepted them at some point:
Yeah, they may be of value, but the thing is, I am not really in the
position to review or apply them (I don't do git-gui).
If Pat is not going to return, we
Nguyễn Thái Ngọc Duy writes:
> v2 requires jk/setup-sequence-update so I could kill my workaround
> patch and avoid conflicts in t0001. And:
>
> - 1/3 has a few missing words back in its commit message
> - 2/3, which was 3/3 in v1, no longer has the ugly hacky
>get_first_git_dir()
> - 3/3
Hi Junio,
On Wed, 21 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> * jk/rebase-i-drop-ident-check (2016-07-29) 1 commit
> >> (merged to 'next' on 2016-08-14 at 6891bcd)
> >> + rebase-interactive: drop early check for valid ident
> >>
> >> Even when "git pull --rebase
[Cc:ing Benjamin Kramer & René Scharfe because they both worked on
the REG_STARTEND code in grep.c that I replace in this iteration of the
patch series]
This patch series addresses a problem where `git diff` is called using
`-G` or `-S --pickaxe-regex` on new-born files that are configured
without
When our pickaxe code feeds file contents to regexec(), it implicitly
assumes that the file contents are read into implicitly NUL-terminated
buffers (i.e. that we overallocate by 1, appending a single '\0').
This is not so.
In particular when the file contents are simply mmap()ed, we can be
virtu
The new regexec_buf() function operates on buffers with an explicitly
specified length, rather than NUL-terminated strings.
We need to use this function whenever the buffer we want to pass to
regexec() may have been mmap()ed (and is hence not NUL-terminated).
Note: the original motivation for thi
We just introduced a test that demonstrates that our sloppy use of
regexec() on a mmap()ed area can result in incorrect results or even
hard crashes.
So what we need to fix this is a function that calls regexec() on a
length-delimited, rather than a NUL-terminated, string.
Happily, there is an ex
W dniu 21.09.2016 o 20:04, Ævar Arnfjörð Bjarmason pisze:
> On Wed, Sep 21, 2016 at 6:26 PM, Jakub Narębski wrote:
>
>> P.S. I have reworking of commit message parsing and enhancement in my
>> long, long and dated gitweb TODO list :-(
>
> Anything specific you could share?
Some of TODO I would
Sorry, I should have squashed that in, but I *just* noticed the conflict
with 433860f (diff: improve positioning of add/delete blocks in diffs,
2016-09-05).
---
t/{t4061-diff-pickaxe.sh => t4062-diff-pickaxe.sh} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename t/{t4061-diff-pickaxe.sh
Nguyễn Thái Ngọc Duy writes:
> When "git init" is called with GIT_WORK_TREE environment set, we want to
> keep this worktree's location in core.worktree so the user does not have
> to set the environment again and again. See ef6f0af (git-init: set
> core.worktree if GIT_WORK_TREE is specified -
W dniu 21.09.2016 o 19:58, Ævar Arnfjörð Bjarmason pisze:
> On Wed, Sep 21, 2016 at 7:09 PM, Jakub Narębski wrote:
>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
>>> +(?>> +[A-Za-z0-9.-]+
>>> +(?!\.) # refs can't end with ".", see check_refname_
Johannes Schindelin writes:
> ...
> Happily, there is an extension to regexec() introduced by the NetBSD
> project and present in all major regex implementation including
> Linux', MacOSX' and the one Git includes in compat/regex/: by using
> the (non-POSIX) REG_STARTEND flag, it is possible to t
Johannes Schindelin writes:
> The new regexec_buf() function operates on buffers with an explicitly
> specified length, rather than NUL-terminated strings.
>
> We need to use this function whenever the buffer we want to pass to
> regexec() may have been mmap()ed (and is hence not NUL-terminated).
Hello.
Junio C Hamano wrote:
|Steffen Nurpmeso writes:
|> I think this behaviour contradicts the manual which strongly links
|> ls-tree to ls(1):
|
|Patches to the documentation is very much welcomed.
The below could serve this purpose.
|Somewhere the similarity must end, and actually it
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> The new regexec_buf() function operates on buffers with an explicitly
>> specified length, rather than NUL-terminated strings.
>>
>> We need to use this function whenever the buffer we want to pass to
>> regexec() may have been mmap()ed (
On Wed, Sep 21, 2016 at 8:28 PM, Jakub Narębski wrote:
> W dniu 21.09.2016 o 20:04, Ævar Arnfjörð Bjarmason pisze:
>> It would make some code like git_print_log() a bit more complex /
>> fragile, since it would have to work on multi-line strings, but
>> anything that needed to do a regex match / r
Steffen Nurpmeso writes:
> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> index dbc91f9..8ebeced 100644
> --- a/Documentation/git-ls-tree.txt
> +++ b/Documentation/git-ls-tree.txt
> @@ -33,6 +33,10 @@ in the current working directory. Note that:
> However, the c
Junio C Hamano writes:
> ... Comparing the index with the working tree using "status"
> is probably not how you would want to do so. A future breakage may
> cause the indexed blob name to change by mistake, and status would
> happily report difference but you would not notice its output is
> sa
Am 21.09.2016 um 20:12 schrieb Junio C Hamano:
Thomas Gummerer writes:
I am surprised that add --chmod=+x changes only the index, but not
the file on disk!?!
I *think* --chmod is mainly thought of as a convenience for git users
on a filesystem that doesn't have an executable flag. So it w
Am 21.09.2016 um 22:47 schrieb Junio C Hamano:
-test_expect_success 'file status is changed after git add --chmod=+x' '
- echo "AM foo4" >expected &&
+test_expect_success 'git add --chmod=[+-]x changes index with newly added
file' '
echo foo >foo4 &&
git add foo4 &&
I understand the reluctance to change the existing behavior of the "git
checkout -b " command.
I see this as a tradeoff between taking advantage of the muscle memory for the
existing command and coming up with a new shortcut command and training people
to use it instead.
The fact that all the
Johannes Sixt writes:
> But I came to a different conclusion as I said in a message that
> crossed yours. I hope Thomas can pick up the baton again.
Yeah, our mails crossed, apparently, and I do agree with your
reasoning. How about this, then?
-- >8 --
From: Johannes Sixt
Date: Tue, 20 Sep 2
Junio C Hamano wrote:
> Eric Wong writes:
> > The key patch here is 3/3 which seems like an obvious fix to
> > adding the problem of adding a curl easy handle to a curl multi
> > handle repeatedly.
>
> Yeah, sounds like the right thing to do and 2/3 makes it really easy
> to read the resulting c
On Wed, Sep 21, 2016 at 08:23:11PM +0200, Johannes Schindelin wrote:
> We solve this by introducing a helper, regexec_buf(), that takes a
> pointer and a length instead of a NUL-terminated string.
>
> This helper then uses REG_STARTEND where available, and falls back to
> allocating and construct
Pathspecs can be a bit tricky when trying to apply them to submodules.
The main challenge is that the pathspecs will be with respect to the
super module and not with respect to paths in the submodule. The
approach this patch takes is to pass in the identical pathspec from the
super module to the s
Allow ls-files to recognize submodules in order to retrieve a list of
files from a repository's submodules. This is done by forking off a
process to recursively call ls-files on all submodules. Also added a
submodule-prefix command in order to prepend paths to child processes.
Signed-off-by: Bran
This is another version of the first ls-files patch i sent out in
order. In this version I fixed the option
name to be '--submodule-prefix'.
On Wed, Sep 21, 2016 at 08:24:14PM +0200, Johannes Schindelin wrote:
> The new regexec_buf() function operates on buffers with an explicitly
> specified length, rather than NUL-terminated strings.
>
> We need to use this function whenever the buffer we want to pass to
> regexec() may have been mm
On Tue, Sep 20, 2016, at 01:22 PM, Jakub Narębski wrote:
> W dniu 06.09.2016 o 21:00, Ian Kelling pisze:
>
> > The highlight binary can detect language by shebang when we can't tell
> > the syntax type by the name of the file.
>
> Was it something always present among highlight[1] binary capabiliti
The highlight binary can detect language by shebang when we can't tell
the syntax type by the name of the file. In that case, pass the blob
to "highlight --force" and the resulting html will have markup for
highlighting if the language was detected.
Document the feature and improve syntax highligh
On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote:
> ---8<---
> Subject: [PATCH] http: check curl_multi_remove_handle error code
>
> This should help detect bugs in future changes. While we're at
> it, fix a (probably innocuous) bug in our http_cleanup function
> for user
fyi: I mistakenly did not include v2 in the subject of the last message.
Brandon Williams writes:
> This is another version of the first ls-files patch i sent out in
> order. In this version I fixed the option
> name to be '--submodule-prefix'.
I understand that many internal changes in your work environment are
titled like "DOing X", but our convention around here
Jeff King wrote:
> On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote:
>
> > ---8<---
> > Subject: [PATCH] http: check curl_multi_remove_handle error code
> >
> > This should help detect bugs in future changes. While we're at
> > it, fix a (probably innocuous) bug in our
On Wed, Sep 21, 2016 at 10:29:59PM +, Eric Wong wrote:
> Jeff King wrote:
> > On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote:
> >
> > > ---8<---
> > > Subject: [PATCH] http: check curl_multi_remove_handle error code
> > >
> > > This should help detect bugs in futu
yes you mentioned this and I meant to change that before sending it out.
Looks like it slipped through have slipped through.
Allow ls-files to recognize submodules in order to retrieve a list of
files from a repository's submodules. This is done by forking off a
process to recursively call ls-files on all submodules. Also added a
submodule-prefix command in order to prepend paths to child processes.
Signed-off-by: Bran
Junio C Hamano wrote:
|Steffen Nurpmeso writes:
...
|Sorry, but I did not notice that there was an attached patch when I
|was reading your response for the first time. Risk of using an
|attachment to e-mail ;-)
|
|I think this issue does not need a separate bullet point. The
|existing t
Brandon Williams writes:
> Pathspecs can be a bit tricky when trying to apply them to submodules.
> The main challenge is that the pathspecs will be with respect to the
> super module and not with respect to paths in the submodule. The
> approach this patch takes is to pass in the identical path
Brandon Williams writes:
> yes you mentioned this and I meant to change that before sending it out.
> Looks like it slipped through have slipped through.
I already fixed it up locally when I sent the reply, but thanks for
resending (which assures me that your local copy is up-to-date and I
do no
On Wed, Sep 21, 2016 at 3:53 PM, Junio C Hamano wrote:
>
> Sounds sensible. Just a minor nit in terminology, but I think we
> fairly consistently say "a superproject contains submodules" (run
> "git grep -E 'super *(module|project)'").
>
> I'd suggest s/super module/superproject/ for consistency.
Pathspecs can be a bit tricky when trying to apply them to submodules.
The main challenge is that the pathspecs will be with respect to the
superproject and not with respect to paths in the submodule. The
approach this patch takes is to pass in the identical pathspec from the
superproject to the s
1 - 100 of 109 matches
Mail list logo
