* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-27 12:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <497EDCB0.8080806@kdbg.org>
On Tue, Jan 27, 2009 at 11:06:40AM +0100, Johannes Sixt wrote:
> - Note that run_command returns the negated exit code, therefore, we must
> negate it again in the call to exit(). Without this t6030 failed. (And
> negative exit codes causes grief on Windows because bash for some reason
> does not recognize that as failure.)
Oops, indeed. And you made me realize that I forgot to run the test
script against this patchset.
However, I'm not sure just negating the exit code is sufficient.
run_command can return codes in the 10000 range for its own internal
errors. We don't want to pass those out through exit, which will
truncate them to 8 bits.
> - The close() calls can overwrite errno.
Good point.
> And since fork() should not (cannot?) fail with ENOENT, it's safe to
> remove the #ifdef __MINGW32__.
Yeah, I thought of that, but I was worried it might make the code a
little bit non-obvious (but it does clean up an ifdef, which is ugly,
too).
Thanks for your feedback. I'll squash in your fixes and repost 2/3 later
today.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Sixt @ 2009-01-27 12:46 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090127122315.GA22628@sigill.intra.peff.net>
Jeff King schrieb:
> However, I'm not sure just negating the exit code is sufficient.
> run_command can return codes in the 10000 range for its own internal
> errors. We don't want to pass those out through exit, which will
> truncate them to 8 bits.
Exit code and start_command/finish_command's return code handling is a
complete mess IMHO and deserves a clean-up series of its own. If the few
codes at 10000 and above are truncated to 8 bits, then we get exit codes
16 and higher; I think that's good enough for this series.
-- Hannes
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 12:48 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael J Gruber, git
In-Reply-To: <bd6139dc0901270416u22b60fefp472935470b1db929@mail.gmail.com>
Sverre Rabbelier wrote:
> On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
>
>> git: ----v1----v2----v3--v4---v5
>> svn: \---v4--v5
>>
>> so the svn history starts from v3, but the git history remains unchanged.
>>
>
> Create the new branch from v3 then, and use git svn to pull it in.
> Then you can do 'git rebase that-svn-branch' on your git branch to put
> all commits (not as one big commit) on top of that branch point. Now
> you 'git checkout' that-svn-branch and do 'git reset --hard
> the-git-branch', which should now consist of
> v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
> the that-svn-branch now it should dcommit to svn each of your git
>
sorry, my ascii art was confusing:
git: ----v1----v2----v3--v4---v5
svn: v1-4---v5
v1-4 is v1 to v4 squashed together. (e.g., if i added a file in v2 and
removed in v3 it will not appear in svn history)
hope it is clear now.
ittay
> commits individually. Of course, don't forget to make a backup before
> you start messing around :P.
>
>
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Michael J Gruber @ 2009-01-27 13:02 UTC (permalink / raw)
To: Ittay Dror; +Cc: Sverre Rabbelier, git
In-Reply-To: <497F0280.2070400@gmail.com>
Ittay Dror venit, vidit, dixit 01/27/09 13:48:
>
> Sverre Rabbelier wrote:
>
>> On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
>>
>>> git: ----v1----v2----v3--v4---v5
>>> svn: \---v4--v5
>>>
>>> so the svn history starts from v3, but the git history remains unchanged.
>>>
>> Create the new branch from v3 then, and use git svn to pull it in.
>> Then you can do 'git rebase that-svn-branch' on your git branch to put
>> all commits (not as one big commit) on top of that branch point. Now
>> you 'git checkout' that-svn-branch and do 'git reset --hard
>> the-git-branch', which should now consist of
>> v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
>> the that-svn-branch now it should dcommit to svn each of your git
>>
> sorry, my ascii art was confusing:
>
> git: ----v1----v2----v3--v4---v5
> svn: v1-4---v5
>
> v1-4 is v1 to v4 squashed together. (e.g., if i added a file in v2 and
> removed in v3 it will not appear in svn history)
Well, for git and svn "revisions" are really "versions" of the complete
tree, not changesets. Have messed around with hg lately? ;)
On the other hand, a commit that introduces a new version is the
difference with respect to the previous "version".
Ususally it's clear what is meant, but you seem to mix both notions.
So, if v? denotes a version, then v4 is the result of all commits
leading up to v4. It *is* v4. "squashing" applies only to commits
("changes").
In any case, Sverre's as well as my suggestions should do what you want.
Why not try it out if you doubt it?
Cheers,
Michael
^ permalink raw reply
* [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-27 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <j6t@kdbg.org>
The last test case checks whether unpacked objects receive the time stamp
of the pack file. Due to different implementations of stat(2) by MSYS and
our version in compat/mingw.c, the test fails in about half of the test
runs.
Note the following facts:
- The test uses perl's -M operator to compare the time stamps. Since we
depend on MSYS perl, the result of this operator is based on MSYS's
implementation of the stat(2) call.
- NTFS on Windows records fractional seconds.
- The MSYS implementation of stat(2) *rounds* fractional seconds to full
seconds instead of truncating them. This becomes obvious by comparing the
modification times reported by 'ls --full-time $f' and 'stat $f' for
various files $f.
- Our implementation of stat(2) in compat/mingw.c *truncates* to full
seconds.
The consequence of this is that
- add_packed_git() picks up truncated whole second modification times
from the pack file time stamp, which is then used for the loose objects,
while the pack file retains its time stamp in fractional seconds;
- but the test case compares the pack file's rounded modification times
to the loose objects' truncated modification times.
And half of the time the rounded modification time is not the same as its
truncated modification time.
The fix is that we replace perl by 'test-chmtime -v +0', which prints the
truncated whole-second mtime without modifying it.
We want to catch failures of test-chmtime; but since it appears in a pipe,
we cannot access its exit code. Therefore, we at least make sure that it
prints time stamps of all files that are passed on its command line.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t7701-repack-unpack-unreachable.sh | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index 63a8225..e6e9f99 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -50,12 +50,15 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '
compare_mtimes ()
{
- perl -e 'my $reference = shift;
- foreach my $file (@ARGV) {
- exit(1) unless(-f $file && -M $file == -M $reference);
- }
- exit(0);
- ' -- "$@"
+ test-chmtime -v +0 "$@" |
+ {
+ read ref files &&
+ while read t name; do
+ test $ref = $t || break
+ files="$files $name"
+ done &&
+ test "$files" = "$*"
+ }
}
test_expect_success '-A without -d option leaves unreachable objects packed' '
--
1.6.1.1.1203.g5882
^ permalink raw reply related
* Re: Valgrind updates
From: Mark Brown @ 2009-01-27 13:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270512171.14855@racer>
On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote:
> I suspected that zlib does something "cute" with alignments, i.e. that it
> writes a possibly odd number of bytes, but then rounds up the buffer to
> the next multiple of two of four bytes.
I don't recall anything along those lines in zlib but it does generate
warnings with valgrind which require overrides - it has at least one
unrolled loop which roll on beyond initialised memory (but keep within
memory that zlib knows it has allocated). It rolls back the results of
the loop before producing output, but it's possible that some unused
bits in the stream may be derived from the results.
^ permalink raw reply
* [PATCHv3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-27 13:29 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the defalt CSS or the
shortcut icon are not accessible beyond the summary page (e.g. in
shortlog or commit view).
Fix this by adding a <base> tag pointing to the script base URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Of course, last time I forgot that the BASE href is supposed to be
absolute. While Opera apparently has no problem with it being relative,
other browsers such as Firefox are stricter about it.
gitweb/gitweb.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..411b1f6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,14 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ my $base = $my_url;
+ my $sname = $ENV{'SCRIPT_NAME'};
+ $base =~ s,\Q$sname\E$,,;
+ $base .= "/";
+ print "<base href=\"$base\"/>\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Wrong url using relative submodule over gitorious-ssh
From: Robert Wohlrab @ 2009-01-27 13:37 UTC (permalink / raw)
To: git
Hi,
I tried to use submodules in git. Since I am using gitorious at the moment it
would be nice to have relative urls to be able to checkout as user and as
developer. When I am using a checkout over git's native protocol it works fine
but when I am trying to use ssh it creates a bogus url and nothing changes if
I am using more ../ before the url.
Lets explain it by example. First thing is that we are assuming that we
checked out it over git's own protocol (it is emulated by setting the origin
url in my example)
$ mkdir test1
$ cd test1
$ git init
$ git remote add origin git://gitorious.org/test/mainline.git
$ git submodule init
$ git submodule add ../../test2/mainline.git subdir
Initialized empty Git repository in ~/test1/subdir/.git/
remote: Counting objects: 123, done.
....
Ok, you will receive a
Initialized empty Git repository in ~/test1/subdir/.git/
fatal: The remote end hung up unexpectedly
Clone of 'git://gitorious.org/test2/mainline.git' into submodule path
'subdir' failed
but that is fine because git://gitorious.org/test2/mainline.git is a valid
gitorious url (if somebody would create test2 as project).
Lets take a look at gitorious urls for ssh push access. They look like
git@gitorious.org:test1/mainline.git - similar to the ones used for pull over
the public git daemon.
$ mkdir test1
$ cd test1
$ git init
$ git remote add origin git@gitorious.org:test1/mainline.git
$ git submodule init
$ git submodule add ../../test2/mainline.git subdir
Initialized empty Git repository in ~/test1/subdir/.git/
Access denied or bad repository path
fatal: The remote end hung up unexpectedly
Clone of 'git@gitorious.org:test1/test2/mainline.git' into submodule path
'subdir' failed
This is definitely not the url I expected. It is unimportant how many more ../
I add but the test1/ will not get away. It is also important that their is no
/ after : or otherwise the clone will fail too.
This is an important issue for KDE because they want to use (Qt's) gitorious
and maybe submodules when they want switch to git.
$ git --version
git version 1.6.1.1.230.gdfb04
and on my origin/next test
$ git --version
git version 1.6.1.1.363.g2a3bd
--
Robert Wohlrab
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Hannu Koivisto @ 2009-01-27 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, git, Theodore Tso
In-Reply-To: <7vocxt3bsc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Perhaps something along this line to teach
>>
>> $ git merge-file --attribute-path=frotz.c file1 orig_file file2
>>
>> to merge what happened since orig_file to file2 into file1, and deposit
>> the result after converting it appropriately for path "frotz.c" obeying
>> core.autocrlf and gitattribute rules.
>>
>> I see rerere.c::merge() has the exact same issue, but its breakage is half
>> hidden by its use of fopen(path, "w"). It should explicitly use
>> convert_to_working_tree() like this patch does, and write the results out
>> in binary mode.
>
> Second try. I forgot how convert_* worked X-<.
Argh, it seems I have wasted your time. That patch may do
something useful but in this case with _or without_ it all the
files seem to be correct in the filesystem before I save the merge
result in emerge. I.e. it seems that for some reason Emacs detects
the coding system of the result file incorrectly. I'll investigate
that at some point especially if ediff suffers from the same
problem.
--
Hannu
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-27 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <873af59fkm.fsf@wine.dyndns.org>
Hi Alexandre,
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 3c37d0d..e314c44 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
> (log-edit-diff-function . git-log-edit-diff)) buffer)
> (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
> (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
> + (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
> (setq buffer-file-coding-system coding-system)
> (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
that patch has the desired effect (tested with GNU Emacs 22.3.1 and
GIT 1.6.1). Thank you very much.
Now, I'd be hugely in favor of applying that change to the repository
so that future versions of GIT have it.
Take care,
Peter
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-27 14:45 UTC (permalink / raw)
To: Git Mailing List; +Cc: Mike Hommey, Dill, Sverre Rabbelier, Jakub Narebski
In-Reply-To: <200901271216.59687.jnareb@gmail.com>
Jakub Narebski:
> Fundamental, that program output is considered API (at least for
> plumbing commands) and used when scripting (this might be ameliorated
> with "I am script" switch or environmental variable).
That's a bug. Protocol data (which one could consider the plumbing
output to be) should never be forwarded to the end-user, except for
debugging purposes. It is the porcelain's task here to translate the
messages for the user.
Plumbing commands could still output semi-readable English, but it is
still to be considered protocol, and be hidden from the user. Having
low-level protocol data filter through to the end-user is a common
mistake in software, unfortunately, and makes internationalization and
localization a lot harder.
Of course, if the user insists on calling the plumbing commands
directly, he will not get translated output. That's expected behaviour.
> Technical, because Git is mixture of programs in C, shell scripts,
> and Perl scripts, and you have to come with technical means of
> translating messages in all three of them.
Gettext has succesfully been used to translate messages in all of these
environments, so that should not be a big problem.
> Not in all cases. Sometimes it shows "long usage". Perhaps that
> should be made more consistent?
Consistency is good.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* "malloc failed"
From: David Abrahams @ 2009-01-27 15:04 UTC (permalink / raw)
To: git
I've been abusing Git for a purpose it wasn't intended to serve:
archiving a large number of files with many duplicates and
near-duplicates. Every once in a while, when trying to do something
really big, it tells me "malloc failed" and bails out (I think it's
during "git add" but because of the way I issued the commands I can't
tell: it could have been a commit or a gc). This is on a 64-bit linux
machine with 8G of ram and plenty of swap space, so I'm surprised.
Git is doing an amazing job at archiving and compressing all this stuff
I'm putting in it, but I have to do it a wee bit at a time or it craps
out. Bug?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: Heads up: rebase -i -p will be made sane again
From: Stephen Haberman @ 2009-01-27 14:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271012550.14855@racer>
> Dear list,
Thanks for keeping me on the cc list--several of the later stages of
cruft are my fault, so I don't know that I'll be able to help any more
than commentary on the use cases I was trying to fulfill.
> As for the design bug I want to fix: imagine this history:
>
> ------A
> / /
> / /
> ---- B
> \ \
> \ \
> C-----D-----E = HEAD
>
> A, C and D touch the same file, and A and D agree on the contents.
>
> Now, rebase -p A does the following at the moment:
>
> ------A-----E' = HEAD
> / /
> / /
> ---- B
>
> In other words, C is truly forgotten, and it is pretended that D never
> happened, either. That is exactly what test case 2 in t3410 tests for
> [*1*].
>
> This is insane.
Agreed.
Does this mean you're just getting rid of the code that calls "rev list
--cherry-pick"?
If so, I'd be all for that--I did not introduce it, nor fully understand
its nuances, and t3410 was just a hack to get the behavior of a rebase
with a dropped/cherry picked commit from the previous behavior of being
a no-op to instead do "something".
A few times I've pondered just removing the --cherry-pick/drop commit
part of rebase-p, but assumed it was there for a reason.
Also, yeah, don't treat the test cases in t3410 as "the result should be
this exact DAG" but "the result should be something that is not a
noop/sane".
> [*1*] The code in t3410 was not really easy to read, even if there was an
> explanation what it tried to do, but the test code was inconsitent,
> sometimes tagging, sometimes not, sometimes committing with -a, sometimes
> "git add"ing first, yet almost repetitive.
>
> In my endeavor not only to understand it, and either fix my code or the
> code in t3410, I refactored it so that others should have a much easier
> time to understand what it actually does.
Thanks for cleaning it up.
I recently saw a test of yours use a `test_commit` bash function that I
really like. My last patch submission debacle had a patch cleaning up
t3411 by introducing `test_commit`--I can brave `git send-email` again
if you have any interest in me resending it.
Thanks,
Stephen
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Stephen Haberman @ 2009-01-27 15:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce, Thomas Rast, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
> I am very sorry if somebody actually scripted rebase -i -p (by setting
> GIT_EDITOR with a script), but I am very certain that this cleanup is
> absolutely necessary to make rebase -i -p useful.
I have scripted rebase-i-p, but with GIT_EDITOR=: [1]. I assume this
will still work and just accept the default script?
(Er, maybe I can just use rebase-p...I forget why [1] is using the
GIT_EDITOR=: with -i.)
My primary pain point with rebase-i-p has been rebasing a branch that
has merged in another branch that has a lot of commits on it. E.g.:
a -- b -- c origin/feature
\
d -- e feature
/
... g origin/master
Where e is merging in, say, a latest release that had a few hundred
commits in the master branch. After resolving conflicts/etc. in e, I
want to rebase d..e from a to be on c.
The two problems have been:
1) `git pull` with rebase set uses rebase-i, with no -p, so all of the
commits from the latest release branch that got merged in with e are
flattened/duplicated. This is what [1] tries to fix. I've made
noises about hacking the branch rebase flag but haven't followed
through.
I know this is a git pull issue, but I bring it up because, IIRC, the
t3410 test case came from a scenario where I was rebasing a merge
like e above and due to --cherry-pick dropping a commit (probably e
itself, I'm not sure), rebase-i-p as it existed then broke and
produced a noop. So I set off to get it to do "something" and ended
up introducing the "DROPPED" directory.
2) With manual invocation of `rebase-i-p`, previously you'd get a
laundry list of commits from the e merge that are new to the feature
branch, but since g and its ancestors aren't changing, you don't need
to consider them in the script and so its (potentially a lot of)
noise. This is what the parent probing back port from git sequencer
addressed.
So, I don't mean to rehash old complaints, as I'd love to see the
rebase-i-p code cleaned up by someone who can really refactor it vs. my
hack patches. But I wanted to emphasize the motivation for my hacks over
their implementation so that hopefully you can still address these use
cases in the new version.
Thanks,
Stephen
[1]: http://github.com/stephenh/git-central/blob/master/scripts/pull
^ permalink raw reply
* Re: "malloc failed"
From: Shawn O. Pearce @ 2009-01-27 15:29 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <878wow7pth.fsf@mcbain.luannocracy.com>
David Abrahams <dave@boostpro.com> wrote:
> I've been abusing Git for a purpose it wasn't intended to serve:
> archiving a large number of files with many duplicates and
> near-duplicates. Every once in a while, when trying to do something
> really big, it tells me "malloc failed" and bails out (I think it's
> during "git add" but because of the way I issued the commands I can't
> tell: it could have been a commit or a gc). This is on a 64-bit linux
> machine with 8G of ram and plenty of swap space, so I'm surprised.
>
> Git is doing an amazing job at archiving and compressing all this stuff
> I'm putting in it, but I have to do it a wee bit at a time or it craps
> out. Bug?
No, not really. Above you said you are "abusing git for a purpose
it wasn't intended to serve"...
Git was never designed to handle many large binary blobs of data.
It was mostly designed for source code, where the majority of the
data stored in it is some form of text file written by a human.
By their very nature these files need to be relatively short (e.g.
under 1 MB each) as no human can sanely maintain a text file that
large without breaking it apart into different smaller files (like
the source code for an operating system kernel).
As a result of this approach, the git code assumes it can malloc()
at least two blocks large enough for each file: one of the fully
decompressed content, and another for the fully compressed content.
Try doing git add on a large file and its very likely malloc
will fail due to ulimit issues, or you just don't have enough
memory/address space to go around.
git gc likewise needs a good chunk of memory, but it shouldn't
usually report "malloc failed". Usually in git gc if a malloc fails
it prints a warning and degrades the quality of its data compression.
But there are critical bookkeeping data structures where we must be
able to malloc the memory, and if those fail because we've already
exhausted the heap early on, then yea, it can fail too.
--
Shawn.
^ permalink raw reply
* friendlier names
From: David Abrahams @ 2009-01-27 15:30 UTC (permalink / raw)
To: git
I'm absolutely certain I'm not the first person to have raised this
issue, so feel free to point me at the threads where I can get the
rationale... but: to me it looks like git's choice of terminology hurts
its adoption and learnability.
For example, why couldn't the "index" be called the "stage" instead?
That, along with knowing that "git add" was a synonym for "git stage"
would have flattened the learning curve considerably for me.
Thanks,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: friendlier names
From: Felipe Contreras @ 2009-01-27 15:33 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <87mydc6a2r.fsf@mcbain.luannocracy.com>
On Tue, Jan 27, 2009 at 5:30 PM, David Abrahams <dave@boostpro.com> wrote:
>
> I'm absolutely certain I'm not the first person to have raised this
> issue, so feel free to point me at the threads where I can get the
> rationale... but: to me it looks like git's choice of terminology hurts
> its adoption and learnability.
>
> For example, why couldn't the "index" be called the "stage" instead?
> That, along with knowing that "git add" was a synonym for "git stage"
> would have flattened the learning curve considerably for me.
+1
I think several people have mentioned it, and there have been
different possible actions, but nothing concrete AFAIK.
--
Felipe Contreras
^ permalink raw reply
* Re: "malloc failed"
From: David Abrahams @ 2009-01-27 15:32 UTC (permalink / raw)
To: git
In-Reply-To: <20090127152915.GA1321@spearce.org>
on Tue Jan 27 2009, "Shawn O. Pearce" <spearce-AT-spearce.org> wrote:
> David Abrahams <dave@boostpro.com> wrote:
>> I've been abusing Git for a purpose it wasn't intended to serve:
>> archiving a large number of files with many duplicates and
>> near-duplicates. Every once in a while, when trying to do something
>> really big, it tells me "malloc failed" and bails out (I think it's
>> during "git add" but because of the way I issued the commands I can't
>> tell: it could have been a commit or a gc). This is on a 64-bit linux
>> machine with 8G of ram and plenty of swap space, so I'm surprised.
>>
>> Git is doing an amazing job at archiving and compressing all this stuff
>> I'm putting in it, but I have to do it a wee bit at a time or it craps
>> out. Bug?
>
> No, not really. Above you said you are "abusing git for a purpose
> it wasn't intended to serve"...
Absolutely; I want to be upfront about that :-)
> Git was never designed to handle many large binary blobs of data.
They're largely text blobs, although there definitely are a fair share
of binaries.
> It was mostly designed for source code, where the majority of the
> data stored in it is some form of text file written by a human.
>
> By their very nature these files need to be relatively short (e.g.
> under 1 MB each) as no human can sanely maintain a text file that
> large without breaking it apart into different smaller files (like
> the source code for an operating system kernel).
>
> As a result of this approach, the git code assumes it can malloc()
> at least two blocks large enough for each file: one of the fully
> decompressed content, and another for the fully compressed content.
> Try doing git add on a large file and its very likely malloc
> will fail due to ulimit issues, or you just don't have enough
> memory/address space to go around.
Oh, so maybe I'm getting hit by ulimit; I didn't think of that. I could
raise my ulimit to try to get around this.
> git gc likewise needs a good chunk of memory, but it shouldn't
> usually report "malloc failed". Usually in git gc if a malloc fails
> it prints a warning and degrades the quality of its data compression.
> But there are critical bookkeeping data structures where we must be
> able to malloc the memory, and if those fail because we've already
> exhausted the heap early on, then yea, it can fail too.
Thanks much for that, and for reminding me about ulimit.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: friendlier names
From: Shawn O. Pearce @ 2009-01-27 15:38 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <87mydc6a2r.fsf@mcbain.luannocracy.com>
David Abrahams <dave@boostpro.com> wrote:
>
> For example, why couldn't the "index" be called the "stage" instead?
> That, along with knowing that "git add" was a synonym for "git stage"
> would have flattened the learning curve considerably for me.
Historical reasons...
Waaay back the "index" was an index of the files git knows about in
your working directory. It made sense to call it an index, as like
a book index it was a full listing of what's here, sorted by name.
That's pre-1.0 days. Like the very first version Linus ever
released. Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.
Much, much later, over many months, the index morphed into what
you see today, which is a "staging area", accessed by "git add".
This was all incremental, in small parts. Nobody set out to
design a "staging area" or to have "staging actions". Back
when it was really the index you updated it with a tool called
git-update-index. Adding new files required the --add flag.
People found --add annoying, so they wrote "git add" as a
wrapper around it. But modified existing files still had
to be updated with git-update-index. Then someone pointed
out that add of an existing file and add of a new file are
similiar enough that they should just be the same command,
"git add".
Only late last October at the GitTogether did we start to talk about
creating a command called "git stage", because people have started to
realize we seem to call it a "staging area" as we train newcomers...
The tools are _all_ slowly evolved over time. Nothing in git
was ever set out from the beginning as a "this is what we are
going to do". The only part of Git that is like that is the core
data structure on disk for the object store. That hasn't changed
since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
the object naming algorithm, and even that was done in the first
couple of weeks.
--
Shawn.
^ permalink raw reply
* Building Documentation in Cygwin
From: Tim Visher @ 2009-01-27 15:41 UTC (permalink / raw)
To: git
Hey Everyone,
I've asked this question here before but unfortunately I can't find
the answer in any of the archives. I'm trying to build the
documentation on Windows in Cygwin. Git builds fine, the html docs
build fine, but when I get to the man pages, I get the following
error:
$ make install-man
rm -f doc.dep+ doc.dep
/usr/bin/perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make -C ../ GIT-VERSION-FILE
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make[1]: `GIT-VERSION-FILE' is up to date.
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make -C ../ GIT-VERSION-FILE
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make[1]: `GIT-VERSION-FILE' is up to date.
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
rm -f git-add.xml+ git-add.xml
asciidoc -b docbook -d manpage -f asciidoc.conf \
-agit_version=1.6.1.1.230.gdfb04 -o git-add.xml+
git-add.txt
mv git-add.xml+ git-add.xml
rm -f git-add.1
xmlto -m callouts.xsl man git-add.xml
xmlto: input does not validate (status 3)
error : Operation not permitted
/home/tvishe01/projects/git/Documentation/git-add.xml:2: warning:
failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
D DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
^
error : Operation not permitted
warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Could not load the external subset
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Document /home/tvishe01/projects/git/Documentation/git-add.xml
does not validate
make: *** [git-add.1] Error 3
I've fixed this before but I've been thwarted all morning on the
Googles trying to find out what to do. I remember it having something
to do with explicitly telling xmlto not to try to download doctypes or
something. Also, I remember there being pre-built man pages somewhere
that I could download and just manually install.
Anyway, I'm not opposed to either of those routes, I just can't figure
out how to do it personally.
Thanks in advance!
--
http://five.sentenc.es/ - Spend less time on e-mail.
Written using [Emacs](http://www.gnu.org/software/emacs/).
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Schindelin @ 2009-01-27 16:31 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
Hi,
On Tue, 27 Jan 2009, Jeff King wrote:
> On Thu, Jan 08, 2009 at 04:07:08PM +0100, Johannes Schindelin wrote:
>
> > Just try this with a submodule that has more changes than fit on a
> > screen:
> >
> > $ git -p submodule summary
> >
> > In my tests, it consistently fscks up my console. I wonder if this is
> > related to ea27a18(spawn pager via run_command interface).
>
> OK, here is a patch series that fixes the problem:
>
> 1/3: git: s/run_command/run_builtin/
> 2/3: run_command: handle missing command errors more gracefully
> 3/3: git: use run_command to execute dashed externals
>
> 1 is a cleanup, 2 is infrastructure support, and 3 is the actual fix.
I like the patch series, well designed and concise (especially with the
fixes Hannes proposed).
> There are two potential downsides to the fix:
>
> 1. There is an extra fork and a parent process sitting in memory for
> dashed externals. This is pretty necessary to any fix, since
> something has to wait to do pager cleanup, and we can't rely on the
> child to do so.
Actually, I think this is a good thing; that way, we can catch
segmentation fault properly and display an error message in the pager.
That was not possible previously.
> 2. A failed attempt to execute a dashed external results in an extra
> fork. For builtins, this has no impact, since they take precedence.
> For aliases, though, it means we will do an extra fork before
> realizing that there is no dashed external and trying the alias.
All the more reason to build more programs in :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Tay Ray Chuan @ 2009-01-27 16:32 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901270741h2f213b99s31bac8829bd182c2@mail.gmail.com>
Hi,
On Tue, Jan 27, 2009 at 11:41 PM, Tim Visher <tim.visher@gmail.com> wrote:
> $ make install-man
> rm -f doc.dep+ doc.dep
> /usr/bin/perl ./build-docdep.perl >doc.dep+
> mv doc.dep+ doc.dep
> make -C ../ GIT-VERSION-FILE
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make[1]: `GIT-VERSION-FILE' is up to date.
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make -C ../ GIT-VERSION-FILE
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make[1]: `GIT-VERSION-FILE' is up to date.
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> rm -f git-add.xml+ git-add.xml
> asciidoc -b docbook -d manpage -f asciidoc.conf \
> -agit_version=1.6.1.1.230.gdfb04 -o git-add.xml+
> git-add.txt
> mv git-add.xml+ git-add.xml
> rm -f git-add.1
> xmlto -m callouts.xsl man git-add.xml
> xmlto: input does not validate (status 3)
hmm i tried running this and this rule passed for me.
try running xmlto in verbose, what does it output? here's mine:
---cut---
$ xmlto -v -m callouts.xsl man git-add.xml
Format script: /usr/share/xmlto/format/docbook/man
Convert to troff
Real stylesheet:
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
xmllint >/dev/null --xinclude --postvalid
/cygdrive/g/temp/git/git/Documentation/git-add.xml
Stylesheet: /tmp/xmlto-xsl.nEUjsh
xsltproc --nonet --xinclude \
-o /tmp/xmlto.MvioXw/git-add.proc \
/tmp/xmlto-xsl.nEUjsh \
/cygdrive/g/temp/git/git/Documentation/git-add.xml
Writing git-add.1 for refentry
---cut---
you might also want to try getting the cygwin package docbook-xml42.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Schindelin @ 2009-01-27 16:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <497F076F.8060509@viscovery.net>
Hi,
On Tue, 27 Jan 2009, Johannes Sixt wrote:
> We want to catch failures of test-chmtime; but since it appears in a
> pipe, we cannot access its exit code. Therefore, we at least make sure
> that it prints time stamps of all files that are passed on its command
> line.
I use this trick in my valgrind series:
($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
test 0 = "$(cat exit.code)"
Ciao,
Dscho
^ permalink raw reply
* Re: friendlier names
From: David Abrahams @ 2009-01-27 16:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090127153837.GB1321@spearce.org>
on Tue Jan 27 2009, "Shawn O. Pearce" <spearce-AT-spearce.org> wrote:
> David Abrahams <dave@boostpro.com> wrote:
>>
>> For example, why couldn't the "index" be called the "stage" instead?
>> That, along with knowing that "git add" was a synonym for "git stage"
>> would have flattened the learning curve considerably for me.
>
> Historical reasons...
>
> Waaay back the "index" was an index of the files git knows about in
> your working directory. It made sense to call it an index, as like
> a book index it was a full listing of what's here, sorted by name.
>
> That's pre-1.0 days. Like the very first version Linus ever
> released. Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.
I'm not saying "index" doesn't make sense. It _still_ makes sense. It
just doesn't make as much sense as "stage." Index is a very generic
term; it doesn't communicate enough.
> Much, much later, over many months, the index morphed into what
> you see today, which is a "staging area", accessed by "git add".
>
> This was all incremental, in small parts. Nobody set out to
> design a "staging area" or to have "staging actions". Back
> when it was really the index you updated it with a tool called
> git-update-index. Adding new files required the --add flag.
>
> People found --add annoying, so they wrote "git add" as a
> wrapper around it. But modified existing files still had
> to be updated with git-update-index. Then someone pointed
> out that add of an existing file and add of a new file are
> similiar enough that they should just be the same command,
> "git add".
>
> Only late last October at the GitTogether did we start to talk about
> creating a command called "git stage", because people have started to
> realize we seem to call it a "staging area" as we train newcomers...
Sounds like, from everything you've said, "stage" rather than "index"
would have been just as sensible in the beginning as it is today; it's
just that you have a much nicer interface for working with it.
> The tools are _all_ slowly evolved over time. Nothing in git
> was ever set out from the beginning as a "this is what we are
> going to do". The only part of Git that is like that is the core
> data structure on disk for the object store. That hasn't changed
> since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
> the object naming algorithm, and even that was done in the first
> couple of weeks.
OK, thanks for the history lesson. It's good to know someone is paying
attention to these things. Is there any movement toward addressing
them outside of GitTogether talk?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 16:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Linus Torvalds, Jeff King, Junio C Hamano, git
In-Reply-To: <20090127131404.GA11870@sirena.org.uk>
Hi,
On Tue, 27 Jan 2009, Mark Brown wrote:
> On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote:
>
> > I suspected that zlib does something "cute" with alignments, i.e. that
> > it writes a possibly odd number of bytes, but then rounds up the
> > buffer to the next multiple of two of four bytes.
>
> I don't recall anything along those lines in zlib but it does generate
> warnings with valgrind which require overrides - it has at least one
> unrolled loop which roll on beyond initialised memory (but keep within
> memory that zlib knows it has allocated). It rolls back the results of
> the loop before producing output, but it's possible that some unused
> bits in the stream may be derived from the results.
That is what I suspected, but the data contradict this:
- accesses to all offsets between 0 and 50 and 52 and 58 (one _more_ than
indicated as valid by stream.total_count!) do not trigger any message in
valgrind.
- access to offset 51, which is well _within_ the boundaries, and even
well outside the range of a stray alignment issue, _does_ trigger a
valgrind message.
So either valgrind gets it wrong (which I find rather unlikely), or zlib
really does not write to that offset.
Or, and I think that makes most sense so far, valgrind has not really
ignored the initialization of byte number 52 in that buffer which partly
depended on an uninitialized value (but does not matter, maybe due to
Huffman cutoff or something similar).
Come to think of it, the word "suppression" is probably a good indicator
that valgrind never claimed it would mark the zlib buffer as properly
initialized.
Sorry for the noise, then,
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