* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7v1x5ic1pe.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
>
> I did not know about that plan, but that is interesting and now
> I understand why you think it is important to be able for more
> than one person to push into a single repository.
Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.
Ciao,
Dscho
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 18:39 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: Josef Weidendorfer, git
In-Reply-To: <7v1x5ic1pe.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
>
> I did not know about that plan, but that is interesting and now
> I understand why you think it is important to be able for more
> than one person to push into a single repository.
For that particular thing, this is only part of the motivation. The much
bigger part of the motivation are projects which don't have a central
maintainer but where group of people needs to be equal in access to a
central repository. That's actually vast majority of larger projects, I
think.
> How will the namespace of N-hundred branches in that repository
> be managed? To avoid collisions, wouldn't there be some
> coordination, and there will be branch names there that
> everybody agrees that they are owned by you?
You could name your branches e.g. "davej/agpgart", "davej/cpufreq", etc.
But those proposals of central repository were certainly quite
preliminary, and perhaps I overstated saying "the plan is".
> At that point, wouldn't it be easier for _you_ (as one kernel
> developer who owns such globally unique branch names) to name
> your branch you intend to push there the same way in your
> working repository as well?
And if you are cloning locally or whatever, you have to mention the
branch name explicitly.
One of the Cogito design bits is that branch name is something local to
the repository. When you are adding a branch, the local name you assign
it is your private thing repository-wise, and doesn't have to have any
correlation to other repositories you might interact width.
As I already argued, this helps when you are importing someone else's
master as your branch called whatever (obviously not master), and if you
have to deal with two remote branches with the same name (such a
conflict is bound to happen and bound to be vulnerable to be a huge
hassle). That also applies to pushing, you might be pushing to multiple
repositories - say you are working on some cool kernel stuff for SuSE,
so you might want to push to kernel.org _and_ into the deep bowels of
some SuSE kernel infrastructure (whatever - I'm not familiar with those
things yet if you are now drooling to get some insight about how this is
working in SuSE].
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Ryan Anderson @ 2005-07-28 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <Pine.LNX.4.58.0507281931180.30371@wgmdd8.biozentrum.uni-wuerzburg.de>
On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:
> Is it possible that those plans only mean to centralize .git/objects/ and
> leave the rest in single repositories? Seems much more sensible to me.
I think that's accurate. It can be done without the repositories even
really noticing if "git relink" is used aggressively to migrate
hard links into the repository regularly. (Though, "packs" cause some
confusion in that scheme, I think.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 18:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Josef Weidendorfer, git
In-Reply-To: <20050728183904.GA24948@pasky.ji.cz>
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
> For that particular thing, this is only part of the motivation. The much
> bigger part of the motivation are projects which don't have a central
> maintainer but where group of people needs to be equal in access to a
> central repository. That's actually vast majority of larger projects, I
> think.
Are you really sure you want to slave git into being a "better
Subversion"? IMHO, if you need a central repository, you should also have
one central HEAD.
Just my tucence,
Dscho
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 18:51 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <20050728184525.GA3144@mythryan2.michonline.com>
Hi,
On Thu, 28 Jul 2005, Ryan Anderson wrote:
> On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:
> > Is it possible that those plans only mean to centralize .git/objects/ and
> > leave the rest in single repositories? Seems much more sensible to me.
>
> I think that's accurate. It can be done without the repositories even
> really noticing if "git relink" is used aggressively to migrate
> hard links into the repository regularly. (Though, "packs" cause some
> confusion in that scheme, I think.)
I guess that's where git-daemon comes into play.
Ciao,
Dscho
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Josef Weidendorfer @ 2005-07-28 18:53 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0507281747320.29968@wgmdd8.biozentrum.uni-wuerzburg.de>
On Thursday 28 July 2005 17:56, Johannes Schindelin wrote:
> localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
> anyway :-)
GIT/Cogito usage is not about linux kernel only.
I actually try to work with a scenario for a project with a few developers,
where each one should have its branch(es) in the central repository. I think
this could be quite common among future GIT uses. I even would allow the few
developers to merge into the central master.
> I just do not see a high demand for mappings of remote and local HEAD
> names, but rather a high potential of making mistakes (after all, it is
> not the machine which makes mistakes, it's the human operator).
I also think it is quite confusing to have different branch names for the same
head in cloned repositories.
But I also think that Paskys scenario is real, where you want to pull branches
in 2 remote repositories with the same name.
So why not put the name of the remote repository into the local branch name?
A remote branch "host1:path#branch1" could be named "host1:path#branch1".
The shorthand specified with "cg-add-branch" would be a local alias, i.e.
(cd .git/refs/heads; ln -s host1:path#branch1 mylocalalias)
I even would find it handy to be able to say
cg-pull host1:path#branch1
, and
cg-push mylocalbranch host2:path#branch2
should create the alias "mylocalbranch"="host2:path#branch2"
and create a entry in .git/branches.
Josef
^ permalink raw reply
* Unnamed branches
From: Petr Baudis @ 2005-07-28 19:19 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200507282053.56786.Josef.Weidendorfer@gmx.de>
Dear diary, on Thu, Jul 28, 2005 at 08:53:56PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> So why not put the name of the remote repository into the local branch name?
> A remote branch "host1:path#branch1" could be named "host1:path#branch1".
> The shorthand specified with "cg-add-branch" would be a local alias, i.e.
> (cd .git/refs/heads; ln -s host1:path#branch1 mylocalalias)
>
> I even would find it handy to be able to say
> cg-pull host1:path#branch1
> , and
> cg-push mylocalbranch host2:path#branch2
> should create the alias "mylocalbranch"="host2:path#branch2"
> and create a entry in .git/branches.
This is a sensible argument, and I initially disallowed this mainly to
save some work. ;-) But I agree that something like this would be nice.
The issues:
* How to name the unnamed branches? You need some way to normalize
URLs like http://www.kernel.org/pub/s%63m//cogito/ to something which is
unique for a given location (http://www.kernel.org/pub/scm/cogito) and
usable as filename - at least substituting the slashes for something,
like underscores, and encoding underscored by % sequences.
* Have all named remote branches as symlinks to their URLs (thus
effectively also eliminating the need for .git/branches/), or keep them
as they are? One disadvantage of the symlinks is that the refs/
directory would become quite messy.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Matthias Urlichs @ 2005-07-28 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <42E9020F.3080302@gmail.com>
Hi, A Large Angry SCM wrote:
> So you're arguing for "last match wins" versus "first match wins". I,
> personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
However ... as a human being, I liik for meaning, not for processing
instructions. Thus, reading the list top-down, this
> *.html
> !f*.html
> fo*.html
makes perfect sense to me. ("Throw away the HTML files. Well, except for
those that start with 'f'. Well, *except* for foobar.html or whatever.")
The other way round, however, the sequence
> fo*.html
> !f*.html
> *.html
is not immediately understandable in one pass, as the second line makes no
sense whatsoever without the third one. ("Throw away foobar.html. Umm,
we're keeping everything anyway, so why ... oh, HTML files are junked, OK,
so ... now ... umm, what did I want to find out in the first place?")
It gets even more confusing when you're lazy and omit the .html suffix in
the second line.
YMMV, and all that.
--
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
- -
(It is an old Debian tradition to leave at least twice a year ...)
-- Sven Rudolph
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 16:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507281747320.29968@wgmdd8.biozentrum.uni-wuerzburg.de>
Dear diary, on Thu, Jul 28, 2005 at 05:56:21PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,
Hello,
> On Thu, 28 Jul 2005, Petr Baudis wrote:
>
> > Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> >
> > > On Thu, 28 Jul 2005, Petr Baudis wrote:
> > >
> > > > See above. I would much rather see more flexible git-send-pack. Junio,
> > > > what about changing its [heads]* parameter e.g. to
> > > > [remotehead[:localhead]]* ?
> > >
> > > IMHO this opens the door for shooting in your own foot. Isn't it much too
> > > easy to make a mistake with that syntax?
> >
> > What mistake?
>
> To mix up different branches. With that syntax you can easily push changes
> onto the wrong head.
How? Only when you explicitly specify the remote head. When you're
explicit, you ought to know what are you doing.
> I might well be wrong here, but I think the most common usage for git-push
> is to update a public repository, which is done by one or just a few
> maintainer(s), in which case it is no problem to enforce
> localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
> anyway :-)
AFAIK the plan is to centralize all the kernel repositories to a single
one. For that, developers would generally push into branches with name
different that "master".
> I just do not see a high demand for mappings of remote and local HEAD
> names, but rather a high potential of making mistakes (after all, it is
> not the machine which makes mistakes, it's the human operator).
If you fear making mistakes, better use something which attempts to do
some babysitting for you, like Cogito. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-28 19:47 UTC (permalink / raw)
To: Catalin Marinas
Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <1122114452.6863.72.camel@localhost.localdomain>
Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > Agreed. What Cogito uses:
> >
> > .git/author Default author information in format
> > Person Name <email@addy>
>
> What about .git/committer? This is useful if I do a commit at work and I
> want the repository to have my gmail address.
The committer field generally identifies the committer "physically", and
isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my
committer field, e.g.
> > .git/branch-name
> > Symbolic name of the branch of this repository.
>
> Isn't this the same as $(readlink .git/HEAD), with some trimming?
No, that is something totally separate from the usual concepts of
branches and repositories, designed to make it possible to distinguish
between repositories etc. from the outside of the system.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Matthias Urlichs @ 2005-07-28 19:47 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0507282047360.30638@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi, Johannes Schindelin wrote:
> Are you really sure you want to slave git into being a "better
> Subversion"?
Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)
> IMHO, if you need a central repository, you should also have
> one central HEAD.
I disagree. Larger projects have multiple HEADs (stable, oldstable,
development, ...). I don't like putting those in different repositories,
you end up with a heap of housekeeping effort to hardlink duplicate
objects, all of which is going to be wasted when different people run
"git repack".
Not everybody has 100-GB disks and multi-MB Internet pipes to play with...
--
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
- -
On ability:
A dwarf is small, even if he stands on a mountain top;
a colossus keeps his height, even if he stands in a well.
-- Lucius Annaeus Seneca, 4BC - 65AD
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 20:14 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.28.19.47.38.753705@smurf.noris.de>
Hi,
On Thu, 28 Jul 2005, Matthias Urlichs wrote:
> Hi, Johannes Schindelin wrote:
>
> Since git is better than all of these, we should be able to easily write a
> SVN-like porcelain, so ... ;-)
Sorry, you're correct.
> > IMHO, if you need a central repository, you should also have
> > one central HEAD.
>
> I disagree. Larger projects have multiple HEADs (stable, oldstable,
> development, ...). I don't like putting those in different repositories,
> you end up with a heap of housekeeping effort to hardlink duplicate
> objects, all of which is going to be wasted when different people run
> "git repack".
Sorry again. I should have been clearer: If you have a larger project
which does have production releases which have to be patched for a while,
and thus need several branches, then there is still a *very good* reason
not to play games with the names of those branches or the tags.
Naming the remote HEAD differently than the local HEAD is just *wrong*
when you want to push back to them. I agree that it is a fine intellectual
challenge to keep juggling a few remote HEADs, and throw in a few local
HEADs, but all that is *complicated*. And complicated things lead to
complications.
BTW I am a Jeff, I use git branches extensively in two projects.
The only sane way if you have to have different local and remote HEADs
that I can think of, would be to allow only the current local active HEAD
to be pushed to a certain remote HEAD (preferably identified by a file in
.git/branches).
Ciao,
Dscho
^ permalink raw reply
* Tutorial problem a/a a/b
From: Darrin Thompson @ 2005-07-28 20:20 UTC (permalink / raw)
To: git
In the tutorial the user is instructed to create two files: a and b.
Then when the user diffs the files, they see this:
diff --git a/a b/a
That really confused somebody and I had to untangle their brain. :-) I
don't have a patch for it, but thought I'd point out: perhaps a and b
aren't the best example filenames given git's diff format. :-D
--
Darrin
^ permalink raw reply
* Dump http servers still slow?
From: Darrin Thompson @ 2005-07-28 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio,
I just ran git clone against the mainline git repository using both http
and rsync. http was still quite slow compared to rsync. I expected that
the http time would be much faster than in the past due to the pack
file.
Is there something simple I'm missing?
--
Darrin
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Matthias Urlichs @ 2005-07-28 21:13 UTC (permalink / raw)
To: git
In-Reply-To: <20050728161815.GC17952@pasky.ji.cz>
Hi, Petr Baudis wrote:
> If you fear making mistakes, better use something which attempts to do
> some babysitting for you, like Cogito. ;-)
Some babysitting needs to be part of the core push protocol; anything else
would be prone to race conditions in a multiuser setting, esp. when people
use different porcelains.
At minimum, you'd send the old branch head with the new one, and let the
server not overwrite it if it changed in the meantime.
Then, you'd kill porcelain writers who don't verify that the old head is
a(n indirect) parent of the new one. ;-)
--
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
- -
Madness takes its toll. Please have exact change.
^ permalink raw reply
* Re: Tutorial problem a/a a/b
From: Darrin Thompson @ 2005-07-28 21:15 UTC (permalink / raw)
To: git
In-Reply-To: <1122582005.12374.6.camel@localhost.localdomain>
On Thu, 2005-07-28 at 15:20 -0500, Darrin Thompson wrote:
> In the tutorial the user is instructed to create two files: a and b.
>
> Then when the user diffs the files, they see this:
>
> diff --git a/a b/a
>
> That really confused somebody and I had to untangle their brain. :-) I
> don't have a patch for it, but thought I'd point out: perhaps a and b
> aren't the best example filenames given git's diff format. :-D
>
Note: I've been fielding a few questions while some Progeny folks get up
to speed on git.
I had to explain what was meant by <tree-ish> in some usage messages.
Perhaps those should be spelled out as "tree, tag, or commit id"?
[Sorry this is a whine and not a patch.]
--
Darrin
^ permalink raw reply
* [PATCH] mmap error handling
From: Pavel Roskin @ 2005-07-28 21:40 UTC (permalink / raw)
To: git
Hello!
I have reviewed all occurrences of mmap() in git and fixed three types
of errors/defects:
1) The result is not checked.
2) The file descriptor is closed if mmap() succeeds, but not when it
fails.
3) Various casts applied to -1 are used instead of MAP_FAILED, which is
specifically defined to check mmap() return value.
I have verified that successful close() after failed mmap() won't reset
the output of perror() to "Success".
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -377,8 +377,10 @@ int diff_populate_filespec(struct diff_f
if (fd < 0)
goto err_empty;
s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
- s->should_munmap = 1;
close(fd);
+ if (s->data == MAP_FAILED)
+ goto err_empty;
+ s->should_munmap = 1;
}
else {
char type[20];
diff --git a/diffcore-order.c b/diffcore-order.c
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -28,7 +28,7 @@ static void prepare_order(const char *or
}
map = mmap(NULL, st.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return;
endp = map + st.st_size;
for (pass = 0; pass < 2; pass++) {
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -54,7 +54,7 @@ int fetch(unsigned char *sha1)
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, ifd, 0);
close(ifd);
- if (-1 == (int)(long)map) {
+ if (map == MAP_FAILED) {
fprintf(stderr, "cannot mmap %s\n", filename);
return -1;
}
diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -392,7 +392,7 @@ int read_cache(void)
return (errno == ENOENT) ? 0 : error("open failed");
size = 0; // avoid gcc warning
- map = (void *)-1;
+ map = MAP_FAILED;
if (!fstat(fd, &st)) {
size = st.st_size;
errno = EINVAL;
@@ -400,7 +400,7 @@ int read_cache(void)
map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
}
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return error("mmap failed");
hdr = map;
diff --git a/rev-cache.c b/rev-cache.c
--- a/rev-cache.c
+++ b/rev-cache.c
@@ -212,11 +212,9 @@ int read_rev_cache(const char *path, FIL
return -1;
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
- if (map == MAP_FAILED) {
- close(fd);
- return -1;
- }
close(fd);
+ if (map == MAP_FAILED)
+ return -1;
memset(last_sha1, 0, 20);
ofs = 0;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -518,7 +518,7 @@ static void *map_sha1_file_internal(cons
}
map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- if (-1 == (int)(long)map)
+ if (map == MAP_FAILED)
return NULL;
*size = st.st_size;
return map;
@@ -1363,7 +1363,7 @@ int index_fd(unsigned char *sha1, int fd
if (size)
buf = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
- if ((int)(long)buf == -1)
+ if (buf == MAP_FAILED)
return -1;
if (!type)
diff --git a/test-delta.c b/test-delta.c
--- a/test-delta.c
+++ b/test-delta.c
@@ -39,11 +39,11 @@ int main(int argc, char *argv[])
}
from_size = st.st_size;
from_buf = mmap(NULL, from_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ close(fd);
if (from_buf == MAP_FAILED) {
perror(argv[2]);
return 1;
}
- close(fd);
fd = open(argv[3], O_RDONLY);
if (fd < 0 || fstat(fd, &st)) {
@@ -52,11 +52,11 @@ int main(int argc, char *argv[])
}
data_size = st.st_size;
data_buf = mmap(NULL, data_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ close(fd);
if (data_buf == MAP_FAILED) {
perror(argv[3]);
return 1;
}
- close(fd);
if (argv[1][1] == 'd')
out_buf = diff_delta(from_buf, from_size,
diff --git a/tools/mailsplit.c b/tools/mailsplit.c
--- a/tools/mailsplit.c
+++ b/tools/mailsplit.c
@@ -116,11 +116,11 @@ int main(int argc, char **argv)
}
size = st.st_size;
map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
- if (-1 == (int)(long)map) {
+ close(fd);
+ if (map == MAP_FAILED) {
perror("mmap");
exit(1);
}
- close(fd);
nr = 0;
do {
char name[10];
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mmap error handling
From: Morten Welinder @ 2005-07-28 23:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1122586842.17837.9.camel@dv>
> I have verified that successful close() after failed mmap() won't reset
> the output of perror() to "Success".
Does $standard guarantee that?
In general, successful libc calls can set errno to whatever they
please, except zero. And they sometimes do. This follows from
C99.
Morten
^ permalink raw reply
* Re: [PATCH] mmap error handling
From: Linus Torvalds @ 2005-07-29 0:30 UTC (permalink / raw)
To: Morten Welinder; +Cc: Pavel Roskin, git
In-Reply-To: <118833cc05072816294f80a829@mail.gmail.com>
On Thu, 28 Jul 2005, Morten Welinder wrote:
>
> > I have verified that successful close() after failed mmap() won't reset
> > the output of perror() to "Success".
>
> Does $standard guarantee that?
>
> In general, successful libc calls can set errno to whatever they
> please, except zero. And they sometimes do. This follows from
> C99.
Indeed.
_always_ save the value of errno before doing any other calls. Even
successful calls are perfectly allowed to change errno.
"close()" may not _normally_ change errno, but the fact is, not only can
close sometimes return an error, but it could validly have some debugging
wrapper that does logging, and change errno because of that.
Yeah, we'd be better off if UNIX had always used the linux kernel practice
of hiding errno as a negative return value (and the "IS_ERR()" test for
pointers), but hey, crud happens to the best of us.
Linus
^ permalink raw reply
* [PATCH] server-info: do not complain if a tag points at a non-commit.
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0507280040380.3227@g5.osdl.org>
Linux 2.6 tree has one of those tree tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
server-info.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
42fa3ca33f92381a73c08ab98dc4b54e6a6412cc
diff --git a/server-info.c b/server-info.c
--- a/server-info.c
+++ b/server-info.c
@@ -2,6 +2,7 @@
#include "refs.h"
#include "object.h"
#include "commit.h"
+#include "tag.h"
#include "rev-cache.h"
/* refs */
@@ -518,10 +519,16 @@ static int update_info_packs(int force)
/* rev-cache */
static int record_rev_cache_ref(const char *path, const unsigned char *sha1)
{
- struct commit *commit;
- if (!(commit = lookup_commit_reference(sha1)))
- return error("not a commit: %s", sha1_to_hex(sha1));
- return record_rev_cache(commit->object.sha1, NULL);
+ struct object *obj = parse_object(sha1);
+
+ if (!obj)
+ return error("ref %s has bad sha %s", path, sha1_to_hex(sha1));
+ while (obj && obj->type == tag_type)
+ obj = parse_object(((struct tag *)obj)->tagged->sha1);
+ if (!obj || obj->type != commit_type)
+ /* tag pointing at a non-commit */
+ return 0;
+ return record_rev_cache(obj->sha1, NULL);
}
static int update_info_revs(int force)
^ permalink raw reply
* Re: [PATCH] support older versions of libcurl
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507281648390.25783@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Some newer features of libcurl are used which are not strictly necessary
> for http-pull. Use them only if libcurl is new enough to know about them.
Do you need to check against that many versions? Especially
cleanup and init not depending on the same version number looks
really suspicious.
Assuming that the answer is still yes, how about doing things
this way instead?
---
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -6,6 +6,16 @@
#include <curl/curl.h>
#include <curl/easy.h>
+#if LIBCURL_VERSION_NUM < 0x070704
+#define curl_global_cleanup() do { /* nothing */ } while(0)
+#endif
+#if LIBCURL_VERSION_NUM < 0x070800
+#define curl_global_init(a) do { /* nothing */ } while(0)
+#endif
+#if LIBCURL_VERSION_NUM < 0x070907
+#define curl_easy_setopt(a, b, c) do { /* nothing */ } while(0)
+#endif
+
static CURL *curl;
static char *base;
^ permalink raw reply
* Re: [RFD] socklen_t needs to be defined and libssl to be linked on old Mac OS X
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507281649230.25783@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On older Mac OS X (10.2.8), no socklen_t is defined, and therefore
> daemon.c does not compile. However, Mac OS X 10.4 seems to define
> socklen_t differently.
>
> Also, linking fails due to some symbols defined in libssl (not just
> libcrypto).
Hmph. While I would want things to be portable, I prefer to
avoid platform specific #ifdef and conditional Makefile
constructs.
> SHA1_HEADER=<openssl/sha.h>
> +ifeq ($(shell uname -s),Darwin)
> + LIBS += -lcrypto -lssl
> +else
> LIBS += -lcrypto
> +endif
> endif
> #include <arpa/inet.h>
> +#ifdef __APPLE__
> +typedef int socklen_t;
> +#endif
I'll keep this in the proposed updates queue until somebody
comes up with a bit cleaner solution.
By the way, Johannes, what mailer do you use? Many of your
patches seem to be whitespace damaged. For example:
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -5,6 +5,9 @@
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <arpa/inet.h>
> +#ifdef __APPLE__
> +typedef int socklen_t;
> +#endif
>
> static const char daemon_usage[] = "git-daemon [--inetd | --port=n]";
The empty line before daemon_usage[] line should start with a
single SP but your message does not seem to have it. I double
checked with the copy marc has:
http://marc.theaimsgroup.com/?l=git&m=112256286508546&q=raw
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Petr Baudis
Cc: Catalin Marinas, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050728194748.GD24948@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> The committer field generally identifies the committer "physically", and
> isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my
> committer field, e.g.
I do not want to get involved in policy decisions, but for the
record I always hated your commit log for that "identifies the
committer physically" approach.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Josef Weidendorfer, git
In-Reply-To: <20050728183904.GA24948@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> One of the Cogito design bits is that branch name is something local to
> the repository. When you are adding a branch, the local name you assign
> it is your private thing repository-wise, and doesn't have to have any
> correlation to other repositories you might interact width.
I do not disagree with that. I think branch name is mostly a
local matter. However, I happen to think that two repositories
you use send-pack (not clone which uses completely different
protocol) to sync one from the other are semantically equivalent
ones, except that the destination may be a strict subset. I
think of it as "a copy I throw at a public place to show what I
have in my private repository I work in", so,...
^ permalink raw reply
* Re: Dump http servers still slow?
From: Junio C Hamano @ 2005-07-29 2:24 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1122584423.12374.11.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> I just ran git clone against the mainline git repository using both http
> and rsync. http was still quite slow compared to rsync. I expected that
> the http time would be much faster than in the past due to the pack
> file.
>
> Is there something simple I'm missing?
No, the only thing you missed was that I did not write it to
make it fast, but just to make it work ;-). The commit walker
simply does not work against a dumb http server repository that
is packed and prune-packed, which is already the case for both
kernel and git repositories.
The thing is, the base pack for the git repository is 1.8MB
currently containing 4500+ objects, while we accumulated 600+
unpacked objects since then which is about ~5MB. The commit
walker needs to fetched the latter one by one in the old way.
When packed incrementally on top of the base pack, these 600+
unpacked objects compress down to something like 400KB, and I
was hoping we could wait until we accumulate enough to produce
an incremental about a meg or so ...
^ 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