* 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
* 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: 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 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: 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 01/11] gitweb: introduce remote_heads feature
From: Jakub Narebski @ 2008-11-14 18:15 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-2-git-send-email-giuseppe.bilotta@gmail.com>
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.
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?
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 31 +++++++++++++++++++++++++++++--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 933e137..b6c4233 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -327,6 +327,18 @@ our %feature = (
> 'ctags' => {
> 'override' => 0,
> 'default' => [0]},
> +
> + # 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"?
> +
> + # To enable system wide have in $GITWEB_CONFIG
> + # $feature{'remote_heads'}{'default'} = [1];
> + # To have project specific config enable override in $GITWEB_CONFIG
> + # $feature{'remote_heads'}{'override'} = 1;
> + # and in project config gitweb.remote_heads = 0|1;
> + 'remote_heads' => {
> + 'sub' => \&feature_remote_heads,
> + 'override' => 0,
> + 'default' => [0]},
> );
>
> sub gitweb_check_feature {
> @@ -392,6 +404,18 @@ sub feature_pickaxe {
> return ($_[0]);
> }
>
> +sub feature_remote_heads {
> + my ($val) = git_get_project_config('remote_heads', '--bool');
> +
> + if ($val eq 'true') {
> + return (1);
> + } elsif ($val eq 'false') {
> + return (0);
> + }
> +
> + return ($_[0]);
> +}
Hmmm... I think it is hight time to provide option to
git_get_project_config to _not_ use backward compatibility with
'git config --bool', i.e. return Perl bool, and not 'true'/'false'
string.
But this is I think outside scope of this patch...
> +
> # checking HEAD file with -e is fragile if the repository was
> # initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
> # and then pruned.
> @@ -2642,10 +2666,12 @@ sub git_get_heads_list {
> my $limit = shift;
> 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'
> + 'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
> or return;
> while (my $line = <$fd>) {
> my %ref_item;
> @@ -2656,8 +2682,9 @@ sub git_get_heads_list {
> my ($committer, $epoch, $tz) =
> ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
> $ref_item{'fullname'} = $name;
> - $name =~ s!^refs/heads/!!;
> + $name =~ s!^refs/(head|remote)s/!!;
>
> + $ref_item{'class'} = $1;
Nice catch.
> $ref_item{'name'} = $name;
> $ref_item{'id'} = $hash;
> $ref_item{'title'} = $title || '(no commit message)';
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-14 17:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Frey, Johannes Schindelin, Alex Riesen, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811140936050.3468@nehalem.linux-foundation.org>
On Fri, 14 Nov 2008, Linus Torvalds wrote:
>
> but if you already do
>
> gitk a..b
>
> then you're _already_ doing a revision limiter and forcing the revision
> walk to be synchronous, so there would be no interactivity downside
> between 'a..b' and '{a..b}'.
Btw, the biggest problem (I think) is actually non-simple ranges and just
the _syntax_ of these things.
It's entirely reasonable to want to group a more complex expression than
just a single range. IOW, something like
gitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}
to show a union of what is in 'pu' but not master or next, and the
symmetrical difference of the current merge. It's a perfectly sensible
thing to do. And we _can_ do it right now, just with a nasty syntax:
gitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)
actually works. But look again at how nasty it is to parse the '{x}'
version, because the '{..}' thing now spans multiple arguments.
Linus
^ permalink raw reply
* Re: [MonoDevelop] git integration with monodevelop
From: Jakub Narebski @ 2008-11-14 17:55 UTC (permalink / raw)
To: Miguel de Icaza
Cc: Johannes Schindelin, Andreas Ericsson, Git Mailing List,
Shawn Pearce, monodevelop-list, Michael Hutchinson
In-Reply-To: <1226683698.4483.265.camel@erandi.site>
On Fri, 14 Nov 2008, Miguel de Icaza wrote:
Please, try to not lose the attribution
> Johannes Schindelin wrote:
> > May I suggest respectfully, that the next time communication channels
> > between the Mono-mentor and at least one knowledgable Git guy are
> > established early in the project? IIRC there was a GSoC project to
> > reimplement Git in C# last year, too, which failed, too.
>
> The first year effort failed because the student never started, he got a
> job before the official SoC start.
>
> This year one of the students vanished before the SoC started, the other
> one did some minimal work, probably because the work was above his
> comfort zone.
I think that it might also be that 'Git# implementation' is just too
big a project for single Google Summer of Code, even for two students.
JGit/EGit is developed for much longer than a single summer, with
larger number of developers than one or two students, and it is not
yet complete Git implementation. The JGit GSoC 2008 project was simply
"Eclipse plugin push support", and that size of project worked
wonderfully (see http://git.or.cz/gitwiki/SoC2008Projects page).
So for the future I think it would be better to a) define smaller sized
projects with definite (and reachable) goals; b) maintain better contact
with Git Development Community (git mailing list, #git IRC channel).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git integration with monodevelop
From: "Andrés G. Aragoneses" @ 2008-11-14 17:53 UTC (permalink / raw)
To: monodevelop-list; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811141419520.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 12 Nov 2008, Miguel de Icaza wrote:
>
>>> I assume that results of Mono's Google Summer of Code 2008 projects to
>>> create managed git implementation in C# (git#)[1][2] were not very
>>> successfull? Taking into account that JGit isn't yet full git
>>> implementation, after much longer development...
>> They were a complete disaster, one student was going to focus on the
>> front-end, the other on the back-end.
>
> I kinda followed the last few weeks via your svn repository (which was not
> helped by the commits being a complete mix of the individual projects).
>
> I was a bit disappointed that nobody asked things on the Git mailing list;
> quite a number of very important lessons were learnt during the first
> implementation of jgit, and you guys could have benefitted tremendously by
> hearing them.
>
> By the time I got aware of your effort, it was too late; for example, the
> code already relied on the fact that every blob's contents were read into
> memory at once (IIU the code correctly).
>
> Note: personally, I do not like C# all that much, so I am not that
> interested in the port myself. However, we get quite a number of
> questions in that direction ("do you support .NET yet?"), so I am quite
> interested to know what's available.
Have you looked at using Sharpen [1]?
[1]
http://evain.net/blog/articles/2008/05/20/sharpen-an-open-source-java-to-c-converter
Regards,
Andrés
--
^ permalink raw reply
* gitk touching paths highlighting oddity
From: Mark Burton @ 2008-11-14 17:51 UTC (permalink / raw)
To: git
Hi,
Using gitk (1.6.0.4) within a given subdirectory of a working tree, I wanted to
see those commits that affected files in the current directory so I selected
touching paths" and then typed "." into the entry field (That's right isn't it?)
On pressing the Next button, not only was a relevant commit successfully found
and highlighted (commit message boldened) but all of the "." characters in the
commit message list were given a yellow background (as if I was
searching the text for "."). Surely the yellow text highlighting shouldn't
happen when finding paths?
A quick look at the gitk code left me no wiser hence this email.
Mark
^ permalink raw reply
* Re: [PATCH v2 09/11] gitweb: git_is_head_detached() function
From: Junio C Hamano @ 2008-11-14 17:44 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <cb7bb73a0811140052h1b7aac6cp6b0b376fa59548a9@mail.gmail.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.
Thanks.
^ permalink raw reply
* [PATCH resend] Documentation: git-svn: fix example for centralized SVN clone
From: Jan Krüger @ 2008-11-14 17:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Eric Wong
The example that tells users how to centralize the effort of the initial
git svn clone operation doesn't work properly. It uses rebase but that
only works if HEAD exists. This adds one extra command to create a
somewhat sensible HEAD that should work in all cases.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
When I first sent this one I said I didn't like the solution all that
much (it would be nicer to use origin/HEAD but we didn't fetch that)
but Eric said he thinks it's okay and the original author of the
section hasn't piped in. It's still better than a nonfunctional example
in any case.
Previous discussion at
<http://thread.gmane.org/gmane.comp.version-control.git/100472>.
Documentation/git-svn.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 84c8f3c..ba94cd1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -544,6 +544,8 @@ have each person clone that repository with 'git-clone':
git remote add origin server:/pub/project
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
+# Create a local branch from one of the branches just fetched
+ git checkout -b master FETCH_HEAD
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git svn init http://svn.example.com/project
# Pull the latest changes from Subversion
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-14 17:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Frey, Johannes Schindelin, Alex Riesen, Miles Bader, git
In-Reply-To: <7v1vxeb4il.fsf@gitster.siamese.dyndns.org>
On Fri, 14 Nov 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > So we could make a '{ }' in the argument space basically do a SHA1
> > expansion of the range inside, and imply --no-walk. It's _not_ entirely
> > trivial, because we'd need to handle the fact that object flags are
> > sticky, and clear them in between invocations of multiple ranges, but it's
> > not _fundmanetally_ difficult. It's just that somebody would need to do
> > it.
>
> Wouldn't you lose the nice streaming output (iow short latency)?
Oh, absolutely. So the '{x}' format would be not be a replacement for
non-{} format - it would be an addition to.
But it's no different from 'a..b' in that sense: anything that sets
'revs->limited' automatically forces a synchronous revision walk. So you'd
be crazy to do
gitk {HEAD}
because
(a) there would be no point
(b) it indeed loses the streaming data and would become synchronous.
but if you already do
gitk a..b
then you're _already_ doing a revision limiter and forcing the revision
walk to be synchronous, so there would be no interactivity downside
between 'a..b' and '{a..b}'.
Linus
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Junio C Hamano @ 2008-11-14 17:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Frey, Johannes Schindelin, Alex Riesen, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So we could make a '{ }' in the argument space basically do a SHA1
> expansion of the range inside, and imply --no-walk. It's _not_ entirely
> trivial, because we'd need to handle the fact that object flags are
> sticky, and clear them in between invocations of multiple ranges, but it's
> not _fundmanetally_ difficult. It's just that somebody would need to do
> it.
Wouldn't you lose the nice streaming output (iow short latency)?
^ permalink raw reply
* Re: git integration with monodevelop
From: Miguel de Icaza @ 2008-11-14 17:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: monodevelop-list, Jakub Narebski, Shawn Pearce, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811141419520.30769@pacific.mpi-cbg.de>
Hello,
> May I suggest respectfully, that the next time communication channels
> between the Mono-mentor and at least one knowledgable Git guy are
> established early in the project? IIRC there was a GSoC project to
> reimplement Git in C# last year, too, which failed, too.
The first year effort failed because the student never started, he got a
job before the official SoC start.
This year one of the students vanished before the SoC started, the other
one did some minimal work, probably because the work was above his
comfort zone.
Miguel.
^ permalink raw reply
* Re: [PATCH v2] Edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-14 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <7v7i77f0f8.fsf@gitster.siamese.dyndns.org>
On Thu, 13 Nov 2008, Junio C Hamano wrote:
> Ian Hilt <ian.hilt@gmx.com> writes:
> > On Wed, 12 Nov 2008, Junio C Hamano wrote:
> >> Ian Hilt <ian.hilt@gmx.com> writes:
> >>
> >> > Sometimes specifying the recipient addresses can be tedious on the
> >> > command-line. This commit allows the user to edit the recipient
> >> > addresses in their editor of choice.
> >> >
> >> > Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
> >> > ---
> >> > Here's an updated commit with improved regex's from Junio and Francis.
> >>
> >> This heavily depends on Pierre's patch, so I am CC'ing him for comments.
> >> Until his series settles down, I cannot apply this anyway.
> >
> > I didn't realize this was such a bad time to submit this patch.
>
> It is not a bad time. I just won't be able to apply it right away, but
> people (like Pierre) who are interested in send-email enhancement can help
> improving your patch by reviewing.
And improvement it needs.
> >> Why does the user must keep "Cc:" in order for this new code to pick up
> >> the list of recipients? ...
> >>
> >> cc = "Cc:" address-list CRLF
> >> bcc = "Bcc:" (address-list / [CFWS]) CRLF
> >> address-list = (address *("," address)) / obs-addr-list
> >
> > I think you're mistaken here. It is entirely possible to delete the Cc
> > and Bcc lines with no ill effect.
>
> You have this piece of code
>
> >> > + if ($c_file =~ /^To:\s*(\S.+?)\s*\nCc:/ism) {
> >> > + @tmp_to = get_recipients($1);
> >> > + }
>
> to pick up the "To: " addressees. If your user deletes Cc: line, would
> that regexp still capture them in @tmp_to? How?
Wow. I don't know why I didn't catch that. You're right.
> > determine if $cc is equal to ''. If it's not, then it will use it.
>
> Ah, somehow I thought C2 you are writing into (message.final) was used as
> the final payload, but you are right. The foreach () loop at the toplevel
> reads them and interprets them.
>
> >> I think the parsing code you introduced simply suck. Why isn't it done as
> >> a part of the main loop to read the same file that already exists?
> >
> > Multiline recipient fields.
>
> So you were trying to handle folded headers after all, I see.
>
> But if you were to go that route, I think you are much better off doing so
> by enabling the header folding for all the header lines in the while (<C>)
> loop that currently reads one line at a time.
>
> I however hove to wonder why we are not using any canned e-mail header
> parser for this part of the code. Surely there must be a widely used one
> that everybody who writes Perl uses???
I thought about this, but I didn't want to introduce another dependency.
I'm sure there's an easy way to do this stuff but I just don't have
enough perl know-how yet.
In any case, I think this concept needs serious work considering the
points that have been raised. I don't have a lot of time to devote to
this however much I would like to complete it sooner than later. So for
now, unless someone else wants to take up the mantle, I think it would
be better to put this patch aside.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-14 16:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Frey, Alex Riesen, Junio C Hamano, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811140800540.3468@nehalem.linux-foundation.org>
Hi,
On Fri, 14 Nov 2008, Linus Torvalds wrote:
> So we _could_ do something like
>
> git log {a..b} {c..d ^e}
>
> and just declare that { $args } is a self-contained "subset", and
> effectively becomes the same thing as "$(git rev-list $args)" but with
> magic no-walking semantics (ie all walking is done only _within_ the {
> }, not between different groups.
>
> You literally _can_ do it right now that way:
>
> git log --no-walk $(git rev-list HEAD~5..HEAD~3) $(git rev-list
> HEAD~1..)
>
> actually works, but that will hit argument size limits on many platforms
> really quickly.
>
> So we could make a '{ }' in the argument space basically do a SHA1
> expansion of the range inside, and imply --no-walk. It's _not_ entirely
> trivial, because we'd need to handle the fact that object flags are
> sticky, and clear them in between invocations of multiple ranges, but
> it's not _fundmanetally_ difficult. It's just that somebody would need
> to do it.
Well, do not forget the case
git log ^HEAD^ {HEAD^..HEAD} $BLUB
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Jeff King @ 2008-11-14 16:21 UTC (permalink / raw)
To: Charles Bailey
Cc: Junio C Hamano, git, Andreas Ericsson, Theodore Ts'o,
William Pursell
In-Reply-To: <491D7C38.7070906@hashpling.org>
On Fri, Nov 14, 2008 at 01:25:12PM +0000, Charles Bailey wrote:
> Previously, if you aborted a merge, you were left with the
> base/local/remote temporaries for the merge that you aborted.
>
> To be honest, I found this a little irritating. The base, local and
> remote temporaries are inputs so are accessible from slots 1,2 and 3 of
> the index, and any intermediate output will be in the target file. You
> can git clean, but if you have other temporaries you need to keep, you
> end up having to manually clean them up in any case.
>
> With --keep-going, the problem is compounded. If you make several passes
> through a list of complex merges you end up with fistfuls of these
> temporary trios in your working tree. It goes from slightly annoying to
> very irritating.
I agree; I have never found the temporary files left by mergetool from a
failed merge to be useful, and get a little annoyed that I have to "git
clean" them away afterwards. Even without --keep-going, I would often
look at and abort a merge several times before resolving it and end up
with several copies.
But I definitely think that is an issue for a separate patch, and one
that needs input from Ted and from other mergetool users.
-Peff
^ 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