* Re: hosting git on a nfs
From: Brandon Casey @ 2008-11-14 18:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: James Pickens, Bruce Fields, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131707090.3468@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>
> On Thu, 13 Nov 2008, Linus Torvalds wrote:
>> I'll clean it up a bit and make a less hacky version. And I'll try to make
>> it work for "git status" and friends too.
>
> Ok, this is a no-longer-totally-hacky thing, which also adds support for
> doing the same for "git status". I haven't actually done any timings, but
> the preload algorithm is all the same. The interface is just a much more
> natural one.
git status > /dev/null
Before:
0.06user 0.37system 0:03.04elapsed 14%CPU
0.07user 0.36system 0:03.25elapsed 13%CPU
0.07user 0.36system 0:03.08elapsed 14%CPU
After:
0.06user 0.53system 0:01.02elapsed 58%CPU
0.05user 0.54system 0:01.01elapsed 58%CPU
0.06user 0.52system 0:01.04elapsed 57%CPU
git diff > /dev/null
Before:
0.02user 0.31system 0:02.88elapsed 11%CPU
0.01user 0.32system 0:02.53elapsed 13%CPU
0.01user 0.28system 0:02.78elapsed 10%CPU
After:
0.01user 0.47system 0:00.52elapsed 92%CPU
0.01user 0.48system 0:00.52elapsed 94%CPU
0.01user 0.47system 0:00.54elapsed 88%CPU
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!
Wow! Thanks!
-brandon
^ permalink raw reply
* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Giuseppe Bilotta @ 2008-11-14 18:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811141533.15427.jnareb@gmail.com>
On Fri, Nov 14, 2008 at 3:33 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 13 Nov 2008, Giuseppe Bilotta wrote:
>
>> This is a patchset I presented about a year ago or so, but after a lively
>> discussion it dropped into silence. I'm now presenting it again, with minor
>> cleanups and adjustements.
>
> That is very nice of you to resend this series. If you could provide
> link to earlier discussion of this series...
There was no actual discussion after I sent the series, although there
was some while I was preparing it. Plus, gmane is quite unresponsive
for me at the moment, but the whereabous of the past discussions are
these http://kerneltrap.org/mailarchive/git/2007/8/30/256411/thread
>> Giuseppe Bilotta (11):
>> gitweb: introduce remote_heads feature
>> gitweb: git_get_heads_list accepts an optional list of refs.
>> gitweb: separate heads and remotes list in summary view
>> gitweb: optional custom name for refs in git_heads_body
>> gitweb: git_split_heads_body function.
>> gitweb: use CSS to style split head lists.
>> gitweb: add 'remotes' action
>> gitweb: display HEAD in heads list when detached
>> gitweb: git_is_head_detached() function
>> gitweb: add HEAD to list of shortlog refs if detached
>> gitweb: CSS style and refs mark for detached HEAD
>
> I'll try to review individual patches, but I haven't examined them
> yet, so perhaps there is a reason why there are so many patches in
> this series?
And I actually squashed some! The original patchset was 14 patches.
Now it's about 10, of which the first 6 as the actual remote heads
stuff, and the last 4 are the detached HEAD stuff.
> Note that on GMane NNTP (news) interface I can see only two last
> patches. Could anyone not CC-ed confirm or deny if this is VGER
> anti-SPAM filter at work, or some GMane archive hiccup?
Seems to be a gmane problem, I can see it too.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Francis Galiegue @ 2008-11-14 18:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Frey, Johannes Schindelin, Alex Riesen, Junio C Hamano,
Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org>
Le Friday 14 November 2008 17:11:41 Linus Torvalds, vous avez écrit :
[...]
>
> So we _could_ do something like
>
> git log {a..b} [...]
>
I don't know if you really meant this, but entering SHA1s as is at a shell
prompt may have dangerous side effects... If not right now, then in (some not
so distant time in) the future. Consider this (I use bash 3.2, maintained by
Gentoo):
$ echo {a..c}
a b c
Who knows if some day they won't have the idea of, say,
extending "{aeb32ca..ee23ff1}" to, well... You see what I mean.
--
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 v2 02/11] gitweb: git_get_heads_list accepts an optional list of refs.
From: Jakub Narebski @ 2008-11-14 18:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-3-git-send-email-giuseppe.bilotta@gmail.com>
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.
This is only a suggestion, but perhaps this patch could be squashed
with a later one?
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b6c4233..d7c97a3 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2663,15 +2663,18 @@ sub parse_from_to_diffinfo {
> ## parse to array of hashes functions
>
> sub git_get_heads_list {
> - my $limit = shift;
> + my ($limit, @class) = @_;
> + unless (defined @class) {
> + my ($remote_heads) = gitweb_check_feature('remote_heads');
> + @class = ('heads', $remote_heads ? 'remotes' : undef);
> + }
> + my @refs = map { "refs/$_" } @class;
Nice.
> 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?
--
Jakub Narebski
Poland
^ 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
* 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: 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
* 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: 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
* 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: [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
* 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 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: 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] 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: 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: 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
* 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: [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
* 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 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: 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 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: [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
* 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
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