* Re: Strangely broken git repo
From: Linus Torvalds @ 2005-10-10 15:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Langhoff (CatalystIT), Nick Hengeveld, Daniel Barkalow,
git
In-Reply-To: <Pine.LNX.4.64.0510100742070.14597@g5.osdl.org>
On Mon, 10 Oct 2005, Linus Torvalds wrote:
>
> It seems to be the space.
Doing an strace on curl vs wget shows that curl seems to do no quoting at
all. I'd personally argue that that is a serious bug in curl: it sure as
hell knows that it's a http transport, and it seems to be just doing
GET %s HTTP/1.0\r\nUser-agent:...
without any sanity checking at all.
Linus
^ permalink raw reply
* [PATCH] t5400-send-pack relies on a working cpio
From: Johannes Schindelin @ 2005-10-10 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since cygwin does not install cpio by default, t5400 results in a very
cryptic failure. So, test for cpio explicitely.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t5400-send-pack.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
applies-to: c1b731620114e8b58054b944865e3bf361f941f5
d3bafb81a99406258cfb318344a176264c269427
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 1a4d2f2..7fc3bd7 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -8,6 +8,9 @@ test_description='See why rewinding head
'
. ./test-lib.sh
+touch cpio-test
+test_expect_success 'working cpio' 'echo cpio-test | cpio -o > /dev/null'
+
cnt='1'
test_expect_success setup '
tree=$(git-write-tree) &&
---
0.99.8.GIT
^ permalink raw reply related
* openbsd version?
From: Randal L. Schwartz @ 2005-10-10 16:12 UTC (permalink / raw)
To: git
I noticed "openbsd" in the operating systems detected in Makefile,
but when I tried this on my openbsd system, I get an abort here:
gcc -g -O2 -Wall -I/usr/local/include -L/usr/local/lib '-DSHA1_HEADER=<openssl/sha.h>' -o git-mailinfo mailinfo.o libgit.a -liconv
mailinfo.o(.text+0x22d): In function `slurp_attr':
/opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'
mailinfo.o(.text+0x2a9): In function `handle_subcontent_type':
/opt/git/src/git-snapshot-20051010/mailinfo.c:155: undefined reference to `strcasestr'
mailinfo.o(.text+0x39d): In function `handle_content_transfer_encoding':
/opt/git/src/git-snapshot-20051010/mailinfo.c:181: undefined reference to `strcasestr'
mailinfo.o(.text+0x3c6):/opt/git/src/git-snapshot-20051010/mailinfo.c:183: undefined reference to `strcasestr'
collect2: ld returned 1 exit status
gmake: *** [git-mailinfo] Error 1
What am I doing wrong?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: openbsd version?
From: Peter Eriksen @ 2005-10-10 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <8664s5gxl9.fsf@blue.stonehenge.com>
On Mon, Oct 10, 2005 at 09:12:34AM -0700, Randal L. Schwartz wrote:
>
> I noticed "openbsd" in the operating systems detected in Makefile,
> but when I tried this on my openbsd system, I get an abort here:
>
> gcc -g -O2 -Wall -I/usr/local/include -L/usr/local/lib '-DSHA1_HEADER=<openssl/sha.h>' -o git-mailinfo mailinfo.o libgit.a -liconv
> mailinfo.o(.text+0x22d): In function `slurp_attr':
> /opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'
> mailinfo.o(.text+0x2a9): In function `handle_subcontent_type':
> /opt/git/src/git-snapshot-20051010/mailinfo.c:155: undefined reference to `strcasestr'
> mailinfo.o(.text+0x39d): In function `handle_content_transfer_encoding':
> /opt/git/src/git-snapshot-20051010/mailinfo.c:181: undefined reference to `strcasestr'
> mailinfo.o(.text+0x3c6):/opt/git/src/git-snapshot-20051010/mailinfo.c:183: undefined reference to `strcasestr'
> collect2: ld returned 1 exit status
> gmake: *** [git-mailinfo] Error 1
>
> What am I doing wrong?
You need to compile with
$ gmake NO_STRCASESTR=Indeed
Peter
^ permalink raw reply
* Re: openbsd version?
From: Linus Torvalds @ 2005-10-10 16:41 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8664s5gxl9.fsf@blue.stonehenge.com>
On Mon, 10 Oct 2005, Randal L. Schwartz wrote:
>
> I noticed "openbsd" in the operating systems detected in Makefile,
> but when I tried this on my openbsd system, I get an abort here:
>
> /opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'
Either do
make NO_STRCASESTR=1 ..
or add that explicitly to the makefile in the OpenBSD rules and send Junio
a tested patch ;)
Linus
^ permalink raw reply
* Re: [PATCH] Add support for parallel HTTP transfers
From: Jon Loeliger @ 2005-10-10 16:48 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Nick Hengeveld, Git List
In-Reply-To: <Pine.LNX.4.63.0510071808071.23242@iabervon.org>
On Fri, 2005-10-07 at 17:39, Daniel Barkalow wrote:
>
> I believe that the situation is the one you describe in your previous
> message: we determine we need to fetch A and B; we ask for A; we ask for
> B; we find A isn't available alone, but is available in a pack; we get the
> pack; we find we now have B (in the pack); the request for B (which would
> probably fail) is left dangling.
>
> The only actual problem I can see is if this happens with a whole bunch of
> objects at the beginning of a big download, and all but one of your
> connections are left in this state while you download all of the loose
> objects over the one connection that got the pack.
>
> I don't know if this is a problem for the new http code, but it could be
> an issue in general if a transport method allocates resources in
> prefetch().
So, this sounds like a classic resource scheduling problem
with various solutions encoded in many compiler schedulers.
Doesn't this sort of scheduling problem get solved by a
two-stage request pipeline model? In particular, you only
"semi-request A" and "semi-request B" into a queue. When
all of the sub-parts (that are needed) of some pack P have
been requested you issue the one request for the common
pack P holding all the sub-parts. Then all the sub-parts
are can be retired from the queue.
Or am I just now finally catching up? :-)
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Fix cygwin install issues
From: Junio C Hamano @ 2005-10-10 16:51 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <434A82A0.7060608@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
>> ... I suspect it might be
>> the responsibility of the user to quote them if she chooses to
>> set bindir or DESTDIR to a funky value, like this:
>> $ make bindir="'My Documents\Programs'"
>
> I don't think that's the right approach.
>
> $(INSTALL) -d -m755 '$(DESTDIR)$(bindir)'
>
> ... at least handles everything except embedded single quotes.
OK. It is better than dq, and the user can still work it around
like this if she really wanted to:
make bindir="Anna'\\''s Home/bin"
I wish we had $(shellquote $(DESTDIR)$(bindir)) in make ;-).
^ permalink raw reply
* Re: [PATCH] Fix cygwin install issues
From: H. Peter Anvin @ 2005-10-10 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64s571t5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> OK. It is better than dq, and the user can still work it around
> like this if she really wanted to:
>
> make bindir="Anna'\\''s Home/bin"
>
> I wish we had $(shellquote $(DESTDIR)$(bindir)) in make ;-).
Hmm... let's think about this for a second...
shellquote = '$(subst ','\'',$(1))'
$(call shellquote,$(whatever))
... seems to work just fine.
(No need to worry about ! since Make commands are always /bin/sh.)
-hpa
^ permalink raw reply
* Re: SVN import
From: Yasushi SHOJI @ 2005-10-10 17:48 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.10.10.09.45.00.468989@smurf.noris.de>
Hi Matthias,
Great work!
At Mon, 10 Oct 2005 11:45:05 +0200,
Matthias Urlichs wrote:
>
> > Quick note: I'm working on importing from SVN.
>
> The first version seems to be finished.
just tried on my svn repo, which had flat directory but moved to trunk
dir after. on that repo, the-current-just-pulled git-svnimport says:
1: Unrecognized path: /main.c
to reproduce:
svnadmin create --fs-type fsfs /tmp/repo
svn co file:///tmp/repo test
cd test
touch main.c
svn add main.c
svn ci main.c -m 'testing svnimport'
svn mkdir trunk
svn move main.c trunk
svn ci -m 'move main.c to trunk/'
cd ..
git-svnimport.perl -C /tmp/test.git -i -v file:///tmp/repo/
hope this helps,
--
yashi
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Daniel Barkalow @ 2005-10-10 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0fpbz43.fsf@assigned-by-dhcp.cox.net>
On Mon, 10 Oct 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Perhaps have a bit in the index mode for the file to say that the mode in
> > the filesystem is unreliable, which gets set if a stat of the
> > newly-written file doesn't match the mode it was supposed to have, or if
> > git chmod is used to change it; then, if the bit is set, ignore the mode
> > in the filesystem and just use the mode in the index.
>
> In effect, you are making the "per-repo configuration" Linus
> mentioned a non configuration but a property recorded in the
> index file. I think this is a clever solution which is very
> helpful to the end user. I have to think about this a bit, but
> my gut feeling tells me that it is the right direction if it
> works.
>
> I do not think you have to necessarily record it in the "index
> mode" -- which implies this is per path -- nor even in the index
> file itself. We might even be able to get away with doing this
> check at git-init-db time just once, and record it in a file,
> say ".git/fs-mode-unreliable".
Actually, you're right; it is information about the behavior of the
working tree, and is also needed if you want to compare the working tree
against a tree object, in which case you aren't using the index at all.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 18:13 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <8764s51cvp.wl@mail2.atmark-techno.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi,
Yasushi SHOJI:
> just tried on my svn repo, which had flat directory but moved to trunk
> dir after. on that repo, the-current-just-pulled git-svnimport says:
>
> 1: Unrecognized path: /main.c
>
True. I could add an option which behaves as if everything that's not
recognized is seen as being on the trunk, but ...
> git-svnimport.perl -C /tmp/test.git -i -v file:///tmp/repo/
>
Fixed in the last upload -- you get an -s2 option which skips the broken
first check-in, and as a special bonus it manages not to skip the *last*
version either. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Be like a duck -- keep calm and unruffled on the surface but paddle like the
devil under water.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Strangely broken git repo
From: Morten Welinder @ 2005-10-10 18:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510100800580.14597@g5.osdl.org>
Spaces in URLs are off-spec. (And common, go figure.)
M.
^ permalink raw reply
* Re: Seeing various mode changes on cygwin
From: Linus Torvalds @ 2005-10-10 18:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0510101354520.23242@iabervon.org>
On Mon, 10 Oct 2005, Daniel Barkalow wrote:
>
> Actually, you're right; it is information about the behavior of the
> working tree, and is also needed if you want to compare the working tree
> against a tree object, in which case you aren't using the index at all.
Git _always_ uses the index for working tree operations.
It may take the actual file _data_ from the working tree, but it will take
the list of files from the index, so it's certainly possible to link the
index to the working tree.
That said, I don't think it's necessarily a good idea. You can have
temporary indexes for various operations that ignore the main one (ie any
random
GIT_INDEX_FILE=tmp git-read-tree ...
will create a new index).
So I think it's much better to have a config file.
I'll write something up. Make it extensible while at it.
Linus
^ permalink raw reply
* Re: Strangely broken git repo
From: Linus Torvalds @ 2005-10-10 18:23 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0510101119n4e7e9399x705993b4608d63b6@mail.gmail.com>
On Mon, 10 Oct 2005, Morten Welinder wrote:
>
> Spaces in URLs are off-spec. (And common, go figure.)
They may be off-spec in url's, but that doesn't mean that "curl" should
just ignore them. It should either escape them, or refuse them. Using
user-supplied data without any checks is usually a really bad idea.
Linus
^ permalink raw reply
* Re: SVN import
From: Yasushi SHOJI @ 2005-10-10 18:30 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20051010181329.GQ567@kiste.smurf.noris.de>
At Mon, 10 Oct 2005 20:13:29 +0200,
Matthias Urlichs wrote:
>
> Yasushi SHOJI:
> > just tried on my svn repo, which had flat directory but moved to trunk
> > dir after. on that repo, the-current-just-pulled git-svnimport says:
> >
> > 1: Unrecognized path: /main.c
> >
> True. I could add an option which behaves as if everything that's not
> recognized is seen as being on the trunk, but ...
hmmm. can libsvn see those file had moved in to the trunk? don't know
how 'svn mv' is treated in svn.
> > git-svnimport.perl -C /tmp/test.git -i -v file:///tmp/repo/
> >
> Fixed in the last upload -- you get an -s2 option which skips the broken
> first check-in, and as a special bonus it manages not to skip the *last*
> version either. ;-)
thanks for quick fix. I was gonna report that one too but your fix
own over my tying speed ;-)
# I guess I need to wait for mirroring script to catch up?
--
yashi
^ permalink raw reply
* Re: Strangely broken git repo
From: Johannes Schindelin @ 2005-10-10 18:30 UTC (permalink / raw)
To: Morten Welinder; +Cc: Linus Torvalds, git
In-Reply-To: <118833cc0510101119n4e7e9399x705993b4608d63b6@mail.gmail.com>
Hi,
On Mon, 10 Oct 2005, Morten Welinder wrote:
> Spaces in URLs are off-spec. (And common, go figure.)
%20
Hth,
Dscho
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-10 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <7vr7avrgr2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
> correctly we do not write file via mmap -- at least we do not
> intend to.
>
Then PROT_READ probably makes more sense?
>
> Yes. It might have been overkill that you supported writing
> changes back, though.
Not just overkill; if we do MAP_PRIVATE it's actively WRONG.
-hpa
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-10 18:45 UTC (permalink / raw)
To: Elfyn McBratney; +Cc: Alex Riesen, Junio C Hamano, git
In-Reply-To: <20051008010021.GA29261@gentoo.org>
Elfyn McBratney wrote:
> >
> > Junio, unless there already are pressing reasons to put the patch in
> > GIT, could you postpone its inclusion (if you ever considered)? Or at
> > least put "#ifdef __cygwin" (I hope this is the define) around it?
>
> Close ;) - the define is "__CYGWIN__".
>
This should be a feature-control macro in the Makefile.
^ permalink raw reply
* Re: SVN import
From: Matthias Urlichs @ 2005-10-10 18:57 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <874q7p1axz.wl@mail2.atmark-techno.com>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
Hi,
Yasushi SHOJI:
> > True. I could add an option which behaves as if everything that's not
> > recognized is seen as being on the trunk, but ...
>
> hmmm. can libsvn see those file had moved in to the trunk? don't know
> how 'svn mv' is treated in svn.
>
see "svn log". The script sees the file, and where it comes from (but
ignores that).
> # I guess I need to wait for mirroring script to catch up?
? it was uptodate when I wrote that mail; see
http://netz.smurf.noris.de/cgi/gitweb?p=git.git;a=shortlog;h=svn
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
All intelligent species own cats.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-10-10 19:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <434AB663.8050205@zytor.com>
Hi,
On Mon, 10 Oct 2005, H. Peter Anvin wrote:
> Junio C Hamano wrote:
> >
> > PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
> > correctly we do not write file via mmap -- at least we do not
> > intend to.
> >
>
> Then PROT_READ probably makes more sense?
Not necessarily. Sometimes you need to annotate the data from the index,
and this does not need to be written back to the index file.
> > Yes. It might have been overkill that you supported writing
> > changes back, though.
>
> Not just overkill; if we do MAP_PRIVATE it's actively WRONG.
See above.
BTW, is there a mechanism to make sure that the index file is locked
between reading and writing?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Cleaning up die() error messages
From: Junio C Hamano @ 2005-10-10 19:04 UTC (permalink / raw)
To: Elfyn McBratney; +Cc: git mailing list
In-Reply-To: <20051010105008.GB30202@gentoo.org>
Elfyn McBratney <beu@gentoo.org> writes:
> (Of course, the C parts (`prog' and `set_prog_name()') would go into a
> header, and not in every single C source file. ;)
>
> So, any thoughts/comments/flames? :)
I do not have objections to either one, except I tend to prefer
programs that tells its full path when erroring out, which helps
me identify "Oops, my path was screwed up and I am not testing
the right one" case.
One thing to keep in mind is how badly this C part might
interact with the libification effort going on underwater.
Since current code Smurf is working on is based on 0.99.6 and
many small pieces need to be reviewed anyway, I am not so much
worried about forward porting the changes. But some die()s that
are in the parts that will be moved to the common library code
would also want to use this prog global somehow.
But that would not be too much of a problem. Worst case, we
force the library clients to do set_prog_name(), or initialize
prog to "(unnamed)", or do both.
^ permalink raw reply
* Re: openbsd version?
From: Junio C Hamano @ 2005-10-10 19:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510100939320.14597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Either do
>
> make NO_STRCASESTR=1 ..
>
> or add that explicitly to the makefile in the OpenBSD rules and send Junio
> a tested patch ;)
Thanks; this has been resolved underwater.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-10-10 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0510102100010.7688@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
>>Junio C Hamano wrote:
>>
>>>PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
>>>correctly we do not write file via mmap -- at least we do not
>>>intend to.
>>>
>>
>>Then PROT_READ probably makes more sense?
>
> Not necessarily. Sometimes you need to annotate the data from the index,
> and this does not need to be written back to the index file.
>
In the above sentence, emphasis on "at least we do not intend to." If
writes are done legitimately then that's fine, but we shouldn't have
"accidental writes" -- those would be program bugs!
>
>>>Yes. It might have been overkill that you supported writing
>>>changes back, though.
>>
>>Not just overkill; if we do MAP_PRIVATE it's actively WRONG.
>
> See above.
>
Eh? If we MAP_PRIVATE, *and* we (intentionally) write to it, we
*BETTER* not write anything back.
-hpa
^ permalink raw reply
* Re: openbsd version?
From: Randal L. Schwartz @ 2005-10-10 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vvf0542fs.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Linus Torvalds <torvalds@osdl.org> writes:
>> Either do
>>
>> make NO_STRCASESTR=1 ..
>>
>> or add that explicitly to the makefile in the OpenBSD rules and send Junio
>> a tested patch ;)
Junio> Thanks; this has been resolved underwater.
And yes, I made my first patch with git today! But I cut-n-pasted
it and blew the leading tabs.
Related question. I created "mybranch" to do the patch, but how
can I have my repository now forget that mybranch was ever made?
Is it sufficient to remove the branch link, and then type some "fsck"
operation?
That's also a question in general... how can I remove a commit,
knowing that I'd never refer to it again? Or is disk space so cheap
that it wouldn't make any difference anyway?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-10-10 19:42 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <434AC058.60803@zytor.com>
Hi,
On Mon, 10 Oct 2005, H. Peter Anvin wrote:
> Johannes Schindelin wrote:
> >
> > > Junio C Hamano wrote:
> > >
> > > > PROT_WRITE is true, but we do MAP_PRIVATE, and if I recall
> > > > correctly we do not write file via mmap -- at least we do not
> > > > intend to.
> > > >
> > >
> > > Then PROT_READ probably makes more sense?
> >
> > Not necessarily. Sometimes you need to annotate the data from the index, and
> > this does not need to be written back to the index file.
> >
>
> In the above sentence, emphasis on "at least we do not intend to." If writes
> are done legitimately then that's fine, but we shouldn't have "accidental
> writes" -- those would be program bugs!
Yes, those would be bugs. However, if I understood the man page for mmap()
correctly, then PROT_WRITE && MAP_PRIVATE makes the data copy-on-write,
which means that those bugs would have been found (because the changes
would no longer be present when git was called the next time). And I
checked: all mmap() calls in git are MAP_PRIVATE.
> > > > Yes. It might have been overkill that you supported writing
> > > > changes back, though.
> > >
> > > Not just overkill; if we do MAP_PRIVATE it's actively WRONG.
> >
> > See above.
> >
>
> Eh? If we MAP_PRIVATE, *and* we (intentionally) write to it, we *BETTER* not
> write anything back.
Yes. That was *my* mistake.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox