* Re: C# Git Implementation
From: Robin Rosenberg @ 2008-11-29 19:55 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: JD Guzman, git
In-Reply-To: <alpine.DEB.2.00.0811291308120.17643@vellum.laroia.net>
lördag 29 november 2008 19:08:58 skrev Asheesh Laroia:
> On Fri, 28 Nov 2008, JD Guzman wrote:
>
> > I read in the archives that there was once talk of porting Git over to
> > C# and was wondering if anything ever came of this? I realize there
> > were some that didn't see the use for this but as Git is becoming more
> > and more popular a more native implementation of Git for windows users
> > would be a good endevour IMHO.
>
> Is it possible to compile the Java-language jgit with the Common Language
> Runtime and access that from a C# application?
>
> -- Asheesh.
>
I tried it half a year ago. Recompiling and running was easy, Unfortunately it hung on reading
blobs and the stacktrace showed it was stuck in deflate. It's not very high on my list of priorities,
but I assume fixing the problem is probably not hard if you decide to get your editor dirty.
-- robin
^ permalink raw reply
* Re: C# Git Implementation
From: Alejandro Riveira @ 2008-11-29 19:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.00.0811291308120.17643@vellum.laroia.net>
El Sat, 29 Nov 2008 13:08:58 -0500, Asheesh Laroia escribió:
> On Fri, 28 Nov 2008, JD Guzman wrote:
>
>> I read in the archives that there was once talk of porting Git over to
>> C# and was wondering if anything ever came of this? I realize there
>> were some that didn't see the use for this but as Git is becoming more
>> and more popular a more native implementation of Git for windows users
>> would be a good endevour IMHO.
>
> Is it possible to compile the Java-language jgit with the Common
> Language Runtime and access that from a C# application?
ikvm ?? http://www.ikvm.net/
>
> -- Asheesh.
^ permalink raw reply
* Overwriting untracked working tree files (when identical)
From: Asheesh Laroia @ 2008-11-29 18:58 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 576 bytes --]
I was using git earlier today and got the familiar error:
"Untracked working tree file 'filename’ would be overwritten by merge"
As it happens, I know that filename in my local filesystem and filename in
the remote git branch have the same contents.
Would it make sense for git to check for this possibility, and if the
working tree file is the same as the file being merged in with that
filename, allow the overwrite?
(I received the message with "git pull," so I imagine it was emitted by
the recursive merge driver.)
-- Asheesh.
--
Reply hazy, ask again later.
^ permalink raw reply
* A better approach to diffing and merging
From: Ian Clarke @ 2008-11-29 18:12 UTC (permalink / raw)
To: git
Apologies if this is off-topic, but I recently had an idea for a
better way to do diffs and merging which I thought may be of interest
to those on this list.
I described it in a blog entry here: http://budurl.com/jyt6
For your convenience text is pasted below (although missing a few hyperlinks):
A plan for better source code diffs and merging
======================================
I've been using Subversion for years, but a few months ago I was
really starting to feel the limitations of being able to create and
merge branches easily. I'd heard that Git made this very easy indeed,
and so I decided to try it.
Anyway, this isn't yet another "I discovered Git and now I've achieved
self-actualization" blog post, so to cut a long story short, I now use
git for everything (together with the excellent GitHub).
Even though merging is a lot better with Git than Subversion, I've
still found myself getting into situations where it requires a lot of
work to merge a branch back into another branch, and it got me
thinking about better ways to do merging.
While I'm no merging expert, it seems that most merging algorithms do
it on a line-by-line basis, treating source code as nothing but a list
of lines of text. It got me thinking, what if the merging algorithm
understood the structure of the source code it is trying to merge?
So the idea is this:
Provide the merge algorithm with the grammar of the programming
language, perhaps in the form of a Bison grammar file, or some other
standardized way to represent a grammar.
The merge algorithm then uses this to parse the files to be diffed
and/or merged into trees, and then the diff and merge are treated as
operations on these trees. These operations may include creating,
deleting, or moving nodes or branches, renaming nodes, etc. There has
been quite a bit (pdf) of academic research on this topic, although I
haven't yet found off-the-shelf code that will do what we need.
Still, it shouldn't be terribly hard to implement.
The beauty of this approach is that the merge algorithm should be far
less likely to be confused by formatting changes, and much more likely
to correctly identify what has changed.
I can't think of any reason that such a tool wouldn't work in the
exact same way as existing diff/merge tools from the programmer's
perspective. The tool would automatically select the correct grammar
based on the file extension, or fall-back to line-based diffs if the
extension is unrecognized (or the file isn't valid for the selected
grammar). Thus, it should be trivial to use this new tool with
existing version control systems.
I'd love to have the time to implement this, although regretfully it
is at the bottom of a very large pile of "some day" projects. I think
this is an interesting enough idea, and one that would be immediately
useful, that if I put it out there someone somewhere might be able to
make it a reality.
Any takers? I've set up a Google Group for further discussion, please
join if interested.
^ permalink raw reply
* Re: C# Git Implementation
From: Asheesh Laroia @ 2008-11-29 18:08 UTC (permalink / raw)
To: JD Guzman; +Cc: git
In-Reply-To: <001501c9515e$66e8ac70$34ba0550$@com>
On Fri, 28 Nov 2008, JD Guzman wrote:
> I read in the archives that there was once talk of porting Git over to
> C# and was wondering if anything ever came of this? I realize there
> were some that didn't see the use for this but as Git is becoming more
> and more popular a more native implementation of Git for windows users
> would be a good endevour IMHO.
Is it possible to compile the Java-language jgit with the Common Language
Runtime and access that from a C# application?
-- Asheesh.
--
Your talents will be recognized and suitably rewarded.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: add patch view
From: Sverre Rabbelier @ 2008-11-29 16:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811290848j1b77fe89m66ead7cc4f5ca2bb@mail.gmail.com>
On Sat, Nov 29, 2008 at 17:48, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> Also, I was in doubt about the name for the new view, and I did
> consider 'patchset' (which you mention in your email). I chose to
> stick with the shorter form in the end, since many people complain
> that gitweb already produces paths that are too long.
Heh, what do I care about the length of the url, there's so many url
shorteners out there, that's not really a problem to me :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* more merge strategies : feature request
From: Caleb Cushing @ 2008-11-29 16:48 UTC (permalink / raw)
To: git
conflict: this strategy would always resolve in a merge conflict
allowing you to use git mergetool to piece the files back together.
no-overwrite: if a change from the branch being merged in would
overwrite something in the current branch don't merge it. (I think it
needs a better name)
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-11-29 16:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: sverre, git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811291710.27891.jnareb@gmail.com>
Wow, I honestly didn't expect this idea to be so successful. I thought
I was the only one using gitweb to send patches around, honestly 8-D
On Sat, Nov 29, 2008 at 5:10 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 29 Nov 2008, Sverre Rabbelier wrote:
>>
>> If this does what I think it does I would be very happy with this
>> feature :). Only yesterday I wanted to link someone to a patch I put
>> up on repo.or.cz, but instead ended up telling them to download the
>> snapshot.
>
> True. 'commitdiff_plain' wasn't good enough; what's more it suffers
> from the same ambiguity as 'commitdiff', i.e. it is both means to
> show diff _for_ a commit (perhaps selecting one of parents), and
> showing diff _between_ two commits; the new 'patch' always shows
> diff for a commit, or for a series of commits.
Maybe commitdiff should me renamed to just be 'diff'.
Also, I was in doubt about the name for the new view, and I did
consider 'patchset' (which you mention in your email). I chose to
stick with the shorter form in the end, since many people complain
that gitweb already produces paths that are too long.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: add patch view
From: Jakub Narebski @ 2008-11-29 16:10 UTC (permalink / raw)
To: sverre; +Cc: Giuseppe Bilotta, git, Petr Baudis, Junio C Hamano
In-Reply-To: <bd6139dc0811290743s6cf8e534nddd8a09698ea22b9@mail.gmail.com>
On Sat, 29 Nov 2008, Sverre Rabbelier wrote:
> On Sat, Nov 29, 2008 at 14:41, Giuseppe Bilotta
> <giuseppe.bilotta@gmail.com> wrote:
> > Trying to use 'commitdiff_plain' output as input to git am results in
> > some annoying results such as doubled subject lines. We thus offer a new
> > 'patch' view that exposes format-patch output directly. This makes it
> > easier to offer patches by linking to gitweb repositories.
>
> If this does what I think it does I would be very happy with this
> feature :). Only yesterday I wanted to link someone to a patch I put
> up on repo.or.cz, but instead ended up telling them to download the
> snapshot.
True. 'commitdiff_plain' wasn't good enough; what's more it suffers
from the same ambiguity as 'commitdiff', i.e. it is both means to
show diff _for_ a commit (perhaps selecting one of parents), and
showing diff _between_ two commits; the new 'patch' always shows
diff for a commit, or for a series of commits.
>
> As an additional feature request; would it be possible to have a view
> that exposes a patch that is directly applyable by the patch command?
Both new 'patch' ('patchset') and old 'blobdiff_plain' should be
directly applicable by patch and by git-apply.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: add patch view
From: Sverre Rabbelier @ 2008-11-29 15:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis, Junio C Hamano
In-Reply-To: <1227966071-11104-2-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, Nov 29, 2008 at 14:41, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> Trying to use 'commitdiff_plain' output as input to git am results in
> some annoying results such as doubled subject lines. We thus offer a new
> 'patch' view that exposes format-patch output directly. This makes it
> easier to offer patches by linking to gitweb repositories.
If this does what I think it does I would be very happy with this
feature :). Only yesterday I wanted to link someone to a patch I put
up on repo.or.cz, but instead ended up telling them to download the
snapshot.
As an additional feature request; would it be possible to have a view
that exposes a patch that is directly applyable by the patch command?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/3] git add --intent-to-add: fix removal of cached emptiness
From: Sverre Rabbelier @ 2008-11-29 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <7vprkf2nki.fsf_-_@gitster.siamese.dyndns.org>
On Sat, Nov 29, 2008 at 04:55, Junio C Hamano <gitster@pobox.com> wrote:
> This uses the extended index flag mechanism introduced earlier to mark
> the entries added to the index via "git add -N" with CE_INTENT_TO_ADD.
Is 'intent' [0] used properly here? Should it not be 'intend' [1]?
[0] http://en.wiktionary.org/wiki/intent
[1] http://en.wiktionary.org/wiki/intend
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: C# Git Implementation
From: Andreas Ericsson @ 2008-11-29 13:44 UTC (permalink / raw)
To: JD Guzman; +Cc: git
In-Reply-To: <001501c9515e$66e8ac70$34ba0550$@com>
JD Guzman wrote:
> Hello I am new to the list and if I am not following some kind of list
> ettiquite please let me know.
>
> I read in the archives that there was once talk of porting Git over to C#
> and was wondering if anything ever came of this?
That depends. I think it's happened at least on three different occasions
that someone wants to port git to C#. The latest is the attempt to write a
libified git (in C) that will be DllImport()'ed from C#, which the devs at
MonoDevelop were sort of interested in. I'm currently working (very slowly)
on libgit2, and it's nowhere near usable today.
> I realize there were some
> that didn't see the use for this but as Git is becoming more and more
> popular a more native implementation of Git for windows users would be a
> good endevour IMHO.
>
Truly. However, a better way forward is to create a portable git library
that any old application can use, no matter what language the application
is written in. That way, GUI-hackers can add all the bells and whistles
they like.
Besides that, msysgit works very well on Windows.
> At any rate any info would be greatly appreciated.
>
libgit2 is available from
http://www.spearce.org/projects/scm/libgit2/libgit2.git
git://git.op5.org/git/libgit2.git
The first URL belongs to Shawn O. Pearce, the initiator of the libgit2
project. The second one is where I stash random stuff that I work on.
Note that git.op5.org is subject to heavy rebasing at the moment, as I'm
basically using it as a patch queue for Shawn (and everyone else who's
interested) to look at when they feel like it. It's not yet interesting
enough to warrant sending everything as patches to git@vger, but a small
bunch of people are helping making the small internal API's reliably
portable (filesystem operations, thread-local error handling) so that
we can nail them down hard to prevent having to change them (and their
hundreds of callers) in the future.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-11-29 13:41 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227966071-11104-1-git-send-email-giuseppe.bilotta@gmail.com>
Trying to use 'commitdiff_plain' output as input to git am results in
some annoying results such as doubled subject lines. We thus offer a new
'patch' view that exposes format-patch output directly. This makes it
easier to offer patches by linking to gitweb repositories.
---
gitweb/gitweb.perl | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..befe6b6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -485,6 +485,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5465,7 +5466,11 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ open $fd, "-|", git_cmd(), "format-patch", '--stdout',
+ $hash_parent ? "$hash_parent..$hash" :
+ ('--root', '-1', $hash)
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5514,6 +5519,14 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
}
# write patch
@@ -5535,6 +5548,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5542,6 +5560,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/2] gitweb: links to patch action in commitdiff and shortlog view
From: Giuseppe Bilotta @ 2008-11-29 13:41 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227966071-11104-2-git-send-email-giuseppe.bilotta@gmail.com>
The link from commitdiff view is an obviously needed one, but we also
offer the option to link to the patchset in shortlog view, when there
are less than 15 commits being shown.
---
gitweb/gitweb.perl | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index befe6b6..5b18fdf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5382,7 +5382,9 @@ sub git_commitdiff {
if ($format eq 'html') {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
- "raw");
+ "raw") . " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5915,6 +5917,12 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ # TODO this should be configurable
+ if ($#commitlist <= 15) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ $#commitlist > 1 ? "patchset" : "patch");
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] gitweb: patch view
From: Giuseppe Bilotta @ 2008-11-29 13:41 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
I recently discovered that the commitdiff_plain view is not exactly
something that can be used by git am directly (for example, the subject
line gets duplicated in the commit message body after using git am).
Since I'm not sure if it was the case to fix the plain view because I
don't know what its intended usage was, I prepared a new view,
uncreatively called 'patch', that exposes git format-patch output
directly.
The second patch exposes it from commitdiff view (obviosly), but also
from shortlog view, when less than 16 patches are begin shown.
Giuseppe Bilotta (2):
gitweb: add patch view
gitweb: links to patch action in commitdiff and shortlog view
gitweb/gitweb.perl | 35 +++++++++++++++++++++++++++++++++--
1 files changed, 33 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-11-29 13:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0811281938250.19665@iabervon.org>
On 11/29/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Fri, 28 Nov 2008, Junio C Hamano wrote:
>
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > ...
> > >> In other words, unless there is more interest in that feature, enough to
> > >> generate a well-understood design before a good implementation, I'd rather
> > >> see this patch series dropped.
> > >
> > > Ack. I agree with every remark made by Dscho, and also want to cry "wolf".
> > >
> > > I haven't had time to read the patch series. Its big and intrusive
> > > and I just don't need the feature.
> >
> > Well, "me neither". Although I personally think resisting changes until
> > it becomes absolutely necessary is a good discipline, we also need to
> > recognise that there is a chicken-and-egg problem. When you have a
> > potentially useful feature, unless people actually try using it in the
> > field, you won't discover the drawbacks in either the design nor the
> > implementation, let alone any improvements.
>
>
> I just looked over most of it (skipping the generic index extension
> portion). It looks to me like it's introducing an extra concept to avoid
> actually fixing maybe-bugs in the "assume unchanged" implementation
> when used with files that have been changed intentionally (with the user
> intending git to overlook this change). Sparse checkout is essentially a
> special case of this, where the user has changed the working directory
> radically (not populating it at all) and wants git to carry on as if this
> was not the case (with a certain amount of porcelain code to cause this to
> happen automatically).
I chose to use another bit because I did not want to change the
behaviour of CE_VALID bit: it assumes all files are present.
> If there's any need for this to be distinguished from "assume unchanged",
> I think it should be used with, not instead of, the CE_VALID bit; and it
> could probably use some bit in the stat info section, since we don't need
> stat info if we know by assumption that the entry is valid.
Interesting. I'll think more about this.
> -Daniel
> *This .sig left intentionally blank*
>
> --
> 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
>
--
Duy
^ permalink raw reply
* Re: [JGIT PATCH 0/4] RepositoryTestCase cleanups
From: Robin Rosenberg @ 2008-11-29 12:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, fonseca
In-Reply-To: <20081127214916.GD23984@spearce.org>
torsdag 27 november 2008 22:49:16 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > Ok, so here is an attempt to improve the ability of the JGit's unit
> > tests to delete temporary repositories. This has probably been seen
> > by many, but Jonas Fonseca raised the issue.
>
> Hmpph. This takes 19 seconds to run the suite, where it used to be
> only 2 seconds on the same system. The slower run isn't something
> I'm too happy about, actually I'd like to make the run even faster
> than 2 seconds.
So maybe we should clean up less. Every new test repo we create has
a new name so we could do without cleaning up so much. The cleanup
however is a verification that we close (and can close) our resources,
though it only works on Windows :/ On unix we could spawn lsof but that
is really really slow.
> If the issue is mmap'd files, why don't we instead disable mmap
> on Windows during JUnit tests, and use the non-mmap variant of
> pack access? At least do that for the bulk of the tests, and
> then have a single test case which tests the mmap code path but
> has careful System.gc calls in place to try and ensure we can
> actually clean up the temporary files.
We would then need some other really slow test to play rough with
memory mapping and gc. As I mentioned above it is actually about
closing resources in general, mmapped files being an especially
nasty case.
> I'd actually like to get that Repository refactoring done soon,
> someone else was asking about it for the RefDatabase (to store the
> refs in a SQL database so JGit ties into JTA) but I may also want
> it for Gerrit 2 - I'm looking at doing something that would put
> 200,000 refs per year into a repository. That's so large that
> most operations can't afford to scan the entire ref database,
> and it really cannot be loose. ;-)
Would be cool, but having that diff engine is more important to me.
>
>
> Refactoring repository is a fair chunk of work, disabling the mmap
> feature under Windows in JUnit may be easier. Hmm, according to
> WindowCache's <clinit> its default by false. Why is it enabling
> on Windows? The only code that calls WindowCache.reconfigure()
> is in the Eclipse plugin, so pure JGit unit tests shouldn't be
> turning on mmap code *at all*.
>
> Which also points out a gap in our tests. Nothing new, we have
> lots of gaps. *sigh*
Yep. :/
-- robin
^ permalink raw reply
* [PATCHv2ter 2/2] gitweb: clean up gitweb_check_feature() calls
From: Giuseppe Bilotta @ 2008-11-29 11:53 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227904793-1821-3-git-send-email-giuseppe.bilotta@gmail.com>
Since gitweb_check_feature now returns a scalar, the parentheses around
the variables initialized from gitweb_check_feature() are not needed.
We remove them for stylistic consistency and to prevent unnecessary
ambiguity in the code.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Third attempt, hopefully I got the commit message right, finally 8-P
gitweb/gitweb.perl | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 128d7ad..b0d00ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -828,7 +828,7 @@ sub href (%) {
}
}
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
@@ -2119,7 +2119,7 @@ sub git_get_projects_list {
$filter ||= '';
$filter =~ s/\.git$//;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
@@ -2965,7 +2965,7 @@ EOF
}
print "</div>\n";
- my ($have_search) = gitweb_check_feature('search');
+ my $have_search = gitweb_check_feature('search');
if (defined $project && $have_search) {
if (!defined $searchtext) {
$searchtext = "";
@@ -2979,7 +2979,7 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
$action .= "/".esc_url($project);
}
@@ -3472,7 +3472,7 @@ sub is_patch_split {
sub git_difftree_body {
my ($difftree, $hash, @parents) = @_;
my ($parent) = $parents[0];
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
print(($#{$difftree} + 1) . " files changed:\n");
@@ -3986,7 +3986,7 @@ sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
my @projects = fill_project_list_info($projlist, $check_forks);
$order ||= $default_projects_order;
@@ -4446,7 +4446,7 @@ sub git_summary {
my @taglist = git_get_tags_list(16);
my @headlist = git_get_heads_list(16);
my @forklist;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if ($check_forks) {
@forklist = git_get_projects_list($project);
@@ -4475,7 +4475,7 @@ sub git_summary {
}
# Tag cloud
- my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
@@ -4765,7 +4765,7 @@ sub git_blob {
$expires = "+1d";
}
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(500, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -4858,7 +4858,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5856,7 +5856,7 @@ insensitive).</p>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
- my ($have_grep) = gitweb_check_feature('grep');
+ my $have_grep = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
@@ -5873,7 +5873,7 @@ EOT
<dt><b>committer</b></dt>
<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
- my ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ my $have_pickaxe = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
print <<EOT;
<dt><b>pickaxe</b></dt>
@@ -5925,7 +5925,7 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
# RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCHv2 2/2] gitweb: clean up gitweb_check_feature() calls
From: Jakub Narebski @ 2008-11-29 11:18 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1227957301-7417-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> Since git_check_feature now returns a scalar, the parentheses around the
^^^
\---- missed one.
> variables initialized from gitweb_check_feature() are not needed.
>
> We remove them for stylistic consistency and to prevent unnecessary
> ambiguity in the code.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>
> Fixed the commit message, use this instead of the previous one.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCHv2 2/2] gitweb: clean up gitweb_check_feature() calls
From: Giuseppe Bilotta @ 2008-11-29 11:15 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227904793-1821-3-git-send-email-giuseppe.bilotta@gmail.com>
Since git_check_feature now returns a scalar, the parentheses around the
variables initialized from gitweb_check_feature() are not needed.
We remove them for stylistic consistency and to prevent unnecessary
ambiguity in the code.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Fixed the commit message, use this instead of the previous one.
gitweb/gitweb.perl | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 128d7ad..b0d00ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -828,7 +828,7 @@ sub href (%) {
}
}
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
@@ -2119,7 +2119,7 @@ sub git_get_projects_list {
$filter ||= '';
$filter =~ s/\.git$//;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
@@ -2965,7 +2965,7 @@ EOF
}
print "</div>\n";
- my ($have_search) = gitweb_check_feature('search');
+ my $have_search = gitweb_check_feature('search');
if (defined $project && $have_search) {
if (!defined $searchtext) {
$searchtext = "";
@@ -2979,7 +2979,7 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
$action .= "/".esc_url($project);
}
@@ -3472,7 +3472,7 @@ sub is_patch_split {
sub git_difftree_body {
my ($difftree, $hash, @parents) = @_;
my ($parent) = $parents[0];
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
print(($#{$difftree} + 1) . " files changed:\n");
@@ -3986,7 +3986,7 @@ sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
my @projects = fill_project_list_info($projlist, $check_forks);
$order ||= $default_projects_order;
@@ -4446,7 +4446,7 @@ sub git_summary {
my @taglist = git_get_tags_list(16);
my @headlist = git_get_heads_list(16);
my @forklist;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if ($check_forks) {
@forklist = git_get_projects_list($project);
@@ -4475,7 +4475,7 @@ sub git_summary {
}
# Tag cloud
- my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
@@ -4765,7 +4765,7 @@ sub git_blob {
$expires = "+1d";
}
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(500, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -4858,7 +4858,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5856,7 +5856,7 @@ insensitive).</p>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
- my ($have_grep) = gitweb_check_feature('grep');
+ my $have_grep = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
@@ -5873,7 +5873,7 @@ EOT
<dt><b>committer</b></dt>
<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
- my ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ my $have_pickaxe = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
print <<EOT;
<dt><b>pickaxe</b></dt>
@@ -5925,7 +5925,7 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
# RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCHv2 0/2] fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-29 11:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811291148.15182.jnareb@gmail.com>
2008/11/29 Jakub Narebski <jnareb@gmail.com>:
> Dnia piątek 28. listopada 2008 21:39, Giuseppe Bilotta napisał:
>> The first patch introduces git_get_feature() to clearly distinguish the
>> feature retrieval from the boolean feature check (which is kept at
>> git_check_feature()). The new function is used where appropriate.
> It is gitweb_get_feature() (for retrieval) and gitweb_check_feature()
> (for checking), not git_get_feature() and git_check_feature().
Ahem. Right. I'll resend the second patch with a fixed subject and
commit message 8-P
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv2 0/2] fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-29 10:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1227904793-1821-1-git-send-email-giuseppe.bilotta@gmail.com>
Dnia piątek 28. listopada 2008 21:39, Giuseppe Bilotta napisał:
> This is v2 of the gitweb feature check fix patch, which has now been
> split into into a code patch and cleanup patch.
>
> The first patch introduces git_get_feature() to clearly distinguish the
> feature retrieval from the boolean feature check (which is kept at
> git_check_feature()). The new function is used where appropriate.
>
> The second patch cleans up use of git_check_feature(): since the
> function now returns a boolean instead of an array, the often-used
> construct
> my ($somevar) = git_check_feature('somefeat');
> although still valid, becomes a rather clumsy stylistic choice, as it
> introduces an unnecessary ambiguity. Make it clear that we're now
> dealing with scalars by using scalar assignment.
It is gitweb_get_feature() (for retrieval) and gitweb_check_feature()
(for checking), not git_get_feature() and git_check_feature().
I really like this series; making coding easier by removing need to
use special construct, and making it easier to avoid mistakes is always
a good thing.
> Giuseppe Bilotta (2):
> gitweb: fixes to gitweb feature check code
> gitweb: clean up git_check_feature() calls
>
> gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 35 insertions(+), 17 deletions(-)
I also like the split, as it separates improvement (much easier to use
and less error prone gitweb_check_feature()) from style cleanup.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: timestamps not git-cloned
From: Thomas Rast @ 2008-11-29 10:16 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Chris Frey, jidanni, dhruvakm, git
In-Reply-To: <20081129092231.GA32630@cuci.nl>
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]
Stephen R. van den Berg wrote:
> Chris Frey wrote:
> >If this is the important bit, perhaps git-archive could be changed
> >to create tarballs with file timestamps based on their commit dates.
>
> Based on the principle of least surprise, I'd consider this a rather good
> idea.
Unless I'm missing something, this would make git-archive rather more
expensive than it is now: Tree objects do not record any timestamps,
so figuring out the last commit that changed a file requires a full
history walk in the worst case[*]. (This is another side-effect of
not versioning files.) On the other hand, current git-archive's
running time depends only on the size of the tree-ish given, including
all subtrees and blobs.
My unscientific guesstimates on how much work this would be, in a
random (old) linux-2.6 clone:
$ git rev-parse HEAD
e013e13bf605b9e6b702adffbe2853cfc60e7806
$ time git ls-tree -r -t $(git rev-list HEAD~5000..HEAD) >/dev/null
real 0m1.385s
user 0m1.164s
sys 0m0.220s
$ git rev-list HEAD | wc -l
117812
So reading (and dumping) all those trees and subtrees incurs a penalty
on the order of 30 seconds. Compare to the current running time of
git-archive:
$ time git archive --format=tar HEAD >/dev/null
real 0m2.790s
user 0m2.684s
sys 0m0.072s
Of course, the ratio will keep getting worse as history gets longer.
- Thomas
[*] I think to really have a "worst case" here, you need at least one
file in every leaf directory that has not changed since the root
commit, and another that changes in every commit to force the search
to really read every subtree.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: timestamps not git-cloned
From: Stephen R. van den Berg @ 2008-11-29 9:22 UTC (permalink / raw)
To: Chris Frey; +Cc: jidanni, dhruvakm, git
In-Reply-To: <20081129085406.GA20428@foursquare.net>
Chris Frey wrote:
>On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:
>> I hate it when I get some latest WhizBang.tgz, only to untar it to
>> find all the files' dates the same, when in fact the README hasn't
>> been touched in seven years, but you can't tell that from ls -l. I
>> recall some content tracker was involved.
>If this is the important bit, perhaps git-archive could be changed
>to create tarballs with file timestamps based on their commit dates.
Based on the principle of least surprise, I'd consider this a rather good
idea.
--
Sincerely,
Stephen R. van den Berg.
To people that say "I could care less" - well, why don't you?
^ permalink raw reply
* Re: timestamps not git-cloned
From: Chris Frey @ 2008-11-29 8:54 UTC (permalink / raw)
To: jidanni; +Cc: dhruvakm, git
In-Reply-To: <87tz9sv3rb.fsf@jidanni.org>
On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:
> I hate it when I get some latest WhizBang.tgz, only to untar it to
> find all the files' dates the same, when in fact the README hasn't
> been touched in seven years, but you can't tell that from ls -l. I
> recall some content tracker was involved.
If this is the important bit, perhaps git-archive could be changed
to create tarballs with file timestamps based on their commit dates.
- Chris
^ 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