* 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
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-14 16:11 UTC (permalink / raw)
To: Chris Frey
Cc: Johannes Schindelin, Alex Riesen, Junio C Hamano, Miles Bader,
git
In-Reply-To: <20081114050822.GA23963@foursquare.net>
On Fri, 14 Nov 2008, Chris Frey wrote:
>
> Would it be possible to add "range" support to a subset of commands by
> using a git-range wrapper?
It would be better to just extend the SHA-1 arithmetic. We could do it, no
problem. It's just a SMOP.
For example, right now the arithmetic is entirely "flat", with no
precedence, no nesting, nothing but a single level of set operations. We
could extend it to be hierarchical.
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.
Linus
^ permalink raw reply
* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Sverre Rabbelier @ 2008-11-14 15:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811141533.15427.jnareb@gmail.com>
On Fri, Nov 14, 2008 at 15:33, Jakub Narebski <jnareb@gmail.com> wrote:
> 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?
I got all of the patches just fine, and I'm not CC-ed ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Error in git-cherry-pick manpage?
From: Jens Seidel @ 2008-11-14 15:14 UTC (permalink / raw)
To: git
Hi,
I try to use git cherry-pick to combine multiple commits but I'm confused
about the second sentence of the description:
"Given one existing commit, apply the change the patch introduces, and
record a new commit that records it. This requires your working tree to be
clean (no modifications from the HEAD commit)."
I intent to use it as follows:
git cherry-pick -x --no-commit 2e855ae
git cherry-pick -x --no-commit 0c1151
...
After the first invocation my working tree will not be clean but contain
changes in the index.
Does this mean that's a wrong usage of cherry-pick?
Jens
^ permalink raw reply
* Re: git integration with monodevelop
From: Johannes Schindelin @ 2008-11-14 14:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Evgeniy Ivanov, Shawn Pearce, Git Mailing List
In-Reply-To: <491D82F3.2090807@op5.se>
Hi,
On Fri, 14 Nov 2008, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 13 Nov 2008, Andreas Ericsson wrote:
> >
> > > Evgeniy Ivanov wrote:
> > >
> > > > But this is the same things Shawn has suggested to my mentor and
> > > > me at the beginning of SoC...
> > > Oh? I didn't know libgit2 started as a SoC project.
> >
> > It did not. It started as a request from GitHub, and following
> > discussion, at the GitTogether '08.
> >
> > There _was_ a SoC project last year, libgit-thin, but the problem as
> > far as GitHub is concerned was that it was a tear-down approach: it
> > took git.git and tried to make a small library of it, and by this
> > approach was bound to the GPL.
> >
>
> Oh. I was under the impression that libgit2 would also be able to reuse
> code from git.git, since there was that huge license thread a couple of
> months ago. Did I misinterpret that thread, and everything in libgit2
> has to be implemented from scratch?
You misinterpreted.
A lot can be reused, because the original authors agree to let the code be
relicensed (including Shawn and me, for example). But a few others have
raised concerns with everything non-GPL (and that includes GPL+gcc
exception), and even stated explicitely that they are not okay with their
code being reused (or adapted) to something as permissive as BSD, for
example.
However, let's not revive the license wars. The topic is kinda boring.
Ciao,
Dscho
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Farrukh Najmi @ 2008-11-14 14:45 UTC (permalink / raw)
To: Kyle Moffett; +Cc: git
In-Reply-To: <f73f7ab80811140638m4045cf83p311c593aff066002@mail.gmail.com>
Kyle Moffett wrote:
> On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
> <farrukh@wellfleetsoftware.com> wrote:
>
>> The problem I am trying to solve is this. In my service I need to store
>> metadata in a relational db and content in git such that both either commit
>> or not in a single transaction. If one commits and the other does not that
>> is a serious integrity issue. Seems to me, two phase commit would be the
>> right solution for that in the long run. This what JDBC + JMS topologies do.
>>
>
> That's really easy! First tweak jgit so that *instead* of using
> .git/refs, it uses your database to store references and exports them
> on a routine basis to .git/refs for debugging purposes.
Wow! This does sound simple in theory. Of course I have much to learn
about jgit code base first.
Any pointers on what parts of the code are involved that I should start
looking at? I would hate to
keep a fork of gjit around. Would this work be of interest to the
project if it could be done in a way
that a few properties control whether to use database or not?
Thanks Kyle!
> Then, for
> each database update:
>
> (1) Start transaction
> (2) Commit the change to GIT (adds ref update to the transaction)
> (3) Make other metadata updates
> (4) Commit transaction
>
> Then set up periodic garbage collection and you're done! If the
> transaction is aborted, there will simply be a bunch of random loose
> objects in the git repository, which will be cleaned up the next time
> you garbage collect. The ref update will be atomic and conditional
> with the rest of the transaction, and in git the *only* part that
> really matters for atomicity is the ref.
>
> Cheers,
> Kyle Moffett
>
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Any plans to support JTA and XA in jgit?
From: Kyle Moffett @ 2008-11-14 14:38 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: Robin Rosenberg, git
In-Reply-To: <491C8DBE.9080105@wellfleetsoftware.com>
On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
> The problem I am trying to solve is this. In my service I need to store
> metadata in a relational db and content in git such that both either commit
> or not in a single transaction. If one commits and the other does not that
> is a serious integrity issue. Seems to me, two phase commit would be the
> right solution for that in the long run. This what JDBC + JMS topologies do.
That's really easy! First tweak jgit so that *instead* of using
.git/refs, it uses your database to store references and exports them
on a routine basis to .git/refs for debugging purposes. Then, for
each database update:
(1) Start transaction
(2) Commit the change to GIT (adds ref update to the transaction)
(3) Make other metadata updates
(4) Commit transaction
Then set up periodic garbage collection and you're done! If the
transaction is aborted, there will simply be a bunch of random loose
objects in the git repository, which will be cleaned up the next time
you garbage collect. The ref update will be atomic and conditional
with the rest of the transaction, and in git the *only* part that
really matters for atomicity is the ref.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH v2 00/11] gitweb: display remote heads
From: Jakub Narebski @ 2008-11-14 14:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226616555-24503-1-git-send-email-giuseppe.bilotta@gmail.com>
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...
> 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?
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?
--
Jakub Narebski
Poland
^ 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