* Re: gitweb and unicode special characters
From: Praveen A @ 2008-12-13 0:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Santhosh Thottingal
In-Reply-To: <m3y6ylf3mq.fsf@localhost.localdomain>
2008/12/12 Jakub Narebski <jnareb@gmail.com>:
> Jakub Narebski <jnareb@gmail.com> writes:
>> "Praveen A" <pravi.a@gmail.com> writes:
>>
>> > Git currently does not handle unicode special characters ZWJ and ZWNJ,
>> > both are heavily used in Malayalam and common in other languages
>> > needing complex text layout like Sinhala and Arabic.
>> >
>> > An example of this is shown in the commit message here
>> > http://git.savannah.gnu.org/gitweb/?p=smc.git;a=commit;h=c3f368c60aabdc380c77608c614d91b0a628590a
>> >
>> > \20014 and \20015 should have been ZWNJ and ZWJ respectively. You just
>> > need to handle them as any other unicode character - especially it is
>> > a commit message and expectation is normal pain text display.
>> >
>> > I hope some one will fix this.
>>
>> Well, I am bit stumped. git_commit calls format_log_line_html, which
>> in turn calls esc_html. esc_html looks like this:
>>
>> sub esc_html ($;%) {
>> my $str = shift;
>> my %opts = @_;
>>
>> ** $str = to_utf8($str);
>> $str = $cgi->escapeHTML($str);
>> if ($opts{'-nbsp'}) {
>> $str =~ s/ / /g;
>> }
>> ** $str =~ s|([[:cntrl:]])|(($1 ne "\t") ? quot_cec($1) : $1)|eg;
>> return $str;
>> }
>>
>> The two important lines are marked with '**'.
> [...]
>
>> So it looks like Perl treats \20014 and \20015 (ZWNJ and ZWJ) as
>> belonging to '[:cntrl:]' class. I don't know if it is correct from the
>> point of view of Unicode character classes, therefore if it is a bug
>> in Perl, or just in gitweb.
>
> I checked this, via this simple Perl script:
>
> #!/usr/bin/perl
>
> use charnames ":full";
>
> my $c = ord("\N{ZWNJ}");
> printf "oct=%o dec=%d hex=%x\n", $c, $c, $c;
>
> "\N{ZWNJ}" =~ /[[:cntrl:]]/ and print "is [:cntrl:]";
>
> And the answer was:
>
> oct=20014 dex=8204 hex=200c
> is [:cntrl:]
>
> 'ZERO WIDTH NON-JOINER' _is_ control character... We probably should
> use [^[:print:][:space:]] instead of [[:cntrl:]] here.
That looks good. But I'm wondering why do we need to filter at all?
Is it a security concern? It is just description.
>
> [...]
>> P.S. Even that might not help much, as Savannah uses git and gitwev
>> version 1.5.6.5, which is probably version released with some major
>> distribution. As of now we are at 1.6.0.5...
>
> Which can be seen from the fact that gitweb uses octal escapes,
> instead of hex escapes...
But we can expect it to work someday when savannah updates their git
version, or we can bug them to upgrade if the fix is in official git
release.
- Praveen
j4v4m4n
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
--
പ്രവീണ് അരിമ്പ്രത്തൊടിയില്
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
Join The DRM Elimination Crew Now!
http://fci.wikia.com/wiki/Anti-DRM-Campaign
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: J. Bruce Fields @ 2008-12-13 1:03 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212194703.GA17573@fieldses.org>
On Fri, Dec 12, 2008 at 02:47:03PM -0500, bfields wrote:
> On Fri, Dec 12, 2008 at 06:28:27PM +0000, David Howells wrote:
> > Add a guide to using GIT's simpler features.
> >
> > Signed-off-by: David Howells <dhowells@redhat.com>
>
> Just a couple random thoughts:
(Also: this patch applies to either the git or linux trees, and you sent
it to both mailing lists. Looks like you meant it for linux, but you
might want to clarify....)
--b.
>
> - The advantage of adding this to the kernel tree is that you
> can tailor it for a more specific audience (kernel developers
> and testers). A lot of this (e.g. the object-database
> discussion) seems to be generic introduction-to-git stuff.
> Is there some canonical external documentation you could refer
> to for that stuff, that would allow you to get more quickly to
> the more tailored information? If not, is there something you
> could improve to the point where you *would* be comfortable
> referring to it?
> - How much overlap is there with
> Documentation/development-process/7.AdvancedTopics? Should
> there be cross-references between the two?
>
> There's an awful lot of introductions to git out there now (and I've got
> my own share of the blame).
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: David Howells @ 2008-12-13 1:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: dhowells, torvalds, git, linux-kernel
In-Reply-To: <m33agtgp2v.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Wouldn't it be better to update either "Git User's Manual",
This is better in some ways than book.git-scm.com. It has pictures for one
thing. It does, however, go into too much detail too quickly.
> or http://book.git-scm.com?
I didn't see that when googling for stuff. I have four issues with what's on
this website, though I could perhaps, as you point out, fix three of them
myself:
(1) It really needs a pictorial representation of the virtual GIT tree. How
GIT actually stores its data is irrelevant to people trying to use GIT
rather than trying to modify GIT. It would help those trying to use GIT
if you can help them visualise what they're dealing with. It doesn't
have to be complex.
See the attached FIG file for examples. Try running it through:
fig2dev -L pdf <in.fig >out.pdf
(2) In my document I've tried to thread a worked example through, so that if
you go through all the steps, they'll work in order. I'm not sure I've
been entirely successful, though.
(3) You put some non-basic stuff in the basic section (branching - this isn't
ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
example).
(4) It needs to be installed with GIT in a form that can easily be cut and
pasted from (maybe this is the case).
I like the videos, though not all of them work, and a number of sections say
things like:
github
repoorcz
whatever that means.
David
#FIG 3.2
Landscape
Center
Inches
A4
100.00
Single
-2
1200 2
0 32 #efefef
0 33 #7f7f7f
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 15420 1485 15660 2025 15660 2025 15420 1485 15420
4 1 0 49 -1 0 10 0.000 4 2 540 1755 15600 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 14820 4365 15060 4905 15060 4905 14820 4365 14820
4 1 0 49 -1 0 10 0.000 4 2 540 4635 15000 B1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 14820 1485 15060 2025 15060 2025 14820 1485 14820
4 1 0 49 -1 0 10 0.000 4 2 540 1755 15000 C1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 14220 4365 14460 4905 14460 4905 14220 4365 14220
4 1 0 49 -1 0 10 0.000 4 2 540 4635 14400 B2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 14220 1485 14460 2025 14460 2025 14220 1485 14220
4 1 0 49 -1 0 10 0.000 4 2 540 1755 14400 C2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 13620 4365 13860 4905 13860 4905 13620 4365 13620
4 1 0 49 -1 0 10 0.000 4 2 540 4635 13800 B3\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 13620 1485 13860 2025 13860 2025 13620 1485 13620
4 1 0 49 -1 0 10 0.000 4 2 540 1755 13800 C3\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 13020 1485 13260 2025 13260 2025 13020 1485 13020
4 1 0 49 -1 0 10 0.000 4 2 540 1755 13200 C4\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 12300 1485 12540 2025 12540 2025 12300 1485 12300
4 1 0 49 -1 0 10 0.000 4 2 540 1755 12480 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 11700 4365 11940 4905 11940 4905 11700 4365 11700
4 1 0 49 -1 0 10 0.000 4 2 540 4635 11880 B1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 11700 1485 11940 2025 11940 2025 11700 1485 11700
4 1 0 49 -1 0 10 0.000 4 2 540 1755 11880 C1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 11100 4365 11340 4905 11340 4905 11100 4365 11100
4 1 0 49 -1 0 10 0.000 4 2 540 4635 11280 B2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 11100 1485 11340 2025 11340 2025 11100 1485 11100
4 1 0 49 -1 0 10 0.000 4 2 540 1755 11280 C2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 10500 4365 10740 4905 10740 4905 10500 4365 10500
4 1 0 49 -1 0 10 0.000 4 2 540 4635 10680 B3\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 10500 1485 10740 2025 10740 2025 10500 1485 10500
4 1 0 49 -1 0 10 0.000 4 2 540 1755 10680 C3\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 9780 4365 10020 4905 10020 4905 9780 4365 9780
4 1 0 49 -1 0 10 0.000 4 2 540 4635 9960 F1A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 9300 4365 9540 4905 9540 4905 9300 4365 9300
4 1 0 49 -1 0 10 0.000 4 2 540 4635 9480 F2A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 9300 2835 9540 3375 9540 3375 9300 2835 9300
4 1 0 49 -1 0 10 0.000 4 2 540 3105 9480 D0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 9300 1485 9540 2025 9540 2025 9300 1485 9300
4 1 0 49 -1 0 10 0.000 4 2 540 1755 9480 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 8820 4365 9060 4905 9060 4905 8820 4365 8820
4 1 0 49 -1 0 10 0.000 4 2 540 4635 9000 F3A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 8340 2835 8580 3375 8580 3375 8340 2835 8340
4 1 0 49 -1 0 10 0.000 4 2 540 3105 8520 D1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 8340 1485 8580 2025 8580 2025 8340 1485 8340
4 1 0 49 -1 0 10 0.000 4 2 540 1755 8520 C1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 8100 4365 8340 4905 8340 4905 8100 4365 8100
4 1 0 49 -1 0 10 0.000 4 2 540 4635 8280 F2B\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 7620 1485 7860 2025 7860 2025 7620 1485 7620
4 1 0 49 -1 0 10 0.000 4 2 540 1755 7800 C3\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 6900 4365 7140 4905 7140 4905 6900 4365 6900
4 1 0 49 -1 0 10 0.000 4 2 540 4635 7080 F1A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 6420 4365 6660 4905 6660 4905 6420 4365 6420
4 1 0 49 -1 0 10 0.000 4 2 540 4635 6600 F2A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 6420 2835 6660 3375 6660 3375 6420 2835 6420
4 1 0 49 -1 0 10 0.000 4 2 540 3105 6600 D0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 6420 1485 6660 2025 6660 2025 6420 1485 6420
4 1 0 49 -1 0 10 0.000 4 2 540 1755 6600 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 5940 4365 6180 4905 6180 4905 5940 4365 5940
4 1 0 49 -1 0 10 0.000 4 2 540 4635 6120 F3A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 5460 2835 5700 3375 5700 3375 5460 2835 5460
4 1 0 49 -1 0 10 0.000 4 2 540 3105 5640 D1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 5460 1485 5700 2025 5700 2025 5460 1485 5460
4 1 0 49 -1 0 10 0.000 4 2 540 1755 5640 C1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 5220 4365 5460 4905 5460 4905 5220 4365 5220
4 1 0 49 -1 0 10 0.000 4 2 540 4635 5400 F2B\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 4740 2835 4980 3375 4980 3375 4740 2835 4740
4 1 0 49 -1 0 10 0.000 4 2 540 3105 4920 D2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 4740 1485 4980 2025 4980 2025 4740 1485 4740
4 1 0 49 -1 0 10 0.000 4 2 540 1755 4920 C2\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 4500 4365 4740 4905 4740 4905 4500 4365 4500
4 1 0 49 -1 0 10 0.000 4 2 540 4635 4680 F1B\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 3780 4365 4020 4905 4020 4905 3780 4365 3780
4 1 0 49 -1 0 10 0.000 4 2 540 4635 3960 F1A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 3300 4365 3540 4905 3540 4905 3300 4365 3300
4 1 0 49 -1 0 10 0.000 4 2 540 4635 3480 F2A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 3300 2835 3540 3375 3540 3375 3300 2835 3300
4 1 0 49 -1 0 10 0.000 4 2 540 3105 3480 D0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 3300 1485 3540 2025 3540 2025 3300 1485 3300
4 1 0 49 -1 0 10 0.000 4 2 540 1755 3480 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 2820 4365 3060 4905 3060 4905 2820 4365 2820
4 1 0 49 -1 0 10 0.000 4 2 540 4635 3000 F3A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 2340 2835 2580 3375 2580 3375 2340 2835 2340
4 1 0 49 -1 0 10 0.000 4 2 540 3105 2520 D1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 2340 1485 2580 2025 2580 2025 2340 1485 2340
4 1 0 49 -1 0 10 0.000 4 2 540 1755 2520 C1\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 2100 4365 2340 4905 2340 4905 2100 4365 2100
4 1 0 49 -1 0 10 0.000 4 2 540 4635 2280 F2B\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 1260 4365 1500 4905 1500 4905 1260 4365 1260
4 1 0 49 -1 0 10 0.000 4 2 540 4635 1440 F1A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 780 4365 1020 4905 1020 4905 780 4365 780
4 1 0 49 -1 0 10 0.000 4 2 540 4635 960 F2A\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
2835 780 2835 1020 3375 1020 3375 780 2835 780
4 1 0 49 -1 0 10 0.000 4 2 540 3105 960 D0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
1485 780 1485 1020 2025 1020 2025 780 1485 780
4 1 0 49 -1 0 10 0.000 4 2 540 1755 960 C0\001
2 2 0 1 0 7 50 -1 19 0.000 0 0 -1 0 0 5
4365 300 4365 540 4905 540 4905 300 4365 300
4 1 0 49 -1 0 10 0.000 4 2 540 4635 480 F3A\001
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 15420 1755 15060
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2025 14940 4365 14940
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4635 14820 4635 14460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 14820 1755 14460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4635 14220 4635 13860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 14220 1755 13860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4365 13740 3555 13740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 13620 1755 13260
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 3
1 1 0.00 60.000 120.000
4635 13620 4635 13140 2025 13140
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 13140 675 13140
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 12300 1755 11940
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2025 11820 4365 11820
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4635 11700 4635 11340
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 11700 1755 11340
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4635 11100 4635 10740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 11100 1755 10740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
4365 10620 3555 10620
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 10620 675 10620
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 9420 2025 9420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 4
1 1 0.00 60.000 120.000
4365 9900 4005 9900 4005 9420 3375 9420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
4005 9420 4005 9060 4365 9060
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
1 1 0.00 60.000 120.000
4005 9420 4365 9420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 9300 1755 8580
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 8460 2025 8460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 0.00 60.000 120.000
1 1 0.00 60.000 120.000
4365 9780 3825 9780 3825 8940 4365 8940
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
3825 8460 3825 8220 4365 8220
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
3825 8940 3825 8460 3375 8460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 8340 1755 7860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 4
1 1 0.00 60.000 120.000
2835 9300 2385 9300 2385 7740 2025 7740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 7740 675 7740
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 6540 2025 6540
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 4
1 1 0.00 60.000 120.000
4365 7020 4005 7020 4005 6540 3375 6540
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
4005 6540 4005 6180 4365 6180
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
1 1 0.00 60.000 120.000
4005 6540 4365 6540
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 6420 1755 5700
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 5580 2025 5580
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 0.00 60.000 120.000
1 1 0.00 60.000 120.000
4365 6900 3825 6900 3825 6060 4365 6060
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
3825 5580 3825 5340 4365 5340
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
3825 6060 3825 5580 3375 5580
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 5460 1755 4980
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 4860 2025 4860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 4860 675 4860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 0.00 60.000 120.000
1 1 0.00 60.000 120.000
4365 5940 3645 5940 3645 5220 4365 5220
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
3645 4860 3645 4620 4365 4620
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
3645 5220 3645 4860 3375 4860
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 3420 2025 3420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 4
1 1 0.00 60.000 120.000
4365 3900 4005 3900 4005 3420 3375 3420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
4005 3420 4005 3060 4365 3060
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
1 1 0.00 60.000 120.000
4005 3420 4365 3420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1755 3300 1755 2580
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 2460 2025 2460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 2460 675 2460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 4
1 1 0.00 60.000 120.000
1 1 0.00 60.000 120.000
4365 3780 3825 3780 3825 2940 4365 2940
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
3825 2460 3825 2220 4365 2220
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3
3825 2940 3825 2460 3375 2460
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
2835 900 2025 900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
1 1 0.00 60.000 120.000
1485 900 675 900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 4
1 1 0.00 60.000 120.000
4365 1380 4005 1380 4005 900 3375 900
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
1 1 0.00 60.000 120.000
4005 900 4005 420 4365 420
2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
1 1 0.00 60.000 120.000
4005 900 4365 900
4 0 0 49 -1 0 10 0.000 4 120 540 3600 13680 Branch\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 13080 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 990 0 12840 POST-MERGE:\001
4 0 0 49 -1 0 10 0.000 4 120 540 3600 10560 Branch\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 10560 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 900 0 10320 PRE-MERGE:\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 7680 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 1350 0 7440 REVERT FILE F2:\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 4800 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 1350 0 4320 CHANGE FILE F1:\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 2400 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 1350 0 1920 CHANGE FILE F2:\001
4 0 0 49 -1 0 10 0.000 4 120 360 720 840 HEAD\001
4 0 0 49 -1 0 10 0.000 4 120 1170 0 120 INITIAL TREE:\001
^ permalink raw reply
* Git weekly news: 2008-50
From: Felipe Contreras @ 2008-12-13 1:10 UTC (permalink / raw)
To: git list
Hi all,
This week I'm trying to address some of the issues mentioned here. I
still would like people to request user accounts to this blog if they
wish to make some git related posts.
http://gitlog.wordpress.com/2008/12/13/git-weekly-links-2008-50/
== Articles ==
Why Subversion does not suck
http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
Articles on Git, a distributed version control system
http://www.gnome.org/~federico/index.html#git
Pushing and pulling with Git, part 2
http://www.gnome.org/~federico/news-2008-12.html#pushing-and-pulling-with-git-2
Setting Up Ruby on Rails Projects with Git and Github
A straight forward guide to setup git and github in Windows
http://beans.seartipy.com/2008/12/09/setting-up-ruby-on-rails-projects-with-git-and-github/
Insider Guide to GitHub
Comprehensive screencasts to get familiar with git by Scott Chacon
http://github.com/blog/261-insider-guide-to-github-series
http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github
YUI on GitHub
Yahoo's User Interface Library is now hosted publicly on Github
http://github.com/blog/262-yui-on-github
Las ventajas de Git
Discussion about Git's advantages in barrapunto.com (Spanish's slashdot)
http://preguntas.barrapunto.com/article.pl?sid=08/12/08/019203
== In Japaneese (I've no idea) ==
coderepos の commit 数ナンバー１の人が github を練習したメモ
http://d.hatena.ne.jp/tokuhirom/20081212/1229080990
gitでドットファイルをバージョン管理する
http://d.hatena.ne.jp/javascripter/20081208/1228730967
gistコマンドよりちょっと便利なgisty
http://d.hatena.ne.jp/swdyh/20081207/1228655198
== Still popular ==
Why Git is Better than X
Brief explanation about why you should switch from X to Git
http://whygitisbetterthanx.com/
Por qué Git es mejor que X
Also very popular is the Spanish version
http://es.whygitisbetterthanx.com/
== My picks ==
What are your favorite git features or tricks?
A bunch of git tricks
http://stackoverflow.com/questions/347901/what-are-your-favorite-git-features-or-tricks
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: David Howells @ 2008-12-13 1:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: dhowells, torvalds, git, linux-kernel
In-Reply-To: <20081212190900.GL5691@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> > > Is there any reason you hide the tag object?
> >
> > What's a tag object?
>
> http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_tag_object
Okay. I do mention tags. How they're stored in the database is irrelevant.
As far as most users need be concerned, a tag is a symbolic representation of
a particular commit in the tree; a particular state of the source tree.
Think of symbolic links as an analogy. Most users just need to know that a
symlink represents the location of another part of the VFS tree; actually most
users will just think of them as a pointer to the name of a file, if even that
much. The fact that, say, ReiserFS tail packs them because they tend to be
small, or that AFS symlinks have weird properties that encode mountpoints is
irrelevant to most users. You don't need to know that to use them.
Yes, GIT's database has blob objects, tree objects, commit objects and tag
objects; but as far as the normal user is concerned, it stores files, lists of
files (directories or, more probably, folders), commits and tags. The
physical low-level stuff is completely irrelevant.
There is one exception to that: commit IDs. These are public-facing as it
were. GIT waves them in your face, and you have to use them occasionally, so
it's useful to say a bit about them.
David
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: David Howells @ 2008-12-13 1:14 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: dhowells, torvalds, git, linux-kernel
In-Reply-To: <20081213010328.GA23224@fieldses.org>
J. Bruce Fields <bfields@fieldses.org> wrote:
> (Also: this patch applies to either the git or linux trees, and you sent
> it to both mailing lists. Looks like you meant it for linux, but you
> might want to clarify....)
It was aimed at addition to Linux, but someone might think it goes better in
GIT instead, and the GIT list is more narrowly focused on the right people to
review it.
David
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Sverre Rabbelier @ 2008-12-13 1:16 UTC (permalink / raw)
To: David Howells; +Cc: Jakub Narebski, torvalds, git, linux-kernel
In-Reply-To: <32073.1229130284@redhat.com>
On Sat, Dec 13, 2008 at 02:04, David Howells <dhowells@redhat.com> wrote:
> (3) You put some non-basic stuff in the basic section (branching - this isn't
> ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
> example).
Erm, branching is not ordinarily useful? I think you're Doing It Wrong
(TM) then, since branching is a Big Thing (also TM) in DVC, not using
branches would be a bit like only using the first 4 gears in a car;
sure, it's possible, but you're missing all that extra power!
> (4) It needs to be installed with GIT in a form that can easily be cut and
> pasted from (maybe this is the case).
I'll agree with you that the git-scm site is in fact, a site, and as
such cannot easily be accessed.
> github
First hit on google:http://github.com/
> repoorcz
http://repo.or.cz
I'm sure both are supposed to be hyperlinks, and some text there as well.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Nicolas Pitre @ 2008-12-13 1:22 UTC (permalink / raw)
To: David Howells; +Cc: Jakub Narebski, torvalds, git, linux-kernel
In-Reply-To: <32073.1229130284@redhat.com>
On Sat, 13 Dec 2008, David Howells wrote:
> (3) You put some non-basic stuff in the basic section (branching - this isn't
> ordinarily useful, IMHO), but you miss other stuff out ('git rm' for
> example).
Hmmm... I use git branches many times a day, while I use git rm...
well... almost never.
Nicolas
^ permalink raw reply
* Re: gitweb and unicode special characters
From: Jakub Narebski @ 2008-12-13 1:31 UTC (permalink / raw)
To: Praveen A; +Cc: git, Santhosh Thottingal
In-Reply-To: <3f2beab60812121655m6cd868bfhaaf386e6f5457533@mail.gmail.com>
On Sat, 13 Dec 2008 01:55, Praveen A wrote:
> 2008/12/12 Jakub Narebski <jnareb@gmail.com>:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> "Praveen A" <pravi.a@gmail.com> writes:
>>>
>>>> Git currently does not handle unicode special characters ZWJ and ZWNJ,
>>>> both are heavily used in Malayalam and common in other languages
>>>> needing complex text layout like Sinhala and Arabic.
>>>>
>>>> An example of this is shown in the commit message here
>>>> http://git.savannah.gnu.org/gitweb/?p=smc.git;a=commit;h=c3f368c60aabdc380c77608c614d91b0a628590a
>>>>
>>>> \20014 and \20015 should have been ZWNJ and ZWJ respectively. You just
>>>> need to handle them as any other unicode character - especially it is
>>>> a commit message and expectation is normal pain text display.
>>>
>>> [...] git_commit calls format_log_line_html, which
>>> in turn calls esc_html. esc_html looks like this:
>>>
>>> sub esc_html ($;%) {
[...]
>>> ** $str =~ s|([[:cntrl:]])|(($1 ne "\t") ? quot_cec($1) : $1)|eg;
>>> return $str;
>>> }
>>>
>>> The two important lines are marked with '**'.
>> [...]
>>
>>> So it looks like Perl treats \20014 and \20015 (ZWNJ and ZWJ) as
>>> belonging to '[:cntrl:]' class. I don't know if it is correct from the
>>> point of view of Unicode character classes, therefore if it is a bug
>>> in Perl, or just in gitweb.
>>
>> I checked this, via this simple Perl script:
[...]
>> "\N{ZWNJ}" =~ /[[:cntrl:]]/ and print "is [:cntrl:]";
>>
>> And the answer was:
>>
>> oct=20014 dex=8204 hex=200c
>> is [:cntrl:]
>>
>> 'ZERO WIDTH NON-JOINER' _is_ control character... We probably should
>> use [^[:print:][:space:]] instead of [[:cntrl:]] here.
>
> That looks good. But I'm wondering why do we need to filter at all?
> Is it a security concern? It is just description.
First, from the new description [^[:print:][:space:]], or even
[^[:print:]] (whichever we choose) you can see that those characters
we are showing using C (\r, \v, \b,...) + octal (in older gitweb) or
hex (in never gitweb) escapes would be invisible otherwise, or do
the strange things like \b aka backspace character.
Sidenote: There is probably one exception we want to add, namely not
escape '\r' at the end of line, to be able to deal better with DOS
line endings (\r\n).
Second, and that is I think reason we started to escape control
characters like \014 or ^L i.e. FORM FEED (FF) character (e.g. in
COPYING file), or \033 or ^[ i.e. ESCAPE (\e) character (e.g. commit
20a3847d) is that they are not allowed in XML, which means that they
are not allowed in XHTML, which means that if they are on the page,
and MIME-type is 'application/xml+html' forcing strict XML/XHTML mode
validating browsers would not display the page because it is not valid
XHTML. Mozilla 1.17.2 did this, and it would not show page; I don't
know how it works with more modern browsers.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-13 2:14 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
guilt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- guilt.orig 2008-12-13 09:53:32.000000000 +0800
+++ guilt 2008-12-13 10:01:03.000000000 +0800
@@ -538,7 +538,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o "x$diffstat" = "x1" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -627,6 +627,9 @@ guilt_push_diff_context=1
# default autotag value
AUTOTAG_DEFAULT=1
+# default diffstat value
+DIFFSTAT_DEFAULT=0
+
#
# Parse any part of .git/config that belongs to us
#
@@ -635,6 +638,10 @@ AUTOTAG_DEFAULT=1
autotag=`git config guilt.autotag`
[ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
+# generate diffstat?
+diffstat=`git config guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
^ permalink raw reply
* [JGIT PATCH 1/2] Add raw buffer fetch methods to FileHeader, HunkHeader
From: Shawn O. Pearce @ 2008-12-13 2:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
These permit application level code to read back the patch
script, for example to slice it up and output parts into a
UI on a per-file or per-hunk basis.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Two last-minute patches. While using this code in Gerrit 2 I
realized I forgot to add a way to get the script back after its
been parsed by the library. :-)
.../src/org/spearce/jgit/patch/BinaryHunk.java | 15 +++++++++++++++
| 15 +++++++++++++++
| 15 +++++++++++++++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
index 92eab86..f43a1b9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
@@ -81,6 +81,21 @@ public FileHeader getFileHeader() {
return file;
}
+ /** @return the byte array holding this hunk's patch script. */
+ public byte[] getBuffer() {
+ return file.buf;
+ }
+
+ /** @return offset the start of this hunk in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the hunk in {@link #getBuffer()}. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/** @return type of this binary hunk */
public Type getType() {
return type;
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
index 79e4b0a..7c3a45a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
@@ -173,6 +173,21 @@ int getParentCount() {
return 1;
}
+ /** @return the byte array holding this file's patch script. */
+ public byte[] getBuffer() {
+ return buf;
+ }
+
+ /** @return offset the start of this file's script in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the file script. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/**
* Get the old name associated with this file.
* <p>
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
index fc149ac..12c670d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
@@ -123,6 +123,21 @@ public FileHeader getFileHeader() {
return file;
}
+ /** @return the byte array holding this hunk's patch script. */
+ public byte[] getBuffer() {
+ return file.buf;
+ }
+
+ /** @return offset the start of this hunk in {@link #getBuffer()}. */
+ public int getStartOffset() {
+ return startOffset;
+ }
+
+ /** @return offset one past the end of the hunk in {@link #getBuffer()}. */
+ public int getEndOffset() {
+ return endOffset;
+ }
+
/** @return information about the old image mentioned in this hunk. */
public OldImage getOldImage() {
return old;
--
1.6.1.rc2.306.ge5d5e
^ permalink raw reply related
* [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Shawn O. Pearce @ 2008-12-13 2:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229136146-15359-1-git-send-email-spearce@spearce.org>
The conversion from byte[] to String is performed one line at a time,
in case the patch is a character encoding conversion patch for the
file. For simplicity we currently assume UTF-8 still as the default
encoding for any content, but eventually we should support using the
.gitattributes encoding property when performing this conversion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/patch/BinaryHunk.java | 8 ++
| 6 ++
| 7 ++
.../src/org/spearce/jgit/patch/PatchUtil.java | 79 ++++++++++++++++++++
4 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
index f43a1b9..f4e2ee3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
@@ -42,6 +42,8 @@
import static org.spearce.jgit.util.RawParseUtils.nextLF;
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
+import org.spearce.jgit.lib.Constants;
+
/** Part of a "GIT binary patch" to describe the pre-image or post-image */
public class BinaryHunk {
private static final byte[] LITERAL = encodeASCII("literal ");
@@ -96,6 +98,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return type of this binary hunk */
public Type getType() {
return type;
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
index 7c3a45a..0110f4a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
@@ -188,6 +188,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getScriptText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/**
* Get the old name associated with this file.
* <p>
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
index 12c670d..5a3b590 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
@@ -42,6 +42,7 @@
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
import org.spearce.jgit.lib.AbbreviatedObjectId;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.util.MutableInteger;
/** Hunk header describing the layout of a single block of lines */
@@ -138,6 +139,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return information about the old image mentioned in this hunk. */
public OldImage getOldImage() {
return old;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
new file mode 100644
index 0000000..89136c0
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.patch;
+
+import java.nio.charset.Charset;
+
+import org.spearce.jgit.util.RawParseUtils;
+
+/** Patch related utility functions. */
+public class PatchUtil {
+ /**
+ * Decode a region of a buffer one line at a time.
+ * <p>
+ * Unlike {@link RawParseUtils#decode(Charset, byte[], int, int)} this
+ * method reads the input one line at a time and decodes each line
+ * individually. This permits a decoding of a file converting from
+ * ISO-8859-1 to UTF-8 encoding (for example), as each line in the patch
+ * script will be in one encoding or the other.
+ *
+ * @param cs
+ * preferred character set to use when decoding the buffer.
+ * @param buf
+ * buffer to pull the raw bytes from.
+ * @param ptr
+ * first position to read.
+ * @param end
+ * one position past the last position to read.
+ * @return a string representation of the region, decoded per-line.
+ */
+ public static String decode(final Charset cs, final byte[] buf, int ptr,
+ final int end) {
+ final StringBuilder r = new StringBuilder(end - ptr);
+ while (ptr < end) {
+ final int eol = Math.min(end, RawParseUtils.nextLF(buf, ptr));
+ r.append(RawParseUtils.decode(cs, buf, ptr, eol));
+ ptr = eol;
+ }
+ return r.toString();
+ }
+
+ private PatchUtil() {
+ // No instances
+ }
+}
--
1.6.1.rc2.306.ge5d5e
^ permalink raw reply related
* Re: gitweb and unicode special characters
From: Edward Z. Yang @ 2008-12-13 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <200812130231.06929.jnareb@gmail.com>
Jakub Narebski wrote:
> Sidenote: There is probably one exception we want to add, namely not
> escape '\r' at the end of line, to be able to deal better with DOS
> line endings (\r\n).
I'm sorry, but I have to disagree. I find being able to see \r
line-endings in the pretty-printed format is exceedingly useful for
figuring out if a file has been checked in with the wrong line-endings.
The number of files that must have \r line endings are vanishingly small
(Bat files are perhaps the one example I can think of right now).
Cheers,
Edward
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Miklos Vajna @ 2008-12-13 3:34 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <32096.1229130776@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Sat, Dec 13, 2008 at 01:12:56AM +0000, David Howells <dhowells@redhat.com> wrote:
> Okay. I do mention tags. How they're stored in the database is irrelevant.
> As far as most users need be concerned, a tag is a symbolic representation of
> a particular commit in the tree; a particular state of the source tree.
Actually I think it matters, that's why a 'tag' differs to a 'tag
object'. Also, a tag can point to any other object, not just to a
commit. (Though usually it does.)
> Think of symbolic links as an analogy. Most users just need to know that a
> symlink represents the location of another part of the VFS tree; actually most
> users will just think of them as a pointer to the name of a file, if even that
> much. The fact that, say, ReiserFS tail packs them because they tend to be
> small, or that AFS symlinks have weird properties that encode mountpoints is
> irrelevant to most users. You don't need to know that to use them.
Won't it be confusing that a symlink can be stored as a blob, tags are
refs, but refs are not blobs?
> Yes, GIT's database has blob objects, tree objects, commit objects and tag
> objects; but as far as the normal user is concerned, it stores files, lists of
> files (directories or, more probably, folders), commits and tags. The
> physical low-level stuff is completely irrelevant.
Agreed, the object database is not interesting for a beginner.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 3:35 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Add a guide to using GIT's simpler features.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> Documentation/git-haters-guide.txt | 1283 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 1283 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/git-haters-guide.txt
>
>
> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
> new file mode 100644
> index 0000000..51e4dac
> --- /dev/null
> +++ b/Documentation/git-haters-guide.txt
> @@ -0,0 +1,1283 @@
> + ===================================
> + THE GIT HATER'S GUIDE TO THE GALAXY
> + ===================================
> +
> +By David Howells <dhowells@redhat.com>
> +
> +Contents:
> ...
> +============
> +INTRODUCTION
> +============
> +
> +So, you want to do some Linux kernel development? And you hear there's this
> +piece of software called 'GIT' that you probably ought to be using when dealing
> +with the kernel community? Then you find out that not only was Linux started
> +by this Linus Torvalds person, but GIT was too! Perhaps it doesn't seem fair:
> +Linus has not just _one_ huge piece of software named after himself, but _two_!
> +And on top of that, globe spanning hardware vendors just queue up to give him
> +all the herring he can eat!!
> +
> +Then you look at webpages about GIT. You look at the manpages! You run the
> +commands with --help! And you *still* don't know how to do anything complex
> +with it!! You feel certain that there's some secret rite you have to perform
> +to become a GIT initiate - probably something involving two goats, an altar and
> +a full moon - oh, and lots of beer (we *are* talking about kernel developers
> +after all).
> +
> +Then you ask around, and people look at you blankly, hedge or say that it's
> +easy and obvious (they should know - they wrote the damned thing). You realise
> +that the manpages are more an aide-memoire and that what you really want is
> +some sort of crib sheet; something that can hold your hand whilst you cut and
> +paste things from of it until you can see the point.
> +
> +Well, let's see if I can help...
> +
> +
> +DISCLAIMER
> +----------
> +
> +I don't really know what I'm doing with GIT...
I think this patch is good up to this point. It is mildly funny and there
would exist some people who share the same sense of humor as the above
paragraphs (I am unfortunately one of them, though).
I've only skimmed the remainder of the patch, and found there are quite a
few technical errors and deviations from standard terminologies that I do
not care to enumerate (I do not have infinite amount of time). They make
me suspect that anybody who tries to learn from this document would be
harmed rather than helped in the longer run.
The document could be a good addition if the remainder of the patch is
replaced by a collection of links to better introductory documents that
are already available on the net, IMHO.
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 4:43 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git
In-Reply-To: <20081213021422.GA28249@localhost>
On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> Introduce option guilt.diffstat so that we don't have to type
> "guilt refresh --diffstat" in its full form every time.
Good idea.
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
> guilt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> --- guilt.orig 2008-12-13 09:53:32.000000000 +0800
> +++ guilt 2008-12-13 10:01:03.000000000 +0800
> @@ -538,7 +538,7 @@ __refresh_patch()
>
> [ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
>
> - if [ ! -z "$5" ]; then
> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
Why the 'x' thing? I've seen it is some scripts before, but I can't think of
a reason to use it if the variable is surrounded in quotation marks.
> (
> echo "---"
> git diff --stat $diffopts "$2"
> @@ -627,6 +627,9 @@ guilt_push_diff_context=1
> # default autotag value
> AUTOTAG_DEFAULT=1
>
> +# default diffstat value
> +DIFFSTAT_DEFAULT=0
> +
> #
> # Parse any part of .git/config that belongs to us
> #
> @@ -635,6 +638,10 @@ AUTOTAG_DEFAULT=1
> autotag=`git config guilt.autotag`
> [ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
>
> +# generate diffstat?
> +diffstat=`git config guilt.diffstat`
> +[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
> +
> #
> # The following gets run every time this file is source'd
> #
Could you throw a quick note into the manpages?
Thanks,
Josef 'Jeff' Sipek.
--
My public GPG key can be found at
http://www.josefsipek.net/gpg/public-0xC7958FFE.txt
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Sixt, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120854k1c366327o9bc696184ea4f02e@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> ...
>> But what if the same persion notices a #define in a kdeutils header file
>> and want's to know whether it is unused in order to remove it:
>>
>> $ git grep FOO
>> kdeutils/foo.h:#define FOO bar
>
> "git grep --cached FOO" ?
That should behave identically when the work tree does not have change
since the index, and by definition paths outside the checkout area in the
"sparse" mode cannot have changes, so "git grep FOO" should behave the
same and should find it.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Daniel Barkalow, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120813m2949e36ar7905d5688b8f6ecb@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
>> So "git grep -e frotz Documentation/", whether you only check out
>> Documentation or the whole tree, should grep only in Documentation area,
>> and "git grep -e frotz" should grep in the whole tree, even if you happen
>> to have a sparse checkout. By definition, a sparse checkout has no
>> modifications outside the checkout area, so whenever grep wants to look
>> for strings outside the checkout area it should pretend as if the same
>> content as what the index records is in the work tree. This is consistent
>> with the way how "git diff" in a sparsely checked out work tree should
>> behave.
>
> Assume someone is using sparse checkout with KDE git repository. They
> sparse-checkout kdeutils module and do "git grep -e foo". I would
> expect that the command only searches in kdeutils only (and is the
> current behavior).
Yes it is the "current in next" behaviour, and no that is not what you
should expect, and that is why I earlier said it is a mistake. The
ability to choose which part to leave out of the working tree should not
change the fact that git is about managing the history of the whole tree,
not an individual file nor a subset of files.
I do not think it is unreasonable to have a mechanism to let the user
limit the area of the whole tree often used Porcelain commands look at.
We already have pathspec "git grep -e foo kdeutils/" mechanism that lets
you do such limiting. It is conceivable that some workflows _might_ find
having the default pathspec convenient in end-user initiated operations,
but then it would be convenient whether the end-user uses the sparse
checkout to limit the area to kdeutils/ or has the whole checkout.
Although I think it would be Okay to default the default pathspec match
the checkout area when the sparse checkout feature is in use, I think the
"checkout area" and "area of interest" should be two independent concepts.
I said "_might_" in the above because I do not think it is such a good
idea to have _the_ default pathspec to begin with, though. It would
probably be more useful to allow people to use shorthands to pathspecs,
and at that point you can use usual shell variables to do that already,
e.g. instead of having to say "git grep -e foo arch/x86 include/asm-i386",
you would say "git grep -e foo $i386", after "i386=arch/x86 include/asm-i386",
or something like that.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 5:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Howells, torvalds, git, linux-kernel
In-Reply-To: <4942C2D1.4090309@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> What do you feel is missing from the Kernel Hackers' Guide to Git? :)
>
> http://linux.yyz.us/git-howto.html
>
> Jeff
For a starter, it is not in-tree ;-).
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Boyd Stephen Smith Jr. @ 2008-12-13 6:18 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: Wu Fengguang, git
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
>> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
>
>Why the 'x' thing? I've seen it is some scripts before, but I can't think of
>a reason to use it if the variable is surrounded in quotation marks.
'[' or test see the arguments after they are unquoted (normally). So,
if "$diffstat" is "-n" it might try and do the -n test, rather than the =
test.
It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
it's not a big deal (to me). That also looks backwards to a lot of people.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 6:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Wu Fengguang, git
In-Reply-To: <200812130018.56061.bss03@volumehost.net>
On Sat, Dec 13, 2008 at 12:18:50AM -0600, Boyd Stephen Smith Jr. wrote:
> On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
> >> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
> >
> >Why the 'x' thing? I've seen it is some scripts before, but I can't think of
> >a reason to use it if the variable is surrounded in quotation marks.
>
> '[' or test see the arguments after they are unquoted (normally). So,
> if "$diffstat" is "-n" it might try and do the -n test, rather than the =
> test.
Oh. I haven't even thought of that posibility!
> It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
> it's not a big deal (to me). That also looks backwards to a lot of people.
Including me.
Thanks for the info.
Josef 'Jeff' Sipek.
--
Penguin : Linux version 2.6.25.4 on an i386 machine (6135.73 BogoMips).
^ permalink raw reply
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Jeff King @ 2008-12-13 6:31 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git
In-Reply-To: <UfCPFu_boLV0ycLKLmOno8GTqmtC4RSZZ9O6aRLGYjmSZOdKv6ywhCjApnplTHLxUIzO8KJ5Mww@cipher.nrlssc.navy.mil>
On Fri, Dec 12, 2008 at 05:20:07PM -0600, Brandon Casey wrote:
> Make it easier to recover from a mistaken branch deletion by displaying the
> sha1 of the branch's tip commit.
This version looks fine to me, but one nit:
> - test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
> + sha1=$(git rev-parse my7 | cut -c 1-7) &&
> + test "$(git branch -d my7 2>&1)" = "Deleted branch my7 ($sha1)."'
There is a very very small chance that this sha1 might require more
than 7 characters to be unique (small because we have such a tiny number
of objects in the trash repo). Maybe:
sha1=$(git log --pretty=format:%h -1 my7)
is better (though I have to admit, if I were writing the test originally
I would have tested the exit value of "git branch" instead of the
message).
-Peff
^ permalink raw reply
* characterizing commits
From: William Pursell @ 2008-12-13 8:28 UTC (permalink / raw)
To: git
I have a desire to add metadata to commits to characterize
their importance/type. (Or I'd like another recommended
method to achieve the following behavior).
A lot of commits in any given project can be grouped into
different types. eg, looking at the history for git,
there are a lot of merge commits, a lot of commits
that only touch gitk, a lot of 'auto-generated manpages',
a lot of 'typo in documentation' etc. In my own
projects, I have a fairly high percentage of commits
that are trivial (eg whitespace only, typos, etc).
What I'm after is the ability to do something like:
git log --group=!trivial
git log --group=importance:3+
and only get the log for those commits that have been
not been classified "trivial" or that have a precedence
of 3 or greater.
For example, I'd like the following work flow:
$ git log --pretty=oneline
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
6fa2e40ed491d1dcbbfac9f2d301b517413bec3b 1
04dcd38a8cb6496e37594a273ca39542912ca1eb important
9bd23c2d08e254058a1a9709f963737dc9a71d16 trivial change
$ git group 6fa2e trivial
$ git group 9bd23 trivial
$ git log --pretty=oneline --group=!trivial
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
04dcd38a8cb6496e37594a273ca39542912ca1eb important
Is there already a mechanism for filtering
commits that I could extend to accomplish this?
--
William Pursell
^ permalink raw reply
* Announce: TortoiseGit 0.1 preview version
From: 李智 @ 2008-12-13 8:33 UTC (permalink / raw)
To: git
TortoiseGit is porting from TortoiseSVN. It is explore extension.
This version just finish a min set of TortoiseSVN porting
1.Context menu(subset of TortoiseSVN)
2.Icon Overlay(version controled\unversion controled at directory)
3.Unified DIFF
4.Use third part diff tools (such as kdiff3)
5.Commit change
6.Show Log
7.Create Repository
Project Home Page at:
http://code.google.com/p/tortoisegit/
Source code at
http://repo.or.cz/w/TortoiseGit.git
It need msysgit 1.6.0.2.
^ permalink raw reply
* Re: characterizing commits
From: Jeff King @ 2008-12-13 8:52 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4943721C.7070200@gmail.com>
On Sat, Dec 13, 2008 at 08:28:12AM +0000, William Pursell wrote:
> A lot of commits in any given project can be grouped into
> different types. eg, looking at the history for git,
> there are a lot of merge commits, a lot of commits
> that only touch gitk, a lot of 'auto-generated manpages',
> a lot of 'typo in documentation' etc. In my own
> projects, I have a fairly high percentage of commits
> that are trivial (eg whitespace only, typos, etc).
> What I'm after is the ability to do something like:
>
> git log --group=!trivial
> git log --group=importance:3+
>
> [...]
> Is there already a mechanism for filtering
> commits that I could extend to accomplish this?
Generally you would put a pseudo-header into your commit message, like:
Status: trivial
Importance: 3
and then use --grep to filter matching commits:
git log --grep="Status: trivial"
git log --grep="Importance: [3-9]"
Obviously the syntax is a little bit clunkier. You could fix that with
an option to parse arbitrary pseudo-headers (and even support numeric
relations), something like:
git log --filter='importance > 3'
which would be converted internally to a grep of the commit message like
this:
/^importance: (\d+)/i
and compare the result to 3.
The nice thing about that approach is that the storage remains the same:
text in the commit message. That means it gets displayed when you look
at the commit, people with older versions of git can still read it, etc.
One thing this _doesn't_ get you is annotating commits after the fact.
This has been discussed in the past; try searching the list for "notes".
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox