* Re: Default remote branch for local branch
From: Andreas Ericsson @ 2006-04-03 7:56 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200604030128.42680.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
>
> Optionally, branching <new> off from <old> could add <new> as
> topic branch of <old>: Thus, if you are on <old> and do git-pull,
> you get <new> merged in.
>
This is clearly insane. If I'm on <old> and want to sync with my
upstream source that would be impossible without explicitly telling it
*not* to merge with <new>. Iow, this change would (possibly) simplify
for the one repo maintainer, but make things harder for the 30-odd
developers.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Default remote branch for local branch
From: Junio C Hamano @ 2006-04-03 8:23 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200604030128.42680.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Sunday 02 April 2006 23:40, you wrote:
>> > Let me try to understand this: the general idea is that
>> >
>> > pull.origin = [<refspec> of] <remote> for <branch>
>> >
>> > specifies the default action of git-pull if we are on <branch>, ie.
>> > a "git pull" then runs "git pull <remote> [<refspec>]".
>>
>> Not quite.
>>
>> It will be (if this were a serious proposal -- I am not
>> absolutely convinced this is a good idea) more like "git fetch
>> <remote>" followed by "git-merge HEAD the-refspec-named-there".
>
> So it is not really a <refspec>, but a <localbranch> which has to
> appear in the .git/remotes file on the right side of a refspec on
> a Pull line.
No, I meant <refspec> not <localbranch> here, because I do not
want to force people to have tracking local branch. The call to
merge in pull that happens immediately after fetch does not use
localbranch, but uses what's recorded in FETCH_HEAD, and if we
were to do this change the above change would most likely to
affect how each remote branch heads fetched are marked for (or
not for) merges.
> All I wanted to remark is, that, with
>
> URL: <remote-URL>
> Pull: refs/head/master:refs/head/remote1
> Pull: refs/head/other:refs/head/remote2
>
> the config
>
> pull.origin = <remote> for refs/head/my-devel-for-remote2
>
> which does not use the [<refspec> of] part, always is bogus:
> We get remote1 merged into my-devel-for-remote2 on a git-pull,
> which is not what we want.
I think we are on the same page, if you just think of not having
[<refspec> of] a short-hand for naming the first Pull: line.
> Optionally, branching <new> off from <old> could add <new> as
> topic branch of <old>: Thus, if you are on <old> and do git-pull,
> you get <new> merged in.
I agree with Andreas on this part.
>> A bigger thing is that I am trying to avoid _requiring_ tracking
>> branches.
>
> I don't think you force anything when you add functionality to git-pull
> for the config discussed here. Nobody *has* to use this config - it's
> a porcelain thingie.
Not if you made the [<refspec> of] part <localbranch>. Then
this configuration for default merge source per local branch
feature is available only to people who are willing to use
tracking branches.
>> If you are not micromanaging your subsystem
>> maintainers, you should not have to care where they were the
>> last time you pulled from them....
>> [...why not needing to use tracking branches is good...]
>> If we are going require tracking branches,
>
> I do not understand. Why should we require this?
I forgot to say "on the other hand" before that "If".
>> we could do a bit
>> more with them, like remembering where the tip was when we
>> fetched the last time (or the time before that...) and diff with
>> that, but the tracking branch heads are not set up to do things
>> like that right now -- they are single pointers.
Actually I think this part is independent and I did not have to
mention. There is no point complicating only the tracking
branches at all.
I just wanted to mention that it would be handy to be able to
take snapshots of tracking branch heads, but it does not really
matter whether they are "your" local development branches or
tracking branches. Just a nightly or on-demand
d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
mkdir "$GIT_DIR/refs/snapshot/$d" &&
tar Ccf "$GIT_DIR/refs/" - heads |
tar Cxf "$d" -
would do, and then you should be able to ask "where was my
'master' head yesterday?".
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: Karl Hasselström @ 2006-04-03 8:29 UTC (permalink / raw)
To: David Ho; +Cc: Junio C Hamano, git
In-Reply-To: <4dd15d180603311421w7b48cfa4y80d3f9d565d4276f@mail.gmail.com>
On 2006-03-31 17:21:48 -0500, David Ho wrote:
[quoting junkio]
> > Remember, a branch in git is very cheap, and is a powerful way to
> > keep track of things while you decide which alternate universe to
> > take. And even after you decide, you could always look at and even
> > build on the other universe.
>
> I feel embarrassed to say this but in my branch there are commits to
> the driver and other commits for the board so it looks more like
>
> ---0---D1---B1---B2---D2---B3---B4---
>
> D* - driver changes
> B* - board changes
>
> So to go back to the 0 state I lose my board changes. But I hope
> what I did (in my reply to Linus) is very close to your idea of
> having separate branches.
You could use either stgit or the cherry-picking stuff in git to
create a new branch with these commits, but reordered any way you
like. (Or, given what you want to use it for, maybe two separate topic
branches -- one for board changes and one for driver changes -- that
can be merged to produce the end result.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Default remote branch for local branch
From: Josef Weidendorfer @ 2006-04-03 9:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <4430D517.5020205@op5.se>
On Monday 03 April 2006 09:56, Andreas Ericsson wrote:
> Josef Weidendorfer wrote:
> >
> > Optionally, branching <new> off from <old> could add <new> as
> > topic branch of <old>: Thus, if you are on <old> and do git-pull,
> > you get <new> merged in.
> >
>
> This is clearly insane. If I'm on <old> and want to sync with my
> upstream source that would be impossible without explicitly telling it
> *not* to merge with <new>. Iow, this change would (possibly) simplify
> for the one repo maintainer, but make things harder for the 30-odd
> developers.
Yes.
Therefore I put "optionally" above. But you are right, mixing up
"merge upstream" and "merge downstream" into one config option is insane.
Some idea independent but related:
I still think it is a better UI of a porcelain to try to note metainfo
automatically, ie. storing somewhere that we branched one off another.
What about adding "branch.topic" config option for this?
"git-branch -t newtopic"/"git-checkout -b newtopic -t"
would create a new topic branch, which is remembered in "branch.topic",
and "git-pull -t" merges these topic branches?
To specify that a remote branch is a topic branch of a given local
branch (to be pulled into with "git-pull -t"), we could add
"git-branch --add-topic <refspec>|<remoteURL>".
Josef
^ permalink raw reply
* Cygwin can't handle huge packfiles?
From: Kees-Jan Dijkzeul @ 2006-04-03 9:46 UTC (permalink / raw)
To: git
Hi,
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
implemented in cygwin, but if they allocate memory and load the file
into it, then this error is not surprising, as the pack file in
question is 1.5Gb in size.
I'm not sure how to approach this problem. Any tips would be greatly
appreciated.
Thanks a lot!
Kees-Jan
^ permalink raw reply
* Re: Default remote branch for local branch
From: Andreas Ericsson @ 2006-04-03 10:03 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200604031138.29227.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Monday 03 April 2006 09:56, Andreas Ericsson wrote:
>
>>Josef Weidendorfer wrote:
>>
>>>Optionally, branching <new> off from <old> could add <new> as
>>>topic branch of <old>: Thus, if you are on <old> and do git-pull,
>>>you get <new> merged in.
>>>
>>
>>This is clearly insane. If I'm on <old> and want to sync with my
>>upstream source that would be impossible without explicitly telling it
>>*not* to merge with <new>. Iow, this change would (possibly) simplify
>>for the one repo maintainer, but make things harder for the 30-odd
>>developers.
>
>
> Yes.
> Therefore I put "optionally" above. But you are right, mixing up
> "merge upstream" and "merge downstream" into one config option is insane.
>
> Some idea independent but related:
> I still think it is a better UI of a porcelain to try to note metainfo
> automatically, ie. storing somewhere that we branched one off another.
> What about adding "branch.topic" config option for this?
> "git-branch -t newtopic"/"git-checkout -b newtopic -t"
> would create a new topic branch, which is remembered in "branch.topic",
> and "git-pull -t" merges these topic branches?
> To specify that a remote branch is a topic branch of a given local
> branch (to be pulled into with "git-pull -t"), we could add
> "git-branch --add-topic <refspec>|<remoteURL>".
>
Sorry, but I still don't see the use of it. Usually, some topics mature
faster than others, meaning I'd still have to do the old "git pull .
this and that", leaving "the-other-one" to soak a bit longer. What
you're suggesting would make the odd case easier while adding nothing
for the normal flow.
For archeological purposes it might make some sense to record what the
branch was named that you forked from, but to me it's more interesting
to see which state the code was in when the code forked, and this is
discernable by the merge-base command.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Johannes Schindelin @ 2006-04-03 13:23 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200604030246q21fccb9ar93004ac67d8b28b3@mail.gmail.com>
Hi,
On Mon, 3 Apr 2006, Kees-Jan Dijkzeul 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
> implemented in cygwin, but if they allocate memory and load the file
> into it, then this error is not surprising, as the pack file in
> question is 1.5Gb in size.
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.
Hth,
Dscho
^ permalink raw reply
* Re: Default remote branch for local branch
From: Josef Weidendorfer @ 2006-04-03 13:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr74ff4oy.fsf@assigned-by-dhcp.cox.net>
On Monday 03 April 2006 10:23, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > On Sunday 02 April 2006 23:40, you wrote:
> >> > Let me try to understand this: the general idea is that
> >> >
> >> > pull.origin = [<refspec> of] <remote> for <branch>
> >> >
> >> > specifies the default action of git-pull if we are on <branch>, ie.
> >> > a "git pull" then runs "git pull <remote> [<refspec>]".
> >>
> >> Not quite.
> >>
> >> It will be (if this were a serious proposal -- I am not
> >> absolutely convinced this is a good idea) more like "git fetch
> >> <remote>" followed by "git-merge HEAD the-refspec-named-there".
> >
> > So it is not really a <refspec>, but a <localbranch> which has to
> > appear in the .git/remotes file on the right side of a refspec on
> > a Pull line.
>
> No, I meant <refspec> not <localbranch> here, because I do not
> want to force people to have tracking local branch.
Oh, ok. I just had to look up the manual regarding refspecs when
pulling/fetching again: "<ref>" is the same as "<ref>:" and does
not create/use any local branch.
> > All I wanted to remark is, that, with
> >
> > URL: <remote-URL>
> > Pull: refs/head/master:refs/head/remote1
> > Pull: refs/head/other:refs/head/remote2
> >
> > the config
> >
> > pull.origin = <remote> for refs/head/my-devel-for-remote2
> >
> > which does not use the [<refspec> of] part, always is bogus:
> > We get remote1 merged into my-devel-for-remote2 on a git-pull,
> > which is not what we want.
>
> I think we are on the same page, if you just think of not having
> [<refspec> of] a short-hand for naming the first Pull: line.
Yes, I understand this. But I do not think that such an optional
shortcut is useful for config files entries. It complicates parsing/editors,
and seems to make it more confusing. Despite, I agree that such optional
shortcuts are nice for porcelain command lines.
As I see the use of "<refspec> of <remote>", I still think that specifying
a local branch is useful, too. So what about
pull.origin = (<refspec> of <remote> | <localbranch>) for <branch>
instead? We can distinguish the two cases by looking for the "of".
When the <refspec> is of the form <src>:<dst> (where <dst> is the local
branch), we probably want to sanity check against .git/remotes/.
> > Optionally, branching <new> off from <old> could add <new> as
> > topic branch of <old>: Thus, if you are on <old> and do git-pull,
> > you get <new> merged in.
>
> I agree with Andreas on this part.
Yup. If we want to support topic branches with defaults, we should use
another config option. And now, I am not convinced about the usefulness
of this any more.
> Not if you made the [<refspec> of] part <localbranch>. Then
> this configuration for default merge source per local branch
> feature is available only to people who are willing to use
> tracking branches.
Yes, I understand this now.
> I just wanted to mention that it would be handy to be able to
> take snapshots of tracking branch heads, but it does not really
> matter whether they are "your" local development branches or
> tracking branches. Just a nightly or on-demand
>
> d="$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`" &&
> mkdir "$GIT_DIR/refs/snapshot/$d" &&
> tar Ccf "$GIT_DIR/refs/" - heads |
> tar Cxf "$d"
Wow. For this, versioning of the /refs directory as subproject
would be good ;-)
Josef
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 13:58 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <20060403072554.GN1259@lug-owl.de>
On Mon, Apr 03, 2006 at 09:25:54AM +0200, Jan-Benedict Glaw wrote:
> On Sun, 2006-04-02 21:10:56 -0700, Keith Packard <keithp@keithp.com> wrote:
> > I think this is a bug in your version of flex; I'm using standard lex
> > conventions here. I don't know how to make it work for you.
>
> It compiles for me with this patch (thanks to Linus for the hint):
>
> diff --git a/Makefile b/Makefile
[...]
> Would you please verify that it doesn't break things for you?
Almost there. I applied your patch and ran "make clean", but the
Makefile forgets to remove lex.c. Here's an updated patch:
diff --git a/Makefile b/Makefile
index 639353a..5651e70 100644
--- a/Makefile
+++ b/Makefile
@@ -3,7 +3,8 @@ GCC_WARNINGS2=-Wmissing-prototypes -Wmis
GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)
CFLAGS=-O0 -g $(GCC_WARNINGS)
-YFLAGS=-d
+YFLAGS=-d -l
+LFLAGS=-l
SRCS=gram.y lex.l cvs.h parsecvs.c cvsutil.c revlist.c atom.c revcvs.c git.c
@@ -20,4 +21,4 @@ lex.o: lex.c
y.tab.h: gram.c
clean:
- rm -f $(OBJS) y.tab.h gram.c parsecvs
+ rm -f $(OBJS) y.tab.h gram.c lex.c parsecvs
It compiles! Ship it! ;-)
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply related
* Re: parsecvs tool now creates git repositories
From: Erik Mouw @ 2006-04-03 14:03 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1143956188.2303.39.camel@neko.keithp.com>
On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
> The UI is a total disaster, sufficient for testing. You must create an
> Authors file in the current directory which looks like the git-cvsimport
> authors file. You must also have a edit-change-log program in your path
> which edits the commit message in place. /bin/true will work if you
> don't need to edit the messages.
>
> I should clearly steal the existing git-cvsimport command line arguments
> and use those.
What is the current way to use it? I get the impression it reads raw ,v
files, but how do I get along with a remote CVS repository?
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Jakub Narebski @ 2006-04-03 14:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
>> The UI is a total disaster, sufficient for testing. You must create an
>> Authors file in the current directory which looks like the git-cvsimport
>> authors file. You must also have a edit-change-log program in your path
>> which edits the commit message in place. /bin/true will work if you
>> don't need to edit the messages.
>>
>> I should clearly steal the existing git-cvsimport command line arguments
>> and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
>From the comments on #git, parsecvs reads raw ,v files for creating history
tree, then uses 'cvs co ...' for getting the contents.
If you have access to remote CVS repository, it was suggested to use either
cvsclone or cvsup.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Morten Welinder @ 2006-04-03 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
> 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.
Maybe, but you aren't going to be able to handler much bigger packs
even on *nix. Unless you go 64-bit, that is.
M.
^ permalink raw reply
* Re: n-heads and patch dependency chains
From: Linus Torvalds @ 2006-04-03 14:29 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <4430D352.4010707@vilain.net>
On Mon, 3 Apr 2006, Sam Vilain wrote:
>
> "Patch dependency chains", the best plain-English term we could find for
> the scary sounding darcs term "patch calculus", are said by some to be a
> very good reason to use a system like darcs, even to some its
> fundamental advantage over systems such as git.
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. And I very
much don't want to see theory over practice.
Linus
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Linus Torvalds @ 2006-04-03 14:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.63.0604031521170.4011@wbgn013.biozentrum.uni-wuerzburg.de>
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).
Using malloc+read on pack-files is pretty wasteful, since we usually only
use a very small part of them (ie if we have a 1.5GB pack-file, it's sad
to read all of it, when we'd usually actually access just a small small
fraction of it).
That said, I think git _does_ have problems with large pack-files. We have
some 32-bit issues etc, and just virtual address space things. So for now,
it's probably best to limit pack-files to the few-hundred-meg size, and
create serveral smaller ones rather than one huge one.
Linus
^ permalink raw reply
* Re: Cygwin can't handle huge packfiles?
From: Linus Torvalds @ 2006-04-03 14:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kees-Jan Dijkzeul, git
In-Reply-To: <Pine.LNX.4.64.0604030730040.3781@g5.osdl.org>
On Mon, 3 Apr 2006, Linus Torvalds wrote:
>
> That said, I think git _does_ have problems with large pack-files. We have
> some 32-bit issues etc
I should clarify that. git _itself_ shouldn't have any 32-bit issues, but
the packfile data structure does. The index has 32-bit offsets into
individual pack-files.
That's not hugely fundamental, but I didn't expect people to hit it this
quickly. What kind of project has a 1.5GB pack-file _already_? I hope it's
fifteen years of history (so that we'll have another fifteen years before
we'll have to worry about 4GB pack-files ;)
Linus
^ permalink raw reply
* Re: parsecvs tool now creates git repositories
From: Keith Packard @ 2006-04-03 14:37 UTC (permalink / raw)
To: Erik Mouw; +Cc: keithp, Git Mailing List
In-Reply-To: <20060403140348.GE16823@harddisk-recovery.com>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On Mon, 2006-04-03 at 16:03 +0200, Erik Mouw wrote:
> On Sat, Apr 01, 2006 at 09:36:28PM -0800, Keith Packard wrote:
> > The UI is a total disaster, sufficient for testing. You must create an
> > Authors file in the current directory which looks like the git-cvsimport
> > authors file. You must also have a edit-change-log program in your path
> > which edits the commit message in place. /bin/true will work if you
> > don't need to edit the messages.
> >
> > I should clearly steal the existing git-cvsimport command line arguments
> > and use those.
>
> What is the current way to use it? I get the impression it reads raw ,v
> files, but how do I get along with a remote CVS repository?
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.
It turns out that parsing the ,v files directly is both faster and more
accurate than attempting to interpret the output of cvs log.
--
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
* 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: 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: 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: 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
* 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: 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
* [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: 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
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