Am 03.06.2016 um 08:41 schrieb Matthieu Moy:
Rejecting colon anywhere in the line would also reject valid patterns
like this:
a:hover {
Rejecting it at end of line is probably a good trade-off.
Good point. Could be worth another test case.
-- Hannes
--
To unsubscribe from this list: send th
Am 03.06.2016 um 08:10 schrieb Jeff King:
On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote:
- name=$(pwd)/.gitconfig
+ name=$HOME/.gitconfig
I haven't tested this, yet, but my guess is that this breaks on Windows:
test-config will produce C:/foo style path, but the up
Johannes Sixt writes:
>> +IPATTERN("css",
>> + "!^.*;\n"
>
> Is there a difference between this and "!;\n"? Is it necessary to
> anchor the pattern at the beginning of the line?
Also, you don't want to force the end of line right after ;. I know
trailing whitespaces are evil, but users may n
On Fri, Jun 03, 2016 at 08:05:56AM +0200, Johannes Sixt wrote:
> > - name=$(pwd)/.gitconfig
> > + name=$HOME/.gitconfig
>
> I haven't tested this, yet, but my guess is that this breaks on Windows:
> test-config will produce C:/foo style path, but the updated test would
> expect /c/foo style p
Am 03.06.2016 um 00:15 schrieb Junio C Hamano:
When your $PWD does not match $(/bin/pwd), e.g. you have your copy
of the git source tree in one place, point it with a symbolic link,
and then "cd" to that symbolic link before running 'make test', one
of the tests in t1308 expects that the per-user
Am 03.06.2016 um 00:48 schrieb William Duclot:
Logic behind the "pattern" regex is:
The name of the macro parameter is "pattern", but the actual meaning is
"function name" regex.
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..81f60ad 100644
---
On 06/03/2016 01:13 AM, Mike Hommey wrote:
On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote:
* mh/connect (2016-06-01) 9 commits
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the -
On Thu, Jun 02, 2016 at 04:23:00PM -0700, Stefan Beller wrote:
> > To prevent this in the future, I switched my default --root= to point to
> > a symlink. I wonder if we could do something in the test suite, though,
> > as we did long ago by introducing "trash directory" with a space to
> > catch
On Thu, Jun 2, 2016 at 4:23 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> However if we add a value restriction here, we need to be as strict in the
>> .gitattributes parsing as well and put a warning there (similar to
>> invalid_attr_name_message) I would think.
>
> Remember, the attrib
Stefan Beller writes:
> However if we add a value restriction here, we need to be as strict in the
> .gitattributes parsing as well and put a warning there (similar to
> invalid_attr_name_message) I would think.
Remember, the attribute system is used for many purposes other than
this new "furthe
On Thu, Jun 2, 2016 at 4:16 PM, Jeff King wrote:
> On Thu, Jun 02, 2016 at 03:15:39PM -0700, Junio C Hamano wrote:
>
>> When your $PWD does not match $(/bin/pwd), e.g. you have your copy
>> of the git source tree in one place, point it with a symbolic link,
>> and then "cd" to that symbolic link b
On Thu, Jun 02, 2016 at 03:15:39PM -0700, Junio C Hamano wrote:
> When your $PWD does not match $(/bin/pwd), e.g. you have your copy
> of the git source tree in one place, point it with a symbolic link,
> and then "cd" to that symbolic link before running 'make test', one
> of the tests in t1308 e
In our own .gitattributes file we have attributes such as:
*.[ch] whitespace=indent,trail,space
When querying for attributes we want to be able to ask for the exact
value, i.e.
git ls-files :(attr:whitespace=indent,trail,space)
should work, but the commas are used in the attr magic to i
On Thu, Jun 02, 2016 at 03:52:41PM -0700, Junio C Hamano wrote:
> * mh/connect (2016-06-01) 9 commits
> - connect: move ssh command line preparation to a separate function
> - connect: actively reject git:// urls with a user part
> - connect: change the --diag-url output to separate user and hos
You can ask rev-list to use bitmaps to speed up an --objects
traversal, which should generally give you your answers much
faster.
Likewise, you can ask rev-list to limit such a traversal
with `-n`, in which case we'll show only a limited set of
commits (and only the tree and commit objects directl
If you ask rev-list for:
git rev-list --count --use-bitmap-index HEAD
we optimize out the actual traversal and just give you the
number of bits set in the commit bitmap. This is faster,
which is good.
But if you ask to limit the size of the traversal, like:
git rev-list --count --use-bi
This series fixes two corner-cases I found when using "-n" along with
bitmaps. The results do make _some_ sense if you interpret them
correctly, but are sufficiently confusing that I think it's worth
dealing with. See the commit messages for the gory details.
The good news is that in the first cas
William Duclot writes:
> diff --git a/userdiff.c b/userdiff.c
> index 6bf2505..00fc3bf 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -148,6 +148,18 @@ PATTERNS("csharp",
>"[a-zA-Z_][a-zA-Z0-9_]*"
>"|[-+0-9.e]+[fFlL]?|0[xXbB]?[0-9a-fA-F]+[lL]?"
>"|[-+*/<>%&^|=!]=|--|\\+
Stefan Beller writes:
> Thinking about efficiency, I have the believe that memmove can be faster
> than a `*src=*dst` thing we do ourselves as it may have access to specialized
> assembly instructions to move larger chunks of memory or such.
> So I think ideally we would do a block copy between
On Thu, Jun 2, 2016 at 2:54 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> In our own .gitattributes file we have attributes such as:
>>
>> *.[ch] whitespace=indent,trail,space
>>
>> When querying for attributes we want to be able to ask for the exact
>> value, i.e.
>>
>> git ls-f
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
2.9-rc2 is scheduled for early nex
CSS is widely used, motivating it being included as a built-in pattern.
It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test
When your $PWD does not match $(/bin/pwd), e.g. you have your copy
of the git source tree in one place, point it with a symbolic link,
and then "cd" to that symbolic link before running 'make test', one
of the tests in t1308 expects that the per-user configuration was
reported to have been read fro
On Thu, Jun 2, 2016 at 2:54 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> In our own .gitattributes file we have attributes such as:
>>
>> *.[ch] whitespace=indent,trail,space
>>
>> When querying for attributes we want to be able to ask for the exact
>> value, i.e.
>>
>> git ls-f
On Thu, Jun 02, 2016 at 02:59:51PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So the greater question is not "should this output be marked" but
> > "should auto-gc data go over the sideband so that all clients see it
> > (and any server-side stderr does not)". And I think the answer
Jeff King writes:
> I think diff_filespec_clear() would not be quite right. It is freeing
> only the allocated _data_, but leaving the other portions intact.
You are (as usual) more right than I am ;-)
Yes, the free_data() is designed to retain enough information about
the filespec so that the
Jeff King writes:
> So the greater question is not "should this output be marked" but
> "should auto-gc data go over the sideband so that all clients see it
> (and any server-side stderr does not)". And I think the answer is
> probably yes. And that fixes the "remote: " thing as a side effect.
T
Stefan Beller writes:
> In our own .gitattributes file we have attributes such as:
>
> *.[ch] whitespace=indent,trail,space
>
> When querying for attributes we want to be able to ask for the exact
> value, i.e.
>
> git ls-files :(attr:whitespace=indent,trail,space)
>
> should work, but th
On Thu, Jun 02, 2016 at 01:14:02PM -0700, Junio C Hamano wrote:
> > What exactly are you referring to (you only quoted the introduction)?
> > Do you think we should fix the git-gc issue but keep the general
> > behavior of printing messages unaltered? Do you think it would be
> > worthwhile to mak
On Thu, Jun 02, 2016 at 01:14:02PM -0700, Junio C Hamano wrote:
> On Thu, Jun 2, 2016 at 1:06 PM, Lukas Fleischer wrote:
> > On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote:
> >> Lukas Fleischer writes:
> >>
> >> > When running `git push`, it might occur that error messages are
> >> > tran
On Thu, Jun 02, 2016 at 02:31:50PM -0700, Junio C Hamano wrote:
> Perhaps like this, taking hint from the log message of 6eafa6d0
> (submodules: don't stumble over symbolic links when cloning
> recursively, 2012-07-12)?
>
> t/t1308-config-set.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
Junio C Hamano writes:
> Torsten Bögershausen writes:
>
>> It seams as ./t1308-config-set.sh is broken,
>> when the the directory is a soft link:
>>
>> -name=/home/tb/NoBackup/projects/git/git.pu/t/trash
>> directory.t1308-config-set/.gitconfig
>> +name=/home/tb/projects/git/git.pu/t/trash
>>
In our own .gitattributes file we have attributes such as:
*.[ch] whitespace=indent,trail,space
When querying for attributes we want to be able to ask for the exact
value, i.e.
git ls-files :(attr:whitespace=indent,trail,space)
should work, but the commas are used in the attr magic to i
On Thu, Jun 02, 2016 at 02:18:47PM -0700, Junio C Hamano wrote:
> The function takes a pointer to a pathspec structure, and releases
> the resources held by it, but does not free() the structure itself.
> Such a function should be called "clear", not "free".
Hmm, makes sense, though...
> * This
Torsten Bögershausen writes:
> It seams as ./t1308-config-set.sh is broken,
> when the the directory is a soft link:
>
> -name=/home/tb/NoBackup/projects/git/git.pu/t/trash
> directory.t1308-config-set/.gitconfig
> +name=/home/tb/projects/git/git.pu/t/trash
> directory.t1308-config-set/.gitconf
The function takes a pointer to a pathspec structure, and releases
the resources held by it, but does not free() the structure itself.
Such a function should be called "clear", not "free".
Signed-off-by: Junio C Hamano
---
* This is just something I noticed. Among the hits in
$ git grep f
Matteo Bertini wrote:
> Il 2016-05-31 20:12 Eric Wong ha scritto:
> >Matteo Bertini wrote:
> >>Sorry to all, but I missed a Checksum mismatch error, I'll have a
> >>look and submit an update.
>
> I've had a look, the problem is a missing smudge filter.
> Unluckily the small svn revision range i
On Thu, Jun 2, 2016 at 1:06 PM, Lukas Fleischer wrote:
> On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote:
>> Lukas Fleischer writes:
>>
>> > When running `git push`, it might occur that error messages are
>> > transferred from the server to the client. While most messages (those
>> > explic
On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > When running `git push`, it might occur that error messages are
> > transferred from the server to the client. While most messages (those
> > explicitly sent on sideband 2) are prefixed with "remote:", it seems
Samuel GROOT wrote:
> On 05/29/2016 01:33 AM, Eric Wong wrote:
> >Matthieu Moy wrote:
> >>Samuel GROOT writes:
> >>
> >>>Parsing and processing in send-email is done in the same loop.
> >>>
> >>>To make the code more maintainable, we create two subroutines:
> >>>- `parse_email` to separate heade
On 02/06/16 20:46, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> I think Junio wants to go with just " quoting (see other thread).
>
> No. I meant just \ quoting.
Yes, sorry, I only just read your last email on the other thread.
ATB,
Ramsay Jones
--
To unsubscribe from this list: send
On 02/06/16 20:29, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones
>> wrote:
That would be workable, I would think. Before attr:VAR=VAL
extention, supported pathspec were only single lowercase-ascii
alphabet tokens, so nob
Ramsay Jones writes:
> I think Junio wants to go with just " quoting (see other thread).
No. I meant just \ quoting.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-i
On 02/06/16 20:04, Stefan Beller wrote:
> On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones
> wrote:
>>
>>
>> On 02/06/16 17:10, Junio C Hamano wrote:
>>> Ramsay Jones writes:
>>>
So, at risk of annoying you, let me continue in my ignorance a little
longer and ask: even if you have to pro
Lukas Fleischer writes:
> When running `git push`, it might occur that error messages are
> transferred from the server to the client. While most messages (those
> explicitly sent on sideband 2) are prefixed with "remote:", it seems
> that error messages printed during the automatic householding
Junio C Hamano writes:
> On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones
> wrote:
>>>
>>> That would be workable, I would think. Before attr:VAR=VAL
>>> extention, supported pathspec were only single lowercase-ascii
>>> alphabet tokens, so nobody would have used " as a part of magic. So
>>> qut
When running `git push`, it might occur that error messages are
transferred from the server to the client. While most messages (those
explicitly sent on sideband 2) are prefixed with "remote:", it seems
that error messages printed during the automatic householding performed
by git-gc(1) are display
On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones
wrote:
>
>
> On 02/06/16 17:10, Junio C Hamano wrote:
>> Ramsay Jones writes:
>>
>>> So, at risk of annoying you, let me continue in my ignorance a little
>>> longer and ask: even if you have to protect all of this 'magic' from
>>> the shell with '/"
On Thu, Jun 2, 2016 at 11:42 AM, Ramsay Jones
wrote:
>>
>> That would be workable, I would think. Before attr:VAR=VAL
>> extention, supported pathspec were only single lowercase-ascii
>> alphabet tokens, so nobody would have used " as a part of magic. So
>> quting with double-quote pair would w
On 02/06/16 17:10, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> So, at risk of annoying you, let me continue in my ignorance a little
>> longer and ask: even if you have to protect all of this 'magic' from
>> the shell with '/" quoting, could you not use (nested) quotes to
>> protect the
Thomas Braun writes:
> + untracked_state="$(__git_find_on_cmdline "--untracked-files=no\
> + --untracked-files=normal --untracked-files=all")"
Just wondering but does this help my use of the command like
$ git status -uno
or do I now have to spell it out like
Michael Haggerty writes:
> Fixing reachability via the index and detached HEADs feels relatively
> important.
> ...
I agree with the order of importance above. But "relatively" is a
very good keyword. Just like bisection refs, what is in the index
and the commit detached HEAD points at are exp
Vasco Almeida writes:
> Às 17:43 de 01-06-2016, Junio C Hamano escreveu:
>> Vasco Almeida writes:
>>
>>> Introduced in 473166b ("config: add 'origin_type' to config_source
>>> struct", 2016-02-19), Git can inform the user about the origin of a
>>> config error, but the implementation does not a
Vasco Almeida writes:
> Às 17:38 de 01-06-2016, Junio C Hamano escreveu:
>> Vasco Almeida writes:
>>
>>> +enum term { BAD, GOOD, OLD, NEW };
>>> +static const char *term_names[] = {
>>> +/* TRANSLATORS: in bisect.c source code file, the following terms are
>>> + used to describe a "bad commit
On 05/29/2016 01:33 AM, Eric Wong wrote:
Matthieu Moy wrote:
Samuel GROOT writes:
Parsing and processing in send-email is done in the same loop.
To make the code more maintainable, we create two subroutines:
- `parse_email` to separate header and body
- `parse_header` to retrieve data from
On Thu, Jun 2, 2016 at 8:59 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
Gaah, of course.
This is coming from the cache preload codepath, where multiple threads
try to run ce_path_match().
It used to be OK because pathspec magic never looked at attributes,
bu
Duy Nguyen writes:
> On Thu, Jun 2, 2016 at 1:44 AM, Junio C Hamano wrote:
>>> We would
>>> need to convert or match both '/' and '\' in "to/foo" case because of
>>> Windows, so it's not much easier than basename().
>>
>> I never said "easier to implement". But can this codepath get
>> backslas
On 06/02/2016 12:08 PM, Duy Nguyen wrote:
> On Mon, May 30, 2016 at 2:55 PM, Michael Haggerty
> wrote:
>> Currently, the API for iterating over references is via a family of
>> for_each_ref()-type functions that invoke a callback function for each
>> selected reference. All of these eventually ca
Duy Nguyen writes:
> On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote:
>> That is, I wonder if the above can become something like:
>>
>>> From github.com:pclouds/git
>>> * [new branch] { -> pclouds/}2nd-index
>>> * [new branch] { -> pclouds/}3nd-index
>>> * [new branch] {
Ramsay Jones writes:
> So, at risk of annoying you, let me continue in my ignorance a little
> longer and ask: even if you have to protect all of this 'magic' from
> the shell with '/" quoting, could you not use (nested) quotes to
> protect the part of an ? For example:
>
> git ls-files ':(a
Junio C Hamano writes:
>>> Gaah, of course.
>>>
>>> This is coming from the cache preload codepath, where multiple threads
>>> try to run ce_path_match().
>>> It used to be OK because pathspec magic never looked at attributes,
>>> but now it does, and attribute system is not thread-safe.
I'll lo
> On 30 May 2016, at 06:45, Antoine Queru
> wrote:
>
> Currently, a user wanting to prevent accidental pushes to the wrong remote
> has to create a pre-push hook.
> The feature offers a configuration to allow users to prevent accidental pushes
> to the wrong remote. The user may define a list
On 02/06/16 06:46, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Not having given this much thought at all, but the question which comes
>> to mind is: can you use some other separator for the -s rather than
>> a comma? That way you don't need to quote them in the part of the
>> -spec.
>>
Signed-off-by: Thomas Braun
---
contrib/completion/git-completion.bash | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 3402475..addea89 100644
--- a/contrib/completion/git-completion.bash
Signed-off-by: Thomas Braun
---
contrib/completion/git-completion.bash | 55 ++
1 file changed, 55 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index addea89..fa7a03a 100644
--- a/contrib/completion/gi
Am 01.06.2016 um 14:15 schrieb SZEDER Gábor:
>
> Quoting Thomas Braun :
>
>> Signed-off-by: Thomas Braun
>> ---
>> contrib/completion/git-completion.bash | 29
>> +
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/contrib/completion/git-completion.bash
>> b/con
Am 01.06.2016 um 13:59 schrieb SZEDER Gábor:
>
> This subject would perhaps read better:
>
> completion: factor out untracked file modes into a variable
Yes, definitly. Will be included in reroll.
> Quoting Thomas Braun :
>
>> Signed-off-by: Thomas Braun
>> ---
>> contrib/completion/git-co
Às 17:43 de 01-06-2016, Junio C Hamano escreveu:
> Vasco Almeida writes:
>
>> Introduced in 473166b ("config: add 'origin_type' to config_source
>> struct", 2016-02-19), Git can inform the user about the origin of a
>> config error, but the implementation does not allow translators to
>> translat
Às 20:30 de 01-06-2016, Junio C Hamano escreveu:
> Junio C Hamano writes:
> Would it allow you to lose the $(git --exec-path) prefix in the new
> dot-source to have this patch before applying your patch?
>
> -- >8 --
> Subject: t2300: run git-sh-setup in an environment that better mimics the
> r
Às 17:38 de 01-06-2016, Junio C Hamano escreveu:
> Vasco Almeida writes:
>
>> +enum term { BAD, GOOD, OLD, NEW };
>> +static const char *term_names[] = {
>> +/* TRANSLATORS: in bisect.c source code file, the following terms are
>> + used to describe a "bad commit", "good commit", "new revision"
On Thu, Jun 02, 2016 at 02:58:22PM +0200, Matthieu Moy wrote:
> Michael Haggerty writes:
>
>> 1. The amount of added code complexity is small and quite
>>encapsulated.
>
> Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if
> done properly: we already have the case where the
It seams as ./t1308-config-set.sh is broken,
when the the directory is a soft link:
-name=/home/tb/NoBackup/projects/git/git.pu/t/trash
directory.t1308-config-set/.gitconfig
+name=/home/tb/projects/git/git.pu/t/trash directory.t1308-config-set/.gitconfig
scope=global
key=foo.bar
not ok 28 - it
On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote:
> That is, I wonder if the above can become something like:
>
>> From github.com:pclouds/git
>> * [new branch] { -> pclouds/}2nd-index
>> * [new branch] { -> pclouds/}3nd-index
>> * [new branch] { -> pclouds/}file-watcher
>>
Michael Haggerty writes:
> 1. The amount of added code complexity is small and quite
>encapsulated.
Actually, STRBUF_OWNS_MEMORY can even be seen as a simplification if
done properly: we already have the case where the strbuf does not own
the memory with strbuf_slopbuf. I already pointed pla
On 05/31/2016 04:33 PM, Matthieu Moy wrote:
> Jordan DE GEA writes:
> [...]
>> +DESCRIPTION
>> +---
>> +
>> +Triangular Workflow (or Asymmetric Workflow) is a workflow which gives
>> +the possibility to:
>> +
>> +- fetch (or pull) from a repository
>> +- push to another repository
>
> [..
On 06/02/2016 11:53 AM, Duy Nguyen wrote:
> (from patch 4/4 mail)
>
> On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty
> wrote:
>>> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect"));
>>> + if (file_exists(path))
>>> + handle_one_reflog(path, NULL, 0, &cb);
>>> +
On 06/01/2016 11:07 PM, Jeff King wrote:
> On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote:
>
>> I have no idea if those ideas would work. But I wouldn't want to start
>> looking into either of them without some idea of how much time we're
>> actually spending on strbuf mallocs (or how m
On Mon, May 30, 2016 at 2:55 PM, Michael Haggerty wrote:
> Currently, the API for iterating over references is via a family of
> for_each_ref()-type functions that invoke a callback function for each
> selected reference. All of these eventually call do_for_each_ref(),
> which knows how to do one
(from patch 4/4 mail)
On Wed, Jun 1, 2016 at 10:51 PM, Michael Haggerty wrote:
>> + path = xstrdup(worktree_git_path(wt, "logs/refs/bisect"));
>> + if (file_exists(path))
>> + handle_one_reflog(path, NULL, 0, &cb);
>> + free(path);
>> +}
>
> `refs/bisect` is not a single r
On Thu, Jun 2, 2016 at 1:44 AM, Junio C Hamano wrote:
>> We would
>> need to convert or match both '/' and '\' in "to/foo" case because of
>> Windows, so it's not much easier than basename().
>
> I never said "easier to implement". But can this codepath get
> backslashed paths in the first place?
On Thu, Jun 2, 2016 at 1:57 AM, David Turner wrote:
>> + struct index_state istate;
>> +
>> + memset(&istate, 0, sizeof(istate));
>
>
> Why not just struct index_state istate = {0}; ?
>
My first thought was.. "hmm.. C99?" but then there are 24 of them in
the code base alre
On Thu, Jun 2, 2016 at 1:13 AM, Eric Sunshine wrote:
> On Wed, Jun 1, 2016 at 6:45 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> Current mark_reachable_objects() only marks objects from index from
>> _current_ worktree as reachable instead of all worktrees. Because this
>> function is used for pruning, t
Eric Wong wrote:
> Eric Sunshine wrote:
> > On Tue, May 31, 2016 at 3:45 AM, Eric Wong wrote:
> > > Eric Sunshine wrote:
> > >> I wonder if hand-coding, rather than using a regex, could be an
> > >> improvement:
> > >>
> > >> static int is_mboxrd_from(const char *s, size_t n)
> > >> {
83 matches
Mail list logo
