* Re: git-svn and svn sw --relocate
From: Eric Wong @ 2006-04-03 22:39 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <44314B41.3050902@iaglans.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> Eric Wong wrote:
> > Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> >>i have now my repository locally and i want to get it remotely on a
> >>server, in order to have a few collaborators...
> >>
> >>the steps on the svn-side are clear. But what do i have todo on the
> >>git-svn-side of this life?
> >>
> >>does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
> >
> >
> > Yes, you'll need to do that in .git/git-svn/tree and also update
> > .git/git-svn/info/url by hand.
>
> Will there be any other sha1-sums for that repository so that i have to
> merge them again and again? This issue occured to me the last time i
> encountered the git-svn-change with the external sources, where i had to
> repair my external git-svn-tree, which resulted in new sha1sums
> somehow... that was very unpleasant to my collegue..
sha1-sums for commits? or trees? I'm not sure that I follow, git-svn
should make commits with at least two explicit parents (one being the
commit you're using and, and the other remote/git-svn) back to
remotes/git-svn.
The commit sha1s for the same svn tree do not necessary always match,
and ac7490506418e3ec495775e432b7040a17449fa9 acknowledges that:
contrib/git-svn: allow rebuild to work on non-linear remote heads
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
The tree sha1 should always match, however. You can use the
--branch <refname/commit> option to do automatic branch joining
based on tree sha1 checksums to combine history.
--
Eric Wong
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Martin Langhoff @ 2006-04-03 22:38 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
Keith,
Looks nifty. Though I thought you'd go for writing a smarter cvsps, so
that git-cvsimport could take advantage of it.
Looks like I'll have to brush up on my C to get to play... :-(
m
^ permalink raw reply
* Re: [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
From: Eric Wong @ 2006-04-03 22:21 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <11441027292908-git-send-email-normalperson@yhbt.net>
Subject: Re: [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
^ oops, disregard that, these should've been 1/2 and 2/2
--
Eric Wong
^ permalink raw reply
* [PATCH 3/4] contrib/git-svn: ensure repo-config returns a value before using it
From: Eric Wong @ 2006-04-03 22:18 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
fetching from repos without an authors-file defined was broken.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
029626bf987cff7ba42d8158c687cf4902765968
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index edfb19c..e7fff46 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -77,10 +77,13 @@ foreach my $o (keys %opts) {
$arg .= ' --bool' if ($o !~ /=[sfi]$/);
$arg .= " svn.$key"; # $key only matches [a-z\-], always shell-safe
if (ref $v eq 'ARRAY') {
- chomp(@$v = `$arg`);
+ chomp(my @tmp = `$arg`);
+ @$v = @tmp if @tmp;
} else {
- chomp($$v = `$arg`);
- $$v = 0 if $$v eq 'false';
+ chomp(my $tmp = `$arg`);
+ if ($tmp && !($arg =~ / --bool / && $tmp eq 'false')) {
+ $$v = $tmp;
+ }
}
}
--
1.3.0.rc1.g595e
^ permalink raw reply related
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 22:19 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <1144083282.2303.102.camel@neko.keithp.com>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On Mon, 2006-04-03 at 09:54 -0700, Keith Packard wrote:
> On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:
>
> > -YFLAGS=-d
> > +YFLAGS=-d -l
> > +LFLAGS=-l
>
> Works for me too; thanks for the fix.
Well, -l *kinda* works; it places a limit on the maximum token size.
And, unlike 'lex', 'flex' places all input into the token buffer, even
if handled outside the usual lexer loop. So, my external function that
sucked up file contents was losing.
I switched it over to doing one-at-a-time reads from the input file, now
the external data function can directly use stdio. This eliminates all
calls to 'input' and 'unput' which should make it work for everyone now.
flex -- it's like lex, except less flexible.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH 4/4] contrib/git-svn: make sure our git-svn is up-to-date for test
From: Eric Wong @ 2006-04-03 22:18 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
In-Reply-To: <11441027292908-git-send-email-normalperson@yhbt.net>
Bugs like the last one could've been avoided if it weren't for
this...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d3ce1325c4933cd0e5f8f9810b2ffc33ddf45aac
diff --git a/contrib/git-svn/Makefile b/contrib/git-svn/Makefile
index d7f1643..acedf73 100644
--- a/contrib/git-svn/Makefile
+++ b/contrib/git-svn/Makefile
@@ -28,7 +28,7 @@ git-svn.xml : git-svn.txt
git-svn.html : git-svn.txt
asciidoc -b xhtml11 -d manpage \
-f ../../Documentation/asciidoc.conf $<
-test:
+test: git-svn
cd t && $(SHELL) ./t0000-contrib-git-svn.sh
clean:
--
1.3.0.rc1.g595e
^ permalink raw reply related
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-03 22:18 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.gitignore | 1 +
Documentation/git-clean.txt | 50 +++++++++++++++++++++++++++++++
Makefile | 2 +
git-clean.sh | 70 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 122 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 75891c3..b5959d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@ git-checkout
git-checkout-index
git-cherry
git-cherry-pick
+git-clean
git-clone
git-clone-pack
git-commit
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
new file mode 100644
index 0000000..0c671e1
--- /dev/null
+++ b/Documentation/git-clean.txt
@@ -0,0 +1,50 @@
+git-clean(1)
+============
+
+NAME
+----
+git-clean - Remove untracked files from the working tree
+
+SYNOPSIS
+--------
+[verse]
+'git-clean' [-d | -D] [-n] [-q] [-x]
+
+DESCRIPTION
+-----------
+Removes files unknown to git. This allows to clean the working tree
+from files that are not under version control. If the '-x' option is
+specified, ignored files are also removed, allowing to remove all
+build products.
+
+OPTIONS
+-------
+-d::
+ Remove untracked directories in addition to untracked files.
+
+-D::
+ Same as above, but use chmod first. This is useful for
+ read-only directories used in some testsuites.
+
+-n::
+ Don't actually remove anything, just show what would be done.
+
+-q::
+ Be quiet, only report errors, but not the files that are
+ successfully removed.
+
+-x::
+ Don't use the ignore rules. This allows removing all untracked
+ files, including build products. This can be used (possibly in
+ conjunction with gitlink:git-reset[1]) to create a pristine
+ working directory to test a clean build.
+
+
+Author
+------
+Written by Pavel Roskin <proski@gnu.org>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index c79d646..221e59a 100644
--- a/Makefile
+++ b/Makefile
@@ -114,7 +114,7 @@ ### --- END CONFIGURATION SECTION ---
SCRIPT_SH = \
git-add.sh git-bisect.sh git-branch.sh git-checkout.sh \
- git-cherry.sh git-clone.sh git-commit.sh \
+ git-cherry.sh git-clean.sh git-clone.sh git-commit.sh \
git-count-objects.sh git-diff.sh git-fetch.sh \
git-format-patch.sh git-log.sh git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
diff --git a/git-clean.sh b/git-clean.sh
new file mode 100755
index 0000000..8470559
--- /dev/null
+++ b/git-clean.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Copyright (c) 2005-2006 Pavel Roskin
+#
+
+USAGE="[-d | -D] [-n] [-q] [-x]"
+LONG_USAGE='Clean untracked files from the working directory
+ -d remove directories as well
+ -D remove directories, try harder (chmod first)
+ -n don'\''t remove anything, just show what would be done
+ -q be quiet, only report errors
+ -x remove ignored files as well'
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+noexclude=
+cleandir=
+cleandirhard=
+quiet=
+rmf="rm -f"
+rmrf="rm -rf"
+rm_refuse="echo Not removing"
+echo1="echo"
+
+for arg in "$@"; do
+ if [ "$arg" = "-d" ]; then
+ cleandir=1
+ elif [ "$arg" = "-D" ]; then
+ cleandir=1
+ cleandirhard=1
+ elif [ "$arg" = "-n" ]; then
+ quiet=1
+ rmf="echo Would remove"
+ rmrf="echo Would remove"
+ rm_refuse="echo Would not remove"
+ echo1=":"
+ elif [ "$arg" = "-q" ]; then
+ quiet=1
+ elif [ "$arg" = "-x" ]; then
+ noexclude=1
+ else
+ echo >&2 "Unknown option: \"$arg\""
+ exit 1
+ fi
+done
+
+excl1=
+excl2=
+if [ -z "$noexclude" ]; then
+ excl1="--exclude-per-directory=.gitignore"
+ if [ -f "$GIT_DIR/info/exclude" ]; then
+ excl2="--exclude-from=$GIT_DIR/info/exclude"
+ fi
+fi
+
+git-ls-files --others --directory "$excl1" "$excl2" |
+while read -r file; do
+ if [ -d "$file" -a ! -L "$file" ]; then
+ if [ -z "$cleandir" ]; then
+ $rm_refuse "$file"
+ continue
+ fi
+ $echo1 "Removing $file"
+ [ "$cleandirhard" ] && chmod -R 700 "$file"
+ $rmrf "$file"
+ else
+ $echo1 "Removing $file"
+ $rmf "$file"
+ fi
+done
^ permalink raw reply related
* Re: n-heads and patch dependency chains
From: linux @ 2006-04-03 22:13 UTC (permalink / raw)
To: junkio; +Cc: git
> I suspect people have hard time grasping _why_ you are jumping
> through hoops. At least I do. What problem are you trying to
> solve? You perhaps described your mechanism well enough, but it
> is not quite clear to me what kind of operations are made easier
> with this exercise, against which possible downside of it, if
> any, would be judged.
Oh... I thought he explained that pretty well.
The problem is a long-lived out-of-tree patch, or anything else that's
going to undergo repeated test releases before merging.
Think about swsusp2 or resiser4 or gfs or user-mode linux (now merged)
or nommu linux (now merged) or some similar large patch that takes a
lot of review.
The challenge is to be able to maintain a "latest Linux release + patches"
distribution and still keep a clean patch to submit to Linus that
doesn't have a zillion cross-merges because he doesn't like that,
and they confuse the development history.
It happens with a single developer when you're working on several
independent features and want a "latest & greatest" tree while still
keeping the feature branches separate.
This is the sort of thing that git-rebase and pu branches are used for,
and jgarzik's libata-dev ALL branch is basically a manually operated
hydra.
Some combination of automatic rebasing and automatic generation of
a pu/ALL tree seems like what's being asked for here. The former
adds new history "before" the branch development, and the latter
adds additional changes "after" it. All this subterfuge is in
the name of keeping the feature development history clean.
But all of darcs' "patch calculus" ideas are just basically
rebase strategies. If someone can come up with a good alternative
to diff-and-patch, perhaps git-rebase can develop a number of
underlying strategies like git-merge.
^ permalink raw reply
* [PATCH] Add git-clean command
From: Pavel Roskin @ 2006-04-03 21:59 UTC (permalink / raw)
To: git
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
0 files changed, 0 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Junio C Hamano @ 2006-04-03 20:01 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
Davide Libenzi <davidel@xmailserver.org> writes:
>> For example, the first hunk says:
>>
>> @@ -0,0 +6 @@
>> +#include "diff.h"
>>
>> Which is inconsistent with what GNU diff says:
>>
>> @@ -5,0 +6 @@
>> +#include "diff.h"
>>
>> I've tried this patch but...
>
> The fix is fine, but you should do the same even in the s2 case. The
> correct hunk should have been:
>
> @@ -6,0 +6 @@
You are right. GNU says -5,0 not -6,0 so presumably "patch"
other people use expect it to say -5,0 not -6,0; even though we
could argue the insertion happens at 6th position and saying
-6,0 is more logical, it does not matter -- what incumbent does
wins X-<. I notice that your fix shows -5,0 to match it ;-).
Thanks for the fix.
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604031222360.30048@alien.or.mcafeemobile.com>
On Mon, 3 Apr 2006, Davide Libenzi wrote:
> On Mon, 3 Apr 2006, Junio C Hamano wrote:
>>
>> I've tried this patch but it is not right; the diff between the
>> attached two files show a 47-line hunk that inserts at line 400,
>> then the next 6-line hunk inserts at line 401 which is obviously
>> bogus.
That's fine, since that's orig file position *before* the insert. Try the
same with GNU diff and you should see the same. Also try to create a diff
with libxdiff (with the fix) and feed it to GNU patch.
- Davide
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Junio C Hamano @ 2006-04-03 19:37 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <4430D352.4010707@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think we can conclude from this:
>
> - this is not impossible using the current model, and some extra
> useful information can be seen in the tree that shows more real
> dependency information and relationships between individual commits
>
> - doing automatic n-head creation would probably be madness, as
> far too many useless heads are created (though it is almost
> guaranteed that supporting 'patch commuting' a la darcs would
> make this *even worse* as it would mean that you could potentially
> have even more heads)
I suspect people have hard time grasping _why_ you are jumping
through hoops. At least I do. What problem are you trying to
solve? You perhaps described your mechanism well enough, but it
is not quite clear to me what kind of operations are made easier
with this exercise, against which possible downside of it, if
any, would be judged.
> - the current tools make this style of development difficult.
Git was born from necessity, and we have been aiming to have
tools to do what are commonly needed. It is not surprising to
see existing tools do not support modes of operations that are
"unusual" (meaning, things we have not done with git so far).
Also we do not tend to do things only because we can.
Now admittably I am guilty of having done a few things only
because we can. Octopus is an example. Making an Octopus only
because you can does not buy you much, other than its coolness
value, and it would make exporting the history to other SCMs
somewhat harder I suspect, and it makes bisecting more
expensive [*1*].
For example, the point jdl raised during the discussion is far
easier to understand. When working on multiple topics, he often
needs to test them as a whole, so he pulls them into a test
branch (can be a throwaway branch). When he needs to do fixups,
it is most efficient to do compile/run test while still in the
test branch, but after things test out, in order to keep
logically different things separate, he needs to go back to
relevant topic branches and make a commit. This is painful --
are there ways to make this easier [*2*]?
Would patch commutation calculus help with his problem?
I suspect patch commutation could be used to solve his problem,
but if it does not, it does not mean what you are trying to do
with hydra is not interesting. It just means from your
descriptions it is not clear what real problems hydra is trying
to solve, and I misunderstood that it is related to his problem
(just like jdl did, I suspect).
So can you step back a bit and start from describing what
problem you are trying to solve, before describing the
mechanisms you think would help?
One thing I can think of that could potentially come out of your
approach would be an alternative implementation of what StGIT
does. Inside a local developer repository, being able to
reorder patches and rewrite them flexibly is very useful.
While I agree with Linus's reaction "I want my merges fast", I
am not necessarily so negative about the approach. For example,
if you use it only as a tool to reorder and clean-up local
development history to a presentable form (IOW, using hydra to
manage your development, but the result exposed to the outside
world is exported from that hydra into a more linear form, that
does not give other people a heart attach when they look at the
ancestry graph in gitk), you would not negatively affect other
people who work with you.
[Footnote]
*1* Do not get me wrong. Octopus is sometimes the most natural
way to express what happened, but the case it applies to is
quite narrowly defined -- to merge in independent branches that
happened to mature at the same time together. So the tool
discourages you from making an Octopus that is not trivial,
deliberately.
*2* I see two approaches, the more obvious being "git checkout
-m that-topic". Just edit (but not update-index) on top of
test, have "checkout -m" adjust your changes to the topic branch
you want to commit to, make a commit there, and then come back
to the test branch, and merge the topic branch again.
Another obvious strategy would be to make commits on top of
"test" and then cherry-pick them back on top of the relevant
topics later.
topicA You have three topics
o---o you need to test together...
/
---o---o topicB
\
o---o
topicC
==>
topicA So merge them up and start testing.
o---o
/ \
---o---o---T
\ /
o---o
topicB
==>
topicA But you find problems, and fix them
o---o up as you go along...
/ \
---o---o---T---1---2
\ /
o---o
topicB
==>
topicA Later you cherry-pick them into
o---o---1' relevant topics.
/
---o---o topicB
\
o---o---2'
topicC
==>
topicA Next round of test will continue
o---o---1' by rebuilding the test branch
/ \
---o---o-------T
\ /
o---o---2'
topicC
^ permalink raw reply
* Re: [RFH] xdiff shows trivially redundant diff.
From: Davide Libenzi @ 2006-04-03 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q1bglkp.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Apr 2006, Junio C Hamano wrote:
> Davide Libenzi <davidel@xmailserver.org> writes:
>
>> No problem. That's only an eye-issue though, since the diff is still a
>> valid diff according to its definition where D=A-B => B+D==A && A-D==B
>> From the day I released 0.18, xregression is continuosly running w/out
>> any issue. I'll check it out though ...
>
> There is another to report, when ctxlen == 0.
>
> Between the attached files "diff -u0 8f352aa dd40a03", the
> header for a hunk with only inserted lines misidentify the
> original location.
>
> For example, the first hunk says:
>
> @@ -0,0 +6 @@
> +#include "diff.h"
>
> Which is inconsistent with what GNU diff says:
>
> @@ -5,0 +6 @@
> +#include "diff.h"
>
> I've tried this patch but it is not right; the diff between the
> attached two files show a 47-line hunk that inserts at line 400,
> then the next 6-line hunk inserts at line 401 which is obviously
> bogus.
>
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index afaada1..3e7f999 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -244,7 +244,7 @@ int xdl_emit_hunk_hdr(long s1, long c1,
> memcpy(buf, "@@ -", 4);
> nb += 4;
>
> - nb += xdl_num_out(buf + nb, c1 ? s1: 0);
> + nb += xdl_num_out(buf + nb, c1 ? s1 : (s1-1));
>
> if (c1 != 1) {
> memcpy(buf + nb, ",", 1);
The fix is fine, but you should do the same even in the s2 case. The
correct hunk should have been:
@@ -6,0 +6 @@
because the lines are actually inserted at the 6th position, but patch
handle its own special 0 count case by adding 1 to the position, so I had
to change even the xpatchi.c code. The 0-context diffs are pretty
dangerous though, since in case of purely added hunks, patch has no way to
verify the orig-file position by matching contexts.
Now I'll take a look at the pre-diff optimization issue ...
- Davide
--- xdiff/xpatchi.c
+++ xdiff/xpatchi.c
@@ -162,9 +162,9 @@
* We start from zero, so decrement by one unless it's the special position
* '0' inside the unified diff (new or deleted file).
*/
- if (hki->s1 > 0)
+ if (hki->s1 > 0 && hki->c1 > 0)
hki->s1--;
- if (hki->s2 > 0)
+ if (hki->s2 > 0 && hki->c2 > 0)
hki->s2--;
return 0;
--- xdiff/xutils.c
+++ xdiff/xutils.c
@@ -537,7 +537,7 @@
memcpy(buf, "@@ -", 4);
nb += 4;
- nb += xdl_num_out(buf + nb, c1 ? s1: 0);
+ nb += xdl_num_out(buf + nb, c1 ? s1: s1 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
@@ -547,7 +547,7 @@
memcpy(buf + nb, " +", 2);
nb += 2;
- nb += xdl_num_out(buf + nb, c2 ? s2: 0);
+ nb += xdl_num_out(buf + nb, c2 ? s2: s2 - 1);
memcpy(buf + nb, ",", 1);
nb += 1;
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
Ah, should have known. I am behind a (lame) transparent proxy on port 80.
I opened that file in my web browser and it showed the old heads. After
a force-refresh (ctrl+F5, which sends some additionally http headers to
refresh the page from the real server), the old heads disappeared, and
git now clones successfully.
git-http-fetch should probably send those extra headers too. I'll try to
find some time to look at this next week.
Thanks!
Daniel
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Nick Hengeveld @ 2006-04-03 18:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Drake, git
In-Reply-To: <7virpqefp1.fsf@assigned-by-dhcp.cox.net>
On Mon, Apr 03, 2006 at 10:23:22AM -0700, Junio C Hamano wrote:
> My standard answer would be
>
> http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
> http-server$ GIT_DIR=. git-update-server-info
Is there any interest in making the HTTP transport slighly less dumb by
using DAV?
I have a working patch to http-fetch that tries to use PROPFIND to get a
remote pack list and falls back to using objects/info/packs. It's
feasible to do something similar to get a remote ref list when cloning,
although that's a bit more work as all refs would have to be fetched
into a local repo and parsed to determine the object type.
Long term, this could give a repo admin the choice of either making sure
git-update-server-info has been run after every ref/pack change or
enabling DAV once. Assuming they need to use HTTP.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: HTTP repo referencing stale heads (can't clone)
From: Junio C Hamano @ 2006-04-03 17:23 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <443146EC.7060704@gentoo.org>
Daniel Drake <dsd@gentoo.org> writes:
> I maintain a small git repo. I upload it over ssh (with git-push) to a
> machine where it is distributed over http:
>
> http://dsd.object4.net/git/zd1211.git/
>...
> I have tried running git-prune and git-update-server-info, but that
> doesn't help.
>
> Any ideas?
My standard answer would be
http-server$ cd /var/www/git/zd1211.git/ ;# or whereever
http-server$ GIT_DIR=. git-update-server-info
but you said you have run it already... Can you try to see if
there is some caching proxy involved that still serves stale
info/refs file?
client$ wget http://dsd.object4.net/git/zd1211.git/info/refs
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 16:54 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 181 bytes --]
On Mon, 2006-04-03 at 09:25 +0200, Jan-Benedict Glaw wrote:
> -YFLAGS=-d
> +YFLAGS=-d -l
> +LFLAGS=-l
Works for me too; thanks for the fix.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] Replace xmalloc+memset(0) with xcalloc.
From: Peter Eriksen @ 2006-04-03 16:35 UTC (permalink / raw)
To: git
From: Peter Eriksen <s022018@student.dtu.dk>
Date: Mon Apr 3 19:30:46 2006 +0100
Subject: [PATCH] Replace xmalloc+memset(0) with xcalloc.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
Is something like this considered a cleaup?
Regards,
Peter
apply.c | 9 +++------
blob.c | 3 +--
commit.c | 3 +--
convert-objects.c | 3 +--
http-push.c | 6 ++----
object.c | 6 ++----
read-tree.c | 9 +++------
tag.c | 3 +--
tree.c | 7 ++-----
update-index.c | 6 ++----
10 files changed, 18 insertions(+), 37 deletions(-)
d5c82aa8a2b9d776bb30efac17d15a8a596b47f4
diff --git a/apply.c b/apply.c
index c50b3a6..6623ae7 100644
--- a/apply.c
+++ b/apply.c
@@ -924,8 +924,7 @@ static int parse_single_patch(char *line
struct fragment *fragment;
int len;
- fragment = xmalloc(sizeof(*fragment));
- memset(fragment, 0, sizeof(*fragment));
+ fragment = xcalloc(1, sizeof(*fragment));
len = parse_fragment(line, size, patch, fragment);
if (len <= 0)
die("corrupt patch at line %d", linenr);
@@ -1651,8 +1650,7 @@ static void add_index_file(const char *p
if (!write_index)
return;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
memcpy(ce->name, path, namelen);
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = htons(namelen);
@@ -1808,8 +1806,7 @@ static int apply_patch(int fd, const cha
struct patch *patch;
int nr;
- patch = xmalloc(sizeof(*patch));
- memset(patch, 0, sizeof(*patch));
+ patch = xcalloc(1, sizeof(*patch));
nr = parse_chunk(buffer + offset, size, patch);
if (nr < 0)
break;
diff --git a/blob.c b/blob.c
index 84ec121..c1fdd86 100644
--- a/blob.c
+++ b/blob.c
@@ -8,8 +8,7 @@ struct blob *lookup_blob(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct blob *ret = xmalloc(sizeof(struct blob));
- memset(ret, 0, sizeof(struct blob));
+ struct blob *ret = xcalloc(1, sizeof(struct blob));
created_object(sha1, &ret->object);
ret->object.type = blob_type;
return ret;
diff --git a/commit.c b/commit.c
index eb42d51..d4976fb 100644
--- a/commit.c
+++ b/commit.c
@@ -73,8 +73,7 @@ struct commit *lookup_commit(const unsig
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct commit *ret = xmalloc(sizeof(struct commit));
- memset(ret, 0, sizeof(struct commit));
+ struct commit *ret = xcalloc(1, sizeof(struct commit));
created_object(sha1, &ret->object);
ret->object.type = commit_type;
return ret;
diff --git a/convert-objects.c b/convert-objects.c
index b49bce2..b2aafbb 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -18,8 +18,7 @@ static struct entry * convert_entry(unsi
static struct entry *insert_new(unsigned char *sha1, int pos)
{
- struct entry *new = xmalloc(sizeof(struct entry));
- memset(new, 0, sizeof(*new));
+ struct entry *new = xcalloc(1, sizeof(struct entry));
memcpy(new->old_sha1, sha1, 20);
memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * sizeof(struct entry *));
convert[pos] = new;
diff --git a/http-push.c b/http-push.c
index ba7d9de..b60fa8d 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1008,8 +1008,7 @@ static int fetch_indices(void)
struct active_request_slot *slot;
struct slot_results results;
- data = xmalloc(4096);
- memset(data, 0, 4096);
+ data = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
buffer.buffer = data;
@@ -2042,8 +2041,7 @@ static void update_remote_info_refs(stru
char *if_header;
struct curl_slist *dav_headers = NULL;
- buffer.buffer = xmalloc(4096);
- memset(buffer.buffer, 0, 4096);
+ buffer.buffer = xcalloc(1, 4096);
buffer.size = 4096;
buffer.posn = 0;
remote_ls("refs/", (PROCESS_FILES | RECURSIVE),
diff --git a/object.c b/object.c
index c9ca481..71e15e1 100644
--- a/object.c
+++ b/object.c
@@ -85,8 +85,7 @@ struct object_refs *alloc_object_refs(un
struct object_refs *refs;
size_t size = sizeof(*refs) + count*sizeof(struct object *);
- refs = xmalloc(size);
- memset(refs, 0, size);
+ refs = xcalloc(1, size);
refs->count = count;
return refs;
}
@@ -178,8 +177,7 @@ struct object *lookup_unknown_object(con
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- union any_object *ret = xmalloc(sizeof(*ret));
- memset(ret, 0, sizeof(*ret));
+ union any_object *ret = xcalloc(1, sizeof(*ret));
created_object(sha1, &ret->object);
ret->object.type = NULL;
return &ret->object;
diff --git a/read-tree.c b/read-tree.c
index eaff444..58e5636 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -133,11 +133,9 @@ #endif
pathlen = strlen(first);
ce_size = cache_entry_size(baselen + pathlen);
- src = xmalloc(sizeof(struct cache_entry *) * src_size);
- memset(src, 0, sizeof(struct cache_entry *) * src_size);
+ src = xcalloc(src_size, sizeof(struct cache_entry *));
- subposns = xmalloc(sizeof(struct tree_list_entry *) * len);
- memset(subposns, 0, sizeof(struct tree_list_entry *) * len);
+ subposns = xcalloc(len, sizeof(struct tree_list_entry *));
if (cache_name && !strcmp(cache_name, first)) {
any_files = 1;
@@ -177,8 +175,7 @@ #endif
else
ce_stage = 2;
- ce = xmalloc(ce_size);
- memset(ce, 0, ce_size);
+ ce = xcalloc(1, ce_size);
ce->ce_mode = create_ce_mode(posns[i]->mode);
ce->ce_flags = create_ce_flags(baselen + pathlen,
ce_stage);
diff --git a/tag.c b/tag.c
index ac0e573..f390ee7 100644
--- a/tag.c
+++ b/tag.c
@@ -19,8 +19,7 @@ struct tag *lookup_tag(const unsigned ch
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tag *ret = xmalloc(sizeof(struct tag));
- memset(ret, 0, sizeof(struct tag));
+ struct tag *ret = xcalloc(1, sizeof(struct tag));
created_object(sha1, &ret->object);
ret->object.type = tag_type;
return ret;
diff --git a/tree.c b/tree.c
index 87e0d74..d599fb5 100644
--- a/tree.c
+++ b/tree.c
@@ -18,10 +18,8 @@ static int read_one_entry(unsigned char
len = strlen(pathname);
size = cache_entry_size(baselen + len);
- ce = xmalloc(size);
+ ce = xcalloc(1, size);
- memset(ce, 0, size);
-
ce->ce_mode = create_ce_mode(mode);
ce->ce_flags = create_ce_flags(baselen + len, stage);
memcpy(ce->name, base, baselen);
@@ -130,8 +128,7 @@ struct tree *lookup_tree(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tree *ret = xmalloc(sizeof(struct tree));
- memset(ret, 0, sizeof(struct tree));
+ struct tree *ret = xcalloc(1, sizeof(struct tree));
created_object(sha1, &ret->object);
ret->object.type = tree_type;
return ret;
diff --git a/update-index.c b/update-index.c
index 797245a..1efac27 100644
--- a/update-index.c
+++ b/update-index.c
@@ -114,8 +114,7 @@ static int add_file_to_cache(const char
namelen = strlen(path);
size = cache_entry_size(namelen);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->name, path, namelen);
ce->ce_flags = htons(namelen);
fill_stat_cache_info(ce, &st);
@@ -312,8 +311,7 @@ static int add_cacheinfo(unsigned int mo
len = strlen(path);
size = cache_entry_size(len);
- ce = xmalloc(size);
- memset(ce, 0, size);
+ ce = xcalloc(1, size);
memcpy(ce->sha1, sha1, 20);
memcpy(ce->name, path, len);
--
1.3.0.rc1.g40e9
^ permalink raw reply related
* Re: git-svn and svn sw --relocate
From: Nicolas Vilz 'niv' @ 2006-04-03 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060402222100.GA17888@localdomain>
Eric Wong wrote:
> Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
>>i have now my repository locally and i want to get it remotely on a
>>server, in order to have a few collaborators...
>>
>>the steps on the svn-side are clear. But what do i have todo on the
>>git-svn-side of this life?
>>
>>does a simple "svn sw --relocate" do the job in the git-svn meta-dir?
>
>
> Yes, you'll need to do that in .git/git-svn/tree and also update
> .git/git-svn/info/url by hand.
Will there be any other sha1-sums for that repository so that i have to
merge them again and again? This issue occured to me the last time i
encountered the git-svn-change with the external sources, where i had to
repair my external git-svn-tree, which resulted in new sha1sums
somehow... that was very unpleasant to my collegue..
Although the uuids there should remain the same... so i think, that
would be no problem to try.
Thanks for the tip.
Nicolas
^ permalink raw reply
* HTTP repo referencing stale heads (can't clone)
From: Daniel Drake @ 2006-04-03 16:01 UTC (permalink / raw)
To: git
Hi,
I maintain a small git repo. I upload it over ssh (with git-push) to a
machine where it is distributed over http:
http://dsd.object4.net/git/zd1211.git/
For some reason it is no longer possible to clone this repo over http:
walk 35afe6b3a859242a18812e7485ea8b211e24abaf
walk 93d9a9f469282e1e392c16ce571da4c08805e8bb
error: Couldn't get
http://dsd.object4.net/git/zd1211.git/refs/heads/softmac-old for
heads/softmac-old
The requested URL returned error: 404
error: Could not interpret heads/softmac-old as something to pull
"softmac-old" is an old branch, which I have recently deleted. I deleted
it by removing the .git/refs/heads/softmac-old file, and relying on
git-prune to clear out old objects.
Even on the server-side, there is no obvious reference to this old head:
$ find -name '*softmac*'
$ grep -R softmac *
(no results for either)
"git-fsck-objects" reports nothing, "git-fsck-objects --full" reports:
dangling commit 7cc423c942975005f96f308186537ad6e7808c2e
dangling commit b36378de6231f1b5100b1517b9c8c243a21090fd
I have tried running git-prune and git-update-server-info, but that
doesn't help.
Any ideas? I'm still new to git.
I am running git-1.2.4
Thanks,
Daniel
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Sam Vilain @ 2006-04-03 15:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604030727250.3781@g5.osdl.org>
On Mon, 2006-04-03 at 07:29 -0700, Linus Torvalds wrote:
> I really think that darcs is just "nice theory", and has nothing to do
> with real life.
>
> Terms like "patch calculus" may sound cool and useful, but let's face it,
> the proof is in the pudding, and quite frankly, I would bet that trying to
> do something like that on a real project would just be a total disaster.
>
> I want my merges simple. I want them to take a couple of seconds. I
> don't want to see strange patch dependencies that nobody cares about.
Dave really was right with his keynote comment about nomenclature in
Dunedin. I shouldn't even have put the term "patch calculus" in the
e-mail body at all :-P
Seriously, though, the rest of the report basically agrees with your
position. Sorry if it was rambling and that key message wasn't clear.
We did kind of work out along the way that the best bits of patch
calculus were probably obtained with good use of topic branches. Likely
if there are any key advances to be made, they will be found in the form
of clever ways to manage topic branches.
> And I very much don't want to see theory over practice.
Theory? Do I *look* like a theorist?
(looks around sheepishly)
This was valuable cross-culture field research!
(looks around at rather non-plussed eyes)
Hey, I found it quite enlightening, and at least a few other people were
amused by the ordeal. And I learned a little bit more about git along
the way.
(waits for a 'hear', 'hear'! silence.)
I'll get me coat.
Sam.
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jeff King @ 2006-04-03 15:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1144075047.2303.97.camel@neko.keithp.com>
On Mon, Apr 03, 2006 at 07:37:27AM -0700, Keith Packard wrote:
> You can't. You need to create a local copy of the repository. There is a
> tool which can do that using the cvs protocol, but I don't recall the
> name.
I believe you're thinking of CVSSuck:
http://cvs.m17n.org/~akr/cvssuck/
-Peff
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Johannes Schindelin @ 2006-04-03 15:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
Hi,
On Mon, 3 Apr 2006, Linus Torvalds wrote:
> On Mon, 3 Apr 2006, Johannes Schindelin wrote:
> >
> > The problem is not mmap() on cygwin, but that a fork() has to jump through
> > loops to reinstall the open file descriptors on cygwin. If the
> > corresponding file was deleted, that fails. Therefore, we work around that
> > on cygwin by actually reading the file into memory, *not* mmap()ing it.
>
> Well, we could actually do a _real_ mmap on pack-files. The pack-files are
> much better mmap'ed - there we don't _want_ them to be removed while we're
> using them. It was the index file etc that was problematic.
>
> Maybe the cygwin fake mmap should be triggered only for the index (and
> possibly the individual objects - if only because there doing a
> malloc+read may actually be faster).
I hit the problem *only* with "git-whatchanged -p". Which means that the
upcoming we-no-longer-write-temp-files-for-diff version should make that
gitfakemmap() hack obsolete. (I have not checked whether there are other
places where a file is mmap()ed and then used by a fork()ed process.)
Ciao,
Dscho
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 14:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: keithp, git
In-Reply-To: <e0rb0j$ml9$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Mon, 2006-04-03 at 16:21 +0200, Jakub Narebski wrote:
> From the comments on #git, parsecvs reads raw ,v files for creating history
> tree, then uses 'cvs co ...' for getting the contents.
It's not using cvs co, it's using the rcs 'co' command. I will probably
fix it to just generate the files directly as that will be a lot faster.
If there was a git command to create blobs directly from file contents,
it would be faster still as I could create all of the blobs for a
particular file in one pass and then just build trees in the index out
of those.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Alex Riesen @ 2006-04-03 14:38 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604030246q21fccb9ar93004ac67d8b28b3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On 4/3/06, Kees-Jan Dijkzeul <k.j.dijkzeul@gmail.com> wrote:
> I'm trying to get Git to manage a 5Gb source tree. Under linux, this
> works like a charm. Under cygwin, however, I run in to difficulties.
> For example:
>
> $ git-clone sgp-wa/ sgp-wa.clone
> fatal: packfile
> ./objects/pack/pack-56aa013a0234e198467ed37ae5db925764a6ee98.pack
> cannot be mapped.
> fatal: unexpected EOF
> fetch-pack from '/cygdrive/e/Projects/sgp-wa/.git' failed.
>
> To figure out what is happening, I printed the value of errno, which
> turns out to be 12 (Cannot allocate memory). I'm not sure how mmap is
mmap in git on cygwin does not mmaps anything,
but just reads the whole file in memory.
> I'm not sure how to approach this problem. Any tips would be greatly
> appreciated.
I ended up hacking gitfakemmap like in the attached patches (sorry for mime).
It's very ugly and unsafe hack, and it's actually exactly the reason why it was
never submitted. Still, it helps me (it speedups revlist, for
instance), and maybe
it'll help you.
It is a really good example what stupid windows restrictions can do to
a program.
The patch is against git as of 3-Apr-2005, ~10 CET
[-- Attachment #2: cygmmap.patch --]
[-- Type: text/x-patch, Size: 5710 bytes --]
diff --git a/Makefile b/Makefile
index c79d646..8a46436
--- a/Makefile
+++ b/Makefile
@@ -389,7 +389,7 @@ ifdef NO_SETENV
endif
ifdef NO_MMAP
COMPAT_CFLAGS += -DNO_MMAP
- COMPAT_OBJS += compat/mmap.o
+ COMPAT_OBJS += compat/mmap.o compat/realmmap.o
endif
ifdef NO_IPV6
ALL_CFLAGS += -DNO_IPV6
diff --git a/compat/realmmap.c b/compat/realmmap.c
new file mode 100644
index 0000000..8f26641
--- /dev/null
+++ b/compat/realmmap.c
@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <sys/mman.h>
+#include "../git-compat-util.h"
+
+#undef mmap
+#undef munmap
+
+void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
+{
+ if (start != NULL || !(flags & MAP_PRIVATE)) {
+ errno = ENOTSUP;
+ return MAP_FAILED;
+ }
+ start = mmap(start, length, prot, flags, fd, offset);
+ return start;
+}
+
+int realmunmap(void *start, size_t length)
+{
+ return munmap(start, length);
+}
+
+
diff --git a/diff.c b/diff.c
index e496905..f1a2cf0 100644
--- a/diff.c
+++ b/diff.c
@@ -450,7 +450,7 @@ int diff_populate_filespec(struct diff_f
fd = open(s->path, O_RDONLY);
if (fd < 0)
goto err_empty;
- s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
+ s->data = realmmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (s->data == MAP_FAILED)
goto err_empty;
@@ -482,7 +482,7 @@ void diff_free_filespec_data(struct diff
if (s->should_free)
free(s->data);
else if (s->should_munmap)
- munmap(s->data, s->size);
+ realmunmap(s->data, s->size);
s->should_free = s->should_munmap = 0;
s->data = NULL;
free(s->cnt_data);
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..85150f8 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -42,22 +42,28 @@ extern int error(const char *err, ...) _
#ifdef NO_MMAP
-#ifndef PROT_READ
+#include <sys/mman.h>
+/*#ifndef PROT_READ
#define PROT_READ 1
#define PROT_WRITE 2
#define MAP_PRIVATE 1
#define MAP_FAILED ((void*)-1)
-#endif
+#endif*/
#define mmap gitfakemmap
#define munmap gitfakemunmap
extern void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
extern int gitfakemunmap(void *start, size_t length);
+extern void *realmmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);
+extern int realmunmap(void *start, size_t length);
+
#else /* NO_MMAP */
#include <sys/mman.h>
+#define realmmap mmap
+#define realmunmap munmap
#endif /* NO_MMAP */
#ifdef NO_SETENV
diff --git a/sha1_file.c b/sha1_file.c
index 58edec0..712a068 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -330,14 +330,14 @@ void prepare_alt_odb(void)
close(fd);
return;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return;
link_alt_odb_entries(map, map + st.st_size, '\n',
get_object_directory());
- munmap(map, st.st_size);
+ realmunmap(map, st.st_size);
}
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
@@ -378,7 +378,7 @@ static int check_packed_git_idx(const ch
return -1;
}
idx_size = st.st_size;
- idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ idx_map = realmmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (idx_map == MAP_FAILED)
return -1;
@@ -423,7 +423,7 @@ static int unuse_one_packed_git(void)
}
if (!lru)
return 0;
- munmap(lru->pack_base, lru->pack_size);
+ realmunmap(lru->pack_base, lru->pack_size);
lru->pack_base = NULL;
return 1;
}
@@ -460,7 +460,7 @@ int use_packed_git(struct packed_git *p)
}
if (st.st_size != p->pack_size)
die("packfile %s size mismatch.", p->pack_name);
- map = mmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, p->pack_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
die("packfile %s cannot be mapped.", p->pack_name);
@@ -494,7 +494,7 @@ struct packed_git *add_packed_git(char *
/* do we have a corresponding .pack file? */
strcpy(path + path_len - 4, ".pack");
if (stat(path, &st) || !S_ISREG(st.st_mode)) {
- munmap(idx_map, idx_size);
+ realmunmap(idx_map, idx_size);
return NULL;
}
/* ok, it looks sane as far as we can check without
@@ -647,7 +647,7 @@ static void *map_sha1_file_internal(cons
*/
sha1_file_open_flag = 0;
}
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ map = realmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (map == MAP_FAILED)
return NULL;
@@ -1184,7 +1184,7 @@ int sha1_object_info(const unsigned char
*sizep = size;
}
inflateEnd(&stream);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return status;
}
@@ -1210,7 +1210,7 @@ void * read_sha1_file(const unsigned cha
map = map_sha1_file_internal(sha1, &mapsize);
if (map) {
buf = unpack_sha1_file(map, mapsize, type, size);
- munmap(map, mapsize);
+ realmunmap(map, mapsize);
return buf;
}
return NULL;
@@ -1493,7 +1493,7 @@ int write_sha1_to_fd(int fd, const unsig
} while (posn < objsize);
if (map)
- munmap(map, objsize);
+ realmunmap(map, objsize);
if (temp_obj)
free(temp_obj);
@@ -1646,7 +1646,7 @@ int index_fd(unsigned char *sha1, int fd
buf = "";
if (size)
- buf = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+ buf = realmmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
if (buf == MAP_FAILED)
return -1;
@@ -1660,7 +1660,7 @@ int index_fd(unsigned char *sha1, int fd
ret = 0;
}
if (size)
- munmap(buf, size);
+ realmunmap(buf, size);
return ret;
}
^ 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