* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 0:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605021659430.4086@g5.osdl.org>
On Tue, 2 May 2006, Linus Torvalds wrote:
>
> Ie not a separate menu, but having the current "view" radio buttons be
> more flexible.
The obvious way to do it would be to just have two buttons per view: one
exclusive one (for the main view - only one selected at a time), and the
other one for the "highlight" one where you could allow multiple views to
be selected for highlighting.
Linus
^ permalink raw reply
* Re: gitk highlight feature
From: Paul Mackerras @ 2006-05-03 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejzcj8da.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Eh, the string entered by me is quoted by the program, or do I
> have to quote it myself? I suspect it should not be so bad to
> code, even if you have to do it with tcl ;-).
It's split up into arguments at whitespace unless the whitespace is
quoted, just like the shell does. I wrote tcl code to do the
splitting and quoting according to the shell rules. So you can, for
example, put:
--unpacked --since='2 days ago'
in there and it will pass two arguments to git-rev-list, the second
containing the embedded spaces (but without the single-quotes).
Paul.
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-03 0:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17495.61142.677439.171773@cargo.ozlabs.ibm.com>
On Wed, 3 May 2006, Paul Mackerras wrote:
>
> I just pushed out some changes to gitk which allow you to use one view
> to highlight another (see the "Highlight" submenu under the "View"
> menu), and which allow you to specify arbitrary git-rev-list arguments
> for a view. The arguments string uses shell quoting conventions.
Ok. It looks interesting. I don't have a particular issue to try it with,
but the bold-face certainly stands out enough that it was easy to ask for
a high-light of any commits that changed the kernel/ subdirectory, and it
was visually very obvious.
The interface does feel a bit awkward, though. Separating out "view" and
"highlight" into two separate things seems wrong. Wouldn't it be better to
just have multiple views in the "view" menu, and just a way to mark one or
more of them as "highliht views".
Ie not a separate menu, but having the current "view" radio buttons be
more flexible.
> I had been thinking of having fields in the view editor dialog where
> you could put in refs that you did and didn't want included, date
> specifiers, etc., all in separate fields with suitable labels. Now
> I'm thinking that it's probably just as convenient to put
> "ORIG_HEAD.." into the git-rev-list arguments field as it is to put
> "ORIG_HEAD" in the "Don't include commits reachable from this" field.
Yeah. I think it's easier with a single thing, just let people stick it
there.
> There may be an argument for having fields for "Exclude commits before
> this date" and "Exclude commits after this date", because those things
> often have spaces in them (e.g. "2 weeks ago") which would have to be
> quoted in the git-rev-list arguments field.
I alwaus use "2.weeks.ago" instead, but I guess you could do a calendar
widget or something.
Linus
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-03 0:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vbqugks8j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Tue, 2 May 2006, Junio C Hamano wrote:
>>>
>>> - The shell-script one, if you use GNU grep, accepts more
>>> options to grep than what the current built-in one supports.
>>> Notable ones that are missing: fixed strings (-F), patterns
>>> from file (-f), count matches (-c), omit filenames (-h),
>>> skipping binary files (-I, -U), files without match (-L),
>>> pcre (-P), silent (-q), word expression (-w), NUL (-z). They
>>> should be easy to add if somebody cares enough, and I plan to
>>> do a few myself before pushing it out to "master".
>>
>> I use "-w" all the time, along with -5 or similar to get context for the
>> grep.
>
> Noted; -w is missing; -A/-B/-C are already there so you could
> say -C 5 instead, and -<n> should be easy to add.
I did both -<n> and -w, and pushed it out in "next".
What we have:
-<n>, -[ABC] <n> (and -[ABC]<n>)
-E
-G
-H (but it is an no-op -- we always show name)
-c
-e (you can do multiple patterns now)
-i
-n
-v
-w
-l
What are still missing:
-I (easy)
-L (probably a bit intrusive)
-P (code is easy -- deciding dependency on pcre is OK is harder)
-U (probably not so easy but may be useful)
-Z (probably easy but is it useful?)
-q (may not be worth doing)
-z (easy but pointless)
-F (dunno)
-f (with the enhancement to do multiple -e, trivial to add this)
^ permalink raw reply
* Re: Features ask for git-send-email
From: Bertrand Jacquin @ 2006-05-02 23:51 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1146612793.19101.50.camel@pmac.infradead.org>
On 5/3/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2006-05-03 at 00:46 +0200, Bertrand Jacquin wrote:
> > I tryed it. I used this patch again master git git release
> >
> > And I got the following with git-send-email :
> >
> > Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> > Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> > <>: missing or malformed local part
>
> Interesting; it worked for me. Does the same happen _without_ the patch
> applied?
It appear without in 1.3.1 and I can't seed mail with too.
Also, 1.2.4 work fine here (without patch).
I don't make any test for other version (too tired for now).
I use exim 4.60 as SMTP server (if it can help).
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: gitk highlight feature
From: Junio C Hamano @ 2006-05-02 23:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17495.61142.677439.171773@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> I just pushed out some changes to gitk which allow you to use one view
> to highlight another (see the "Highlight" submenu under the "View"
> menu), and which allow you to specify arbitrary git-rev-list arguments
> for a view. The arguments string uses shell quoting conventions.
Eh, the string entered by me is quoted by the program, or do I
have to quote it myself? I suspect it should not be so bad to
code, even if you have to do it with tcl ;-).
> I had been thinking of having fields in the view editor dialog where
> you could put in refs that you did and didn't want included, date
> specifiers, etc., all in separate fields with suitable labels. Now
> I'm thinking that it's probably just as convenient to put
> "ORIG_HEAD.." into the git-rev-list arguments field as it is to put
> "ORIG_HEAD" in the "Don't include commits reachable from this" field.
> There may be an argument for having fields for "Exclude commits before
> this date" and "Exclude commits after this date", because those things
> often have spaces in them (e.g. "2 weeks ago") which would have to be
> quoted in the git-rev-list arguments field.
>
> Thoughts?
Calendar widgets. BTW, "rev-list --since=2.days.ago" would work
rather well ;-).
^ permalink raw reply
* gitk highlight feature
From: Paul Mackerras @ 2006-05-02 23:44 UTC (permalink / raw)
To: git; +Cc: torvalds
I just pushed out some changes to gitk which allow you to use one view
to highlight another (see the "Highlight" submenu under the "View"
menu), and which allow you to specify arbitrary git-rev-list arguments
for a view. The arguments string uses shell quoting conventions.
I had been thinking of having fields in the view editor dialog where
you could put in refs that you did and didn't want included, date
specifiers, etc., all in separate fields with suitable labels. Now
I'm thinking that it's probably just as convenient to put
"ORIG_HEAD.." into the git-rev-list arguments field as it is to put
"ORIG_HEAD" in the "Don't include commits reachable from this" field.
There may be an argument for having fields for "Exclude commits before
this date" and "Exclude commits after this date", because those things
often have spaces in them (e.g. "2 weeks ago") which would have to be
quoted in the git-rev-list arguments field.
Thoughts?
Paul.
^ permalink raw reply
* Re: [ANNOUNCE] Git wiki
From: Junio C Hamano @ 2006-05-02 23:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060502232553.GL27689@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm personally not exceptionally fond of wikis (other than Wikipedia)
> but a wish to have one has been expressed several times and I hope it
> will be helpful for the Git community; not only the newbies might dig
> (and especially exchange!) some useful information, tips'n'trick and
> such. Ideally, it could become a melting pot for the Documentation/
> directories or the rather austere (I take patches) Git homepage - or
> something entirely different. Whatever _you_ make from it.
Thanks for doing this. I am not a Wiki person myself, and
would rather want to see we have useful and authoritative bits
in the Documentation set, but this would help the community.
I'd love to see somebody volunteer to act as an editor to feed
cooked topics for inclusion of the Documentation/ set. Anybody?
^ permalink raw reply
* Re: Features ask for git-send-email
From: David Woodhouse @ 2006-05-02 23:33 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Git Mailing List
In-Reply-To: <4fb292fa0605021546i45c740c4i42c64125b8c560e@mail.gmail.com>
On Wed, 2006-05-03 at 00:46 +0200, Bertrand Jacquin wrote:
> I tryed it. I used this patch again master git git release
>
> And I got the following with git-send-email :
>
> Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
> <>: missing or malformed local part
Interesting; it worked for me. Does the same happen _without_ the patch
applied?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] repo-config: support --get-regexp and fix crash
From: Junio C Hamano @ 2006-05-02 23:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605021422150.7051@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Junio made me aware of a crash, a fix for which was too easy to
> merit a separate patch.
Not really. The fix is clean-and-obvious, and is readily
applicable to "master" without being cooked in "next". On the
other hand, --get-regexp may or may not be so; by conflating the
two, you are delaying the trivial and useful fix unnecessarily.
I already split the patch and applied the fix on "master", while
keeping the rest in "pu" (sorry, I ran out of patience to test
everything to put it in "next" -- will do so tomorrow).
It is usually a good idea to avoid making an otherwise good
clean patch a hostage to new features (intentionally or
accidentally).
> Strange thing I realized: A value is white-space-trimmed at the end
> only if the line does not end with a comment. This fact is accounted
> for in the new tests.
Thanks - a note like this helps me quite a bit, because I
usually apply e-mailed patches with --whitespace=strip, which
would have destroyed the test, leaving me scratching my head
without such a notice.
^ permalink raw reply
* Re: [PATCH] cache-tree: replace a sscanf() by two strtol() calls
From: Junio C Hamano @ 2006-05-02 23:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605020327400.31493@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On one of my systems, sscanf() first calls strlen() on the buffer. But
> this buffer is not terminated by NUL. So git crashed.
Interesting.
"git grep sscanf next -- '*.c'" reports handful sscanf() there.
Most of them scan argv[], which are NUL terminated, so they
should be OK. The rest in convert-objects.c, tree-walk.c, and
tree.c all scan the mode bits in tree objects, which will later
have the pathname component terminated with NUL, so that would
also be OK.
But I think your patch is wrong, and makes it ignore cache-tree
structure; I suspect you have two off-by-one errors and are
making buf and size out of sync.
> Maybe, a better solution would be to store the integers in
> binary form. But I am not familiar with that part of git, and
> further, it would break setups which already have an index
> with cache-tree information.
In theory, it is stashed in the extension section of index so we
could define a new extension type, say "TRE2" and store the
information in the new format. But this is purely a cache used
as optimiation, so we could just say, "make sure to save local
modifications before doing an update, then run 'rm .git/index &&
git-read-tree HEAD' please".
I've applied a fixed up one, but I am actually thinking about
ripping out the whole cache-tree thing and redoing it all in the
index.
Currently the index stores set of blobs after flattening the
hierarchical tree structure, losing the original "tree"
information. We could instead store something that looks like
"ls-tree -t -r" output (plus the toplevel tree information which
"ls-tree -t -r" does not give you). Just like an update-index
on the path t/t0000-basic.sh invalidates the cache-tree entry
for "" and "t/", we could either invalidate or recompute (I am
inclined to do the former to make things lazy) these "tree"
entries in the index. This would be more direct way to store
what I am storing in the cache-tree.
Keeping the object names of unchanged subtrees available will
allow us to walk the index and a tree (or two or more trees) in
parallel in various applications. "diff-index --cached" and
"read-tree -m" extract one entry from tree and index for each
blob, but when we have an up-to-date information for a subtree
in the index, and when that subtree matches the corresponding
subtree in the tree object diff-index or read-tree is reading,
the application can short-cut without reading anything in the
subtree.
^ permalink raw reply
* [PATCH] gitweb: Add shorthand URLs for summary and a special html branch
From: Martin Waitz @ 2006-05-02 23:25 UTC (permalink / raw)
To: git
gitweb now supports URLs like .../gitweb.cgi/<projectpath> as a shortcut
for the project summary page and .../gitweb.cgi/<projectpath>/<file.html>
to access .html pages in an "html" branch.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
gitweb.cgi | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 56 insertions(+), 4 deletions(-)
05d0376478ccc273d12dbe177cf11c62c86ab848
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..959ca3e 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -20,6 +20,7 @@ my $cgi = new CGI;
my $version = "264";
my $my_url = $cgi->url();
my $my_uri = $cgi->url(-absolute => 1);
+my $my_path = $cgi->url(-path => 1);
my $rss_link = "";
# absolute fs-path which will be prepended to the project path
@@ -42,8 +43,30 @@ # source of projects list
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+
+my ($action, $project, $file_name, $hash);
+
+# rewrite to support direct access to .html files in the "html" branch
+if ($my_path =~ /^$my_url\/(.*\.git)\/?$/) {
+ $action = "summary";
+ $project = validate_input($1);
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(.*\.html)$/) {
+ $action = "blob_html";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+ $hash = "html:$file_name";
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(HEAD|objects\/info\/packs|info\/refs|refs\/.*)$/) {
+ $action = "direct_text";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+} elsif ($my_path =~ /^$my_url\/(.*\.git)\/(objects\/.*)$/) {
+ $action = "direct_object";
+ $project = validate_input($1);
+ $file_name = validate_input($2);
+}
+
# input validation and dispatch
-my $action = $cgi->param('a');
+$action ||= $cgi->param('a');
if (defined $action) {
if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
undef $action;
@@ -66,7 +89,7 @@ if (defined $order) {
}
}
-my $project = $cgi->param('p');
+$project ||= $cgi->param('p');
if (defined $project) {
$project = validate_input($project);
if (!defined($project)) {
@@ -88,7 +111,7 @@ if (defined $project) {
exit;
}
-my $file_name = $cgi->param('f');
+$file_name ||= $cgi->param('f');
if (defined $file_name) {
$file_name = validate_input($file_name);
if (!defined($file_name)) {
@@ -96,7 +119,7 @@ if (defined $file_name) {
}
}
-my $hash = $cgi->param('h');
+$hash ||= $cgi->param('h');
if (defined $hash) {
$hash = validate_input($hash);
if (!defined($hash)) {
@@ -167,6 +190,9 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "blob_plain") {
git_blob_plain();
exit;
+} elsif ($action eq "blob_html") {
+ git_blob_html();
+ exit;
} elsif ($action eq "tree") {
git_tree();
exit;
@@ -203,6 +229,10 @@ if (!defined $action || $action eq "summ
} elsif ($action eq "tag") {
git_tag();
exit;
+} elsif ($action eq "direct_text") {
+ git_direct_text();
+} elsif ($action eq "direct_object") {
+ git_direct_object();
} else {
undef $action;
die_error(undef, "Unknown action.");
@@ -1423,6 +1453,28 @@ sub git_blob_plain {
close $fd;
}
+sub git_blob_html {
+ my $save_as = "$hash";
+ if (defined $file_name) {
+ $save_as = $file_name;
+ }
+ print $cgi->header(-type => "text/html", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
+ open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
+ undef $/;
+ print <$fd>;
+ $/ = "\n";
+ close $fd;
+}
+
+sub git_direct_text {
+ print $cgi->header(-type => "test/plain");
+ exec("cat", "$projectroot/$project/$file_name");
+}
+sub git_direct_object {
+ print $cgi->header(-type => "application/binary", -expires => "+1y");
+ exec("cat", "$projectroot/$project/$file_name");
+}
+
sub git_tree {
if (!defined $hash) {
$hash = git_read_head($project);
--
1.3.1.g6ef7
--
Martin Waitz
^ permalink raw reply related
* [ANNOUNCE] Git wiki
From: Petr Baudis @ 2006-05-02 23:25 UTC (permalink / raw)
To: git
Hi,
I have just set up a (fairly crude, but hey, it seems to work) wiki at
http://git.or.cz/gitwiki
It's slow and ugly but if it becomes popular, I will move it to
something better than Apache CGI. ;-) I also haven't written more than
an introductory paragraph on the front page, the rest is up to you.
I'm personally not exceptionally fond of wikis (other than Wikipedia)
but a wish to have one has been expressed several times and I hope it
will be helpful for the Git community; not only the newbies might dig
(and especially exchange!) some useful information, tips'n'trick and
such. Ideally, it could become a melting pot for the Documentation/
directories or the rather austere (I take patches) Git homepage - or
something entirely different. Whatever _you_ make from it.
Editally yours,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Linus Torvalds @ 2006-05-02 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqugks8j.fsf@assigned-by-dhcp.cox.net>
On Tue, 2 May 2006, Junio C Hamano wrote:
>
> On a related tangent, ever since I started using the built-in
> grep with ls-files like wildcard, I find myself typing something
> like this by mistake (this is from my day-job work project that
> has src/mx.js and src/mxstyle.css among other things):
>
> git diff 268a94 -- 'src/mx*'
>
> I am tempted to suggest switching pathspecs used by diff and log
> family to do the same wildcarding, perhaps after tightening the
> wildcard vs directory prefix logic used in the builtin-grep of
> the current "next" tip, which is a bit looser than necessary.
Yeah, the wildcarding is nice. You need to be very careful about it,
though, to make sure that you take full advantage of the path
component optimizations _before_ the wildcards, so that when you do
something like the above ('src/mx*'), you do the "src/" part with the
tree-level optimizations, and only the latter part with the pattern
matching (because you do _not_ want to expand the whole tree when you
don't want to).
That "ls-files.c" thing already does part of this (that whole "prefix_len"
thing for the "longest common prefix").
Linus
^ permalink raw reply
* Re: Features ask for git-send-email
From: Bertrand Jacquin @ 2006-05-02 22:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1146573417.14059.21.camel@pmac.infradead.org>
On 5/2/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sat, 2006-04-29 at 15:30 +0200, Bertrand Jacquin wrote:
> > Could it be possible to add a features in git-send-email.perl to
> > accept a differrent charset as iso-8859-1 ? I would like to send
> > fr_FR.utf8 mail as I use git to manager a latex files tree which are
> > written in utf8.
> >
> > Any objection ?
>
> Seems reasonable. I think we just forgot to include the Content-Type:
> header. This fixes it...
I tryed it. I used this patch again master git git release
And I got the following with git-send-email :
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
<>: missing or malformed local part
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
Use of uninitialized value in hash element at /usr/bin/git-send-email line 437.
<>: missing or malformed local part
And with my smtp server :
2006-05-03 00:44:01 unexpected disconnection while reading SMTP
command from localhost (localhost.localdomain) [127.0.0.1]
Is it a known bug ? I can't send mail with patch thow :/ I tried to
add Mime-Version: 1.0 too but I got the sam.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: cg-mkpatch use case
From: Petr Baudis @ 2006-05-02 22:34 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Belmar-Letelier, git
In-Reply-To: <46a038f90605021519x5ee680b0v78dd5c092e1b191f@mail.gmail.com>
Dear diary, on Wed, May 03, 2006 at 12:19:00AM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> >not many people actually use it nowadays, I believe. You can apply it
> >back using cg-patch (or even patch itself, or git-apply if you are
> >lucky), but it won't automagically extract the commit message and
> >authorship information.
>
> Erm... I don't personally use it, but cg-patch --long-help tells me...
>
> -c::
> Automatically extract the commit message and authorship information
> (if provided) from the patch and commit it after applying it
> successfuly.
>
> Truth in advertising? ;-)
Uhm, no, it just didn't stick in my mind in the storm of cg-patch
improvements. :-) Oops.
So, YES, there IS a way to apply cg-mkpatches preserving autorship and
everything - cg-patch -c. Sorry for the confusion. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: cg-mkpatch use case
From: Martin Langhoff @ 2006-05-02 22:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Belmar-Letelier, git
In-Reply-To: <20060502215703.GK27689@pasky.or.cz>
On 5/3/06, Petr Baudis <pasky@suse.cz> wrote:
> not many people actually use it nowadays, I believe. You can apply it
> back using cg-patch (or even patch itself, or git-apply if you are
> lucky), but it won't automagically extract the commit message and
> authorship information.
Erm... I don't personally use it, but cg-patch --long-help tells me...
-c::
Automatically extract the commit message and authorship information
(if provided) from the patch and commit it after applying it
successfuly.
Truth in advertising? ;-)
cheers,
martin
^ permalink raw reply
* Re: cg-mkpatch use case
From: Petr Baudis @ 2006-05-02 21:57 UTC (permalink / raw)
To: Belmar-Letelier; +Cc: git
In-Reply-To: <44570E8E.5070402@itaapy.com>
Hi,
Dear diary, on Tue, May 02, 2006 at 09:47:26AM CEST, I got a letter
where Belmar-Letelier <luis@itaapy.com> said that...
> I have 3 questions about cg-mkpatch
>
> 1. I've receive a file "xxx.patch", this content came from
> cg-mkpatch, but I can't apply it.
> For example if I try git-am I get::
>
> $ git-am --signoff xxx.patch
> Patch does not have a valid e-mail address.
>
> What is the Cogito way to apply the result of "cg-mkpatch"
cg-mkpatch is a very old tool which has been long neglected and
not many people actually use it nowadays, I believe. You can apply it
back using cg-patch (or even patch itself, or git-apply if you are
lucky), but it won't automagically extract the commit message and
authorship information.
> 2. What are the difference between usecases with "cg-mkpatch"
> and "git-format-patch" ?
git-format-patch outputs stuff in the mailbox format while cg-mkpatch
outputs it in a more "human readable" (well, but quite historical)
format, but really, you probably want to use git-format-patch in almost
every case. In the (probably relatively near) future, cg-mkpatch might
become merely a git-format-patch wrapper.
> 3. It seem that if a commit as a binary file they are no way to manage
> it by email patches. Any plan about this in Cogito ?
Not any clear plans. I will welcome patches but it is not high
priority for me currently.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-02 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605021422200.4086@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 2 May 2006, Junio C Hamano wrote:
>>
>> - The shell-script one, if you use GNU grep, accepts more
>> options to grep than what the current built-in one supports.
>> Notable ones that are missing: fixed strings (-F), patterns
>> from file (-f), count matches (-c), omit filenames (-h),
>> skipping binary files (-I, -U), files without match (-L),
>> pcre (-P), silent (-q), word expression (-w), NUL (-z). They
>> should be easy to add if somebody cares enough, and I plan to
>> do a few myself before pushing it out to "master".
>
> I use "-w" all the time, along with -5 or similar to get context for the
> grep.
Noted; -w is missing; -A/-B/-C are already there so you could
say -C 5 instead, and -<n> should be easy to add.
On a related tangent, ever since I started using the built-in
grep with ls-files like wildcard, I find myself typing something
like this by mistake (this is from my day-job work project that
has src/mx.js and src/mxstyle.css among other things):
git diff 268a94 -- 'src/mx*'
I am tempted to suggest switching pathspecs used by diff and log
family to do the same wildcarding, perhaps after tightening the
wildcard vs directory prefix logic used in the builtin-grep of
the current "next" tip, which is a bit looser than necessary.
^ permalink raw reply
* Re: [PATCH]: Allow misc https cert for git-svnimport
From: Eric Wong @ 2006-05-02 21:44 UTC (permalink / raw)
To: P. Christeas; +Cc: git, Matthias Urlichs
In-Reply-To: <200604281801.07155.p_christ@hol.gr>
"P. Christeas" <p_christ@hol.gr> wrote:
> Just had to access a server with a broken certificate (self signed), so I
> added that patch to git-svnimport.
Matthias should know more about git-svnimport than I do :)
I'm not fully up-to-date on how the SVN:: modules work for this, nor do
I know off the top of my head an ssl svn server with a self-signed cert
to test with. I just copied the ssl stuff off svn-mirror a while ago :)
> --- /usr/bin/git-svnimport 2006-04-13 09:39:39.000000000 +0300
> +++ /home/panos/bin/git-svnimport 2006-04-28 17:55:45.000000000 +0300
> @@ -96,9 +96,14 @@
> sub conn {
> my $self = shift;
> my $repo = $self->{'fullrep'};
> - my $auth = SVN::Core::auth_open ([SVN::Client::get_simple_provider,
> +# my $auth = SVN::Core::auth_open ([SVN::Client::get_simple_provider,
> +# SVN::Client::get_ssl_server_trust_file_provider,
> +# SVN::Client::get_ssl_server_trust_prompt_provider(\&_trust_callback),
> +# SVN::Client::get_username_provider]);
> + my $auth = [SVN::Client::get_simple_provider,
> SVN::Client::get_ssl_server_trust_file_provider,
> - SVN::Client::get_username_provider]);
> + SVN::Client::get_ssl_server_trust_prompt_provider(\&_trust_callback),
> + SVN::Client::get_username_provider];
> my $s = SVN::Ra->new(url => $repo, auth => $auth);
> die "SVN connection to $repo: $!\n" unless defined $s;
> $self->{'svn'} = $s;
> @@ -125,6 +130,45 @@
> return $name;
> }
>
> +sub _trust_callback {
> + my ($cred,$realm,$ifailed,$server_cert_info,$may_save) = @_;
> + #$cred->accepted_failures($SVN::Auth::SSL::UNKNOWNCA);
> + print "SSL certificate is not trusted: $ifailed \n";
> + print "Fingerprint: " . $server_cert_info->fingerprint . "\n";
> + print "Hostname: ". $server_cert_info->hostname ;
> + print " (MISMATCH)" if ( $ifailed & $SVN::Auth::SSL::CNMISMATCH);
> + print "\n";
> +
> + print "Valid from: ". $server_cert_info->valid_from;
> + print " (NOT YET)" if ( $ifailed & $SVN::Auth::SSL::NOTYETVALID);
> + print "\n";
> +
> + print "Valid until: ". $server_cert_info->valid_until;
> + print " (EXPIRED)" if ( $ifailed & $SVN::Auth::SSL::EXPIRED);
> + print "\n";
> +
> + print "Issuer: ". $server_cert_info->issuer_dname;
> + print " (UNKNOWN)" if ( $ifailed & $SVN::Auth::SSL::UNKNOWNCA);
> + print "\n\n";
> +
> + print "Do you still want to accept that certificate? [y/N] ";
> + my $accept = <STDIN>;
> + chomp($accept);
> + print "\n";
> + if (($accept eq "y") or ($accept eq "Y" )) {
> + $cred->accepted_failures($ifailed);
> + # print "Save cert, so that it is accepted in future calls? [y/N] ";
> + # my $mmsave = <STDIN>;
> + # chomp($mmsave);
> + # if (($mmsave eq "y") or ($mmsave eq "Y" )) {
> + # $may_save = 1;
> + # }
> + print "\n";
> + }
> +
> +}
> +
> +
> package main;
> use URI;
>
--
Eric Wong
^ permalink raw reply
* [PATCH] git-send-email: fix version string to be valid perl
From: Martin Langhoff @ 2006-05-02 21:44 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
This makes git-send-email easier to develop and debug, skipping the need
to `make git-send-email` every time.
---
git-send-email.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
1f6dd44e0c919196f9c3d5d617a64111004f24e5
diff --git a/git-send-email.perl b/git-send-email.perl
index ecfa347..2eb4f6c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -291,6 +291,13 @@ sub send_message
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc);
my $date = strftime('%a, %d %b %Y %H:%M:%S %z', localtime($time++));
+ my $gitversion = '@@GIT_VERSION@@';
+ if ($gitversion =~ m/..GIT_VERSION../) {
+ $gitversion = `git --version`;
+ chomp $gitversion;
+ # keep only what's after the last space
+ $gitversion =~ s/^.* //;
+ }
my $header = "From: $from
To: $to
@@ -299,7 +306,7 @@ Subject: $subject
Reply-To: $from
Date: $date
Message-Id: $message_id
-X-Mailer: git-send-email @@GIT_VERSION@@
+X-Mailer: git-send-email $gitversion
";
$header .= "In-Reply-To: $reply_to\n" if $reply_to;
--
1.3.0.rc4.ge6bf-dirty
^ permalink raw reply related
* Re: cg-mkpatch use case
From: Martin Langhoff @ 2006-05-02 21:41 UTC (permalink / raw)
To: Belmar-Letelier; +Cc: git
In-Reply-To: <44570E8E.5070402@itaapy.com>
On 5/2/06, Belmar-Letelier <luis@itaapy.com> wrote:
> What is the Cogito way to apply the result of "cg-mkpatch"
AFAIK, cg-patch. However, cg-mkpatch appeared before cg-patch, so you
may have a version of Cogito without cg-patch.
> 2. What are the difference between usecases with "cg-mkpatch"
> and "git-format-patch" ?
If you are familiar with git tools, use them instead of cg tools ;-)
Cg is simpler, so if you have relatively simple needs, or a team with
simple needs that doesn't need to know all the git tricks and
internals, it can be a timesaver. In my team, people start with Cg and
eventually evolve into using more and more of git.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Linus Torvalds @ 2006-05-02 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v1wvcmejr.fsf@assigned-by-dhcp.cox.net>
On Tue, 2 May 2006, Junio C Hamano wrote:
>
> - The shell-script one, if you use GNU grep, accepts more
> options to grep than what the current built-in one supports.
> Notable ones that are missing: fixed strings (-F), patterns
> from file (-f), count matches (-c), omit filenames (-h),
> skipping binary files (-I, -U), files without match (-L),
> pcre (-P), silent (-q), word expression (-w), NUL (-z). They
> should be easy to add if somebody cares enough, and I plan to
> do a few myself before pushing it out to "master".
I use "-w" all the time, along with -5 or similar to get context for the
grep.
Linus
^ permalink raw reply
* Re: git-bisect broken in 1.2.4
From: Johannes Schindelin @ 2006-05-02 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslnskzjj.fsf@assigned-by-dhcp.cox.net>
Hi
On Tue, 2 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Why not just use the existing method:
> >
> > [core]
> > onlyusesymrefs = false
>
> USE_SYMLINK_HEAD is not enabled by default, and when it is, it
> _defaults_ to use symlink head.
Okay. I missed the part that support is disabled by default.
Sorry for the noise,
Dscho
^ permalink raw reply
* Re: [PATCH] built-in "git grep" (git grip).
From: Junio C Hamano @ 2006-05-02 19:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e378fs$lpc$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> I renamed "git grip" to "git grep" and "git diffn" to "git diff"
>> both in "next" branch to avoid confusion. Thanks Andreas,
>> Jakub, and others for input.
>
> So, is there a way to use old, script version of those commands?
I'd say that is probably not the real question you wanted to
ask, but let's pretend it is for a moment.
The "master" branch has not been updated to remove the script
one, so you can keep running "master" one (or 1.3.X series). Or
you can fork your own private edition by tweaking git.c (prevent
it from running the builtin one) and Makefile (resurrect the
script based one and prevent it from installing git-grep
hardlinked with git itself). One thing that I will not do in
the long run, however, is to keep the script based one and have
builtin one. It is like carrying all the earlier slightly
incompatible versions as git-grep-1.1.sh, git-grep-1.2.sh, and
git-grep-1.3.sh in the source for fear of backward compatibility
problems -- it is crazy.
So the real question, is what are still missing in the built-in
implementation. What will we lose if we remove the script based
one and replace it with today's built-in one, if we are ready to
do it today, and if not what we are going to do about them. My
answer to the latter questions are "not yet" (obviously, that is
why "master" does not have it yet), and "will support what are
reasonable".
Here are main differences that I am aware of:
- The shell-script one, if you use GNU grep, accepts more
options to grep than what the current built-in one supports.
Notable ones that are missing: fixed strings (-F), patterns
from file (-f), count matches (-c), omit filenames (-h),
skipping binary files (-I, -U), files without match (-L),
pcre (-P), silent (-q), word expression (-w), NUL (-z). They
should be easy to add if somebody cares enough, and I plan to
do a few myself before pushing it out to "master".
- The shell-script one can be coaxed to use different "grep"
implementation from the standard one with an appropriate PATH
settings.
At the lowest level, buitlin-grep.c::grep_buffer() function is
called with the set of parsed options, the "filename" used for
reporting, and the text to grepped in-core. The shell-script
one always worked on working tree files, but the built-in one
can work on working tree files and also alternatively on files
from other versions. Regardless of where the file comes from,
this function is called to look for the pattern the user is
looking for.
You can do two things.
One is to add support for commonly used but still missing
features to built-in one. For this, you would need to extend
"struct grep_opt" to hold new option parameters (e.g. if you
want to do "-f", you would need to hold all patterns you obtain
from the named file so grep_buffer() can use them -- currently
it supports only one pattern), and teach grep_buffer() how to do
the new feature.
Another thing you can do is to detect GIT_EXTERNAL_GREP (in the
same spirit as GIT_EXTERNAL_DIFF) environment variable at the
front of grep_buffer(), and when it is set, spawn the named
external program with the original parameters the user supplied,
probably stashed away in "struct grep_opt" when cmd_grep() does
its parameter parsing, and feed it the contents of the buffer.
^ 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