* 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
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Charles Bailey @ 2008-01-11 22:18 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, drafnel
In-Reply-To: <4787E981.7010200@nrlssc.navy.mil>
Brandon Casey wrote:
> 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
I have seen this exact type of failure (commit reports possible
oom, but commit appears to have succeeded) with most recent gits.
I had assumed that it was because I was using a very large
repository (experimenting with using git for general backup
purposes) on a machine with not too much memory.
Perhaps there's a real bug in here somewhere after all.
Charles.
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Marco Costalba @ 2008-01-11 22:19 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, drafnel
In-Reply-To: <4787E981.7010200@nrlssc.navy.mil>
On Jan 11, 2008 11:11 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
> 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
>
I had the same message about one week ago for few times, same
symptoms, I didn't had the time to dig it out and today it seems no
more happening.
> 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.
>
I don't use any NFS mount.
Marco
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Sam Ravnborg @ 2008-01-11 22:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <alpine.LSU.1.00.0801112116180.31053@racer.site>
On Fri, Jan 11, 2008 at 09:18:49PM +0000, Johannes Schindelin wrote:
> 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.
Some of the people I have in my mind I will certainly not call lazy, but the
other part of the description is a fine match.
> That might sound cynical, but you will have to _show_ me different
> examples to make me reconsider.
I just wanted to say that things looks different in some places of the
world nad for some types of development.
I do not even know what I should try to make you reconsider - as I did not
follow the full thread. Just stumbled over this statement.
Sam
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-11 22:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: drafnel
In-Reply-To: <4787E981.7010200@nrlssc.navy.mil>
It's reproduceable for me by amending the commit.
Any suggestions?
-brandon
Brandon Casey wrote:
> 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
>
> -
> 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
>
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: David Kastrup @ 2008-01-11 23:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kevin Ballard, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801111356000.3148@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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),
Ah, those young whippersnappers who think they are so smart... there is
a history to that, you know. Early character sets (like those on punch
cards) had just capital letters. Even when lowercase letters were
introduced, those tended to use more space (12 instead of 6 bit) and be
harder to print (and the line printers who churned out 40 lines per
second did not bother with such finesse, anyway). But capital letters
are not designed for readability of long lines. So when printing or
even screen terminals came into use, one tended to prefer writing in
lowercase letters. Which actually had the uppercase code points
usually. Some early microcomputers (for which CP/M was designed)
actually were hooked up with a "standard" 50 or 110 Baud teletype as I/O
device, and those tended to have only lowercase letters, too, in their
basic incantations. So CP/M, not knowing which kind of input device
would be used and whether it would prefer (or offer exclusively) upper
or lower case, had case-insensitive commands, and consequently also
case-insensitive file names. And QDOS (whence MSDOS) was basically
intended to be a CP/M ripoff.
> but with OS X?
OS X has an Apple inheritance, Apple has the same inheritance as other
microcomputers which includes a case-insensitive BASIC interpreter
(BASIC again coming from old teletype times). It is, again, a decision
to drag along old history.
But actually, there is more to it nowadays: two file names containing ü,
but one with a single letter and one with combining accent, look exactly
the same. If they don't act exactly the same, one opens up quite a hole
for spoofing attacks. Well, probably hard to avoid (since things like
uppercase Alpha and uppercase A look the same and need to be different
code points, too). But one also opens a can of worms for confusion. So
the problem of canonical file names does not go away just with case
sensitivity.
> 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.
It is not like Linux does not support some case-insensitive file system
types, too. So the same problems can be had there as well.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Daniel Barkalow @ 2008-01-11 23:11 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, git
In-Reply-To: <1200022189-2400-1-git-send-email-mlevedahl@gmail.com>
I'm not sure if this is actually relevant to your situation, but I've got
a patch (which I'll probably send post-1.5.4) to allow configuration of
aliases for URLs, such that git will rewrite (for example)
master.kernel.org:/pub/... to git://git.kernel.org/pub/...; if you're
reading a discussion between kernel.org users on the linux-kernel mailing
list and you don't have a kernel.org account, and you want to try things,
this patch makes it a lot easier (cut-and-paste the URL you can't actually
use, and it uses the variant you prefer without making you deal with it
for each URL).
If, for each person, there's a single best access method to the data, but
there's no single access method that works for all of the participants,
they could use this patch, and use per-user configuration to replace all
of the other possible names with the one they have to use.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-11 23:12 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <85abnc6jsg.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Jan 11, 2008, at 6:10 PM, David Kastrup wrote:
>> 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.
>
> It is not like Linux does not support some case-insensitive file
> system
> types, too. So the same problems can be had there as well.
In addition, while there is an option for HFS+ Case-Sensitive, using
that can cause bad things to happen as Mac OS X programs are written
under a case-insensitive assumption and may behave badly when
presented with a case-sensitive filesystem.
-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: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-11 23:36 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20801111210n7bd7a71cw437819aa6253ae85@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
> @@ -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")));
> +
I'd almost agree with this patch if if added AUTHOR but not
COMMITTER, and only when AUTHOR is different from me. That
would help reassure anybody while amending other's changes.
COMMITTER is always me and I should not reminded with extra
lines that waste precious screen real estate.
And no, I did not check if your change correctly supports the
use case of amending other's changes. But if I recall the code
correctly, I suspect that your change doesn't. The recorded
author is determined after the log message is prepared, way
later.
I strongly agree with Dscho that this change needs to be
defended with a good description on the reason why this is good.
If the reason is "newbie protection", I do not think this is a
good change at all. Newbie protection is never a good reason to
make people who graduated that state to pay extra price
unconditionally.
^ permalink raw reply
* Re: [PATCH] gitk: Update and fix Makefile
From: Paul Mackerras @ 2008-01-11 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Stimming, git
In-Reply-To: <7vfxx43f5r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I applied three patches since last pull from you and pushed the
> > result (pure gitk part) out in gitk branch:
> >
> > master.kernel.org:/pub/scm/git/git.git/ gitk
> >
> > Could you please pull?
I get:
~/gitk$ git pull master.kernel.org:/pub/scm/git/git.git/ gitk
error: no such remote ref refs/heads/gitk
fatal: Fetch failure: master.kernel.org:/pub/scm/git/git.git/
> Sorry, this was a very ill-behaved pull request. The patches
> picked up from the list I applied are these three:
>
> Charles Bailey (1):
> gitk: Fix the Makefile to cope with systems lacking msgfmt
>
> Christian Stimming (2):
> gitk: Fix typo in user message.
I was going to ignore this one since "descendent" is actually a valid
alternate spelling, and is the one I am used to. However, I don't
have a strong feeling about it.
Paul.
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Junio C Hamano @ 2008-01-11 23:48 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, drafnel
In-Reply-To: <4787F1F5.2010905@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> It's reproduceable for me by amending the commit.
Reliably reproducible? Can you build with "-O0 -g" and run
"commit --amend" under gdb?
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Robin Rosenberg @ 2008-01-11 23:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kevin Ballard, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801111356000.3148@woody.linux-foundation.org>
fredagen den 11 januari 2008 skrev Linus Torvalds:
> 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?
Could it be some comfort that the other SCM's I know of make a mess of
these cases, regardless of the number of digits in the price tag.
[...]
> 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!
Could we just have a lookup table index extension for identifying the
duplicates (when checking is enabled using core configuration option #3324)?
That table would keep a mapping from a normalized form (maybe include
canonical encoding while we're at it) to the actual octet sequence(s) used.
Many operations would translate any supplied form throug the table before
doing the lookup so if we have Foo.h and give FOO.h to git add, it would
notice and perform add (update index) on Foo.h instead as that is the form we
alreay know (or refuse yielding an error message; pick your poison). And,
well you get the picture.
-- robin
^ permalink raw reply
* Re: [PATCH] gitk: Update and fix Makefile
From: Junio C Hamano @ 2008-01-11 23:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Christian Stimming, git
In-Reply-To: <18311.64910.643392.816623@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> I get:
>
> ~/gitk$ git pull master.kernel.org:/pub/scm/git/git.git/ gitk
> error: no such remote ref refs/heads/gitk
> fatal: Fetch failure: master.kernel.org:/pub/scm/git/git.git/
My bash history tells me that I only did push --dry-run. Stupid
me. Sorry about the noise.
>> Christian Stimming (2):
>> gitk: Fix typo in user message.
>
> I was going to ignore this one since "descendent" is actually a valid
> alternate spelling, and is the one I am used to. However, I don't
> have a strong feeling about it.
I agree with you that both are valid spellings, but when I
received 9e5d87d49070fe0463040e826824d6ce41beb089, I consulted a
couple of dictionaries and descendant seemed to be more widely
used. Besides, I think the german translation update depends on
it ;-).
Anyway, I pushed it (this time without --dry-run) to
master.kernel.org:/pub/scm/git/git.git/ gitk-for-paulus
Sorry, and thanks.
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-12 0:03 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <200801120026.01930.robin.rosenberg@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
Speaking of normalizing composed sequences, could that be the cause
for the following?
kevin@KBALLARD:~/Dev/git> ls
kevin@KBALLARD:~/Dev/git> ls -a
./ ../ .git/ .gitignore
kevin@KBALLARD:~/Dev/git> git reset --hard
HEAD is now at 58beb2c... Trim leading / off of paths in git-svn
prop_walk
kevin@KBALLARD:~/Dev/git> git st
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# gitweb/test/Märchen
nothing added to commit but untracked files present (use "git add" to
track)
Some further exploration seems to support my cause:
kevin@KBALLARD:~/Dev/git> git ls-files gitweb/test
"gitweb/test/M\303\244rchen"
gitweb/test/file with spaces
gitweb/test/file+plus+sign
kevin@KBALLARD:~/Dev/git/gitweb/test> ls Märchen | xxd
0000000: 4d61 cc88 7263 6865 6e0a Ma..rchen.
As you can see, git has the file tracked using M\303\244rchen, where
\303\244 (or 0xC3A4, or U+00E4) is Latin Small Letter A With
Diaeresis, but the filesystem reports it as "Ma\xCC\x88rchen" where
0xCC88 (or U+0308) is Combining Diaeresis.
In other words, the git repository itself exhibits a problem under OS
X. I'm not sure if I didn't notice this untracked file before, or if
the filesystem (or the index) actually used the other form previously,
but regardless there's a problem that I believe would be present even
if I was using Case-Sensitive HFS+.
-Kevin Ballard
On Jan 11, 2008, at 6:26 PM, Robin Rosenberg wrote:
> Could we just have a lookup table index extension for identifying the
> duplicates (when checking is enabled using core configuration option
> #3324)?
> That table would keep a mapping from a normalized form (maybe include
> canonical encoding while we're at it) to the actual octet
> sequence(s) used.
--
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] Document some default values in config.txt
From: Junio C Hamano @ 2008-01-12 0:06 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200801112211.13816.barra_cuda@katamail.com>
I am not a very big fan of describing the default values, but I
would grudgingly agree they should be mentioned somewhere.
I dropped all the "which in turn defaults to" as they will
invite maintenance nightmare in the future, though.
Thanks.
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Stephen Sinclair @ 2008-01-12 0:09 UTC (permalink / raw)
To: git
In-Reply-To: <7v3at42avd.fsf@gitster.siamese.dyndns.org>
> I'd almost agree with this patch if if added AUTHOR but not
> COMMITTER, and only when AUTHOR is different from me. That
> would help reassure anybody while amending other's changes.
> COMMITTER is always me and I should not reminded with extra
> lines that waste precious screen real estate.
The purpose of my patch was to remind _myself_ what my name is, in
case I hadn't configured it correctly.
But I can see this use case also being useful.
> And no, I did not check if your change correctly supports the
> use case of amending other's changes. But if I recall the code
> correctly, I suspect that your change doesn't. The recorded
> author is determined after the log message is prepared, way
> later.
Sure, that's possible.
> I strongly agree with Dscho that this change needs to be
> defended with a good description on the reason why this is good.
The patch was really to go along with my RFC about the idea. I guess
it was too early to post a possible implementation.
(I have only just begun to look at the git code after all..)
> If the reason is "newbie protection", I do not think this is a
> good change at all. Newbie protection is never a good reason to
> make people who graduated that state to pay extra price
> unconditionally.
I agree. I wouldn't necessarily say it is "newbie protection", so
much as a friendly reminder of what username you are using while doing
a commit, which, as I said, might not be as expected if you have just
sat down at a new machine. Especially if you have been using git for
a long time on a single machine, it is something you might easily
forget to configure. (As I have, several times now.) I agree,
however, that this it is not necessarily worth having this on the
screen every time you do a commit, for the exceptional instance where
it might be wrong. Perhaps more usefully it could appear only if you
haven't yet created a user.email and user.name config entry.
Actually in my honest opinion, the default of using the computer's
host name and login is pretty much _never_ right, but I thought this
patch might be less intrusive than introducing a new error message.
I do have a slightly better patch now that has a more informative
message and uses git_committer_info() and git_author_info(), however
I'll wait for any more opinions before posting it.
In retrospect, I guess I could just as easily solve my problem by
introducing a post-receive hook for my personal repo that issues a
warning for commits not configured to my email address.
Steve
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Robin Rosenberg @ 2008-01-12 0:15 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <1973E1D5-C8CC-4979-A085-85A2C5A13E57@sb.org>
lördagen den 12 januari 2008 skrev Kevin Ballard:
> Speaking of normalizing composed sequences, could that be the cause
> for the following?
[...]
> kevin@KBALLARD:~/Dev/git/gitweb/test> ls Märchen | xxd
> 0000000: 4d61 cc88 7263 6865 6e0a Ma..rchen.
>
> As you can see, git has the file tracked using M\303\244rchen, where
> \303\244 (or 0xC3A4, or U+00E4) is Latin Small Letter A With
> Diaeresis, but the filesystem reports it as "Ma\xCC\x88rchen" where
> 0xCC88 (or U+0308) is Combining Diaeresis.
Yes that is due to normalization. When adding a file by name git uses the user
supplied name, but when adding files indirectly it gets the names from the
file system without denormalizing them. Likewize status gets the names from
the file system without denormalizing and thus you get a mismatch.
-- robin
^ permalink raw reply
* Re: [PATCH decompress BUG] Fix decompress_next_from() wrong argument value
From: Junio C Hamano @ 2008-01-12 0:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801111247l1ccf171ene5b53b8d6841a864@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Patch to be applied above decompress helper series.
No way. That will mean that the resulting series will start
with a known bug.
> 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.
Pardon me. Are you talking about a bug you introduced earlier
in your own series that hasn't been applied (and you very well
know will not be until 1.5.4 is out, now we are deep in -rc
cycle)?
If so, you did a great disservice to me by sounding as if you
are blaming somebody else's existing bug. I wasted some time
hunting for a non-existent bug in the code that is being readied
for 1.5.4 final for quite some time, in order to pick only the
relevant "fix" from your patch.
It turns out, luckily, existing code did not have such a bug.
What a relief for the maintainer in bugfix-only freeze mode.
Next time around, please mark the patch on the Subject: line to
be squashed to your earlier [PATCH 5/6] before [PATCH 6/6].
That will also solve the bisectability problem.
Anyway, thanks. I was planning to queue the series in 'pu' or
'next' after tagging -rc3, so not be silent and giving a proper
fix was the right thing to do. My above rant is just about the
presentation.
^ permalink raw reply
* Re: [PATCH] Add committer and author names to top of COMMIT_EDITMSG.
From: Junio C Hamano @ 2008-01-12 0:22 UTC (permalink / raw)
To: Stephen Sinclair; +Cc: git
In-Reply-To: <9b3e2dc20801111609t3103af1frc23519cab43ae8be@mail.gmail.com>
"Stephen Sinclair" <radarsat1@gmail.com> writes:
>> I'd almost agree with this patch if if added AUTHOR but not
>> COMMITTER, and only when AUTHOR is different from me. That
>> would help reassure anybody while amending other's changes.
>> COMMITTER is always me and I should not reminded with extra
>> lines that waste precious screen real estate.
>
> The purpose of my patch was to remind _myself_ what my name is, in
> case I hadn't configured it correctly.
In that case, I would imagine a rule like this would be more
appropriate than unconditionally showing AUTHOR/COMMITTER in all
cases:
* If AUTHOR_NAME+EMAIL is different from AUTHOR_NAME+EMAIL that
I would normally get for myself, or
* If AUTHOR_NAME+EMAIL contains garbage identifier commonly
found when misconfigured (e.g. ".(none)" at the end of
e-mail),
then show AUTHOR. In addition, if it is the latter case, give
hints to configure before casting the mistake in stone.
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Kevin Ballard @ 2008-01-12 0:25 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <200801120115.41274.robin.rosenberg@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Jan 11, 2008, at 7:15 PM, Robin Rosenberg wrote:
> lördagen den 12 januari 2008 skrev Kevin Ballard:
>> Speaking of normalizing composed sequences, could that be the cause
>> for the following?
> [...]
>> kevin@KBALLARD:~/Dev/git/gitweb/test> ls Märchen | xxd
>> 0000000: 4d61 cc88 7263 6865 6e0a Ma..rchen.
>>
>> As you can see, git has the file tracked using M\303\244rchen, where
>> \303\244 (or 0xC3A4, or U+00E4) is Latin Small Letter A With
>> Diaeresis, but the filesystem reports it as "Ma\xCC\x88rchen" where
>> 0xCC88 (or U+0308) is Combining Diaeresis.
>
> Yes that is due to normalization. When adding a file by name git
> uses the user
> supplied name, but when adding files indirectly it gets the names
> from the
> file system without denormalizing them. Likewize status gets the
> names from
> the file system without denormalizing and thus you get a mismatch.
Is there a reason for this? It seems like it would be trivial to end
up with misdiagnosed "untracked" files when using any language other
than English given this behaviuor.
-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: Junio C Hamano @ 2008-01-12 0:27 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Robin Rosenberg, Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <191B60D7-FD89-48D8-8D48-C91645D4814D@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> Is there a reason for this? It seems like it would be trivial to end
> up with misdiagnosed "untracked" files when using any language other
> than English given this behaviuor.
No. The assumption of the code has always been that sane
filesystems would return from readdir() the names you gave from
creat().
^ permalink raw reply
* Re: gitk font configuration
From: Paul Mackerras @ 2008-01-12 0:29 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712201318270.27181@ds9.cixit.se>
Peter Karlsson writes:
> I can configure git gui's fonts through its preferences, but gitk does
> not have font settings.
It does, now, in the preferences window (do Edit->Preferences).
Paul.
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Junio C Hamano @ 2008-01-12 0:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Linus Torvalds, Kevin Ballard, Johannes Schindelin, git
In-Reply-To: <200801120026.01930.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> Could we just have a lookup table index extension for identifying the
> duplicates (when checking is enabled using core configuration option #3324)?
> That table would keep a mapping from a normalized form (maybe include
> canonical encoding while we're at it) to the actual octet sequence(s) used.
I would agree that the index extension, if we ever are going to
do this, would be the right place to store this information, at
the single repository level.
However, this opens up a can of worms. What's the canonical key
should be? If you want to protect yourself from a unicode
normalizing filesystem, you would use one canonicalization,
while if you want to protect from a case losing filesystem you
would use another? Or do we at the same time downcase and NFD
normalize at the same time and be done with it?
And where should the configuration be stored? If a project
wants to be interoperable across Linux and vfat, for example,
that canonicalization needs to be enabled in repositories of all
participants, be they on Linux or vfat, so that people on Linux
can be prevented from creating and register two files xt_mark.c
and xt_MARK.c in the same directory, so that people who extract
the source on vfat won't have troubles.
Which means the information needs to be in-tree. But that
should not be in .gitattributes (which by definition is for
per-path things).
^ permalink raw reply
* [PATCH] manpages: linking all mail-related commands
From: Humberto Diogenes @ 2008-01-11 23:48 UTC (permalink / raw)
To: git; +Cc: gitster, humberto
From: humberto <humberto@digi.com.br>
---
Documentation/git-am.txt | 6 ++++--
Documentation/git-apply.txt | 4 ++++
Documentation/git-format-patch.txt | 7 ++++---
Documentation/git-imap-send.txt | 5 +++++
Documentation/git-send-email.txt | 6 ++++++
5 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index e4a6b3a..fd00fc1 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -144,8 +144,10 @@ names.
SEE ALSO
--------
-gitlink:git-apply[1].
-
+gitlink:git-apply[1],
+gitlink:git-format-patch[1],
+gitlink:git-imap-send[1],
+gitlink:git-send-email[1]
Author
------
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index c1c54bf..53fa937 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -189,6 +189,10 @@ If --index is not specified, then the submodule commits in the patch
are ignored and only the absence of presence of the corresponding
subdirectory is checked and (if possible) updated.
+See Also
+--------
+gitlink:git-am[1]
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f0617ef..0221b6d 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -184,10 +184,11 @@ git-format-patch -3::
Extract three topmost commits from the current branch
and format them as e-mailable patches.
-See Also
+SEE ALSO
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
-
+gitlink:git-am[1],
+gitlink:git-imap-send[1],
+gitlink:git-send-email[1]
Author
------
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index eca9e9c..8397dcb 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -48,6 +48,11 @@ BUGS
----
Doesn't handle lines starting with "From " in the message body.
+SEE ALSO
+--------
+gitlink:git-am[1],
+gitlink:git-format-patch[1],
+gitlink:git-send-email[1]
Author
------
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 16bfd7b..9214596 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -143,6 +143,12 @@ sendemail.chainreplyto::
sendemail.smtpserver::
Default smtp server to use.
+SEE ALSO
+--------
+gitlink:git-am[1],
+gitlink:git-format-patch[1],
+gitlink:git-imap-send[1]
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
--
1.5.3.6
^ permalink raw reply related
* Re: Re-casing directories on case-insensitive systems
From: Johannes Schindelin @ 2008-01-12 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Ballard, Robin Rosenberg, Linus Torvalds, git
In-Reply-To: <7v7iif28i2.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 11 Jan 2008, Junio C Hamano wrote:
> Kevin Ballard <kevin@sb.org> writes:
>
> > Is there a reason for this? It seems like it would be trivial to end
> > up with misdiagnosed "untracked" files when using any language other
> > than English given this behaviuor.
>
> No. The assumption of the code has always been that sane filesystems
> would return from readdir() the names you gave from creat().
We do not really have to rehash that whole discussion for the Nth time, do
we?
Ciao,
Dscho
^ 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