On Tue, Oct 22, 2013 at 2:02 AM, Johannes Sixt wrote:
>> (or maybe at higher level to skip checking out those paths).
>
> More like this, yeah.
The good thing is we do not stop checking out if one entry fails. But
due to the lack of worktree entries, one may accidentally remove files
in new commi
On Mon, Oct 21, 2013 at 03:14:39PM -0400, Jeff King wrote:
> On Mon, Oct 21, 2013 at 09:07:26PM +0200, Erik Faye-Lund wrote:
>
> > I would argue that this is probably even a bug on Linux, only harder
> > (if not impossible) to trigger by accident as there's probably no
> > git-client that will ge
On Mon, Oct 21, 2013 at 09:07:26PM +0200, Erik Faye-Lund wrote:
> I would argue that this is probably even a bug on Linux, only harder
> (if not impossible) to trigger by accident as there's probably no
> git-client that will generate such trees. But a "malicious" client
> might.
I've just been p
On Mon, Oct 21, 2013 at 9:02 PM, Johannes Sixt wrote:
> Am 21.10.2013 03:31, schrieb Duy Nguyen:
>> On Mon, Oct 21, 2013 at 12:57 AM, Antoine Pelisse wrote:
>>> My main motive was to not *stop* the process when a long path is met.
>>> Because somebody created a repository on Linux with a long fil
Am 21.10.2013 03:31, schrieb Duy Nguyen:
> On Mon, Oct 21, 2013 at 12:57 AM, Antoine Pelisse wrote:
>> My main motive was to not *stop* the process when a long path is met.
>> Because somebody created a repository on Linux with a long file-name
>> doesn't mean you should not be able to clone it *a
On Mon, Oct 21, 2013 at 12:57 AM, Antoine Pelisse wrote:
> My main motive was to not *stop* the process when a long path is met.
> Because somebody created a repository on Linux with a long file-name
> doesn't mean you should not be able to clone it *at all* on Windows.
That should be handled at
My main motive was to not *stop* the process when a long path is met.
Because somebody created a repository on Linux with a long file-name
doesn't mean you should not be able to clone it *at all* on Windows.
On Sun, Oct 20, 2013 at 12:33 PM, Duy Nguyen wrote:
> On Sun, Oct 20, 2013 at 12:47 PM, T
On Sun, Oct 20, 2013 at 12:47 PM, Torsten Bögershausen wrote:
> I'm not sure how to handle overlong path in general, there are several ways:
> a) Silently overwrite memory (with help of memcpy() and/or strcpy()
> b) Silently shorten the path using strlcpy() instead of strcpy()
> c) Avoid the overw
On Sun, Oct 20, 2013 at 08:27:13AM +0200, Torsten Bögershausen wrote:
> Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
> popelka.ms.mff.cuni.cz
> Status: O
> Content-Length: 2690
> Lines: 89
>
> On 20.10.13 08:05, Ondřej Bílka wrote:
> > On Sun, Oct 20, 2013 at 07:47:06AM +0200, To
On 20.10.13 08:05, Ondřej Bílka wrote:
> On Sun, Oct 20, 2013 at 07:47:06AM +0200, Torsten Bögershausen wrote:
>> (may be s/path is too big/path is too long/ ?)
>>
>> On 19.10.13 12:52, Antoine Pelisse wrote:
>>> Currently, most buffers created with PATH_MAX length, are not checked
>>> when being w
On Sun, Oct 20, 2013 at 07:47:06AM +0200, Torsten Bögershausen wrote:
> (may be s/path is too big/path is too long/ ?)
>
> On 19.10.13 12:52, Antoine Pelisse wrote:
> > Currently, most buffers created with PATH_MAX length, are not checked
> > when being written, and can overflow if PATH_MAX is not
(may be s/path is too big/path is too long/ ?)
On 19.10.13 12:52, Antoine Pelisse wrote:
> Currently, most buffers created with PATH_MAX length, are not checked
> when being written, and can overflow if PATH_MAX is not big enough to
> hold the path.
>
> Fix that by using strlcpy() where strcpy()
12 matches
Mail list logo