* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-14 23:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, James Pickens, Bruce Fields, Git Mailing List
In-Reply-To: <7v63mq9iao.fsf@gitster.siamese.dyndns.org>
On Fri, 14 Nov 2008, Junio C Hamano wrote:
>
> If you have 1000 files in a single directory, do you still want 2 threads
> following the "1/500" rule, or they would compete reading the same
> directory and using a single thread is better off?
Well, first off, the "single directory" thing is really a Linux kernel
deficiency, and it's entirely possible that it doesn't even exist on other
systems. Linux has a very special directory cache (dcache) model that is
pretty unique - it's part of why cached 'lstat()' calls are so cheap on
Linux - but it is also part of the reason for why we serialize lookups
when we do miss in the cache (*).
Secondly, anybody who has a thousand tracked files in a single directory
can damn well blame themselves for being stupid. So I don't think it's a
case that is worth worrying too much about. Git will slow down for that
kind of situation for other reasons (ie a lot of the tree pruning
optimization won't work for projects that have large flat directories).
So i wouldn't worry about it. That said, with the second patch, we default
to having people enable this explicitly, so it's something that people can
decide on their own.
Linus
(*) That said - the Linux dcache consistency is just _one_ reason why we
serialize lookups. I would not be in the least surprised if other OS's
have the exact same issue. I'd love to fix it in Linux, but quiet
honestly, it has never actually come up before now, and we've literally
worked on multi-threading the _cached_ case, not the uncached one.
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-14 22:57 UTC (permalink / raw)
To: sverre; +Cc: Martin Koegler, Git Mailing List
In-Reply-To: <bd6139dc0811141346w194ae4c5m9f7b0fdb106108fc@mail.gmail.com>
Sverre Rabbelier wrote:
> On Fri, Nov 14, 2008 at 22:33, Martin Koegler
> <mkoegler@auto.tuwien.ac.at> wrote:
>> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>>> I've put everyone who "owns" more than 500 lines of code
>>> on the bcc list, figuring your permission is important
>>> but that you don't want the hundreds (well, one can hope)
>>> of emails from people saying "ok". The list of major owners
>>> was generated with "git showners *.c" in a worktree from
>>> the next branch of git.git.
>> I don't think, that your way for relicensing is bullet proof:
>>
>> I consider many of my GIT patches as derived work from other parts of
>> GIT, even if git blame is stating me as author. I can gurantee you,
>> that I comply with the "Developer's Certificate of Origin 1.1" point
>> b, as its based on code out of git.git. But I can't tell you, from
>> which files I reused code anymore.
>>
>> Probably other people did the same.
>>
>> Your method is ignoring such derived code.
>
> Perhaps git stats can be of assistance here, it can summarize how much
> lines a person changed (per file, or in total), that should be a
> better metric (at least for code reused from within git.git, ofcourse
> GPL-ed code taken from somewhere else is not covered).
>
That will almost certainly not be a problem. I'm working on reading stuff
into git-specific structures and then updating those structures. I doubt
any such code exists outside git. If it does, it's more likely derived
from git than the other way around.
It's also worth noting that I'm aiming for the really low-level core
stuff at first. It would be beneficial to get such simple things going
as updating the index (with an entire file) and then creating a commit
from that index. Such a thing would definitely be enough for (very basic)
IDE integration, and then we can build further on that but utilizing
developers from other projects than the git developer community.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-14 22:56 UTC (permalink / raw)
To: Martin Koegler; +Cc: Git Mailing List
In-Reply-To: <20081114213352.GA12134@auto.tuwien.ac.at>
Martin Koegler wrote:
> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>> I've put everyone who "owns" more than 500 lines of code
>> on the bcc list, figuring your permission is important
>> but that you don't want the hundreds (well, one can hope)
>> of emails from people saying "ok". The list of major owners
>> was generated with "git showners *.c" in a worktree from
>> the next branch of git.git.
>
> I don't think, that your way for relicensing is bullet proof:
>
I know that it's not, which is why I'm doing research to take care
of the pieces interesting for libgit2 that could possibly have
been derived from elsewhere. Reading and filling structures specific
to git is something I'd be surprised if they originated outside of
git though.
> I consider many of my GIT patches as derived work from other parts of
> GIT, even if git blame is stating me as author. I can gurantee you,
> that I comply with the "Developer's Certificate of Origin 1.1" point
> b, as its based on code out of git.git.
Right, but if we can never re-use code from git.git, libgit will never
fly. It's unfortunately as simple as that. So perhaps we're left with
the option of writing a GPL'd library or just go hang.
> But I can't tell you, from which files I reused code anymore.
>
To a certain point, "git blame" can.
> Probably other people did the same.
>
> Your method is ignoring such derived code.
>
Right. If possible, I'd still like an OK from you though. If nothing
else, it'll make it possible to re-use code that originated from
someone else and that you changed, assuming that "someone else" also
agree to relicensing their code. With 100% of the authors agreeing
to that, we could have a libified git flying in a matter of months
instead of never.
It's unfortunate if the letter of the law pertaining to a particular
license should prevent the copyright owners from doing whatever
they want with the code, but perhaps that's the world we live in.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: reflog delete results in reflog show strangeness?
From: Bob Hiestand @ 2008-11-14 22:44 UTC (permalink / raw)
To: git
In-Reply-To: <cc29171c0811141433t43d27c5gb57ca11d2ddb67cb@mail.gmail.com>
On Fri, Nov 14, 2008 at 4:33 PM, Bob Hiestand <bob.hiestand@gmail.com> wrote:
> I see a possible bug in the output of 'git reflog show' after using
> 'git reflog delete'. Simple example:
>
> $ git init
> $ git commit --allow-empty -m 'root'
> $ git commit --allow-empty -m 'good'
> $ git commit --allow-empty -m 'bad'
> $ git reflog
> 996ca67... HEAD@{0}: commit: bad
> e431a20... HEAD@{1}: commit: good
> 992dd88... HEAD@{2}: commit (initial): root
>
> $ git reset HEAD^
> $ git reflog
> e431a20... HEAD@{0}: HEAD^: updating HEAD
> 996ca67... HEAD@{1}: commit: bad
> e431a20... HEAD@{2}: commit: good
> 992dd88... HEAD@{3}: commit (initial): root
>
> $ git reflog delete HEAD@{1}
> $ git reflog
> e431a20... HEAD@{0}: HEAD^: updating HEAD
> 996ca67... HEAD@{1}: commit: good
> 992dd88... HEAD@{2}: commit (initial): root
>
> In this listing, please note that, after the delete, the commit SHA
> shown as HEAD@{1} is that of the deleted reference (the bad commit)
> and does not match the reflog message, which has the expected value.
Sorry, forgot to add this:
$ git describe
v1.6.0.4-969-g58a38d0
^ permalink raw reply
* reflog delete results in reflog show strangeness?
From: Bob Hiestand @ 2008-11-14 22:33 UTC (permalink / raw)
To: git
I see a possible bug in the output of 'git reflog show' after using
'git reflog delete'. Simple example:
$ git init
$ git commit --allow-empty -m 'root'
$ git commit --allow-empty -m 'good'
$ git commit --allow-empty -m 'bad'
$ git reflog
996ca67... HEAD@{0}: commit: bad
e431a20... HEAD@{1}: commit: good
992dd88... HEAD@{2}: commit (initial): root
$ git reset HEAD^
$ git reflog
e431a20... HEAD@{0}: HEAD^: updating HEAD
996ca67... HEAD@{1}: commit: bad
e431a20... HEAD@{2}: commit: good
992dd88... HEAD@{3}: commit (initial): root
$ git reflog delete HEAD@{1}
$ git reflog
e431a20... HEAD@{0}: HEAD^: updating HEAD
996ca67... HEAD@{1}: commit: good
992dd88... HEAD@{2}: commit (initial): root
In this listing, please note that, after the delete, the commit SHA
shown as HEAD@{1} is that of the deleted reference (the bad commit)
and does not match the reflog message, which has the expected value.
Thank you,
bob
^ permalink raw reply
* Re: [PATCH v2 03/11] gitweb: separate heads and remotes list in summary view
From: Giuseppe Bilotta @ 2008-11-14 22:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811142104.35019.jnareb@gmail.com>
2008/11/14 Jakub Narebski <jnareb@gmail.com>:
> Dnia czwartek 13. listopada 2008 23:49, Giuseppe Bilotta napisał:
>
> Very nice patch. Now that I have read it, I don't think it should be
> squashed with previous patch (well, again that is only a suggestion).
See reply in previous patch. Sometimes it's hard to tell what's the
best patch-splitting strategy ...
> Barring one issue (see below) its conciseness shows that gitweb has
> quite good internal API.
Most definitely. I find that working on gitweb is almost pleasurable ;-)
[I mean, it's still Perl, which is not Tcl but not Ruby either 8-P]
>> my @forklist;
>> my ($check_forks) = gitweb_check_feature('forks');
>>
>> @@ -4535,6 +4537,13 @@ sub git_summary {
>> $cgi->a({-href => href(action=>"heads")}, "..."));
>> }
>>
>> + if (@remotelist) {
>> + git_print_header_div('remotes');
>> + git_heads_body(\@remotelist, $head, 0, 15,
>> + $#remotelist <= 15 ? undef :
>> + $cgi->a({-href => href(action=>"heads")}, "..."));
>> + }
>> +
>
> The only problem is that link leads to list of _all_ heads (best case),
> or list to local branches (worst case, but I don't think gitweb does
> it), instead of only list of remotes refs (remote-tracking branches),
> as one would think. Perhaps we could use 'h' (hash), or 'opt (extra
> options) parameter for this action, or just add 'remotes' action?
Adding a 'remotes' section (and corresponding action, too) is what is
done by subsequent patches. It's quite obvious, I think, that the
patch sequence follows _very_ closely the order in which I
implemented/tested features. It might make more sense to move some of
them earlier, but then such earlier patches would only make sense
because of the ones that follow ... this is why I decided to keep the
sequence as is.
>> 1.5.6.5
>
> P.S. Not uptodate (git version 1.6.0.4)? Just kidding...
Yeah, I know, given that I work with 'next' gitweb, I could as well
just upgrade the system git to the same version 8-P
Instead, I'm just relying on stock Debian stuff, which obviously,
being in freeze now, is not updating unstable either 8-P
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH v2 02/11] gitweb: git_get_heads_list accepts an optional list of refs.
From: Giuseppe Bilotta @ 2008-11-14 21:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811141948.57785.jnareb@gmail.com>
On Fri, Nov 14, 2008 at 7:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia czwartek 13. listopada 2008 23:49, Giuseppe Bilotta napisał:
>
>> git_get_heads_list(limit, dir1, dir2, ...) can now be used to retrieve
>> refs/dir1, refs/dir2 etc. Defaults to ('heads') or ('heads', 'remotes')
>> depending on the remote_heads option.
>
> Minor nit: I think it would be better to use the same terminology in
> commit message as in code, i.e. 'class1' instead of 'dir1', or perhaps
> 'ref_class1' if it would be better.
Uhm, ref/ref_class1 reads horrible, but sticking with a uniform
terminology is a good point. I adjusted the commit message
consequently.
> This is only a suggestion, but perhaps this patch could be squashed
> with a later one?
Or with the previous one, since as you remark it's a generalization of
the previous.
>> my @headslist;
>>
>> - my ($remote_heads) = gitweb_check_feature('remote_heads');
>> -
>> open my $fd, '-|', git_cmd(), 'for-each-ref',
>> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
>> '--format=%(objectname) %(refname) %(subject)%00%(committer)',
>> - 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
>> + @refs
>> or return;
>> while (my $line = <$fd>) {
>> my %ref_item;
>
> So this is a bit of generalization of (part of) previous patch,
> isn't it?
Precisely. I must say I had problems finding the proper splitting
point for some of these patches, because they had a very organic
evolution, but at the same time sqashing them together would give too
large changesets at once. You'll find that this is not the only patch
that makes the most sense only after seeing what comes later.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Sverre Rabbelier @ 2008-11-14 21:46 UTC (permalink / raw)
To: Martin Koegler; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <20081114213352.GA12134@auto.tuwien.ac.at>
On Fri, Nov 14, 2008 at 22:33, Martin Koegler
<mkoegler@auto.tuwien.ac.at> wrote:
> On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
>> I've put everyone who "owns" more than 500 lines of code
>> on the bcc list, figuring your permission is important
>> but that you don't want the hundreds (well, one can hope)
>> of emails from people saying "ok". The list of major owners
>> was generated with "git showners *.c" in a worktree from
>> the next branch of git.git.
>
> I don't think, that your way for relicensing is bullet proof:
>
> I consider many of my GIT patches as derived work from other parts of
> GIT, even if git blame is stating me as author. I can gurantee you,
> that I comply with the "Developer's Certificate of Origin 1.1" point
> b, as its based on code out of git.git. But I can't tell you, from
> which files I reused code anymore.
>
> Probably other people did the same.
>
> Your method is ignoring such derived code.
Perhaps git stats can be of assistance here, it can summarize how much
lines a person changed (per file, or in total), that should be a
better metric (at least for code reused from within git.git, ofcourse
GPL-ed code taken from somewhere else is not covered).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 01/11] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-14 21:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811141915.17680.jnareb@gmail.com>
On Fri, Nov 14, 2008 at 7:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
>
>> With this feature enabled, remotes are retrieved (and displayed)
>> when getting (and displaying) the heads list.
>
> I think it would be good idea to add in commit message idea _why_
> such feature would be useful, for example
>
> This is useful if you want to use git-instaweb to examine the state
> of repository, influding remote-tracking branches, or a repository
> is fork of other repository, and remote-tracking branches are used
> to see what commits this fork has in addition to those from forked
> (main) repository.
>
> Or something like that.
Ah yes, many commit messages in this patchset are way too terse. A
side effect of this being something like the first patchset I ever
prepared. I'll rework them to something more sensible.
> It would be also in my opinion a good idea to modify git-instaweb.sh
> (I guess better in separate commit) to make it make use of this new
> feature... unless it does it already, doesn't it?
It doesn't, but it's something I have considered. I'll work on it (on
a separate patch)
>> + # Make gitweb show remotes too in the heads list
>
> I'm not native engish speaker, but shouldn't instead of "remotes too"
> be "also remotes" or "remotes also"?
No idea, I guess we'll wait for a native english speaker opinion 8-D
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Martin Koegler @ 2008-11-14 21:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
On Fri, Nov 14, 2008 at 09:59:56PM +0100, Andreas Ericsson wrote:
> I've put everyone who "owns" more than 500 lines of code
> on the bcc list, figuring your permission is important
> but that you don't want the hundreds (well, one can hope)
> of emails from people saying "ok". The list of major owners
> was generated with "git showners *.c" in a worktree from
> the next branch of git.git.
I don't think, that your way for relicensing is bullet proof:
I consider many of my GIT patches as derived work from other parts of
GIT, even if git blame is stating me as author. I can gurantee you,
that I comply with the "Developer's Certificate of Origin 1.1" point
b, as its based on code out of git.git. But I can't tell you, from
which files I reused code anymore.
Probably other people did the same.
Your method is ignoring such derived code.
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Nanako Shiraishi @ 2008-11-14 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vk5b69p87.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
>> I have been thinking about making this detached HEAD thing an
>> additional option, but it _really_ seemed like overkill.
>
> I agree that it does not make much sense to make this feature an option.
> Detaching the HEAD in the repository itself is an enough clue from the
> user to the code that the user wants to trigger the feature.
Shouldn't the feature to show remote tracking branches also be unconditionally active, then?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-14 20:59 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
I've been working quite a lot on git -> libgit2 code moving,
but the licensing stuff is a bit depressing, as I can't know
if the work I'm doing is for nothing or not.
The license decided for libgit2 is "GPL with gcc exception".
Those who are OK with relicensing their contributions under
that license for the purpose of libgit2, can you please say
so?
I'm planning on writing a tool for this that will have "ok",
"not ok" and "ask-each-patch" as options.
The list of people whose position I know is rather short.
Please correct me if you're on it and would like not to be.
Junio C. Hamano ask
Johannes Schindelin ok
Shawn O. Pearce ok
Andreas Ericsson ok
Pierre Habouzit ok
Brian Gernhardt ok
I've put everyone who "owns" more than 500 lines of code
on the bcc list, figuring your permission is important
but that you don't want the hundreds (well, one can hope)
of emails from people saying "ok". The list of major owners
was generated with "git showners *.c" in a worktree from
the next branch of git.git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: git-showners --]
[-- Type: text/plain, Size: 673 bytes --]
#!/bin/sh
test "$#" -gt 0 || { echo "Usage: $0 <file>"; exit 1; }
combined=t
while test "$#" -gt 0
do
case "$1" in
-c|--combined)
combined=t
;;
-i|--individual)
combined=
;;
--)
shift
break
;;
*)
break
;;
esac
shift
done
sort_enumerate ()
{
sed -e 's/[^(]*(\([^0-9]*\).*/\1/' -e 's/[\t ]*$//' \
| sort | uniq -c | sort -nr
}
show_owners ()
{
for f in "$@"; do
test -d "$f" && { show_owners "$f"/*; continue; }
git blame -C -C -M "$f"
done
}
if test "$combined" = t; then
echo "$@"
show_owners "$@" | sort_enumerate
else
echo "Showing one-at-a-time ownership"
for f in "$@"; do
echo "$f"
show_owners "$f" | sort_enumerate
done
fi
^ permalink raw reply
* Re: git compile error on AIX
From: Junio C Hamano @ 2008-11-14 20:21 UTC (permalink / raw)
To: Dinakar; +Cc: git
In-Reply-To: <1226691918584-1499908.post@n2.nabble.com>
Dinakar <desas2@gmail.com> writes:
> /usr/bin/getopt: Not a recognized flag: d
> Usage: install [-c DirectoryA] [-f DirectoryB] [-i] [-m] [-M Mode] [-O
> Owner]
> [-G Group] [-S] [-n DirectoryC] [-o] [-s] File [DirectoryX
> ...]
Your "install" program is telling you that it does not understand 'd'
option ("install -d" to create a directory, I presume).
> gmake[1]: *** [boilerplates.made] Error 2
> gmake: *** [all] Error 2
> I would appreciate, if you could help me to resolve this issue.
An obvious solution would be to get a better install.
You seem to be using gmake, so perhaps you already have ginstall and can
use it like "gmake INSTALL=ginstall"?
^ permalink raw reply
* Re: hosting git on a nfs
From: Junio C Hamano @ 2008-11-14 20:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brandon Casey, James Pickens, Bruce Fields, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811141109580.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I also think the thread cost was wrong: it did
>
> threads = index->cache_nr / 100;
>
> to give a first-order "how many threads do we want", but the thread
> startup is likely to be higher than 100 lstat calls, so we probably want
> fewer threads than that. It doesn't much matter for something like the
> Linux kernel, where there are so many files that we'll end up maxing out
> the threads anyway, but for smaller projects, I suspect a thread cost of
> "one thread per 500 files" is more reasonable. You almost certainly don't
> want to thread anything at all for fewer than a few hundred files.
If you have 1000 files in a single directory, do you still want 2 threads
following the "1/500" rule, or they would compete reading the same
directory and using a single thread is better off?
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Francis Galiegue @ 2008-11-14 20:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Sam Vilain, git
In-Reply-To: <491DD671.8070801@op5.se>
Le Friday 14 November 2008 20:50:09 Andreas Ericsson, vous avez écrit :
> Francis Galiegue wrote:
> > Le Friday 14 November 2008 20:05:19 Junio C Hamano, vous avez écrit :
> > [...]
> >
> >>> fd = mkstemp(buffer);
> >>> - if (fd < 0 && dirlen && (errno != EPERM)) {
> >>> + if (fd < 0 && dirlen && (errno != EACCESS)) {
> >>
> >> Is this accepting the two as equivalents???
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe git" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > Well, looking at mkdir(2), it says:
> >
> > EPERM The file system containing pathname does not support the
> > creation of directories.
> >
> > Hmm, err... git would fail at an earlier point anyway, wouldn't it? Even
> > git init would fail there.
>
> Not necessarily. .git could be mounted erroneously from via a networked
> filesystem but without write permissions.
In which case EACCESS would be returned anyway. There is quite a difference
between EACCESS (Permission denied) and EPERM (operation not permitted).
Basically, my understanding is that mkdir() will only return EPERM if the
underlying filesystem can not even CREATE directories on the filesystem. So,
unless you are doing very bizarre things with your git repository, I cannot
see how you can even trigger an EPERM unless you asked for it.
> Yes, other things would fail
> then too, but both EPERM and EACCESS are valid and possible return codes.
And so is ENOSPC, and so is EIO, and so is... It's endless. I think focus
should be made on the most common ones, and EACCESS _is_ such one. Others
just aren't.
This is why I suggested replacing EPERM with EACCESS in the first place:
EACCESS is by far the most common error code you will get (even root will get
that on a read-only filesystem, not EPERM).
--
fge
^ permalink raw reply
* Re: Can git ignore parts of files
From: Elijah Newren @ 2008-11-14 20:06 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1226690252.6176.9.camel@rotwang.fnordora.org>
On Fri, Nov 14, 2008 at 12:17 PM, Alan <alan@clueserver.org> wrote:
> I have kind of an odd problem that is causing me grief in git. I figure
> someone has a good solution here. (Or not, they will soon.)
>
> I have a couple of kernel .config files that are checked into git. They
> are used to test kernel configurations for the nightly builds where I
> work.
>
> We have a bunch of kernel developers working on drivers. When they add
> a new driver, they add in the options in the test file to make it
> compile in the test builds.
>
> The problem is that the kernel config file has a timestamp at the top of
> the file that is generated by "make oldconfig" or "make config". Other
> than removing the timestamp each time manually, is there a way to get
> git to ignore the timestamp on a merge?
>
> What happens is that the authors submit the changes on a branch in most
> cases. Sometimes they have a version of that file that is quite out of
> date. When I go to merge, that one file gives me grief 95% of the time.
>
> Is there an easy way around this? Am I approaching the problem wrong?
> Is there a better way to do this?
Someone wrote a special merge algorithm to handle similar conflicts in
tracked ChangeLog files (see
http://www.mail-archive.com/bug-gnulib@gnu.org/msg09183.html).
Perhaps you could write a similar merge algorithm and use it?
Hope that helps,
Elijah
^ permalink raw reply
* Re: [PATCH v2 03/11] gitweb: separate heads and remotes list in summary view
From: Jakub Narebski @ 2008-11-14 20:04 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-4-git-send-email-giuseppe.bilotta@gmail.com>
Dnia czwartek 13. listopada 2008 23:49, Giuseppe Bilotta napisał:
Very nice patch. Now that I have read it, I don't think it should be
squashed with previous patch (well, again that is only a suggestion).
Barring one issue (see below) its conciseness shows that gitweb has
quite good internal API.
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d7c97a3..ab29aec 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4449,6 +4449,7 @@ sub git_summary {
> my %co = parse_commit("HEAD");
> my %cd = %co ? parse_date($co{'committer_epoch'}, $co{'committer_tz'}) : ();
> my $head = $co{'id'};
> + my ($remote_heads) = gitweb_check_feature('remote_heads');
>
> my $owner = git_get_project_owner($project);
>
> @@ -4456,7 +4457,8 @@ sub git_summary {
> # These get_*_list functions return one more to allow us to see if
> # there are more ...
> my @taglist = git_get_tags_list(16);
> - my @headlist = git_get_heads_list(16);
> + my @headlist = git_get_heads_list(16, 'heads');
> + my @remotelist = $remote_heads ? git_get_heads_list(16, 'remotes') : ();
Nice.
> my @forklist;
> my ($check_forks) = gitweb_check_feature('forks');
>
> @@ -4535,6 +4537,13 @@ sub git_summary {
> $cgi->a({-href => href(action=>"heads")}, "..."));
> }
>
> + if (@remotelist) {
> + git_print_header_div('remotes');
> + git_heads_body(\@remotelist, $head, 0, 15,
> + $#remotelist <= 15 ? undef :
> + $cgi->a({-href => href(action=>"heads")}, "..."));
> + }
> +
The only problem is that link leads to list of _all_ heads (best case),
or list to local branches (worst case, but I don't think gitweb does
it), instead of only list of remotes refs (remote-tracking branches),
as one would think. Perhaps we could use 'h' (hash), or 'opt (extra
options) parameter for this action, or just add 'remotes' action?
> if (@forklist) {
> git_print_header_div('forks');
> git_project_list_body(\@forklist, 'age', 0, 15,
> --
> 1.5.6.5
P.S. Not uptodate (git version 1.6.0.4)? Just kidding...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Can git ignore parts of files
From: Alan @ 2008-11-14 19:58 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811142033.51019.fg@one2team.net>
On Fri, 2008-11-14 at 20:33 +0100, Francis Galiegue wrote:
> Le Friday 14 November 2008 20:17:32 Alan, vous avez écrit :
> > I have kind of an odd problem that is causing me grief in git. I figure
> > someone has a good solution here. (Or not, they will soon.)
> >
> > I have a couple of kernel .config files that are checked into git. They
> > are used to test kernel configurations for the nightly builds where I
> > work.
> >
> > We have a bunch of kernel developers working on drivers. When they add
> > a new driver, they add in the options in the test file to make it
> > compile in the test builds.
> >
> > The problem is that the kernel config file has a timestamp at the top of
> > the file that is generated by "make oldconfig" or "make config". Other
> > than removing the timestamp each time manually, is there a way to get
> > git to ignore the timestamp on a merge?
> >
> > What happens is that the authors submit the changes on a branch in most
> > cases. Sometimes they have a version of that file that is quite out of
> > date. When I go to merge, that one file gives me grief 95% of the time.
> >
> > Is there an easy way around this? Am I approaching the problem wrong?
> > Is there a better way to do this?
> >
>
> Do they ever touch to the kernel core? You say that they are developing
> drivers, they basically use core kernel interfaces but not modify them right?
>
> For quite a few years now, the kernel build system has allowed one to build
> drivers out of the kernel tree (but _using_ the kernel tree) fairly easily.
> Why not go this route? You won't have any conflict problems anymore, _and_
> you can maintain (and update) your kernel tree regularly.
Because these will go into core at some later date. (I work for Intel.)
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Andreas Ericsson @ 2008-11-14 19:50 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Junio C Hamano, Sam Vilain, Francis Galiegue, git
In-Reply-To: <200811142009.51803.fg@one2team.com>
Francis Galiegue wrote:
> Le Friday 14 November 2008 20:05:19 Junio C Hamano, vous avez écrit :
> [...]
>>> fd = mkstemp(buffer);
>>> - if (fd < 0 && dirlen && (errno != EPERM)) {
>>> + if (fd < 0 && dirlen && (errno != EACCESS)) {
>> Is this accepting the two as equivalents???
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Well, looking at mkdir(2), it says:
>
> EPERM The file system containing pathname does not support the
> creation of directories.
>
> Hmm, err... git would fail at an earlier point anyway, wouldn't it? Even git
> init would fail there.
>
Not necessarily. .git could be mounted erroneously from via a networked
filesystem but without write permissions. Yes, other things would fail
then too, but both EPERM and EACCESS are valid and possible return codes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git compile error on AIX
From: Dinakar @ 2008-11-14 19:45 UTC (permalink / raw)
To: git
Hello:
I am trying to compile git-1.6.0 on AIX 5.3 with gcc (GCC) 4.2.3. I getting
following error.
cp private-Error.pm blib/lib/Error.pm
cp Git.pm blib/lib/Git.pm
Manifying blib/man3/private-Error.3
Manifying blib/man3/Git.3
SUBDIR templates
/usr/bin/getopt: Not a recognized flag: d
Usage: install [-c DirectoryA] [-f DirectoryB] [-i] [-m] [-M Mode] [-O
Owner]
[-G Group] [-S] [-n DirectoryC] [-o] [-s] File [DirectoryX
...]
gmake[1]: *** [boilerplates.made] Error 2
gmake: *** [all] Error 2
I would appreciate, if you could help me to resolve this issue.
Thank you.
Dinakar
--
View this message in context: http://n2.nabble.com/git-compile-error-on-AIX-tp1499908p1499908.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Can git ignore parts of files
From: Francis Galiegue @ 2008-11-14 19:33 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1226690252.6176.9.camel@rotwang.fnordora.org>
Le Friday 14 November 2008 20:17:32 Alan, vous avez écrit :
> I have kind of an odd problem that is causing me grief in git. I figure
> someone has a good solution here. (Or not, they will soon.)
>
> I have a couple of kernel .config files that are checked into git. They
> are used to test kernel configurations for the nightly builds where I
> work.
>
> We have a bunch of kernel developers working on drivers. When they add
> a new driver, they add in the options in the test file to make it
> compile in the test builds.
>
> The problem is that the kernel config file has a timestamp at the top of
> the file that is generated by "make oldconfig" or "make config". Other
> than removing the timestamp each time manually, is there a way to get
> git to ignore the timestamp on a merge?
>
> What happens is that the authors submit the changes on a branch in most
> cases. Sometimes they have a version of that file that is quite out of
> date. When I go to merge, that one file gives me grief 95% of the time.
>
> Is there an easy way around this? Am I approaching the problem wrong?
> Is there a better way to do this?
>
Do they ever touch to the kernel core? You say that they are developing
drivers, they basically use core kernel interfaces but not modify them right?
For quite a few years now, the kernel build system has allowed one to build
drivers out of the kernel tree (but _using_ the kernel tree) fairly easily.
Why not go this route? You won't have any conflict problems anymore, _and_
you can maintain (and update) your kernel tree regularly.
--
fge
^ permalink raw reply
* Can git ignore parts of files
From: Alan @ 2008-11-14 19:17 UTC (permalink / raw)
To: git
I have kind of an odd problem that is causing me grief in git. I figure
someone has a good solution here. (Or not, they will soon.)
I have a couple of kernel .config files that are checked into git. They
are used to test kernel configurations for the nightly builds where I
work.
We have a bunch of kernel developers working on drivers. When they add
a new driver, they add in the options in the test file to make it
compile in the test builds.
The problem is that the kernel config file has a timestamp at the top of
the file that is generated by "make oldconfig" or "make config". Other
than removing the timestamp each time manually, is there a way to get
git to ignore the timestamp on a merge?
What happens is that the authors submit the changes on a branch in most
cases. Sometimes they have a version of that file that is quite out of
date. When I go to merge, that one file gives me grief 95% of the time.
Is there an easy way around this? Am I approaching the problem wrong?
Is there a better way to do this?
^ permalink raw reply
* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-14 19:23 UTC (permalink / raw)
To: Brandon Casey
Cc: James Pickens, Bruce Fields, Junio C Hamano, Git Mailing List
In-Reply-To: <vzAozXmaOLEpyz-7DHx4nMusAdaTsFp7iZ8xfFsgAIraex6_wfvyuw@cipher.nrlssc.navy.mil>
On Fri, 14 Nov 2008, Brandon Casey wrote:
>
> I have no explanation for why the diff numbers are different from
> yesterday. Could be that there was some nightly cron job running last
> night which slowed things down. Still, the same ~5x speedup is observed!
One of the things I changed (inadvertently - it was just meant to be a
test) was that the last patch had MAX_PARALLEL set to 100 rather than 10.
That's definitely overkill.
I also think the thread cost was wrong: it did
threads = index->cache_nr / 100;
to give a first-order "how many threads do we want", but the thread
startup is likely to be higher than 100 lstat calls, so we probably want
fewer threads than that. It doesn't much matter for something like the
Linux kernel, where there are so many files that we'll end up maxing out
the threads anyway, but for smaller projects, I suspect a thread cost of
"one thread per 500 files" is more reasonable. You almost certainly don't
want to thread anything at all for fewer than a few hundred files.
So here's a slight incremental update to my patch from yesterday. It also
adds the config variable, and it defaults to off, so to actually see this
in action, you now need to add
[core]
PreloadIndex = true
to your ~/.gitconfig file.
Totally untested. As usual. Maybe it works. Maybe it doesn't.
Linus
---
Documentation/config.txt | 12 +++++++++++-
cache.h | 1 +
config.c | 5 +++++
environment.c | 3 +++
preload-index.c | 18 +++++++++++++-----
5 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 32dcd64..9260121 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -411,7 +411,17 @@ core.fsyncobjectfiles::
This is a total waste of time and effort on a filesystem that orders
data writes properly, but can be useful for filesystems that do not use
journalling (traditional UNIX filesystems) or that only journal metadata
-and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
+and not file contents (OS X's HFS+, or Linux ext3 with
+"data=writeback").
+
+core.preloadindex::
+ Enable parallel index preload for operations like 'git diff'
++
+This can speed up operations like 'git diff' and 'git status' especially
+on filesystems like NFS that have weak caching semantics and thus
+relatively high IO latencies. With this set to 'true', git will do the
+index comparison to the filesystem data in parallel, allowing
+overlapping IO's.
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
diff --git a/cache.h b/cache.h
index 64239fb..685a866 100644
--- a/cache.h
+++ b/cache.h
@@ -460,6 +460,7 @@ extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern int auto_crlf;
extern int fsync_object_files;
+extern int core_preload_index;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/config.c b/config.c
index 67cc1dc..d2fc8f5 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.preloadindex")) {
+ core_preload_index = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index bb96ac0..e278bce 100644
--- a/environment.c
+++ b/environment.c
@@ -43,6 +43,9 @@ unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+/* Parallel index stat data preload? */
+int core_preload_index = 0;
+
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
static char *work_tree;
diff --git a/preload-index.c b/preload-index.c
index e322c27..3ce42e0 100644
--- a/preload-index.c
+++ b/preload-index.c
@@ -4,9 +4,14 @@
#include <pthread.h>
#include "cache.h"
-/* Hacky hack-hack start */
-#define MAX_PARALLEL (100)
-int parallel_lstats = 1;
+/*
+ * Mostly randomly chosen maximum thread counts: we
+ * cap the parallelism to 20 threads, and we want
+ * to have at least 500 lstat's per thread for it to
+ * be worth starting a thread.
+ */
+#define MAX_PARALLEL (20)
+#define THREAD_COST (500)
struct thread_data {
pthread_t pthread;
@@ -47,10 +52,13 @@ static void *preload_thread(void *_data)
static void preload_index(struct index_state *index, const char **pathspec)
{
- int i, work, offset;
- int threads = index->cache_nr / 100;
+ int threads, i, work, offset;
struct thread_data data[MAX_PARALLEL];
+ if (!core_preload_index)
+ return;
+
+ threads = index->cache_nr / THREAD_COST;
if (threads < 2)
return;
if (threads > MAX_PARALLEL)
^ permalink raw reply related
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Francis Galiegue @ 2008-11-14 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, Francis Galiegue, git
In-Reply-To: <7vfxlu9lhs.fsf@gitster.siamese.dyndns.org>
Le Friday 14 November 2008 20:05:19 Junio C Hamano, vous avez écrit :
[...]
> > fd = mkstemp(buffer);
> > - if (fd < 0 && dirlen && (errno != EPERM)) {
> > + if (fd < 0 && dirlen && (errno != EACCESS)) {
>
> Is this accepting the two as equivalents???
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Well, looking at mkdir(2), it says:
EPERM The file system containing pathname does not support the
creation of directories.
Hmm, err... git would fail at an earlier point anyway, wouldn't it? Even git
init would fail there.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] sha1_file: make sure correct error is propagated
From: Junio C Hamano @ 2008-11-14 19:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: Francis Galiegue, git
In-Reply-To: <1226655681.17731.4.camel@maia.lan>
Sam Vilain <sam@vilain.net> writes:
> Subject: sha1_file: accept EACCESS as equivalent to EPERM
>
> This was testing for 'Operation not permitted' rather than any kind
> of 'Permission Denied' error; prefer EACCESS.
>
> Signed-off-by: Sam Vilain <sam@vilain.net>
> --
> Sorry for the inevitable wrapping/whitespace fail :(
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 7662330..cd422e6 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t
> bufsiz, const char *filename)
> memcpy(buffer, filename, dirlen);
> strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
> fd = mkstemp(buffer);
> - if (fd < 0 && dirlen && (errno != EPERM)) {
> + if (fd < 0 && dirlen && (errno != EACCESS)) {
Is this accepting the two as equivalents???
^ 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