* Re: [PATCH] Use commit template when cherry picking
From: Junio C Hamano @ 2008-01-11 18:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Deepak Saxena, git, Perry Wagle
In-Reply-To: <alpine.LSU.1.00.0801111208020.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I would do a combination of "cherry-pick -n", "cat-file commit <commit> |
> sed '1,/^$/d'" and "commit -F" or "commit -f".
Doesn't cherry-pick have -e switch to allow you further edit the
message?
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-11 19:00 UTC (permalink / raw)
To: Steffen Prohaska, Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <D36EB89D-11A3-4EAF-BC1C-6100383FCBFC@zib.de>
Sticking my head above the parapet again ...
On 11/1/08 16:28, "Steffen Prohaska" <prohaska@zib.de> wrote:
> I don't think the CRLF problem is a Windows vs. Unix discussion.
Agreed.
> In my view, the discussion is wether git will have real cross-
> platform support as its default or not. The current default is
> sane for native Unix or native Windows projects. For cross-
Absolutely
> platform projects the default needs to be changed in the way
> described above. Git needs to ensure that CRLF never enters the
> repository for text files.
LF only repositories are model that everyone is tending towards but I feel
that there are (sane) people out there who would sometimes like to have CRLF
files in the repository and do cross-platform development (I would
developing on a Mac for a Windows originated Win/Mac project or if I were
keeping vendor source code in a tree). In spite of the plethora of autocrlf
variants so far there is still none that on unix would give you LF->CRLF on
check in and CRLF->LF on checkout! This should be perfectly compatible with
git's internals and I think it should be possible to allow this without
breaking anything for other situations. One solution, which would have
other uses, would be to allow checkin conversion to a specified line ending
and checkout conversion to platform line ending as separately configurable
options.
If this seems outrageous then it should be made perfectly clear that the git
project strongly discourages CRLF text files in cross-platform repositories,
that to prevent CRLF creep we disallow them by default even in the privacy
of your own OS (if it's Windows) and that if you want to do this you're on
your own mate. But I think that would be a shame, inflexible and definitely
not PC ;-)
> If you did not set autocrlf=true,
> copying source code from Windows to Unix would not be supported.
> But as you earlier mentioned, this seems to be a common
> operation and I am observing the same. So I recommend
> autocrlf=input on Unix if you plan to ever go cross-platform.
For me this is kind of the mathematician vs the engineer. I think Steffen
is logically correct in saying that autocrlf=input on unix is the direct
orthologue of autocrlf=true on windows and I dislike the idea that git
should show logically different behaviour on different platforms. However I
think Linus's cost/benefit analysis is right: CRLF files appear infrequently
on unix system and often as not it's because someone specifically wants them
to stay that way.
So I think autocrlf=input is a useful option but not a necessary default on
unix.
^ permalink raw reply
* [PATCH 6/6] Convert sha1_file.c to use decompress helpers
From: Marco Costalba @ 2008-01-11 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This is "The King".
It is the most difficult file to convert and some
decompression functions have been created just for it.
Anyhow the lines of code removed (45) far surpass the
ones added (26).
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This is the last patch all git has been converted to
compress/decompress helpers.
No more open coded zlib calls in git now.
sha1_file.c | 71 +++++++++++++++++++++------------------
1 files changed, 26 insertions(+), 45 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 6c94bd5..708727a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1063,16 +1063,11 @@ static int unpack_sha1_header(z_stream *stream,
enum object_type type;
/* Get the data stream */
- memset(stream, 0, sizeof(*stream));
- stream->next_in = map;
- stream->avail_in = mapsize;
- stream->next_out = buffer;
- stream->avail_out = bufsiz;
+ decompress_alloc(stream);
+ decompress_into(stream, buffer, bufsiz);
- if (legacy_loose_object(map)) {
- inflateInit(stream);
- return inflate(stream, 0);
- }
+ if (legacy_loose_object(map))
+ return decompress_next_from(stream, map, mapsize, Z_NO_FLUSH);
/*
@@ -1089,9 +1084,7 @@ static int unpack_sha1_header(z_stream *stream,
mapsize -= used;
/* Set up the stream for the rest.. */
- stream->next_in = map;
- stream->avail_in = mapsize;
- inflateInit(stream);
+ decompress_from(stream, map, mapsize);
/* And generate the fake traditional header */
stream->total_out = 1 + snprintf(buffer, bufsiz, "%s %lu",
@@ -1125,14 +1118,13 @@ static void *unpack_sha1_rest(z_stream *stream,
* we also want to check that zlib tells us that all
* went well with status == Z_STREAM_END at the end.
*/
- stream->next_out = buf + bytes;
- stream->avail_out = size - bytes;
+ decompress_into(stream, buf + bytes, size - bytes);
while (status == Z_OK)
- status = inflate(stream, Z_FINISH);
+ status = decompress_next(stream, Z_FINISH);
}
buf[size] = 0;
if (status == Z_STREAM_END && !stream->avail_in) {
- inflateEnd(stream);
+ decompress_free(stream);
return buf;
}
@@ -1217,20 +1209,18 @@ unsigned long get_size_from_delta(struct
unsigned char delta_head[20], *in;
z_stream stream;
int st;
+ unsigned int in_size = 0;
- memset(&stream, 0, sizeof(stream));
- stream.next_out = delta_head;
- stream.avail_out = sizeof(delta_head);
+ decompress_alloc(&stream);
+ decompress_into(&stream, delta_head, sizeof(delta_head));
- inflateInit(&stream);
do {
- in = use_pack(p, w_curs, curpos, &stream.avail_in);
- stream.next_in = in;
- st = inflate(&stream, Z_FINISH);
+ in = use_pack(p, w_curs, curpos, &in_size);
+ st = decompress_next_from(&stream, in, in_size, Z_FINISH);
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
- inflateEnd(&stream);
+ decompress_free(&stream);
if ((st != Z_STREAM_END) && stream.total_out != sizeof(delta_head))
die("delta data unpack-initial failed");
@@ -1307,7 +1297,7 @@ static int packed_delta_info(struct packed_git *p,
/* We choose to only get the type of the base object and
* ignore potentially corrupt pack file that expects the delta
* based on a base with a wrong size. This saves tons of
- * inflate() calls.
+ * decompress() calls.
*/
if (sizep)
*sizep = get_size_from_delta(p, w_curs, curpos);
@@ -1428,21 +1418,18 @@ static void *unpack_compressed_entry(struct
int st;
z_stream stream;
unsigned char *buffer, *in;
+ unsigned int in_size = 0;
buffer = xmalloc(size + 1);
buffer[size] = 0;
- memset(&stream, 0, sizeof(stream));
- stream.next_out = buffer;
- stream.avail_out = size;
-
- inflateInit(&stream);
+ decompress_alloc(&stream);
+ decompress_into(&stream, buffer, size);
do {
- in = use_pack(p, w_curs, curpos, &stream.avail_in);
- stream.next_in = in;
- st = inflate(&stream, Z_FINISH);
+ in = use_pack(p, w_curs, curpos, &in_size);
+ st = decompress_next_from(&stream, in, in_size, Z_FINISH);
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
- inflateEnd(&stream);
+ decompress_free(&stream);
if ((st != Z_STREAM_END) || stream.total_out != size) {
free(buffer);
return NULL;
@@ -1788,7 +1775,7 @@ static int sha1_loose_object_info(const unsigned
status = error("unable to parse %s header", sha1_to_hex(sha1));
else if (sizep)
*sizep = size;
- inflateEnd(&stream);
+ decompress_free(&stream);
munmap(map, mapsize);
return status;
}
@@ -2196,21 +2183,15 @@ int write_sha1_from_fd(const unsigned char
*sha1, int fd,
return error("unable to create temporary sha1 filename %s: %s\n",
tmpfile, strerror(errno));
}
- memset(&stream, 0, sizeof(stream));
-
- inflateInit(&stream);
-
+ decompress_alloc(&stream);
SHA1_Init(&c);
do {
ssize_t size;
if (*bufposn) {
- stream.avail_in = *bufposn;
- stream.next_in = (unsigned char *) buffer;
+ decompress_from(&stream, (unsigned char *) buffer, *bufposn);
do {
- stream.next_out = discard;
- stream.avail_out = sizeof(discard);
- ret = inflate(&stream, Z_SYNC_FLUSH);
+ ret = decompress_next_into(&stream, discard, sizeof(discard),
Z_SYNC_FLUSH);
SHA1_Update(&c, discard, sizeof(discard) -
stream.avail_out);
} while (stream.avail_in && ret == Z_OK);
@@ -2233,7 +2214,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd,
}
*bufposn += size;
} while (1);
- inflateEnd(&stream);
+ decompress_free(&stream);
fchmod(local, 0444);
if (close(local) != 0)
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-11 19:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <14E7B5D5-B1B8-4532-A471-106B14B912B8@zib.de>
On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>
> I already started to teach everyone the new "autocrlf=input" policy to
> avoid these questions.
I certainly don't think "autocrlf=input" is wrong. It might even be a
reasonable default on Unix, although I don't think it's nearly as obvious
as the Windows case. I wouldn't mind using it myself, for example,
although probably only because I know that for the stuff I work on it
simply cannot possibly ever do the wrong thing.
In fact, we had a case of bogus CRLF in one of the kernel documentation
files for some reason that we ended up fixing by hand. "autocflf=input"
would have fixed it (except in that case it wouldn't have, since it came
from the original kernel tree, long before crlf was an issue for git ;)
So I'd say that autocrlf=input is quite possibly a good idea on Unix in
general, but my gut feel is still that it's not a big enough issue to be
actually worth making a default change over. But there's absolutely
nothing wrong with having it as a policy at a company that has mixed Unix
and Windows machines.
(Every place I've ever been at, people who had a choice would never ever
develop under Windows, so I've never seen any real mixing - even when some
parts of the project were DOS/Windows stuff, there was a clear boundary
between the stuff that was actually done under Windows)
Linus
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Sam Ravnborg @ 2008-01-11 19:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steffen Prohaska, Gregory Jefferis, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801111103420.3148@woody.linux-foundation.org>
On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Steffen Prohaska wrote:
> >
> > I already started to teach everyone the new "autocrlf=input" policy to
> > avoid these questions.
>
> I certainly don't think "autocrlf=input" is wrong. It might even be a
> reasonable default on Unix, although I don't think it's nearly as obvious
> as the Windows case. I wouldn't mind using it myself, for example,
> although probably only because I know that for the stuff I work on it
> simply cannot possibly ever do the wrong thing.
>
> In fact, we had a case of bogus CRLF in one of the kernel documentation
> files for some reason that we ended up fixing by hand. "autocflf=input"
> would have fixed it (except in that case it wouldn't have, since it came
> from the original kernel tree, long before crlf was an issue for git ;)
>
> So I'd say that autocrlf=input is quite possibly a good idea on Unix in
> general, but my gut feel is still that it's not a big enough issue to be
> actually worth making a default change over. But there's absolutely
> nothing wrong with having it as a policy at a company that has mixed Unix
> and Windows machines.
>
> (Every place I've ever been at, people who had a choice would never ever
> develop under Windows, so I've never seen any real mixing - even when some
> parts of the project were DOS/Windows stuff, there was a clear boundary
> between the stuff that was actually done under Windows)
The reality I see is the other way around as common practice.
For people that has never tried a Linux box the barrier
is quite high and they prefer to stick with Windows.
Where I work today and in several other places I know of the
default choice is to work on Windows and use a Linux box only
for cross compilation.
This is common practice in many smaller embedded companies
and it is also these companies that like to be able to build
Linux on a Windows box.
Sam
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Christer Weinigel @ 2008-01-11 19:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steffen Prohaska, Gregory Jefferis, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org>
On Fri, 11 Jan 2008 10:10:00 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 11 Jan 2008, Steffen Prohaska wrote:
> > Ah sorry, I misunderstood you in [1]. I thought your last point
> > "Mixed Windows usage" meant what I have in mind: A user working
> > in a mixed Windows/Unix environment who creates a file using
> > Windows tools and commits it in the Unix environment. In this
> > case the CRLF file will be transferred from Windows to Unix
> > without git being involved. The right thing for git on Unix is
> > to remove CRLF during a commit but still write only LF during
> > check out. So autocrlf=input is the right choice.
>
> Oh, ok, I didn't realize.
>
> But yes, if you use a network share across windows and Unixand
> actually *share* the working tree over it, then yes, you'd want
> "autocrlf=input" on the unix side.
>
> However, I think that falls under the "0.1%" case, not the "99.9%"
> case.
That's how I work all the time. My Linux box is a Samba server where I
check things out from perforce (with the "share" settings for end of
line which means that text files are checked out with LF only and CRLF
is converted to LF on checkin). Having the data on the Linux box is
nice since I can have all the nice Unix tools such as sed, find, grep,
and they run fast on a native Linux system, which is not true about
cygwin on Windows.
> I realize that people probably do that more often with centralized
> systems, but with a distributed thing, it probably makes a *ton* more
> sense to have separate trees. But I could kind of see having a shared
> development directory and accessing it from different types of
> machines too.
We're working in a mixed environment, and even though I do most of my
development on Linux I usually want to make sure that things build in
Visual Studio before I check in, so the easiest thing to do is to point
Visual Studio at the files on the Samba share. Same thing when using
Altera's tools to do CPLD development, I run the Altera tools on
Windows (their free version is Windows only) but all the files are on
the Linux box. My tools that take the SVF file (the "binary image" for
the CPLD) and program the CPLD all run under Linux though.
A lot of my colleagues have Windows on the desktop, and when they
develop on Linux they usually edit the files locally using the Samba
share, and then they have a Putty (ssh) connected to the Linux box
where they build and test the software.
So the shared scenario is actually a very common one for us.
> I'd also bet that crlf behavior of git itself will be the *least* of
> your problems in that situation. You'd have all the *other* tools to
> worry about, and would probably be very aware indeed of any CRLF
> issues. So at that point, the "automatic" or default behaviour is
> probably not a big deal, because everything _else_ you do likely
> needs special effort too!
Actually I seldom have any problems with CRLF at all. Sometimes
the Xilinx or Altera editors will insert some stray CRLFs in some files,
but all the tools I use seem to tolerate that. And as soon as I check
in the CRLFs disappear anyway. We just have to make sure to turn on
the "share" setting in our Perforce views and everything just works.
/Christer
^ permalink raw reply
* [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Stephen Sinclair @ 2008-01-11 20:10 UTC (permalink / raw)
To: git, Junio C Hamano
Add committer and author names to top of COMMIT_EDITMSG.
Signed-off-by: Stephen Sinclair <radarsat1@gmail.com>
---
builtin-commit.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..4fd9367 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -423,8 +423,18 @@ static int prepare_log_message(const char
*index_file, const char *prefix)
"#\n",
git_path("MERGE_HEAD"));
+ fprintf(fp, "\n");
+
+ fprintf(fp,
+ "# Committer: %s\n"
+ "# Author: %s\n"
+ "#\n",
+ fmt_name(getenv("GIT_AUTHOR_NAME"),
+ getenv("GIT_AUTHOR_EMAIL")),
+ fmt_name(getenv("GIT_COMMITTER_NAME"),
+ getenv("GIT_COMMITTER_EMAIL")));
+
fprintf(fp,
- "\n"
"# Please enter the commit message for your changes.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
--
1.5.4.rc2.85.ga7943-dirty
^ permalink raw reply related
* Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-11 20:19 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]
Somehow I managed to change the case of a directory without git
realizing it. I thought I issued `git mv CS4536 cs4536` but since that
won't work in my efforts to reproduce the problem, I must have simply
issued the `mv` outside of git and then re-added it.
Anyway, here's the state of my directory:
kevin@KBALLARD:~/Documents/School/C07> git ls-tree HEAD
040000 tree b47c8103e2e01fcf145bdc237c0e56ffc61f1c47 CS4536
040000 tree dbf7fc51ef3effebdf9b4e9172e4c86cae52b163 cs4536
040000 tree 15834a7b6534a285bf6930be4e5404b37e1dc718 ece3601
040000 tree 62d229b8c4a389b550df20a3752d666c48c767a4 ma2071
Note that I have both versions of the directory present.
Unfortunately, only one of them can be present on the filesystem. If I
run `mv cs4536 CS4536; git reset --hard` I end up with a different
working tree.
Git should be able to detect this sort of conflict on a case-
insensitive system. I didn't even realize what I'd done until I pushed
back to the master repo and ran `git reset --hard` there, then
wondered why the new file I added to cs4536/ was missing and why my
directory was still named CS4536.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply
* [PATCH decompress BUG] Fix decompress_next_from() wrong argument value
From: Marco Costalba @ 2008-01-11 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Function decompress_next_from() needs a pointer to a buffer
and the buffer size as arguments.
Interesting enough the function fill() that returns the
buffer pointer happens to modify also the buffer size,
stored in a variable at file scope.
So we need to guarantee fill() is called before to use buffer
size as argument in decompress_next_from()
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Patch to be applied above decompress helper series.
Not to be pedantic, but have a function that gives two really
coupled values, as a buffer pointer and the size, the first as return
value and the second through a variable at file scope is not something
you are going to see advertised in the programming books!
Sorry for this little rant but this bug really made me crazy.
With this patch 'make test' runs with success!
builtin-unpack-objects.c | 3 ++-
index-pack.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index f1a4883..72293ec 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -68,7 +68,8 @@ static void *get_data(unsigned long size)
decompress_into(&stream, buf, size);
for (;;) {
- int ret = decompress_next_from(&stream, fill(1), len, Z_NO_FLUSH);
+ void* tmp = fill(1); // fill() modifies len, so be sure is evaluated as first
+ int ret = decompress_next_from(&stream, tmp, len, Z_NO_FLUSH);
use(len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
diff --git a/index-pack.c b/index-pack.c
index 30d7837..13b308d 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -173,7 +173,8 @@ static void *unpack_entry_data(unsigned long
offset, unsigned long size)
decompress_into(&stream, buf, size);
for (;;) {
- int ret = decompress_next_from(&stream, fill(1), input_len, Z_NO_FLUSH);
+ void* tmp = fill(1); // fill() modifies input_len, so be sure is
evaluated as first
+ int ret = decompress_next_from(&stream, tmp, input_len, Z_NO_FLUSH);
use(input_len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
--
1.5.4.rc2.95.g0eaa-dirty
^ permalink raw reply related
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-11 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1w8o4ws0.fsf@gitster.siamese.dyndns.org>
On Jan 11, 2008 3:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Does this mean "default" is now a new reserved word that cannot
> be used as "git remote update default"?
oops...git-remote already has a (partially undocumented) use for
remotes.* as well as remote.*, so I need another variable name,
probably core.origin to avoid either defining new namespace or
polluting one reserved for arbitrary end-user use. Will resend patches
later tonight.
>
> However, it is a bit hard to judge how much of inconvenience it
> really is in your real life that the current behaviour does not
> allow you to.
I believe I addressed this in the thread with Dscho.
> > git_config(handle_config);
> > + if (!default_remote_name) {
> > + default_remote_name = remotes_default_name ?
> > + remotes_default_name : xstrdup("origin");
> > + }
>
> Is this a bit too deep indentation?
>
will fix.
Mark
^ permalink raw reply
* [PATCH] Document some default values in config.txt
From: Michele Ballabio @ 2008-01-11 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This documents the default values of gc.auto, gc.autopacklimit
fetch.unpacklimit, receive.unpacklimit and transfer.unpacklimit.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Documentation/config.txt | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..6f09fee 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -473,7 +473,9 @@ fetch.unpackLimit::
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
- especially on slow filesystems.
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` (which in turn defaults to 100) is
+ used instead.
format.numbered::
A boolean which can enable sequence numbers in patch subjects.
@@ -499,14 +501,14 @@ gc.auto::
When there are approximately more than this many loose
objects in the repository, `git gc --auto` will pack them.
Some Porcelain commands use this command to perform a
- light-weight garbage collection from time to time. Setting
- this to 0 disables it.
+ light-weight garbage collection from time to time. The
+ default value is 6700. Setting this to 0 disables it.
gc.autopacklimit::
When there are more than this many packs that are not
marked with `*.keep` file in the repository, `git gc
- --auto` consolidates them into one larger pack. Setting
- this to 0 disables this.
+ --auto` consolidates them into one larger pack. The
+ default value is 20. Setting this to 0 disables it.
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
@@ -861,7 +863,9 @@ receive.unpackLimit::
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
- especially on slow filesystems.
+ especially on slow filesystems. If not set, the value of
+ `transfer.unpackLimit` (which in turn defaults to 100) is
+ used instead.
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
@@ -872,6 +876,7 @@ receive.denyNonFastForwards::
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
+ The default value is 100.
web.browser::
Specify a web browser that may be used by some commands.
--
1.5.3.5
^ permalink raw reply related
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-11 21:09 UTC (permalink / raw)
To: git
In-Reply-To: <579DF776-4F4E-464C-88DB-B22C2EC291BD@sb.org>
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
Wow, it's even worse. I made a tmp branch and used git-filter-branch
to remove the commit that introduced CS4536, leaving only the cs4536
directory. But now if I try and run `git co master` it refuses, as it
thinks it's going to overwrite the untracked file CS4536/
introduction.txt. I believe it's actually seeing the tracked file
cs4536/introduction.txt.
-Kevin Ballard
On Jan 11, 2008, at 3:19 PM, Kevin Ballard wrote:
> Somehow I managed to change the case of a directory without git
> realizing it. I thought I issued `git mv CS4536 cs4536` but since
> that won't work in my efforts to reproduce the problem, I must have
> simply issued the `mv` outside of git and then re-added it.
>
> Anyway, here's the state of my directory:
>
> kevin@KBALLARD:~/Documents/School/C07> git ls-tree HEAD
> 040000 tree b47c8103e2e01fcf145bdc237c0e56ffc61f1c47 CS4536
> 040000 tree dbf7fc51ef3effebdf9b4e9172e4c86cae52b163 cs4536
> 040000 tree 15834a7b6534a285bf6930be4e5404b37e1dc718 ece3601
> 040000 tree 62d229b8c4a389b550df20a3752d666c48c767a4 ma2071
>
> Note that I have both versions of the directory present.
> Unfortunately, only one of them can be present on the filesystem. If
> I run `mv cs4536 CS4536; git reset --hard` I end up with a different
> working tree.
>
> Git should be able to detect this sort of conflict on a case-
> insensitive system. I didn't even realize what I'd done until I
> pushed back to the master repo and ran `git reset --hard` there,
> then wondered why the new file I added to cs4536/ was missing and
> why my directory was still named CS4536.
>
> -Kevin Ballard
>
> --
> Kevin Ballard
> http://kevin.sb.org
> kevin@sb.org
> http://www.tildesoft.com
>
>
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Johannes Schindelin @ 2008-01-11 21:12 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <30e4a070801110815q1dee8f0cr7966fc2896e4c790@mail.gmail.com>
Hi,
On Fri, 11 Jan 2008, Mark Levedahl wrote:
> On Jan 11, 2008 10:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > Mark, if this change is mainly about the fact that git doesn't allow
> > to specify default remote to fetch for detached HEAD (and submodules
> > use detached HEAD), why not provide "branch.HEAD.remote" etc., which
> > would be used _only_ if we are on detached HEAD (i.e. branch has no
> > name).
>
> Practically speaking, this would just change the name of the config
> variable (from remotes.default to branch.HEAD.remote). However, this
> value is used *whenever* the current branch does not have corresponding
> branch.<name>.remote, and that is not restricted to detached heads, it
> applies anytime the current HEAD is not a tracking branch. So, I believe
> remotes.default better reflects this generality than does
> branch.HEAD.remote.
Practically speaking, I have enough experience to _know_ that your
solution will not help very much. It will just add to confusion.
You stated quite clearly -- _after_ I asked -- what your problem is, and I
am quite certain that you _still_ have to look up _something_ (as I
remarked in the email you responded to).
So it is still _utterly_ unclear to me how your patch helps anything.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Linus Torvalds @ 2008-01-11 21:18 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <579DF776-4F4E-464C-88DB-B22C2EC291BD@sb.org>
On Fri, 11 Jan 2008, Kevin Ballard wrote:
>
> Anyway, here's the state of my directory:
>
> kevin@KBALLARD:~/Documents/School/C07> git ls-tree HEAD
> 040000 tree b47c8103e2e01fcf145bdc237c0e56ffc61f1c47 CS4536
> 040000 tree dbf7fc51ef3effebdf9b4e9172e4c86cae52b163 cs4536
> 040000 tree 15834a7b6534a285bf6930be4e5404b37e1dc718 ece3601
> 040000 tree 62d229b8c4a389b550df20a3752d666c48c767a4 ma2071
Hmm. You can do something like
git ls-files CS4536 | xargs git update-index --force-remove
which will remove gits knowledge of that directory even though "lstat()"
will still claim that all the files still exists.
Case-insensitive filesystems are a pain.
I wish we had some way to handle it sanely, but I don't think a sane
solution to case-insensitivity exists. If you limit it to strictly just
7bit ascii names (like in your example), then some of the problems do go
away, but it would still be probably fairly major surgery to try to teach
git about the whole insanity of a case-independent working tree.
Linus
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-11 21:18 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, git
In-Reply-To: <20080111195022.GC29189@uranus.ravnborg.org>
Hi,
On Fri, 11 Jan 2008, Sam Ravnborg wrote:
> On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:
>
> > (Every place I've ever been at, people who had a choice would never
> > ever develop under Windows, so I've never seen any real mixing - even
> > when some parts of the project were DOS/Windows stuff, there was a
> > clear boundary between the stuff that was actually done under Windows)
>
> The reality I see is the other way around as common practice.
Not in my world.
I see a few people who are stuck to Windows, but they are so because they
are lazy. They do not ever do something interesting with computers in
their free time, and while working, they only do what they are told to do.
That might sound cynical, but you will have to _show_ me different
examples to make me reconsider.
And no, my work with msysgit did a poor job to convince me otherwise.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-11 21:19 UTC (permalink / raw)
To: git
In-Reply-To: <CCDF6298-4F17-4F70-AF00-E63F2C2A2816@sb.org>
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
Err, make that git-rebase (for removing the commit).
-Kevin Ballard
On Jan 11, 2008, at 4:09 PM, Kevin Ballard wrote:
> Wow, it's even worse. I made a tmp branch and used git-filter-branch
> to remove the commit that introduced CS4536, leaving only the cs4536
> directory. But now if I try and run `git co master` it refuses, as
> it thinks it's going to overwrite the untracked file CS4536/
> introduction.txt. I believe it's actually seeing the tracked file
> cs4536/introduction.txt.
>
> -Kevin Ballard
>
> On Jan 11, 2008, at 3:19 PM, Kevin Ballard wrote:
>
>> Somehow I managed to change the case of a directory without git
>> realizing it. I thought I issued `git mv CS4536 cs4536` but since
>> that won't work in my efforts to reproduce the problem, I must have
>> simply issued the `mv` outside of git and then re-added it.
>>
>> Anyway, here's the state of my directory:
>>
>> kevin@KBALLARD:~/Documents/School/C07> git ls-tree HEAD
>> 040000 tree b47c8103e2e01fcf145bdc237c0e56ffc61f1c47 CS4536
>> 040000 tree dbf7fc51ef3effebdf9b4e9172e4c86cae52b163 cs4536
>> 040000 tree 15834a7b6534a285bf6930be4e5404b37e1dc718 ece3601
>> 040000 tree 62d229b8c4a389b550df20a3752d666c48c767a4 ma2071
>>
>> Note that I have both versions of the directory present.
>> Unfortunately, only one of them can be present on the filesystem.
>> If I run `mv cs4536 CS4536; git reset --hard` I end up with a
>> different working tree.
>>
>> Git should be able to detect this sort of conflict on a case-
>> insensitive system. I didn't even realize what I'd done until I
>> pushed back to the master repo and ran `git reset --hard` there,
>> then wondered why the new file I added to cs4536/ was missing and
>> why my directory was still named CS4536.
>>
>> -Kevin Ballard
>>
>> --
>> Kevin Ballard
>> http://kevin.sb.org
>> kevin@sb.org
>> http://www.tildesoft.com
>>
>>
>
> --
> Kevin Ballard
> http://kevin.sb.org
> kevin@sb.org
> http://www.tildesoft.com
>
>
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply
* Re: [PATCH] Use commit template when cherry picking
From: Johannes Schindelin @ 2008-01-11 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Deepak Saxena, git, Perry Wagle
In-Reply-To: <7v7iig2npe.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 11 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I would do a combination of "cherry-pick -n", "cat-file commit
> > <commit> | sed '1,/^$/d'" and "commit -F" or "commit -f".
>
> Doesn't cherry-pick have -e switch to allow you further edit the
> message?
Good point. But nevertheless, Deepak wanted to have a template which is
automatically added, and I think the only way to do that right now is as I
described.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Linus Torvalds @ 2008-01-11 21:25 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <CCDF6298-4F17-4F70-AF00-E63F2C2A2816@sb.org>
On Fri, 11 Jan 2008, Kevin Ballard wrote:
>
> Wow, it's even worse. I made a tmp branch and used git-filter-branch to remove
> the commit that introduced CS4536, leaving only the cs4536 directory. But now
> if I try and run `git co master` it refuses, as it thinks it's going to
> overwrite the untracked file CS4536/introduction.txt. I believe it's actually
> seeing the tracked file cs4536/introduction.txt.
If you don't have any dirty state, I'd suggest removing your working tree
before doing a "git checkout". That's needed anyway to make sure that your
working tree has the same case as your index and git trees, because
otherwise since the crazy filesystem thinks that CS4536/cs4536 ar ethe
same, you might end up having all the wrong names.
Case differences are hard anyway, but you probably made them even harder
by them using a rename that actually meant that the old name still
*existed* in the filesystem (since the new name would always map to the
old name thanks to your crazy filesystem).
I'm sure you can get into even more trouble with case-independent
filesystems, but I think you did a pretty good job of hitting on one of
the craziest cases ;)
Linus
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Johannes Schindelin @ 2008-01-11 21:26 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git, Junio C Hamano
In-Reply-To: <9b3e2dc20801111210n7bd7a71cw437819aa6253ae85@mail.gmail.com>
Hi,
On Fri, 11 Jan 2008, Stephen Sinclair wrote:
> Add committer and author names to top of COMMIT_EDITMSG.
This commit message is severely lacking: it is just a repetition of the
commit subject, it is too technical (what is COMMIT_EDITMSG for,
anyway?), and even worse, it does not begin to explain _why_ this is a
good change.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Johannes Schindelin @ 2008-01-11 21:29 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <579DF776-4F4E-464C-88DB-B22C2EC291BD@sb.org>
Hi,
On Fri, 11 Jan 2008, Kevin Ballard wrote:
> Somehow I managed to change the case of a directory without git
> realizing it. I thought I issued `git mv CS4536 cs4536` but since that
> won't work in my efforts to reproduce the problem, I must have simply
> issued the `mv` outside of git and then re-added it.
>
> Anyway, here's the state of my directory:
>
> kevin@KBALLARD:~/Documents/School/C07> git ls-tree HEAD
> 040000 tree b47c8103e2e01fcf145bdc237c0e56ffc61f1c47 CS4536
> 040000 tree dbf7fc51ef3effebdf9b4e9172e4c86cae52b163 cs4536
> 040000 tree 15834a7b6534a285bf6930be4e5404b37e1dc718 ece3601
> 040000 tree 62d229b8c4a389b550df20a3752d666c48c767a4 ma2071
>
> Note that I have both versions of the directory present. Unfortunately,
> only one of them can be present on the filesystem. If I run `mv cs4536
> CS4536; git reset --hard` I end up with a different working tree.
>
> Git should be able to detect this sort of conflict on a case-insensitive
> system.
Do not blame git for the shortcomings of your setup!
However, as luck has it, I looked into this issue again, as somebody
raised it with msysgit (for obvious reasons; file systems on Windows are
case challenged). If you are serious about this problem, I can give you
tons of pointers how to go solve it. (Although I might be disconnected
this weekend, because of the lack of competence of the IT department
here.)
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-11 21:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LSU.1.00.0801112127040.31053@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
On Jan 11, 2008, at 4:29 PM, Johannes Schindelin wrote:
>> Git should be able to detect this sort of conflict on a case-
>> insensitive
>> system.
>
> Do not blame git for the shortcomings of your setup!
Oh, I'm not surprised git doesn't handle this case, nor do I think
git's required to. I merely think that, given the increasing relevance
of OS X and the fact that it uses a case-insensitive system by
default, this sort of problem is going to occur more and more
frequently and it's quite a learning experience trying to fix it by
hand. It would be very helpful if git could detect these problems
itself.
> However, as luck has it, I looked into this issue again, as somebody
> raised it with msysgit (for obvious reasons; file systems on Windows
> are
> case challenged). If you are serious about this problem, I can give
> you
> tons of pointers how to go solve it. (Although I might be
> disconnected
> this weekend, because of the lack of competence of the IT department
> here.)
I think I've got a handle on it. I've already expunged the mis-cased
file using git-rebase to remove the offending commit, now I just need
to rewrite the second commit's message so it looks like the original
commit (luckily I didn't do any work in the directory before I re-
cased it). Thanks anyway.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2432 bytes --]
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Robin Rosenberg @ 2008-01-11 21:59 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <CCDF6298-4F17-4F70-AF00-E63F2C2A2816@sb.org>
fredagen den 11 januari 2008 skrev Kevin Ballard:
> Wow, it's even worse. I made a tmp branch and used git-filter-branch
> to remove the commit that introduced CS4536, leaving only the cs4536
> directory. But now if I try and run `git co master` it refuses, as it
> thinks it's going to overwrite the untracked file CS4536/
> introduction.txt. I believe it's actually seeing the tracked file
> cs4536/introduction.txt.
I think you should try an index filter. That should help you avoid file system problems.
-- robin
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Johannes Schindelin @ 2008-01-11 22:05 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <34F43A68-6041-42BE-85BD-3EF971875C0F@sb.org>
Hi,
On Fri, 11 Jan 2008, Kevin Ballard wrote:
> On Jan 11, 2008, at 4:29 PM, Johannes Schindelin wrote:
>
> > If you are serious about this problem, I can give you tons of pointers
> > how to go solve it. (Although I might be disconnected this weekend,
> > because of the lack of competence of the IT department here.)
>
> I think I've got a handle on it. I've already expunged the mis-cased
> file using git-rebase to remove the offending commit, now I just need to
> rewrite the second commit's message so it looks like the original commit
> (luckily I didn't do any work in the directory before I re-cased it).
> Thanks anyway.
I was not talking about fixing it up in your repository. If you really
think that git should help you, you gotta teach it to. Because people who
do not experience the same as you will be less likely to feel the urge to
teach git to help in that situation (because they did not experience that
situation yet). For example, I am one of these people. And I guess a lot
of these people hang out on this list.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Linus Torvalds @ 2008-01-11 22:08 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Johannes Schindelin, git
In-Reply-To: <34F43A68-6041-42BE-85BD-3EF971875C0F@sb.org>
On Fri, 11 Jan 2008, Kevin Ballard wrote:
>
> Oh, I'm not surprised git doesn't handle this case, nor do I think git's
> required to. I merely think that, given the increasing relevance of OS X and
> the fact that it uses a case-insensitive system by default, this sort of
> problem is going to occur more and more frequently and it's quite a learning
> experience trying to fix it by hand. It would be very helpful if git could
> detect these problems itself.
I do agree that we could/should do something to help with case-insensitive
filesystems.
I absolutely *detest* those things, and I think that people who design
them are total morons - with MS-DOS, you could understand it (people
didn't know better), but with OS X?
But considering that they exist, we should probably offer at least *some*
help for people who didn't realize that you could make OS X behave better.
However, it's not like there is even a simple solution. The right place to
do that check would probably be in "add_index_entry()", but doing a check
whether the same file already exists (in a different case) is simply
*extremely* expensive for a very critical piece of code, unless we were to
change that index data structure a lot (ie add a separate hash for the
filenames).
Inside the Linux kernel, we have support for insane case-insensitive
filesystems, and it really does need a lot of effort to do an even
half-way decent thing while not penalizing the sane case. So it's hard.
(And that's totally ignoring the fact that case-insensitivity then also
has tons of i18n issues and can get *really* messy - in the above I'm
talking purely about the issues that would hit us even with 7-bit straight
ASCII).
So handling case-sensitivity (even when you restrict it to ASCII-only) is
actually rather messy. The obvious thing to do is to sort everything using
a case-insensitive sort, but that in turn would break all the rules git
has for the sorting of trees.
So you can't just change the sort order: you'd literally have to have two
*different* lookup keys for the index (the "strict sort" and the "case-
insensitive sort"), and keep them both around.
Almost all of the code that actually touches the index is in read-cache.c,
and it's not like that is a very complex data structure (or a very big
file), so adding another key to the sorting probably wouldn't be too
horrid. But it's definitely a lot more than just a few lines of code!
Linus
^ permalink raw reply
* git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-11 22:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: drafnel
I got this message from git-commit:
$ git commit -a
<edit message, :wq>
fatal: Out of memory? mmap failed: Bad file descriptor
Create commit <my_prompt_string>
The exit status was 128.
Looks like the commit was successful though.
The partial message 'Create commit ' comes from print_summary()
in builtin-commit.c which is _after_ the actual commit.
$ git --version
git version 1.5.4.rc2.84.gf85fd-dirty
It was compiled with NO_CURL=1. The dirtiness comes from the
patches I submitted for relink earlier today.
The other possible clue is that this repo is on NFS.
-brandon
^ 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