* Re: [FEATURE REQUEST] git-svn format-patch
From: Jean-Luc Herren @ 2008-01-15 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <c0f2d4110801150559x155ffabaj6bea52715522a070@mail.gmail.com>
Chris Ortman wrote:
> Something that would really benefit the folks who use git to manage a
> subversion repository (such as myself) would be a special format-patch
> command for git-svn that creates a tortoise svn compatible diff file.
Isn't it that TortoiseSVN is simply being too strict about the
diff format it accepts? Since even GNU patch reads and applies
them fine (I didn't test it thoroughly though), I would assume git
diffs follow some sort of standard (couldn't find it though) for
the unified diff format, or at least was designed to not break
patch. So in the long term, I think this is rather or at least
also something to be addressed in TortoiseSVN.
jlh
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Paul Umbers @ 2008-01-15 20:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080115200437.GB3213@steel.home>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
git ls (see below) returns nothing - it looks like the object doesn't
exist at all. I've attached a .zip of the entire test directory (one
text file plus .git). This is after "git init" followed by "git add ."
What do you think?
>
> Does the object exists at all? Try
>
> ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152
>
> Is it possible to get a hold of this repo (just the .git directly
> after "git add .")? It would be interesting to see the nature of the
> corruption.
>
>
--
Computer Science is no more about computers than astronomy is about telescopes.
--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP
paul.umbers@gmail.com
[-- Attachment #2: test.zip --]
[-- Type: application/zip, Size: 8621 bytes --]
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Linus Torvalds @ 2008-01-15 20:09 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen,
Kristian H?gsberg
In-Reply-To: <478D0CDA.5050709@nrlssc.navy.mil>
On Tue, 15 Jan 2008, Brandon Casey wrote:
>
> In that same vein, just above your changes in prepare_index() is:
>
> if (!pathspec || !*pathspec) {
> fd = hold_locked_index(&index_lock, 1);
> refresh_cache(REFRESH_QUIET);
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) || commit_locked_index(&index_lock))
> die("unable to write new_index file");
> commit_style = COMMIT_AS_IS;
> return get_index_file();
> }
Yeah, I think that may be the one that got you. I obviously couldn't
follow the exact path through the code, I was just looking at the trace of
system calls and found that one thing that looked like it was your case,
but it's entirely possible that it was another path of the index lock file
that causes it.
Your patch seems "ObviouslyCorrect(tm)".
Linus
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-15 20:04 UTC (permalink / raw)
To: Paul Umbers; +Cc: git
In-Reply-To: <a5eb9c330801140921m63b1b8a9pe67bf6f0d2e58dba@mail.gmail.com>
Paul Umbers, Tue, Jan 15, 2008 16:21:15 +0100:
> I've just completely uninstalled (ie: deleted) and re-installed
> cygwin, ensuring that bin mode was selected for the install (I'm sure
> it was before, that's the default). "mount" confirms that everything
> is mounted in binmode.
Ok, so it is a bit more complicated...
Paul Umbers, Mon, Jan 14, 2008 18:21:44 +0100:
> Trying to create a repository under the cygwin install of git, windows
> XP Pro. I can create the initial repository OK using "git init" and
> add files using "git add .", but when I come to commit I get the
> messages:
>
> error: invalid object d9b06fceac52f6c24357e6a7f85c601088381152
> fatal: git-write-tree: error building trees
Does the object exists at all? Try
ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152
Is it possible to get a hold of this repo (just the .git directly
after "git add .")? It would be interesting to see the nature of the
corruption.
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Kristian Høgsberg @ 2008-01-15 20:00 UTC (permalink / raw)
To: Brandon Casey
Cc: Linus Torvalds, Git Mailing List, drafnel, Junio C Hamano,
Alex Riesen
In-Reply-To: <478D0CDA.5050709@nrlssc.navy.mil>
On Tue, 2008-01-15 at 13:43 -0600, Brandon Casey wrote:
> Linus Torvalds wrote:
> >
> > On Tue, 15 Jan 2008, Brandon Casey wrote:
> >> Linus Torvalds wrote:
> >>> It would obviously be interesting to see the base repository and the
> >>> commit you are trying to do - is that possibly publicly available?
> >> I wish it was.
> >
> > It's ok, I found the bug in your full strace.
>
> Good catch, but that wasn't it. Still getting the same error.
>
> > and now it's trying to close that fd *again*
>
> In that same vein, just above your changes in prepare_index() is:
>
> if (!pathspec || !*pathspec) {
> fd = hold_locked_index(&index_lock, 1);
> refresh_cache(REFRESH_QUIET);
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) || commit_locked_index(&index_lock))
> die("unable to write new_index file");
> commit_style = COMMIT_AS_IS;
> return get_index_file();
> }
>
> If I followed hold_locked_index() correctly, then fd and index_lock.fd
> are equal, and commit_locked_index() does a close(lk->fd) making the
> close(fd) above, redundant (or vice-versa).
To my defense, the lockfile API is used a little inconsitently in git.
Many places in git does a close(fd) and the call commit_locked_index(),
which will close the fd again. Normally that will just cause an EBADFD
which we ignore, but the problem here is that there's a longer time
between close(fd) and the commit/rollback of the lock file. I guess the
correct way to use the API is to never close the fd manually, but I
copied and pasted the lockfile use in builtin-commit.c from somewhere
else and along with it the double close.
There's four close(fd) calls in prepare_index() and they're all
incorrect. The open fd's are cleaned up in rollback_index_files() and
shouldn't be closed manually. The patch below gets rid of the extra
close() calls and should fix the problem.
cheers,
Kristian
diff --git a/builtin-commit.c b/builtin-commit.c
index 73f1e35..4494c9c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -212,7 +212,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
int fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(0, also ? prefix : NULL, pathspec);
refresh_cache(REFRESH_QUIET);
- if (write_cache(fd, active_cache, active_nr) || close(fd))
+ if (write_cache(fd, active_cache, active_nr))
die("unable to write new_index file");
commit_style = COMMIT_NORMAL;
return index_lock.filename;
@@ -231,7 +231,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
fd = hold_locked_index(&index_lock, 1);
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
- close(fd) || commit_locked_index(&index_lock))
+ commit_locked_index(&index_lock))
die("unable to write new_index file");
commit_style = COMMIT_AS_IS;
return get_index_file();
@@ -273,7 +273,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
fd = hold_locked_index(&index_lock, 1);
add_remove_files(&partial);
refresh_cache(REFRESH_QUIET);
- if (write_cache(fd, active_cache, active_nr) || close(fd))
+ if (write_cache(fd, active_cache, active_nr))
die("unable to write new_index file");
fd = hold_lock_file_for_update(&false_lock,
@@ -289,7 +289,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
add_remove_files(&partial);
refresh_cache(REFRESH_QUIET);
- if (write_cache(fd, active_cache, active_nr) || close(fd))
+ if (write_cache(fd, active_cache, active_nr))
die("unable to write temporary index file");
return false_lock.filename;
}
^ permalink raw reply related
* [PATCH] git-gui: Improve German translation.
From: Christian Stimming @ 2008-01-15 19:44 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, git
[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]
Change translation of "clone" back to "klonen" because "kopieren" is a
much broader term than this particular git action.
---
This patch is against git-gui.git with my previous de.po patch
of 2008-01-07 already applied. Patch also attached
in case whitespace was messed up.
po/de.po | 14 +++++++-------
po/glossary/de.po | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index 251bbba..2dfe07e 100644
--- a/po/de.po
+++ b/po/de.po
@@ -8,7 +8,7 @@ msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-11-24 10:36+0100\n"
-"PO-Revision-Date: 2008-01-07 21:52+0100\n"
+"PO-Revision-Date: 2008-01-15 20:33+0100\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
@@ -914,11 +914,11 @@ msgstr "Neu..."
#: lib/choose_repository.tcl:93 lib/choose_repository.tcl:468
msgid "Clone Existing Repository"
-msgstr "Projektarchiv kopieren"
+msgstr "Projektarchiv klonen"
#: lib/choose_repository.tcl:99
msgid "Clone..."
-msgstr "Kopieren..."
+msgstr "Klonen..."
#: lib/choose_repository.tcl:106 lib/choose_repository.tcl:978
msgid "Open Existing Repository"
@@ -968,7 +968,7 @@ msgstr "Datei »%s« existiert bereits."
#: lib/choose_repository.tcl:463
msgid "Clone"
-msgstr "Kopieren"
+msgstr "Klonen"
#: lib/choose_repository.tcl:476
msgid "URL:"
@@ -976,7 +976,7 @@ msgstr "URL:"
#: lib/choose_repository.tcl:496
msgid "Clone Type:"
-msgstr "Art der Kopie:"
+msgstr "Art des Klonens:"
#: lib/choose_repository.tcl:502
msgid "Standard (Fast, Semi-Redundant, Hardlinks)"
@@ -1025,7 +1025,7 @@ msgstr "Kopien von Objekten/Info/Alternates konnten nicht erstellt werden: %s"
#: lib/choose_repository.tcl:690
#, tcl-format
msgid "Nothing to clone from %s."
-msgstr "Von »%s« konnte nichts kopiert werden."
+msgstr "Von »%s« konnte nichts geklont werden."
#: lib/choose_repository.tcl:692 lib/choose_repository.tcl:906
#: lib/choose_repository.tcl:918
@@ -1086,7 +1086,7 @@ msgstr "Verzeichnis »%s« kann nicht aufgeräumt werden."
#: lib/choose_repository.tcl:897
msgid "Clone failed."
-msgstr "Kopieren fehlgeschlagen."
+msgstr "Klonen fehlgeschlagen."
#: lib/choose_repository.tcl:904
msgid "No default branch obtained."
diff --git a/po/glossary/de.po b/po/glossary/de.po
index 0e4ef86..0b33c57 100644
--- a/po/glossary/de.po
+++ b/po/glossary/de.po
@@ -7,7 +7,7 @@ msgid ""
msgstr ""
"Project-Id-Version: git-gui glossary\n"
"POT-Creation-Date: 2008-01-07 21:20+0100\n"
-"PO-Revision-Date: 2008-01-07 21:27+0100\n"
+"PO-Revision-Date: 2008-01-15 20:32+0100\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German \n"
"MIME-Version: 1.0\n"
@@ -62,7 +62,7 @@ msgstr ""
#. ""
msgid "clone [verb]"
-msgstr "kopieren"
+msgstr "klonen"
#. "A single point in the git history."
msgid "commit [noun]"
--
1.5.3.4.206.g58ba4
[-- Attachment #2: 0004-git-gui-Improve-German-translation.patch.gz --]
[-- Type: application/x-gzip, Size: 1217 bytes --]
^ permalink raw reply related
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-15 19:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen,
Kristian Høgsberg
In-Reply-To: <alpine.LFD.1.00.0801151036110.2806@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Tue, 15 Jan 2008, Brandon Casey wrote:
>> Linus Torvalds wrote:
>>> It would obviously be interesting to see the base repository and the
>>> commit you are trying to do - is that possibly publicly available?
>> I wish it was.
>
> It's ok, I found the bug in your full strace.
Good catch, but that wasn't it. Still getting the same error.
> and now it's trying to close that fd *again*
In that same vein, just above your changes in prepare_index() is:
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
close(fd) || commit_locked_index(&index_lock))
die("unable to write new_index file");
commit_style = COMMIT_AS_IS;
return get_index_file();
}
If I followed hold_locked_index() correctly, then fd and index_lock.fd
are equal, and commit_locked_index() does a close(lk->fd) making the
close(fd) above, redundant (or vice-versa).
Probably not causing the error at hand, but not good.
-brandon
diff --git a/builtin-commit.c b/builtin-commit.c
index 1e55c2e..3b4f4e2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -256,7 +256,7 @@ static char *prepare_index(int argc, const char **argv, cons
fd = hold_locked_index(&index_lock, 1);
refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) ||
- close(fd) || commit_locked_index(&index_lock))
+ commit_locked_index(&index_lock))
die("unable to write new_index file");
commit_style = COMMIT_AS_IS;
return get_index_file();
^ permalink raw reply related
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-15 19:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0801151709330.5289@eeepc-johanness>
Myself and many others have excellent luck with the cygwin version.
But the reasoning behind wanting this isn't so much for the developer
that is creating the patch as it is for the person receiving it. Most
of the projects I work on use tortoise to apply the patches and don't
typically have patch.exe
If something like this was to be accepted and become part of standard
git is there a requirement that it be written in perl or is some other
scripting language fine?
Thanks
^ permalink raw reply
* Re: How to structure a project distributed with varyingly interdependent feature branches?
From: Matt McCutchen @ 2008-01-15 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsqrvpur.fsf@gitster.siamese.dyndns.org>
Junio, thanks for the response. I am finally getting around to
following up.
On Wed, 2008-01-02 at 14:12 -0800, Junio C Hamano wrote:
> > 1. How to properly represent the history of an individual branch and
> > update it when the trunk (or the branch on which it depends) changes.
> > Right now, Wayne updates the branch by rebasing; unfortunately, if the
> > trunk changes in such a way that one of the intermediate commits no
> > longer makes sense, it is impossible to update the branch while
> > preserving a record that the intermediate commit once existed.
>
> I take this to mean a situation like this:
>
> * There is a series of patch X Y Z that implements some nicety
> not present in the mainline yet. This set applies to older
> codebase at point A.
>
> * Newer codebase B does things differently from codebase A and
> patch X is no longer needed --- IOW, what X achieves on top
> of A has already been incorporated somewhere between A and B.
> Applying Y and Z suffices to obtain that nice feature on top
> of B.
Actually, I was thinking of a change to the mainline that causes a
conflict with the patch series. For example, my repository of git was
at point A when I made the first draft X of my "gitweb: snapshot
cleanups & support for offering multiple formats" change. Then I
updated my repository and got commit B, "gitweb.perl - Optionally send
archives as .zip files", among others. When I rebased X on top of the
new master C, there was a conflict, which I resolved to produce X':
X X'
/ /
---A---...---B---...---C
But now, with refs only to C and X', I have lost the information that
the previous incarnation of X' was X.
Essentially, my objection to rebasing is that I want to keep a history
for the patch series containing all of the patched versions that I have
released (here X and X'), especially when they differ in interesting
ways (i.e., conflict resolutions), and this history should be a
first-class object that others can pull from me via the git remote
system.
I only want to use a separate patch management tool if it is integrated
with git. I have some familiarity with StGIT, and I assume guilt is
similar. StGIT uses rebasing and keeps an additional "patch changelog"
viewable by "stg log" which might seem to be what I want. The trouble
is that this changelog behaves more like a reflog than an orderly
history, and "stg refresh" does not support storing a user-entered
message describing *the change to the patch* in the patch changelog.
One option I am considering is to use StGIT and track some subset of the
StGIT area itself (.git/patches) in git.
The other approach is to maintain the feature patches/branches by
merging instead of rebasing. This has two significant advantages: patch
history is naturally kept and the full power of git's distributed merge
is available. However, it also has two significant disadvantages: the
complaint by Linus about "useless merges" mentioned in the git-rerere
manpage applies, and it's impossible to fully revert a merge (the
ancestry remains and will cause trouble if the merge is redone later).
Matt
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Linus Torvalds @ 2008-01-15 18:50 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen,
Kristian Høgsberg
In-Reply-To: <478CFAFF.6010006@nrlssc.navy.mil>
On Tue, 15 Jan 2008, Brandon Casey wrote:
>
> Linus Torvalds wrote:
> > It would obviously be interesting to see the base repository and the
> > commit you are trying to do - is that possibly publicly available?
>
> I wish it was.
It's ok, I found the bug in your full strace.
The bug really is pretty stupid:
- prepare_index() does a
fd = hold_lock_file_for_update(&false_lock, ...
...
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write temporary index file");
and the magic here is that *it*closes*the*fd*.
But that's not how "hold_lock_file_for_update()" works. It still has that
fd squirrelled away in it's "false_lock.fd", and later on, when we do
rollback_lock_file(&false_lock);
(in the COMMIT_PARTIAL case of either "commit_index_files()" or
"rollback_index_files()"), that rollback_lock_file() will do:
void rollback_lock_file(struct lock_file *lk)
{
if (lk->filename[0]) {
close(lk->fd);
unlink(lk->filename);
}
lk->filename[0] = 0;
}
and now it's trying to close that fd *again* and would normally get a
EBADF there. But in the meantime, somebody already re-used it for
something else, and what rollback_lock_file() ends up doing is to just
close some random file descriptor.
In other words, I'm pretty sure that the bug goes away with this really
ugly hack. The real problem is that that "false_lockfile" thing simply
mis-uses the whole lockfile interface. So this is not a pretty fix, but it
at least should hide the effects of the mis-use of the interface.
In other words: the file descriptor that is returned by the lock_file
interface functions *MUST*NOT* be closed. But if you violate that rule,
you'd better make sure that you also fix the effects.
Linus
---
builtin-commit.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 265ba6b..7a52224 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -308,6 +308,9 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write temporary index file");
+
+ /* We closed the false lock-file fd, make sure we don't do anything else to it */
+ false_lock.fd = -1;
return false_lock.filename;
}
^ permalink raw reply related
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-15 18:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen
In-Reply-To: <alpine.LFD.1.00.0801150931260.2806@woody.linux-foundation.org>
Linus Torvalds wrote:
> It would obviously be interesting to see the base repository and the
> commit you are trying to do - is that possibly publicly available?
I wish it was.
-brandon
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Linus Torvalds @ 2008-01-15 17:36 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen
In-Reply-To: <478CECAB.2030906@nrlssc.navy.mil>
On Tue, 15 Jan 2008, Brandon Casey wrote:
>
> Do you have a suggestion for a public place to upload? I do not have
> one of my own, and I've never used any of the 'free' services. The
> strace log is about 8.5MB, compressed to about 500K.
Can you just email the compressed one to me as an attachement, I'll put it
somewhere..
> Not that it's important, but looks like the file descriptor that
> is closed too soon is 3.
Yes and no. There obviously are several "close(3)"s in even that short
snippet, but they are for a different kind of close - they are for the
regular loose object open/mmap/close/munmap sequence which has re-used
that file descriptor.
So the *incorrect* close(3) happened some time much earlier.
The other alternative is, of course, that the 3 itself is just wrong, and
something corrupted the packfile data structures.
> > Does it reliably reproduce for any commit in the repository, or
> > reliably reproduce for one particular commit, or sometimes
> > reprooduce for one particular commit?
>
> Reliably for one particular commit.
>
> Additional commits on top of this commit complete successfully.
It would obviously be interesting to see the base repository and the
commit you are trying to do - is that possibly publicly available?
Linus
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-15 17:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen
In-Reply-To: <alpine.LFD.1.00.0801142140560.2806@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Mon, 14 Jan 2008, Brandon Casey wrote:
>> To reiterate, I only have problems with the builtin-commit,
>> i.e. 1.5.4.*, the 1.5.3.* series works correctly. Of course
>> if this is a memory corruption issue, then it could just be
>> that the pattern of memory accesses in 1.5.3 does not tweak
>> the problem.
>
> Can you do an strace of the failure case and put it up on some public
> place (it's likely going to be too big to send as email)?
I did the strace. Below is the last screenful of lines.
Do you have a suggestion for a public place to upload? I do not have
one of my own, and I've never used any of the 'free' services. The
strace log is about 8.5MB, compressed to about 500K.
$ git --version
git version 1.5.4.rc3.11.g4e67
Not that it's important, but looks like the file descriptor that
is closed too soon is 3. I got 6 when running under gdb. This is
also using the latest version of git. The results are the same
with either version (including the fd#) so I just used this one.
Junio C Hamano wrote:
> What platform is this on?
$ cat /etc/redhat-release
CentOS release 4.5 (Final)
i686
> Does it reliably reproduce for any commit in the repository, or
> reliably reproduce for one particular commit, or sometimes
> reprooduce for one particular commit?
Reliably for one particular commit.
Additional commits on top of this commit complete successfully.
If this commit is amended without error by amending with '-C HEAD'
or by using a 1.5.3 version, then additional amends or commits
will not produce the error.
-brandon
16170 mmap2(NULL, 417, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb1699000
16170 close(3) = 0
16170 munmap(0xb1699000, 417) = 0
16170 stat64("/home/casey/auto_v3.5/src_temp2/.git/objects/67/981a61208756cf4973
7ec065e7bc0d7ff1a89d", {st_mode=S_IFREG|0444, st_size=417, ...}) = 0
16170 open("/home/casey/auto_v3.5/src_temp2/.git/objects/67/981a61208756cf49737e
c065e7bc0d7ff1a89d", O_RDONLY|O_LARGEFILE) = 3
16170 mmap2(NULL, 417, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb1699000
16170 close(3) = 0
16170 munmap(0xb1699000, 417) = 0
16170 stat64("/home/casey/auto_v3.5/src_temp2/.git/objects/4e/7c1178482f4b3c52e8
afce15db3bc8419530d2", {st_mode=S_IFREG|0444, st_size=417, ...}) = 0
16170 open("/home/casey/auto_v3.5/src_temp2/.git/objects/4e/7c1178482f4b3c52e8af
ce15db3bc8419530d2", O_RDONLY|O_LARGEFILE) = 3
16170 mmap2(NULL, 417, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb1699000
16170 close(3) = 0
16170 munmap(0xb1699000, 417) = 0
16170 stat64("/home/casey/auto_v3.5/src_temp2/.git/objects/02/3777b3c0e5f7697deb
2ce738c6b38b1ec2b17c", {st_mode=S_IFREG|0444, st_size=417, ...}) = 0
16170 open("/home/casey/auto_v3.5/src_temp2/.git/objects/02/3777b3c0e5f7697deb2c
e738c6b38b1ec2b17c", O_RDONLY|O_LARGEFILE) = 3
16170 mmap2(NULL, 417, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb1699000
16170 close(3) = 0
16170 munmap(0xb1699000, 417) = 0
16170 mmap2(NULL, 996168, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EBADF (Bad file des
criptor)
16170 munmap(0xb56bd000, 33554432) = 0
16170 mmap2(NULL, 996168, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EBADF (Bad file des
criptor)
16170 write(2, "fatal: Out of memory? mmap faile"..., 55) = 55
16170 write(1, "Created commit ", 15) = 15
16170 exit_group(128) = ?
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Johannes Schindelin @ 2008-01-15 17:11 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801150907y59593407u820c7b3db556ed31@mail.gmail.com>
Him
On Tue, 15 Jan 2008, Chris Ortman wrote:
> Should this be a new command in git-svn.perl? or something in contrib?
I'd just start with an alias at first, and if it develops into something
you're happy with, send it here and let others comment on it -- also where
it should go.
Possibly the best place really would be git-svn, but it might also be less
interesting for other people, given that git-svn does not work in msysGit
yet (and your use case was for TortoiseSVN, which is Windows-only).
Ciao,
Dscho
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Pascal Obry @ 2008-01-15 17:10 UTC (permalink / raw)
To: Chris Ortman; +Cc: Johannes Schindelin, git
In-Reply-To: <c0f2d4110801150758t68714570y83e1e74acbb67325@mail.gmail.com>
Chris,
You want to use format-patch's --no-prefix option.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Pascal Obry @ 2008-01-15 17:08 UTC (permalink / raw)
To: Paul Umbers; +Cc: Alex Riesen, git
In-Reply-To: <a5eb9c330801141421g13c627e5x77afb357e2a78463@mail.gmail.com>
Paul Umbers a écrit :
> The "mount" command tells me everything I have is mounted in binmode.
> I have used Git on a default cygwin install (win XP pro) before and
> not had this problem - that's why this is so frustrating. Not sure
> what changed this time round as I tend to use defaults for most
> installations.
>
> Are you saying I need to make sure the repository directory is mounted
> in text-mode (for Windows compatibility)? I just reinstalled cygwin,
> selecting text-mode as the default. I can create a git repository, but
> "git add ." returns:
Avoid text-mode on Windows with Cygwin. I can't help with your problem
but I can tell you that Git is working fine here!
What about permissions for /cygdrive/c/test ?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-15 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0801151650240.5289@eeepc-johanness>
Should this be a new command in git-svn.perl? or something in contrib?
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Johannes Schindelin @ 2008-01-15 16:52 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801150823u7899e6dds1192b5f3bb3f7133@mail.gmail.com>
Hi,
On Tue, 15 Jan 2008, Chris Ortman wrote:
> Are you thinking to just create the standard patch but then regex
> replace the necessary lines or something different?
I was thinking exactly that. TortoiseSVN's diff format is not important
enough to git to merit a core-level change (in git), but it should be easy
enough even to write a "sed" command line with three expressions to effect
the transformation you desire.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-remote - Unset core.origin when deleting the default remote
From: Jeff King @ 2008-01-15 16:50 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, git
In-Reply-To: <478C3E75.2030801@gmail.com>
On Tue, Jan 15, 2008 at 12:02:45AM -0500, Mark Levedahl wrote:
>> I'm not sure I see the use case that this helps.
>>
> Just being thorough: the man page claims that "git remote rm foo" removes
> all mention of remote foo.
I was going to respond "by that rationale, 'git remote rm' should be
removing branch.*.remote keys that point to the removed remote". But
looking at the code, it already does that. So your change actually keeps
things consistent.
Not the choice I would have made, but I guess it just goes to show that
I use "vi" instead of "git remote". Consider my objection withdrawn.
-Peff
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-15 16:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0801151612470.5289@eeepc-johanness>
Sure, but I will probably need some guidance.
Are you thinking to just create the standard patch but then regex
replace the necessary lines or something different?
Thanks
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Johannes Schindelin @ 2008-01-15 16:13 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801150758t68714570y83e1e74acbb67325@mail.gmail.com>
Hi,
On Tue, 15 Jan 2008, Chris Ortman wrote:
> The format that TortoiseSVN expects is the same as the format of svn diff.
> The most apparent differences are
>
> [...]
Nothing a simple perl script cannot do. Wanna give it a try?
Ciao,
Dscho
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-15 15:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0801151444180.5289@eeepc-johanness>
The format that TortoiseSVN expects is the same as the format of svn diff.
The most apparent differences are
diff --git a/Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj
b/Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj
becomes
Index: Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj
and
index a0a0d38..9676e16 100644
becomes
===================================================================
and
--- a/Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj
+++ b/Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj
becomes
--- Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj (revision
4715)
+++ Facilities/EventWiring/Castle.Facilities.EventWiring.Tests/Castle.Facilities.EventWiring.Tests-vs2005.csproj (working
copy)
The rest is pretty much the same.
Thanks
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Paul Umbers @ 2008-01-15 15:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080115054807.GA3694@steel.home>
I've just completely uninstalled (ie: deleted) and re-installed
cygwin, ensuring that bin mode was selected for the install (I'm sure
it was before, that's the default). "mount" confirms that everything
is mounted in binmode.
Sadly, I still can't commit to a git repository - same problem: every
file & directory immediately shows as a "missing blob" after "git add
."
I'll try the same install on my home system (Win XP Home) and see if I
get the same problem.
Paul
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Johannes Schindelin @ 2008-01-15 14:45 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801150559x155ffabaj6bea52715522a070@mail.gmail.com>
Hi,
On Tue, 15 Jan 2008, Chris Ortman wrote:
> Something that would really benefit the folks who use git to manage a
> subversion repository (such as myself) would be a special format-patch
> command for git-svn that creates a tortoise svn compatible diff file.
How does the output of "git format-patch" differ from that? (I do not use
TortoiseSVN, and I guess a lot of people on this list don't, either...)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] treat any file with NUL as binary
From: Dmitry Potapov @ 2008-01-15 14:28 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Steffen Prohaska, Dmitry Potapov
There are two heuristics in Git to detect whether a file is binary
or text. One in xdiff-interface.c relied on existing NUL byte at
the beginning. However, convert.c used a different heuristic, which
relied that the number of non-printable symbols is less than 1%.
Due to difference in approaches whether a file is binary or not,
it was possible that a file that diff treats as binary will not be
treated as text by CRLF conversation. This is very confusing for
a user who seeing that 'git diff' shows file as binary expects it
to be added as binary.
This patch makes is_binary to consider any file that contains at
least one NUL character as binary.
---
Junio,
I believe that the current behavior where 'git diff' shows me a file
as binary and then adds it as text with crlf conversation is a bug.
Though, it is not very likely to happen, it still possible cases where
a binary file contains large amount of text. For instance, a tar file
of text files can be such a file. Probably, word processor that store
text in binary format may also generate a file with more 99% printable
characters. So, such files will be considered as text by current convert
heuristic. Still such files are considered by diff due present of a NUL
character. This is very confusing for a user to see 'git diff' saying
that a file is binary and then having it converted as text. Because I
don't think that any real text file (especially one that requires CRLF
conversation) may contain NUL character, I believe this change should
improve binary heuristic and avoid user confusion.
So, please, consider it for inclusion as a bug fix.
convert.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/convert.c b/convert.c
index 5adef4f..a51da1f 100644
--- a/convert.c
+++ b/convert.c
@@ -17,8 +17,8 @@
#define CRLF_INPUT 2
struct text_stat {
- /* CR, LF and CRLF counts */
- unsigned cr, lf, crlf;
+ /* NUL, CR, LF and CRLF counts */
+ unsigned nul, cr, lf, crlf;
/* These are just approximations! */
unsigned printable, nonprintable;
@@ -51,6 +51,9 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
case '\b': case '\t': case '\033': case '\014':
stats->printable++;
break;
+ case 0:
+ stats->nul++;
+ /* fall through */
default:
stats->nonprintable++;
}
@@ -66,6 +69,8 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
static int is_binary(unsigned long size, struct text_stat *stats)
{
+ if (stats->nul)
+ return 1;
if ((stats->printable >> 7) < stats->nonprintable)
return 1;
/*
--
1.5.4.rc3.3.g0321b
^ permalink raw reply related
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