On Fri, Sep 21 2018, Jeff King wrote:
> On Sat, Sep 22, 2018 at 01:37:17AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Thanks, both of you ;-). I was aware of the issue and proposed fix
>> > but forgot about it when merging things down to 'master'. Sorry
>> > about that.
>>
>> Just a follow-
On Sat, Sep 22, 2018 at 01:37:17AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Thanks, both of you ;-). I was aware of the issue and proposed fix
> > but forgot about it when merging things down to 'master'. Sorry
> > about that.
>
> Just a follow-up question, in your merge commit you just pushed
On Fri, Sep 21 2018, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>> On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
>>> On Fri, Sep 21 2018, Derrick Stolee wrote:
>>>
This error was reported by Peff [1] and fixed in [2], but as stated
[3] I was waiting for more review
Derrick Stolee writes:
> On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Sep 21 2018, Derrick Stolee wrote:
>>
>>>
>>> This error was reported by Peff [1] and fixed in [2], but as stated
>>> [3] I was waiting for more review before sending a v3. I'll send that
>>> v3 shortly, res
On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Derrick Stolee wrote:
This error was reported by Peff [1] and fixed in [2], but as stated
[3] I was waiting for more review before sending a v3. I'll send that
v3 shortly, responding to the feedback so far.
-Stolee
[1
On Fri, Sep 21 2018, Derrick Stolee wrote:
> On 9/21/2018 10:30 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Sep 21 2018, Junio C Hamano wrote:
>>
>>> * ds/reachable (2018-08-28) 19 commits
>>>(merged to 'next' on 2018-08-28 at b1634b371d)
>>> + commit-reach: correct accidental #include o
On 9/21/2018 10:30 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Junio C Hamano wrote:
* ds/reachable (2018-08-28) 19 commits
(merged to 'next' on 2018-08-28 at b1634b371d)
+ commit-reach: correct accidental #include of C file
(merged to 'next' on 2018-08-22 at 17f3275afb)
+
I made:
$git stash
$git checkout
$git stash pop - crash here. changes were applied, but index.lock was
not removed.
The issue appeared only once, I haven't seen it before and cannot
reproduce it now.
Thanks, updated git to 2.15.1.
2017-12-31 10:59 GMT+02:00 Eric Sunshine :
> On Fri, Dec 29, 201
On Fri, Dec 29, 2017 at 4:04 AM, Andrew Tsykhonya
wrote:
> git stash pop resulted in crash:
> /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470:
> 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree
> $w_tree
> although, the changes have been applied successfully.
> Hi Rémi,
>
> On Wed, 5 Apr 2017, Rémi Galan Alfonso wrote:
>
> > At $DAYWORK, the code is versionned under SVN. Since I haven't used SVN
> > before and try to have a clean and bisectable history, I installed git
> > with the intent to manage my code locally before pushing to SVN when I'm
> > sa
Hi Rémi,
On Wed, 5 Apr 2017, Rémi Galan Alfonso wrote:
> At $DAYWORK, the code is versionned under SVN. Since I haven't used SVN
> before and try to have a clean and bisectable history, I installed git
> with the intent to manage my code locally before pushing to SVN when I'm
> satisfied (I haven
On Wed, Sep 07, 2016 at 04:06:42PM -0400, Jeff King wrote:
> +test_expect_success 'remote-http complains cleanly about malformed urls' '
> + # do not actually issue "list" or other commands, as we do not
> + # want to rely on what curl would actually do with such a broken
> + # URL. Th
On Wed, Sep 07, 2016 at 03:44:04PM +0200, Lars Wendler wrote:
> we at Gentoo got a bug report [1] about git-remote-https segfaulting
> when the URL has been mistyped.
> This seems to only be triggered when git was compiled with curl
> support:
>
> git clone https::/some.example-site.net/test.g
On Mon, Jun 27, 2016 at 06:51:26AM +, Greg Werbin wrote:
> I was in the middle of a big messy rebase when the following
> happened:
>
> $ git rebase --continue
> /usr/local/Cellar/git/2.9.0/libexec/git-core/git-rebase--interactive:
> line 238: 60305
> Segmentation fault: 11 "$@"
> Could not
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
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 Thu, Jun 2, 2016 at 8:02 AM, Duy Nguyen wrote:
> On Thu, Jun 2, 2016 at 5:17 AM, Junio C Hamano wrote:
>> 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 attr
On Thu, Jun 2, 2016 at 5:17 AM, Junio C Hamano wrote:
> 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 thr
Junio C Hamano writes:
> 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
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.
The symlink check c
Stefan Beller writes:
> I propose to not escape commas, but use
> white spaces instead, i.e.
>
> git status ':(attr:whitespace=indent trail space,attr:label=with
> more values)' ':attr(attr:foo:bar)'
>
> would match
> * all files that have the whitespace AND the label setting (matching
> exac
On Wed, Jun 1, 2016 at 3:11 PM, Junio C Hamano wrote:
>
> By the way, I just noticed that the part of the
> ':(attr:)' syntax would need to be rethought. In the
> .gitattributes file everybody has, we see these lines:
>
> *.[ch] whitespace=indent,trail,space
> *.sh whitespace=ind
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.
On Wed, Jun 1, 2016 at 3:11 PM, Stefan Beller wrote:
>
This can be reproduced on sb/pathspec-label in git.git as well.
The key difference I notice is `git ls-files` works perfectly (e.g. in
the tests)
while `git status` fails.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
Stefan Beller writes:
> In the Gerrit repo I did
> $ echo "/plugins/commit-message-length-validator sub-default"
>>>.gitattributes
> $ git status ":(attr:sub-default)"
> Segmentation fault (core dumped)
Thanks. I can reproduce this easily with git.git, e.g.
$ cat >>.git/info/at
On Wed, Dec 30, 2015 at 01:28:06PM +0100, Dennis Kaarsemaker wrote:
> On wo, 2015-12-30 at 18:28 +0700, Duy Nguyen wrote:
> > On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen
> > wrote:
> > > On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
> > > wrote:
> > >> On wo, 2015-12-30 at 10:24 +0100, Denn
On wo, 2015-12-30 at 18:28 +0700, Duy Nguyen wrote:
> On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen
> wrote:
> > On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
> > wrote:
> >> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
> >>> spirit:~/code/git (master)$ cat .git/logs/HEAD
> >>>
On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen wrote:
> On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
> wrote:
>> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
>>> spirit:~/code/git (master)$ cat .git/logs/HEAD
>>> 2635c2b8bfc9aec07b7f023d8e3b3d02df715344
>>> 54bc41416c5d3ecb978
On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
wrote:
> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
>> spirit:~/code/git (master)$ cat .git/logs/HEAD
>> 2635c2b8bfc9aec07b7f023d8e3b3d02df715344
>> 54bc41416c5d3ecb978acb0df80d57aa3e54494c Dennis Kaarsemaker
>> 1446765642 +01
On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
> spirit:~/code/git (master)$ cat .git/logs/HEAD
> 2635c2b8bfc9aec07b7f023d8e3b3d02df715344
> 54bc41416c5d3ecb978acb0df80d57aa3e54494c Dennis Kaarsemaker
> 1446765642 +0100
> 74c855f87d25a5b5c12d0485ec77c785a1c734c5
> 54bc41416c5d3ec
On Wed, Dec 30, 2015 at 4:24 PM, Dennis Kaarsemaker
wrote:
> I've hit a segfault in git reflog with latest git, reproducable in git.git:
>
> spirit:~/code/git (master)$ ./git describe
> v2.7.0-rc3
>
> I've minimized the reflog to:
>
> spirit:~/code/git (master)$ cat .git/logs/HEAD
> 2635c2b8bfc9ae
Hi,
Ralf Thielow wrote:
> I've fetched from the current git.git on GitHub minutes ago and got a
> segfault. I could reproduce it with the Git version of the current "next"
> branch
> (1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with
> version 1.8.5.
Yep, I can reprodu
On Mon, Jul 15, 2013 at 4:03 PM, Michael Haggerty wrote:
> On 07/13/2013 03:27 PM, Mantas Mikulėnas wrote:
>> I have a clone of linux.git with various stuff added to it (remotes for
>> 'stable' and 'next', a bunch of local tags, and historical repositories
>> imported using `git replace`).
>>
>> Y
On 07/13/2013 03:27 PM, Mantas Mikulėnas wrote:
> I have a clone of linux.git with various stuff added to it (remotes for
> 'stable' and 'next', a bunch of local tags, and historical repositories
> imported using `git replace`).
>
> Yesterday, I noticed that `git describe`, built from git.git mast
On Mon, May 06, 2013 at 03:29:23PM +0100, John Keeping wrote:
> On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
> > Sure, here you go, this time built from the HEAD I found on github
> > (7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
> >
> > NO_GETTEXT=1 make prefix=/usr/local/
On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
> Sure, here you go, this time built from the HEAD I found on github
> (7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
>
> NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
> -g' install (this is homebrew's setu
Sure, here you go, this time built from the HEAD I found on github
(7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
-g' install (this is homebrew's setup, but I built it manually rather
than using the recipe.)
And the gdb outpu
On Mon, May 06, 2013 at 03:02:10PM +0200, Andreas Jacobsen wrote:
> I'm getting a segfault in git merge-tree using v1.8.2.2 on MacOS
> 10.8.3. I can't share the repo, but I can build patches and check if
> they fix the problem :)
Can you rebuild with debugging information and try the backtrace aga
On Wed, Apr 10, 2013 at 12:16:25PM -0700, rh wrote:
> > > This returns no error on the command line and produced the segfault
> > > reported by the kernel. git clone returns immediately.
> >
> > It does correctly report a failed exit code. The lack of message is
> > because git assumes that the h
On Wed, Apr 10, 2013 at 02:51:14PM -0400, Jeff King wrote:
> As for why dmesg reports git-remote-http, I'm not sure. If you "strace
> -f" the command, you can see that git is running git-remote-https. Why
> the kernel chooses to report "git-remote-http", I don't know; you'd have
> to look into how
On Wed, Apr 10, 2013 at 09:08:50AM -0700, rh wrote:
> > which should show both program names. Git invokes git-remote-* based
> > on the URL you fed it. So if you are seeing a segfault in
> > git-remote-http, presumably you fed it an http URL (which may still
> > execute SSL code if it redirects to
On Tue, Apr 09, 2013 at 12:40:44PM -0700, rh wrote:
> > does not support hardlinks or symlinks). But I'm not sure which error
> > you are talking about. We can figure out inside the program which
> > program was invoked by checking argv, but I do not see us printing
> > remote-http anywhere.
>
>
On Tue, Apr 09, 2013 at 10:41:34AM -0700, rh wrote:
> > git-remote-http does not touch the openssl code itself at all. We only
> > talk to curl, which handles all of the ssl (and may even be built on
> > gnutls). So if that is the problem, then I think it may be a libcurl
> > bug, not a git one.
>
On Tue, 9 Apr 2013, Jeff King wrote:
git-remote-http does not touch the openssl code itself at all. We only talk
to curl, which handles all of the ssl (and may even be built on gnutls). So
if that is the problem, then I think it may be a libcurl bug, not a git one.
... and if/when you do make
On Tue, Apr 09, 2013 at 08:47:18AM -0700, rh wrote:
> The symptoms that this patch addresses look similar:
>
> http://article.gmane.org/gmane.mail.postfix.user/217790
>
> Quote from that thread:
> "This behavior is actually documented (SSL_set_fd() destroys
> a BIO already on the SSL handle, and
On 27/03/13 20:01, Jeff King wrote:
On Wed, Mar 27, 2013 at 07:45:21PM +, John Keeping wrote:
On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:
Charlie Smurthwaite writes:
Yes, I would need to be able to do this on a bare repo for my use case.
And if it's on the server, you do
John Keeping writes:
> You could use a temporary index and do something like:
>
> rm -f TMP_INDEX
> GIT_INDEX_FILE=TMP_INDEX
> export GIT_INDEX_FILE
> git read-tree -m $base $ours $theirs &&
> git merge-index git-merge-one-file -a
>
> then inspect that with "git diff
On Wed, Mar 27, 2013 at 07:45:21PM +, John Keeping wrote:
> On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:
> > Charlie Smurthwaite writes:
> >
> > > Yes, I would need to be able to do this on a bare repo for my use case.
> >
> > And if it's on the server, you don't want this to
On Wed, Mar 27, 2013 at 02:16:24PM -0500, Jed Brown wrote:
> Charlie Smurthwaite writes:
>
> > Yes, I would need to be able to do this on a bare repo for my use case.
>
> And if it's on the server, you don't want this to be observable, so
> you don't want HEAD to move around. I don't know a bet
Charlie Smurthwaite writes:
> Yes, I would need to be able to do this on a bare repo for my use case.
And if it's on the server, you don't want this to be observable, so
you don't want HEAD to move around. I don't know a better way than:
$ git clone --shared -b upstream-branch bare-repo.git
On 27/03/13 18:06, Jed Brown wrote:
Charlie Smurthwaite writes:
I am also using this to obtain a diff that would be applied if a merge
were to be run. Is there a better way to obtain this information that is
more commonly used?
You can do an actual merge using detached HEAD:
$ git checkou
Charlie Smurthwaite writes:
> I am also using this to obtain a diff that would be applied if a merge
> were to be run. Is there a better way to obtain this information that is
> more commonly used?
You can do an actual merge using detached HEAD:
$ git checkout --detach upstream-branch
$ g
On 27/03/13 17:06, Junio C Hamano wrote:
Charlie Smurthwaite writes:
I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945
On 27/03/13 17:06, Junio C Hamano wrote:
Charlie Smurthwaite writes:
I am experiencing a segmentation fault in various versions of Git using
different repositories.
...
Test Command
git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
8d6bdf012941d876b2279994e02f1bb0d5c26e7d
d5ef97ac407d945
Charlie Smurthwaite writes:
> I am experiencing a segmentation fault in various versions of Git using
> different repositories.
> ...
> Test Command
> git merge-tree 26bb22a052fef9f74063afd4fc6fc11fe200b19f
> 8d6bdf012941d876b2279994e02f1bb0d5c26e7d
> d5ef97ac407d945f231cd7c8fb1cfe48b3a12083
Tha
John Keeping writes:
> Looks like a simple typo in merge-tree.c::unresolved:
Thanks.
>
> -- >8 --
> merge-tree: fix typo in merge-tree.c::unresolved
>
> When calculating whether there is a d/f conflict, the calculation of
> whether both sides are directories generates an incorrect references
>
John Keeping writes:
> merge-tree: fix typo in merge-tree.c::unresolved
>
> When calculating whether there is a d/f conflict, the calculation of
> whether both sides are directories generates an incorrect references
> mask because it does not use the loop index to set the correct bit.
> Fix this
On Wed, Mar 27, 2013 at 04:53:27PM +0100, thomas wrote:
> Charlie Smurthwaite writes:
>
> > I am experiencing a segmentation fault in various versions of Git using
> > different repositories. Specifically, I have reproduced it using a
> > public repo and the latest stable Git version. Other repos
Charlie Smurthwaite writes:
> I am experiencing a segmentation fault in various versions of Git using
> different repositories. Specifically, I have reproduced it using a
> public repo and the latest stable Git version. Other repos trigger the
> error on different versions.
>
> Full info can be f
On Saturday 09 March 2013 13.16:35 Junio C Hamano wrote:
> Strasser Pablo writes:
> > I segfault with the following command:
> >
> > git checkout HEAD~1
> > git branch -u origin/master
>
> A patch to address this in cooking in 'next', and is expected to be
> in 1.8.2.1 or later.
Ok thanks.
--
T
Strasser Pablo writes:
> I segfault with the following command:
>
> git checkout HEAD~1
> git branch -u origin/master
A patch to address this in cooking in 'next', and is expected to be
in 1.8.2.1 or later.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
On za, 2013-03-09 at 21:16 +0100, Strasser Pablo wrote:
> Hello,
>
> I segfault with the following command:
>
> git checkout HEAD~1
> git branch -u origin/master
>
> I think it's because i'm in detached head.
> A error message like cannot use this command in would be a better responce
> than a
Jeff King writes:
> On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > Jeff King writes:
>> >
>> >> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>> >>
>> >>> > Yeah, that actually is a good point. We should be using
>> >>> >
On Mon, Feb 11, 2013 at 12:36:52PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Jeff King writes:
> >
> >> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> >>
> >>> > Yeah, that actually is a good point. We should be using logmsg_reencode
> >>> > so that we look
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>>
>>> > Yeah, that actually is a good point. We should be using logmsg_reencode
>>> > so that we look for strings in the user's encoding.
>>>
>>> Perhaps like this. Just like the p
Jeff King writes:
> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>
>> > Yeah, that actually is a good point. We should be using logmsg_reencode
>> > so that we look for strings in the user's encoding.
>>
>> Perhaps like this. Just like the previous one (which should be
>> di
On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> > Yeah, that actually is a good point. We should be using logmsg_reencode
> > so that we look for strings in the user's encoding.
>
> Perhaps like this. Just like the previous one (which should be
> discarded), this makes the fun
On Fri, Feb 08, 2013 at 08:05:24PM -0500, Jeff King wrote:
> On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
>
> > > Yeah, that actually is a good point. We should be using logmsg_reencode
> > > so that we look for strings in the user's encoding.
> >
> > Perhaps like this. Just
On Fri, Feb 08, 2013 at 04:47:01PM -0800, Junio C Hamano wrote:
> > Yeah, that actually is a good point. We should be using logmsg_reencode
> > so that we look for strings in the user's encoding.
>
> Perhaps like this. Just like the previous one (which should be
> discarded), this makes the fun
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
>>
>>> Junio C Hamano writes:
>>>
>>> > Thomas Haller writes:
>>> >
>>> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>> >>
>>> >> retval
Jeff King writes:
> On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>> > Thomas Haller writes:
>> >
>> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
>> >>
>> >> retval = grep_buffer(&opt->grep_filter,
>> >
On Fri, Feb 08, 2013 at 04:29:11PM -0800, Junio C Hamano wrote:
> Perhaps something along this line...
>
> -- >8 --
> Subject: "log --grep": commit's buffer may already have been discarded
>
> Following up on be5c9fb9049e (logmsg_reencode: lazily load missing
> commit buffers, 2013-01-26), extra
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Thomas Haller writes:
>>
>>> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>>
>>> retval = grep_buffer(&opt->grep_filter,
>>> commit->buffer,
>>> strlen(commit->buf
On Fri, Feb 08, 2013 at 04:22:15PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thomas Haller writes:
> >
> >> it happens in file revision.c:2306 because "commit->buffer" is zero:
> >>
> >> retval = grep_buffer(&opt->grep_filter,
> >>
Junio C Hamano writes:
> Thomas Haller writes:
>
>> it happens in file revision.c:2306 because "commit->buffer" is zero:
>>
>> retval = grep_buffer(&opt->grep_filter,
>> commit->buffer, strlen(commit->buffer));
>
> I think this has been fixed
Thomas Haller writes:
> it happens in file revision.c:2306 because "commit->buffer" is zero:
>
> retval = grep_buffer(&opt->grep_filter,
> commit->buffer, strlen(commit->buffer));
I think this has been fixed at be5c9fb9049e (logmsg_reencode: l
76 matches
Mail list logo
