* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-10 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801101208500.3148@woody.linux-foundation.org>
On 10/1/08 20:20, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
> - Mixed windows usage - either with other UNIX users, or even just
> *within* a windows environment if *some* of the tools are basically
> UNIX ports (ie MinGW or Cygwin without text-mounts)
>
> In this case, some tools will write files with CRLF, and others will
> write them with LF. Again, usually all tools can *read* either form,
> but the writing is mixed and depends on the tool (so if you work in a
> group where different people use different editors, you will literally
> switch back-and-forth between LF and CRLF, sometimes mixing the two in
> the same file!).
>
> This one - at the very least - basically requires "autocrlf=input".
> Anything else is just madness, because otherwise you'll get files that
> get partly or entirely rewritten in the object database just due to
> line ending changes.
So this is what has to be accommodated. But instead of having autocrlf
always set on Windows and always converting to LF in the repository, why not
do nothing by default unless the repository contains some information
specifying that it wants some or all text files to have a particular kind of
line ending (e.g. in gitattributes). Then the choice of line ending inside
the repository is up to the people creating/maintaining the repo, which just
seems right.
Insisting that repos created on windows should have textfiles munged to LF
by default doesn't seem right. Even using Dmitry's clever autocrlf=safe
option on Windows would lead to inconvenience since all LF files have to be
explicitly attributed as text. We should be helping Windows people to use
LF files rather than hindering them!
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-10 21:15 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <47868530.2010501@dawes.za.net>
On 10/1/08 20:50, "Rogan Dawes" <lists@dawes.za.net> wrote:
> Gregory Jefferis wrote:
>> Isn't plain git functionally agnostic about line endings? You can
>> check in CRLF text files to git and it doesn't care. You can diff, show etc
>> just fine. I haven't yet found anything that breaks with CRLF files. In
>> this sense plain git is already Windows ready. Maybe I'm missing something?
>
> One example that bit me recently was "git-apply --whitespace=strip"
>
> I have files with CRLF in my repo, but git was stripping the CR from
> lines that I applied via a patch.
>
> I worked around it with a smudge/clean filter of "dos2unix | unix2dos"
> (first removes all CR's, second puts one back on each line)
>
> Rogan
OK so that's interesting. Is it a case where core git is not crlf agnostic?
Looks like CR is being considered whitespace. I think git diff
--ignore-space-at-eol also works because CR is considered whitespace. Maybe
that's the wrong behaviour.
So the big question for me. Should git expect that text files inside a
repository have to have LF only line endings? I don't think that it should,
but should accommodate both CRLF and LF. I guess at the moment git normally
accommodates CRLF files because they look like an LF file that happens to
have a funky whitespace char in front of the LFs. Maybe it would be better
if edge cases like the one you described were ironed out.
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Dennis Schridde @ 2008-01-10 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7v63y178a3.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]
Am Donnerstag, 10. Januar 2008 21:08:52 schrieb Junio C Hamano:
> Dennis Schridde <devurandom@gmx.net> writes:
> >> [svn-remote "svn"]
> >> reposRoot = file:///var/svn/warzone2100
> >> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
> >> branches-maxRev = 14
> >> tags-maxRev = 14
> >> svnsync-uuid = 4a71c877-e1ca-e34f-864e-861f7616d084\n
> >> svnsync-url = http://svn.gna.org/svn/warzone
> >> [svn-remote "tags/1.10a.12"]
> >> reposRoot = file:///var/svn/warzone2100
> >> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
> >> ---
> >
> > The rest of the file is rather boring. The "svn" remote is not changed
> > (besides having higher revisions) and the other remotes look exactly like
> > the "tags/1.10a.12" one.
> >
> > Somehow I think that the \n at the end of the svnsync-uuid shouldn't be
> > there... It could be that this is the same linebreak which prevents
> > people from relocating (svn switch --relocate) from
> > svn://svn.gna.org/svn/warzone to http://svn.gna.org/svn/warzone, so that
> > would be a Gna bug.
> > However git-svn shouldn't throw any warnings (or even (make perl) crash?)
> > on such occasions, either...
> >
> > I now got it to run through without a segfault, by compiling an unstriped
> > perl binary with debug symbols (Gentoo: FEATURES=nostrip CFLAGS="...
> > -g"). Maybe this is a bug in GCC or something...
> >
> > The "Odd number of elements in anonymous hash" still stays, though.
>
> The code in question is:
>
> my $svnsync;
> # see if we have it in our config, first:
> eval {
> my $section = "svn-remote.$self->{repo_id}";
> $svnsync = {
> url => tmp_config('--get', "$section.svnsync-url"),
> uuid => tmp_config('--get', "$section.svnsync-uuid"),
> }
> };
>
> I think the "Odd number" is an indication that one of the
> tmp_config() calls is returning an even number of elements (so
> the hash whose ref will be stored in $svnsync ends up having an
> odd number of elements), and that is why I initially asked you
> about "more than one" svnsync-url. 0 is also an even number,
> and it could be that it is not finding any.
>
> How about doing something ugly like this _just for diagnosis_?
>
> my $svnsync;
> # see if we have it in our config, first:
> eval {
> my $section = "svn-remote.$self->{repo_id}";
> my @u = tmp_config('--get', "$section.svnsync-url");
> my @v = tmp_config('--get', "$section.svnsync-uuid");
> if (@u != 1 || @v != 1) {
> print STDERR "Oops: <$section> $#u <@u> $#v <@v>\n";
> }
> $svnsync = {
> url => @u,
> uuid => @v,
> }
> };
I've created /usr/bin/git-svndbg and changed that part, like you proposed.
I now get this output. (As it continues to run, there are probably more
occassions of the Oops.)
---
Oops: <svn-remote.svn> 0 <http://svn.gna.org/svn/warzone> 1
<4a71c877-e1ca-e34f-864e-861f7616d084 >
Odd number of elements in anonymous hash at /usr/bin/git-svndbg line 1768.
r13 = ee6d5a48dd5cf1a96ed5217d638f372d2c173d89 (tags/1.10a)
---
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 5/5] Use new decompress helpers in sha1_file.c
From: Marco Costalba @ 2008-01-10 21:09 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
sha1_file.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 6583797..2a76043 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -7,6 +7,7 @@
* creation etc.
*/
#include "cache.h"
+#include "compress.h"
#include "delta.h"
#include "pack.h"
#include "blob.h"
@@ -2086,25 +2087,19 @@ int write_sha1_file(void *buf, unsigned long
len, const char *type, unsigned cha
}
/* Set it up */
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, zlib_compression_level);
- size = 8 + deflateBound(&stream, len+hdrlen);
+ size = 8 + z_deflate_init(&stream, zlib_compression_level, len+hdrlen);
compressed = xmalloc(size);
/* Compress it */
- stream.next_out = compressed;
- stream.avail_out = size;
+ z_deflate_start(&stream, (unsigned char *)hdr, hdrlen, compressed, size);
/* First header.. */
- stream.next_in = (unsigned char *)hdr;
- stream.avail_in = hdrlen;
- while (deflate(&stream, 0) == Z_OK)
- /* nothing */;
+ z_deflate_next(&stream, Z_NO_FLUSH);
/* Then the data itself.. */
stream.next_in = buf;
stream.avail_in = len;
- ret = deflate(&stream, Z_FINISH);
+ ret = z_deflate_next(&stream, Z_FINISH);
if (ret != Z_STREAM_END)
die("unable to deflate new object %s (%d)", sha1_to_hex(sha1), ret);
--
1.5.4.rc2.89.g1b3f
^ permalink raw reply related
* [PATCH 4/5] Use new decompress helpers in http-push.c
From: Marco Costalba @ 2008-01-10 21:08 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
http-push.c | 18 +++++++-----------
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/http-push.c b/http-push.c
index 55d0c94..03b2615 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "commit.h"
+#include "compress.h"
#include "pack.h"
#include "tag.h"
#include "blob.h"
@@ -491,27 +492,22 @@ static void start_put(struct transfer_request
hdrlen = sprintf(hdr, "%s %lu", typename(type), len) + 1;
/* Set it up */
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, zlib_compression_level);
- size = deflateBound(&stream, len + hdrlen);
+ size = z_deflate_init(&stream, zlib_compression_level, len + hdrlen);
strbuf_init(&request->buffer.buf, size);
request->buffer.posn = 0;
/* Compress it */
- stream.next_out = (unsigned char *)request->buffer.buf.buf;
- stream.avail_out = size;
+ z_deflate_start(&stream, (void *)hdr, hdrlen,
+ (unsigned char *)request->buffer.buf.buf, size);
/* First header.. */
- stream.next_in = (void *)hdr;
- stream.avail_in = hdrlen;
- while (deflate(&stream, 0) == Z_OK)
- /* nothing */;
+ z_deflate_next(&stream, Z_NO_FLUSH);
/* Then the data itself.. */
stream.next_in = unpacked;
stream.avail_in = len;
- while (deflate(&stream, Z_FINISH) == Z_OK)
- /* nothing */;
+ z_deflate_next(&stream, Z_FINISH);
+
deflateEnd(&stream);
free(unpacked);
--
1.5.4.rc2.89.g1b3f
^ permalink raw reply related
* [PATCH 3/5] Use new decompress helpers in index-pack.c
From: Marco Costalba @ 2008-01-10 21:07 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
index-pack.c | 20 +++-----------------
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 9fd6982..3c4ea51 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "compress.h"
#include "delta.h"
#include "pack.h"
#include "csum-file.h"
@@ -494,24 +495,9 @@ static void parse_pack_objects(unsigned char *sha1)
static int write_compressed(int fd, void *in, unsigned int size,
uint32_t *obj_crc)
{
- z_stream stream;
- unsigned long maxsize;
- void *out;
+ unsigned char *out = NULL;
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, zlib_compression_level);
- maxsize = deflateBound(&stream, size);
- out = xmalloc(maxsize);
-
- /* Compress it */
- stream.next_in = in;
- stream.avail_in = size;
- stream.next_out = out;
- stream.avail_out = maxsize;
- while (deflate(&stream, Z_FINISH) == Z_OK);
- deflateEnd(&stream);
-
- size = stream.total_out;
+ size = z_deflate_all(zlib_compression_level, in, size, &out);
write_or_die(fd, out, size);
*obj_crc = crc32(*obj_crc, out, size);
free(out);
--
1.5.4.rc2.89.g1b3f
^ permalink raw reply related
* [PATCH 2/5] Use new decompress helpers in diff.c
From: Marco Costalba @ 2008-01-10 21:06 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
diff.c | 22 +++++-----------------
1 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/diff.c b/diff.c
index b18c140..ecfa721 100644
--- a/diff.c
+++ b/diff.c
@@ -2,6 +2,7 @@
* Copyright (C) 2005 Junio C Hamano
*/
#include "cache.h"
+#include "compress.h"
#include "quote.h"
#include "diff.h"
#include "diffcore.h"
@@ -1037,23 +1038,10 @@ static unsigned char *deflate_it(char *data,
unsigned long size,
unsigned long *result_size)
{
- int bound;
- unsigned char *deflated;
- z_stream stream;
-
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, zlib_compression_level);
- bound = deflateBound(&stream, size);
- deflated = xmalloc(bound);
- stream.next_out = deflated;
- stream.avail_out = bound;
-
- stream.next_in = (unsigned char *)data;
- stream.avail_in = size;
- while (deflate(&stream, Z_FINISH) == Z_OK)
- ; /* nothing */
- deflateEnd(&stream);
- *result_size = stream.total_out;
+ unsigned char *deflated = NULL;
+
+ *result_size = z_deflate_all(zlib_compression_level,
+ (unsigned char *)data, size, &deflated);
return deflated;
}
--
1.5.4.rc2.89.g1b3f
^ permalink raw reply related
* [PATCH 1/5] Add zlib decompress helper functions
From: Marco Costalba @ 2008-01-10 21:04 UTC (permalink / raw)
To: Git Mailing List
When decompressing a zlib stream use this
helpers instead of calling low level zlib
function.
This patch introduces the necessary framework,
still no code change.
This is the first step in generalizing compress and
decompress functions avoiding zlib directly calls.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Makefile | 4 ++--
compress.c | 52 ++++++++++++++++++++++++++
compress.h | 14 ++++++++++++++
3 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 compress.c
create mode 100644 compress.h
diff --git a/Makefile b/Makefile
index 21c80e6..89bd99d 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,7 @@ LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
LIB_H = \
- archive.h blob.h cache.h cache-tree.h commit.h csum-file.h delta.h grep.h \
+ archive.h blob.h cache.h cache-tree.h commit.h compress.h
csum-file.h delta.h grep.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h list-objects.h sideband.h \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
@@ -301,7 +301,7 @@ DIFF_OBJS = \
diffcore-delta.o log-tree.o
LIB_OBJS = \
- blob.o commit.o connect.o csum-file.o cache-tree.o base85.o \
+ blob.o commit.o compress.o connect.o csum-file.o cache-tree.o base85.o \
date.o diff-delta.o entry.o exec_cmd.o ident.o \
pretty.o interpolate.o hash.o \
lockfile.o \
diff --git a/compress.c b/compress.c
new file mode 100644
index 0000000..f40e09c
--- /dev/null
+++ b/compress.c
@@ -0,0 +1,52 @@
+#include "cache.h"
+#include "compress.h"
+
+unsigned long z_deflate_init(z_stream *stream, int level, unsigned long size)
+{
+ memset(stream, 0, sizeof(*stream));
+ deflateInit(stream, level);
+ return deflateBound(stream, size);
+}
+
+int z_deflate_start(z_stream *stream, unsigned char *in, unsigned long in_size,
+ unsigned char *out, unsigned long out_size)
+{
+ stream->next_out = (out ? out : xmalloc(out_size));
+ stream->avail_out = out_size;
+ stream->next_in = in;
+ stream->avail_in = in_size;
+ return Z_OK;
+}
+
+int z_deflate_next(z_stream *stream, int flush)
+{
+ int result;
+
+ do {
+ result = deflate(stream, flush);
+ } while (result == Z_OK);
+
+ return result;
+}
+
+unsigned long z_deflate_all(int level, unsigned char *data,
+ unsigned long size, unsigned char **out)
+{
+ int bound, result;
+ z_stream stream;
+
+ bound = z_deflate_init(&stream, level, size);
+ z_deflate_start(&stream, data, size, NULL, bound);
+
+ *out = stream.next_out;
+ result = z_deflate_next(&stream, Z_FINISH);
+
+ if (result != Z_STREAM_END) {
+ deflateEnd(&stream);
+ free(*out);
+ *out = NULL;
+ return 0;
+ }
+ deflateEnd(&stream);
+ return stream.total_out;
+}
diff --git a/compress.h b/compress.h
new file mode 100644
index 0000000..926450c
--- /dev/null
+++ b/compress.h
@@ -0,0 +1,14 @@
+#ifndef COMPRESS_H
+#define COMPRESS_H
+
+extern unsigned long z_deflate_init(z_stream *stream, int level,
unsigned long size);
+
+extern int z_deflate_start(z_stream *stream, unsigned char *in,
unsigned long in_size,
+ unsigned char *out, unsigned long out_size);
+
+extern int z_deflate_next(z_stream *stream, int flush);
+
+extern unsigned long z_deflate_all(int level, unsigned char *data,
+ unsigned long size, unsigned char **out);
+
+#endif
--
1.5.4.rc2.89.g1b3f
^ permalink raw reply related
* Re: Decompression speed: zip vs lzo
From: Linus Torvalds @ 2008-01-10 21:01 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pierre Habouzit, Sam Vilain, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101332150.3054@xanadu.home>
On Thu, 10 Jan 2008, Nicolas Pitre wrote:
>
> Here's my rather surprising results:
>
> My kernel repo pack size without the patch: 184275401 bytes
> Same repo with the above patch applied: 205204930 bytes
>
> So it is only 11% larger. I was expecting much more.
It's probably worth doing those statistics on some other projects.
The kernel has for the last five+ years very much encouraged people to
make series of small changes, so I would not be surprised if it turns out
that the deltas for the kernel are smaller than average, if only because
the whole development process has encouraged people to send in a series of
ten patches rather than a single larger one.
And there are basically *no* generated files in the kernel source repo.
Maybe the difference to other repositories isn't huge, and maybe the
kernel *is* a good test-case, but I just wouldn't take that for granted.
Yes, delta's are bound to compress much less well than non-deltas, and
especially for tree objects (which is a large chunk of them) they probably
compress even less (because a big part of the delta is actually just the
SHA1 changes), but if it's 11% on the kernel, it could easily be 25% on
something else.
Try with the gcc repo, especially the one that has deep delta chains (so
it has even *more* deltas in relation to full objects than the kernel has)
Linus
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Rogan Dawes @ 2008-01-10 20:50 UTC (permalink / raw)
To: Gregory Jefferis; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <C3AC2971.10D2D%jefferis@gmail.com>
Gregory Jefferis wrote:
> I'm not sure that I understand the whole deal about platform default line
> endings. Isn't plain git functionally agnostic about line endings? You can
> check in CRLF text files to git and it doesn't care. You can diff, show etc
> just fine. I haven't yet found anything that breaks with CRLF files. In
> this sense plain git is already Windows ready. Maybe I'm missing something?
>
> Doesn't the problem only come if you try to diff a CRLF file with a new
> version that has LF only line endings? Then right now you have to use
> something like:
>
> git diff --ignore-space-at-eol
>
> In conclusion all of these CRLF options are designed to help Windows users
> play nicely with others. But it seems to me naïve Windows users can be
> perfectly happy with plain git so long as they stay in their own Windows
> world.
>
> jm2c, corrections welcome and apologies to those suffering from eol
> exhaustion,
>
> Greg.
One example that bit me recently was "git-apply --whitespace=strip"
I have files with CRLF in my repo, but git was stripping the CR from
lines that I applied via a patch.
I worked around it with a smudge/clean filter of "dos2unix | unix2dos"
(first removes all CR's, second puts one back on each line)
Rogan
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-10 20:39 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Sam Vilain, Git Mailing List, Johannes Schindelin, Marco Costalba,
Junio C Hamano
In-Reply-To: <20080110091607.GA17944@artemis.madism.org>
On Thu, 10 Jan 2008, Pierre Habouzit wrote:
> Well, lzma is excellent for *big* chunks of data, but not that impressive for
> small files:
>
> $ ll git.c git.c.gz git.c.lzma git.c.lzop
> -rw-r--r-- 1 madcoder madcoder 12915 2008-01-09 13:47 git.c
> -rw-r--r-- 1 madcoder madcoder 4225 2008-01-10 10:00 git.c.gz
> -rw-r--r-- 1 madcoder madcoder 4094 2008-01-10 10:00 git.c.lzma
> -rw-r--r-- 1 madcoder madcoder 5068 2008-01-10 09:59 git.c.lzop
This is really the big point here. Git uses _lots_ of *small* objects,
usually much smaller than 12KB. For example, my copy of the gcc
repository has an average of 270 _bytes_ per compressed object, and
objects must be individually compressed.
Performance with really small objects should be the basis for any
Git compression algorithm comparison.
> Though I don't agree with you (and some others) about the fact that
> gzip is fast enough. It's clearly a bottleneck in many log related
> commands where you would expect it to be rather IO bound than CPU
> bound. LZO seems like a fairer choice, especially since what it makes
> gain is basically the compression of the biggest blobs, aka the delta
> chains heads.
The delta heads, though, are far from being the most frequently accessed
objects. First they're clearly in minority, and often cached in the
delta base cache.
> It's really unclear to me if we really gain in
> compressing the deltas, trees, and other smallish informations.
Remember that delta objects represent the vast majority of all objects.
For example, my kernel repo currently has 555015 delta objects out of
677073 objects, or 82% of the total. There is actually only 25869 non
deltified blob objects which are likely to be the larger objects, but
they represent only 4% of the total.
But just let's try not compressing delta objects so to check your
assertion with the following hack:
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index a39cb82..252b03e 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -433,7 +433,10 @@ static unsigned long write_object(struct sha1file *f,
}
/* compress the data to store and put compressed length in datalen */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, pack_compression_level);
+ if (obj_type == OBJ_REF_DELTA || obj_type == OBJ_OFS_DELTA)
+ deflateInit(&stream, 0);
+ else
+ deflateInit(&stream, pack_compression_level);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
/* Compress it */
You then only need to run 'git repack -a -f -d' with and without the
above patch.
Here's my rather surprising results:
My kernel repo pack size without the patch: 184275401 bytes
Same repo with the above patch applied: 205204930 bytes
So it is only 11% larger. I was expecting much more.
I'll let someone else do profiling/timing comparisons.
> What is obvious to me is that lzop seems to take 10% more space than gzip,
> while being around 1.5 to 2 times faster. Of course this is very sketchy and a
> real test with git will be better.
Right. Abstracting the zlib code and having different compression
algorithms tested in the Git context is the only way to do meaningful
comparisons.
Nicolas
^ permalink raw reply related
* Re: [PATCH] gitweb: Change feeds from commit to commitdiff output.
From: Junio C Hamano @ 2008-01-10 20:21 UTC (permalink / raw)
To: Florian La Roche; +Cc: git
In-Reply-To: <20080110130900.GA9395@dudweiler.stuttgart.redhat.com>
Florian La Roche <laroche@redhat.com> writes:
> [PATCH] gitweb: Change feeds from commit to commitdiff output.
>
> Change feeds from displaying the commit to displaying the commitdiff
> output. This way the patches are shown directly and code review is
> done more easily via watching feeds.
>
> Signed-off-by: Florian La Roche <laroche@redhat.com>
I can see that easier access to commitdiff output is sometimes
desirable.
If you are making this change unconditional, however, I think
there needs a list discussion between you and the silent
majority of people that have been perfectly happy with the
current "log only" behaviour.
And to have that discussion, you first have to wake them up,
which this patch would serve well as a wake-up call. But if
that was the purpose of the posting, please (1) mark the patch
as such (commonly done by saying [RFC/PATCH] instead), and (2)
keep me out of the "To:" list, if the patch is not for inclusion
but for discussion ("cc:" is fine but it's redundant as long as
you are sending to the list).
After such a discussion, we may end up finding out that
everybody have been silently unhappy and wanted to have
commitdiff there, and agree on doing this unconditionally.
But we do not know that yet.
Thanks.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-10 20:20 UTC (permalink / raw)
To: Gregory Jefferis; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <C3AC2971.10D2D%jefferis@gmail.com>
On Thu, 10 Jan 2008, Gregory Jefferis wrote:
>
> I'm not sure that I understand the whole deal about platform default line
> endings. Isn't plain git functionally agnostic about line endings? You can
> check in CRLF text files to git and it doesn't care. You can diff, show etc
> just fine. I haven't yet found anything that breaks with CRLF files. In
> this sense plain git is already Windows ready. Maybe I'm missing something?
If you work together with other people on other platforms, then CRLF is a
major pain in the *ss.
So you have various options:
- only develop on unix-like platforms: lines end with LF, and nobody has
any problems regardless of autocrlf behaviour. Might as well consider
everything binary.
- only develop on windows, using only one set of basic tools: lines
normally end with CRLF, and nobody cares. Migth as well consider
everything binary.
- Mixed windows/unix platfoms, but the Windows people are constrained to
use only tools that write text-files with LF. Might we well consider
everything binary.
Quite frankly, Johannes seems to argue that this is a viable
alternative, but I seriously doubt that is really true. Yes, there are
lots of Windows tools (pretty much all of them by now, I suspect) that
*understand* LF-only line endings, but it's also undoubtedly the case
that if you allow windows developers to use their normal tools, a
number of them *will* write files with CRLF.
- Mixed windows usage - either with other UNIX users, or even just
*within* a windows environment if *some* of the tools are basically
UNIX ports (ie MinGW or Cygwin without text-mounts)
In this case, some tools will write files with CRLF, and others will
write them with LF. Again, usually all tools can *read* either form,
but the writing is mixed and depends on the tool (so if you work in a
group where different people use different editors, you will literally
switch back-and-forth between LF and CRLF, sometimes mixing the two in
the same file!).
This one - at the very least - basically requires "autocrlf=input".
Anything else is just madness, because otherwise you'll get files that
get partly or entirely rewritten in the object database just due to
line ending changes.
So in *most* of the situations, you probably don't need to worry about
autocrlf. But the thing is, I'm almost 100% convinced that the moment you
have even *one* windows developer, and any UNIX experience at all (whether
due to people actually working on unix, or just using unixy tools under
Windows), you will end up in that final case that really does want
autocrlf.
Linus
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Junio C Hamano @ 2008-01-10 20:08 UTC (permalink / raw)
To: Dennis Schridde; +Cc: Eric Wong, git
In-Reply-To: <200801101813.45938.devurandom@gmx.net>
Dennis Schridde <devurandom@gmx.net> writes:
>> [svn-remote "svn"]
>> reposRoot = file:///var/svn/warzone2100
>> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
>> branches-maxRev = 14
>> tags-maxRev = 14
>> svnsync-uuid = 4a71c877-e1ca-e34f-864e-861f7616d084\n
>> svnsync-url = http://svn.gna.org/svn/warzone
>> [svn-remote "tags/1.10a.12"]
>> reposRoot = file:///var/svn/warzone2100
>> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
>> ---
> The rest of the file is rather boring. The "svn" remote is not changed
> (besides having higher revisions) and the other remotes look exactly like
> the "tags/1.10a.12" one.
>
> Somehow I think that the \n at the end of the svnsync-uuid shouldn't be
> there... It could be that this is the same linebreak which prevents people
> from relocating (svn switch --relocate) from svn://svn.gna.org/svn/warzone to
> http://svn.gna.org/svn/warzone, so that would be a Gna bug.
> However git-svn shouldn't throw any warnings (or even (make perl) crash?) on
> such occasions, either...
>
> I now got it to run through without a segfault, by compiling an unstriped perl
> binary with debug symbols (Gentoo: FEATURES=nostrip CFLAGS="... -g").
> Maybe this is a bug in GCC or something...
>
> The "Odd number of elements in anonymous hash" still stays, though.
The code in question is:
my $svnsync;
# see if we have it in our config, first:
eval {
my $section = "svn-remote.$self->{repo_id}";
$svnsync = {
url => tmp_config('--get', "$section.svnsync-url"),
uuid => tmp_config('--get', "$section.svnsync-uuid"),
}
};
I think the "Odd number" is an indication that one of the
tmp_config() calls is returning an even number of elements (so
the hash whose ref will be stored in $svnsync ends up having an
odd number of elements), and that is why I initially asked you
about "more than one" svnsync-url. 0 is also an even number,
and it could be that it is not finding any.
How about doing something ugly like this _just for diagnosis_?
my $svnsync;
# see if we have it in our config, first:
eval {
my $section = "svn-remote.$self->{repo_id}";
my @u = tmp_config('--get', "$section.svnsync-url");
my @v = tmp_config('--get', "$section.svnsync-uuid");
if (@u != 1 || @v != 1) {
print STDERR "Oops: <$section> $#u <@u> $#v <@v>\n";
}
$svnsync = {
url => @u,
uuid => @v,
}
};
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-10 19:58 UTC (permalink / raw)
To: Junio C Hamano, Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <7vmyrgry20.fsf@gitster.siamese.dyndns.org>
On 8/1/08 18:07, "Junio C Hamano" <gitster@pobox.com> wrote:
> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
>
>> msysgit installs plain git. core.autocrlf is unset. Whatever plain
>> git's default is, this is msysgit's default, too.
>
> That sounds like a mistake if you are installing a port to a
> platform whose native line ending convention is different from
> where plain git natively runs on (i.e. UNIX).
I'm not sure that I understand the whole deal about platform default line
endings. Isn't plain git functionally agnostic about line endings? You can
check in CRLF text files to git and it doesn't care. You can diff, show etc
just fine. I haven't yet found anything that breaks with CRLF files. In
this sense plain git is already Windows ready. Maybe I'm missing something?
Doesn't the problem only come if you try to diff a CRLF file with a new
version that has LF only line endings? Then right now you have to use
something like:
git diff --ignore-space-at-eol
Or if a Windows user clones a repository created on another system. For
these cross-platform circumstances, it seems to me sensible to have an
option (probably enabled by default on all platforms) that allows files to
be munged on check in to whatever EOL style the repository creator preferred
(probably stored in .gitattributes and could be different for different
files in the repo - e.g. a windows vendor src dir on a cross-platform
project). Note that this means that munging would only happen if someone
actually asked for it - which would be a sensible thing to do as the
administrator of a cross-platform project.
Then there would be a separate option (probably not enabled by default) to
check out with the platform's native line ending instead of whatever is in
the repo. This would allow people to work with inflexible toolsets.
Finally for people who want to work with native line endings that are
different from repository line endings, then it might be necessary to
improve the handling of diffs by providing a config var to make
--ignore-space-at-eol the default (or perhaps more correctly
--ignore-line-endings) for text files. From my preliminary reading of list
history improving the inspection of content rather than trying to change
content might be the more gitish thing to do.
In conclusion all of these CRLF options are designed to help Windows users
play nicely with others. But it seems to me naïve Windows users can be
perfectly happy with plain git so long as they stay in their own Windows
world.
jm2c, corrections welcome and apologies to those suffering from eol
exhaustion,
Greg.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Dana How @ 2008-01-10 19:34 UTC (permalink / raw)
To: Marco Costalba
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Git Mailing List,
Junio C Hamano, danahow
In-Reply-To: <e5bfff550801092255wc852252m9086567a88b1ae99@mail.gmail.com>
On Jan 9, 2008 10:55 PM, Marco Costalba <mcostalba@gmail.com> wrote:
> On Jan 10, 2008 4:41 AM, Nicolas Pitre <nico@cam.org> wrote:
> > On Wed, 9 Jan 2008, Johannes Schindelin wrote:
> >
> > > I agree that gzip is already fast enough.
> > >
> > > However, pack v4 had more goodies than just being faster; it also promised
> > > to have smaller packs.
> >
> > Right, like not having to compress tree objects and half of commit
> > objects at all.
>
> Decompression speed has been shown to be a bottle neck on some tests
> involving mainly 'git log'.
Thanks for looking into this, in this email and your subsequent ones.
I agree that zip time is an issue. I was looking into reducing the _number_
of zip calls on the same data, but work and personal crises have reduced
me from an infrequent contributor to an occasional gadfly for the moment.
> Regarding back compatibility I really don't know at what level git
> functions actually need to know the compression format, looking at the
> code I would say at very low level, functions that deal directly with
> inflate() and friends are few [1] and not directly connected to UI,
> nor to git config. Is this compression format something user should
> know/care? and if yes why?
>
> In my tests the assumption of a source files tar ball is unrealistic,
> to test the final size difference I would like testing different
> compressions on a big already packaged but still not zipped file.
> Someone could be so kind to hint me on how to create such a package
> with good quality, i.e. with packaging levels similar to what is done
> for public repos?
>
> This does not realistically tests speed because as Junio pointed out
> the real decompressing schema is different: many calls on small
> objects, not one call on a big one. But if final size is acceptable we
> can go on more difficult tests.
The approach you're taking (here and in following emails) of being
able to make zip/lzo selection and measure the results should be
enlightening. For the vast majority of git users, Junio's scenario
is the most relevant.
Of additional interest to me is handling enormous objects more quickly.
I would like to replace some p4 usage here with git, but most users will
only notice the speed difference and not use git's extra features. Thus
they will compare git add/git commit/git push unfavorably to p4 edit/p4 submit,
because the former effectively does zip/unzip/zip/send, while the latter
only does zip/send (git's extra "unzip/zip" comes from loose objects not
being directly copyable into packs). This speed difference is irrelevant
for small to normal files, but a killer when commiting a collection of say
100MB files.
Your lzo option could reduce this performance degradation vs p4 from
3x to close to 1.5x. If you get it accepted, I'd love to then "fix" the loose
object copying "problem" making git _faster_ than p4 on large files!
2 simple forms for this "fix" would be to use the once-and-future "new"
loose object format (an idea already rejected), or to encode all loose
objects as singleton packs under .git/objects/xx (so that all (re)packing,
in the absence of new deltification, becomes pack-to-pack copying).
This latter idea is a modification of an idea from Nicolas Pitre.
It certainly adds less code than other approaches for such a "fix".
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Pierre Habouzit @ 2008-01-10 18:18 UTC (permalink / raw)
To: Jim Meyering; +Cc: Johannes Schindelin, git list
In-Reply-To: <87lk6xftdn.fsf@rho.meyering.net>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
On Thu, Jan 10, 2008 at 06:05:56PM +0000, Jim Meyering wrote:
> Pierre Habouzit <madcoder@artemis.madism.org> wrote:
> ....
> >> On the other hand, if that write failure is truly ignorable,
> >> a mindless minimalist :-) might argue that it's best just to
> >> omit the syscall.
> >
> > And leak a file descriptor :)
>
> Not that mindless.
> The *write* syscall, not the close.
> I would never suggest eliminating the close.
oh *oops*
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Jim Meyering @ 2008-01-10 18:05 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git list
In-Reply-To: <20080110162526.GB27808@artemis.madism.org>
Pierre Habouzit <madcoder@artemis.madism.org> wrote:
...
>> On the other hand, if that write failure is truly ignorable,
>> a mindless minimalist :-) might argue that it's best just to
>> omit the syscall.
>
> And leak a file descriptor :)
Not that mindless.
The *write* syscall, not the close.
I would never suggest eliminating the close.
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Dennis Schridde @ 2008-01-10 17:13 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <200801101204.58300.devurandom@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
Am Donnerstag, 10. Januar 2008 12:04:54 schrieb Dennis Schridde:
> Am Donnerstag, 10. Januar 2008 09:38:46 schrieb Eric Wong:
> > Dennis Schridde <devurandom@gmx.net> wrote:
> > > Am Dienstag, 8. Januar 2008 18:21:55 schrieb Junio C Hamano:
> > > > Dennis Schridde <devurandom@gmx.net> writes:
> > > > > I am getting "Odd number of elements in anonymous hash at
> > > > > /usr/bin/git-svn line 1760." (normal output, no warning/error)
> > > > > during git-svn-clone. I am using git version 1.5.4.rc2.
> >
> > Can you look in .git/svn/.metadata for the svnsync-* values? Thanks.
> >
> > I downloaded your repository and couldn't reproduce it locally.
>
> This is the file left after the segfault from the other mail:
> ---
> [svn-remote "svn"]
> reposRoot = file:///var/svn/warzone2100
> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
> branches-maxRev = 14
> tags-maxRev = 14
> svnsync-uuid = 4a71c877-e1ca-e34f-864e-861f7616d084\n
> svnsync-url = http://svn.gna.org/svn/warzone
> [svn-remote "tags/1.10a.12"]
> reposRoot = file:///var/svn/warzone2100
> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
> ---
The rest of the file is rather boring. The "svn" remote is not changed
(besides having higher revisions) and the other remotes look exactly like
the "tags/1.10a.12" one.
Somehow I think that the \n at the end of the svnsync-uuid shouldn't be
there... It could be that this is the same linebreak which prevents people
from relocating (svn switch --relocate) from svn://svn.gna.org/svn/warzone to
http://svn.gna.org/svn/warzone, so that would be a Gna bug.
However git-svn shouldn't throw any warnings (or even (make perl) crash?) on
such occasions, either...
I now got it to run through without a segfault, by compiling an unstriped perl
binary with debug symbols (Gentoo: FEATURES=nostrip CFLAGS="... -g").
Maybe this is a bug in GCC or something...
The "Odd number of elements in anonymous hash" still stays, though.
--Dennis
svn, version 1.4.6 (r28521)
git version 1.5.4.rc2
This is perl, v5.8.8 built for i686-linux
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: Pierre Habouzit @ 2008-01-10 16:25 UTC (permalink / raw)
To: Jim Meyering; +Cc: Johannes Schindelin, git list
In-Reply-To: <87hchlhm3k.fsf@rho.meyering.net>
[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]
On Thu, Jan 10, 2008 at 01:00:15PM +0000, Jim Meyering wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Are you aware what this code does? It writes a ".keep" file. Whose
> > purpose is to _exist_, and whose purpose is fulfilled, even if the write
> > or the push-back did not succeed.
>
> Hi,
>
> I do see what you mean.
>
> If the write is not necessary, then perhaps you would prefer a comment
> documenting that failures of the write and following close are ignorable.
> And add a '(void)' stmt prefix, to tell compilers that ignoring the
> return value is deliberate.
Note that (void) isn't enough with the most recent gcc flavours, which
is a pain. I do use:
#define IGNORE(expr) do { if (expr) (void)0; } while (0)
for that purpose in my code. I know IGNORE isn't a brilliant name, but
it's modeled after the ocaml function doing the same thing.
> However, even if it's not technically required to fail at that point,
> if it were my choice, I'd prefer to know when a .keep file whose
> contents are unimportant just happens to reside on a bad spot on my
> disk. I/O errors should never be ignored.
Actually I think .keep files are empty, so the write() should not be
there in the first place, and we should only check for close() right ?
not that it matters that much.
> > I could not care less what the manual says. What is important is if the
> > defensive programming is done mindlessly, and therefore can fail so not
> > gracefully.
>
> On the other hand, if that write failure is truly ignorable,
> a mindless minimalist :-) might argue that it's best just to
> omit the syscall.
And leak a file descriptor :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Harris @ 2008-01-10 14:31 UTC (permalink / raw)
To: Peter Karlsson
Cc: Johannes Schindelin, Junio C Hamano, Linus Torvalds,
J. Bruce Fields, Steffen Prohaska, Robin Rosenberg, Jeff King,
Git Mailing List, msysGit
In-Reply-To: <Pine.LNX.4.64.0801101424580.11922@ds9.cixit.se>
On Jan 10, 2008 8:28 AM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> I meant to say that any software that claims to be Windows software
> should handle, and produce, CRLF line breaks in text files.
Including zip/unzip? How about tar? rsync? NFS and SMB copies from
network shares? I bet the Samba folks would just *love* to have this
discussion for the hundredth time.
Just because CVS and FTP got the defaults wrong (and modern FTP
clients mostly default to automatically switching to binary, so
basically just CVS) doesn't mean that Git has to get the default
wrong, too. Git *does* handle and produce CRLF line breaks, as long as
you tell it to. Please don't lose sight of that fact.
I'm just glad that VMS is effectively dead. Line endings on VMS are
stored outside the text body, IIRC...
Peter Harris
^ permalink raw reply
* Re: Revert git push
From: Johannes Sixt @ 2008-01-10 14:12 UTC (permalink / raw)
To: Markus Korber; +Cc: git
In-Reply-To: <6zve61q0t3.fsf@odpc25.int.ondemand.co.at>
Markus Korber schrieb:
> Hi,
>
> I've got two local git repositories, linux and mplayer, where I push to
> from a local directory. Now I accidentally pushed from mplayer into the
> linux repository (via a not updated URL[1]). Is it somehow possible to
> revert this push if nobody has pushed something since my last pull from
> the linux repository?
Sure.
$ cd /the/linux/repo
$ git checkout 94545baded
$ git branch -f master 94545baded
$ git checkout master
Omit the two checkouts if the repo is bare or if it did not have 'master'
checked out.
-- Hannes
^ permalink raw reply
* Re: Revert git push
From: Markus Korber @ 2008-01-10 13:45 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <57518fd10801100531v6f6aef85k4b1b875c6f16aeba@mail.gmail.com>
Thus spake Jonathan del Strother:
> On Jan 10, 2008 1:15 PM, Markus Korber <korbse@gmx.at> wrote:
>
>> I've got two local git repositories, linux and mplayer, where I push to
>> from a local directory. Now I accidentally pushed from mplayer into the
>> linux repository (via a not updated URL[1]). Is it somehow possible to
>> revert this push if nobody has pushed something since my last pull from
>> the linux repository?
>
> You can push again to revert your original push, just specifying a
> different ref to push. Something like this ought to work :
>
> git push -f mplayer 94545bade:master
>
> which will update the remote 'master' branch with commit 94545bade,
> which is what it was before your accidental push
Unfortunately this gives:
,----[ git push -f mplayer 94545bade:master ]
| error: src refspec 94545bade does not match any.
| fatal: The remote end hung up unexpectedly
| error: failed to push to '/prj/gitroot/linux'
`----
,----[ git --version ]
| git version 1.5.3.1
`----
Regards,
Markus Korber
^ permalink raw reply
* Re: Revert git push
From: Jonathan del Strother @ 2008-01-10 13:31 UTC (permalink / raw)
To: Markus Korber; +Cc: git
In-Reply-To: <6zve61q0t3.fsf@odpc25.int.ondemand.co.at>
On Jan 10, 2008 1:15 PM, Markus Korber <korbse@gmx.at> wrote:
> Hi,
>
> I've got two local git repositories, linux and mplayer, where I push to
> from a local directory. Now I accidentally pushed from mplayer into the
> linux repository (via a not updated URL[1]). Is it somehow possible to
> revert this push if nobody has pushed something since my last pull from
> the linux repository?
>
> (Or can I just copy the .git/objects/ directory over to the repository?)
>
> ,----[ .git/remotes/mplayer [1]]
> | URL: /prj/gitroot/linux
> | Push: +master:master
> `----
>
> ,----[ git push mplayer ]
> | updating 'refs/heads/master'
> | from 94545baded0bfbabdc30a3a4cb48b3db479dd6ef
> | to 9085d919f7954ad629447157f054e55230513936
> | Generating pack...
> | Done counting 3240 objects.
> | Deltifying 3240 objects...
> | 100% (3240/3240) done
> | Writing 3240 objects...
> | 100% (3240/3240) done
> | Total 3240 (delta 774), reused 0 (delta 0)
> | refs/heads/master: 94545baded0bfbabdc30a3a4cb48b3db479dd6ef -> 9085d919f7954ad629447157f054e55230513936
> `----
You can push again to revert your original push, just specifying a
different ref to push. Something like this ought to work :
git push -f mplayer 94545bade:master
which will update the remote 'master' branch with commit 94545bade,
which is what it was before your accidental push
Jon
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-10 13:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Git Mailing List, msysGit
In-Reply-To: <alpine.LSU.1.00.0801101155140.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
Johannes Schindelin:
> I cannot help but wonder what exactly you wanted to achieve with this
> provably bogus statement, other than provoking flames. I hereby
> refuse to insult you for it.
I meant to say that any software that claims to be Windows software
should handle, and produce, CRLF line breaks in text files. Whether it
also supports Unix (LF) or old Mac (CR) line breaks is up to it, but if
it is a Windows program, it should do CRLF, as that is the convention
(inherited from MS-DOS, which inherited it from CP/M).
> > True. And I run git a lot on a Novell disk share, which doesn't exactly
> > help improve the speed either :-)
> Don't do that, then.
I have to. Otherwise the compile server can't see the files (this is
not for the project that at in the start of the thread, this is what I
use to work around that my employer's choice of version control systems
could be better).
> > Windows has CRLF line endings. Just deal with it.
> No, I will not just deal with it.
Me neither, that is why I expect the software to do it for me.
Thinking of text files as a stream of bytes is so 1900s. In the 2000s
we should think of text files as a stream of characters. How these
characters are represented is up to each system that wants it. I see no
problem with storing text files as UTF-32 internally (disk is cheap).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox