* [PATCH v2 3/4] Speed up git notes lookup
From: Johannes Schindelin @ 2008-12-20 12:05 UTC (permalink / raw)
To: Jeff King; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812201304210.30769@pacific.mpi-cbg.de>
To avoid looking up each and every commit in the notes ref's tree
object, which is very expensive, speed things up by slurping the tree
object's contents into a hash_map.
The idea fo the hashmap singleton is from David Reiss, initial
benchmarking by Jeff King.
Note: the implementation allows for arbitrary entries in the notes
tree object, ignoring those that do not reference a valid object. This
allows you to annotate arbitrary branches, or objects.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
notes.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 102 insertions(+), 11 deletions(-)
diff --git a/notes.c b/notes.c
index 91ec77f..68bcb24 100644
--- a/notes.c
+++ b/notes.c
@@ -4,16 +4,112 @@
#include "refs.h"
#include "utf8.h"
#include "strbuf.h"
+#include "tree-walk.h"
+
+struct entry {
+ unsigned char commit_sha1[20];
+ unsigned char notes_sha1[20];
+};
+
+struct hash_map {
+ struct entry *entries;
+ off_t count, size;
+};
static int initialized;
+static struct hash_map hash_map;
+
+static int hash_index(struct hash_map *map, const unsigned char *sha1)
+{
+ int i = ((*(unsigned int *)sha1) % map->size);
+
+ for (;;) {
+ unsigned char *current = map->entries[i].commit_sha1;
+
+ if (!hashcmp(sha1, current))
+ return i;
+
+ if (is_null_sha1(current))
+ return -1 - i;
+
+ if (++i == map->size)
+ i = 0;
+ }
+}
+
+static void add_entry(const unsigned char *commit_sha1,
+ const unsigned char *notes_sha1)
+{
+ int index;
+
+ if (hash_map.count + 1 > hash_map.size >> 1) {
+ int i, old_size = hash_map.size;
+ struct entry *old = hash_map.entries;
+
+ hash_map.size = old_size ? old_size << 1 : 64;
+ hash_map.entries = (struct entry *)
+ xcalloc(sizeof(struct entry), hash_map.size);
+
+ for (i = 0; i < old_size; i++)
+ if (!is_null_sha1(old[i].commit_sha1)) {
+ index = -1 - hash_index(&hash_map,
+ old[i].commit_sha1);
+ memcpy(hash_map.entries + index, old + i,
+ sizeof(struct entry));
+ }
+ free(old);
+ }
+
+ index = hash_index(&hash_map, commit_sha1);
+ if (index < 0) {
+ index = -1 - index;
+ hash_map.count++;
+ }
+
+ hashcpy(hash_map.entries[index].commit_sha1, commit_sha1);
+ hashcpy(hash_map.entries[index].notes_sha1, notes_sha1);
+}
+
+static void initialize_hash_map(const char *notes_ref_name)
+{
+ unsigned char sha1[20], commit_sha1[20];
+ unsigned *mode;
+ struct tree_desc desc;
+ struct name_entry entry;
+ void *buf;
+
+ if (!notes_ref_name || read_ref(notes_ref_name, commit_sha1) ||
+ get_tree_entry(commit_sha1, "", sha1, mode))
+ return;
+
+ buf = fill_tree_descriptor(&desc, sha1);
+ if (!buf)
+ die ("Could not read %s for notes-index", sha1_to_hex(sha1));
+
+ while (tree_entry(&desc, &entry))
+ if (!get_sha1(entry.path, commit_sha1))
+ add_entry(commit_sha1, entry.sha1);
+ free(buf);
+}
+
+static unsigned char *lookup_notes(const unsigned char *commit_sha1)
+{
+ int index;
+
+ if (!hash_map.size)
+ return NULL;
+
+ index = hash_index(&hash_map, commit_sha1);
+ if (index < 0)
+ return NULL;
+ return hash_map.entries[index].notes_sha1;
+}
void get_commit_notes(const struct commit *commit, struct strbuf *sb,
const char *output_encoding)
{
static const char *utf8 = "utf-8";
- struct strbuf name = STRBUF_INIT;
- const char *hex;
- unsigned char sha1[20];
+ unsigned char *sha1;
char *msg;
unsigned long msgoffset, msglen;
enum object_type type;
@@ -24,17 +120,12 @@ void get_commit_notes(const struct commit *commit, struct strbuf *sb,
notes_ref_name = getenv(GIT_NOTES_REF_ENVIRONMENT);
else if (!notes_ref_name)
notes_ref_name = GIT_NOTES_DEFAULT_REF;
- if (notes_ref_name && read_ref(notes_ref_name, sha1))
- notes_ref_name = NULL;
+ initialize_hash_map(notes_ref_name);
initialized = 1;
}
- if (!notes_ref_name)
- return;
-
- strbuf_addf(&name, "%s:%s", notes_ref_name,
- sha1_to_hex(commit->object.sha1));
- if (get_sha1(name.buf, sha1))
+ sha1 = lookup_notes(commit->object.sha1);
+ if (!sha1)
return;
if (!(msg = read_sha1_file(sha1, &type, &msglen)) || !msglen ||
--
1.6.1.rc3.412.ga72b
^ permalink raw reply related
* [PATCH v2 4/4] Add an expensive test for git-notes
From: Johannes Schindelin @ 2008-12-20 12:06 UTC (permalink / raw)
To: Jeff King; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812201304210.30769@pacific.mpi-cbg.de>
git-notes have the potential of being pretty expensive, so test with
a lot of commits. A lot. So to make things cheaper, you have to
opt-in explicitely, by setting the environment variable
GIT_NOTES_TIMING_TESTS.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3302-notes-index-expensive.sh | 98 ++++++++++++++++++++++++++++++++++++++
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100755 t/t3302-notes-index-expensive.sh
diff --git a/t/t3302-notes-index-expensive.sh b/t/t3302-notes-index-expensive.sh
new file mode 100755
index 0000000..00d27bf
--- /dev/null
+++ b/t/t3302-notes-index-expensive.sh
@@ -0,0 +1,98 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='Test commit notes index (expensive!)'
+
+. ./test-lib.sh
+
+test -z "$GIT_NOTES_TIMING_TESTS" && {
+ say Skipping timing tests
+ test_done
+ exit
+}
+
+create_repo () {
+ number_of_commits=$1
+ nr=0
+ parent=
+ test -d .git || {
+ git init &&
+ tree=$(git write-tree) &&
+ while [ $nr -lt $number_of_commits ]; do
+ test_tick &&
+ commit=$(echo $nr | git commit-tree $tree $parent) ||
+ return
+ parent="-p $commit"
+ nr=$(($nr+1))
+ done &&
+ git update-ref refs/heads/master $commit &&
+ {
+ export GIT_INDEX_FILE=.git/temp;
+ git rev-list HEAD | cat -n | sed "s/^[ ][ ]*/ /g" |
+ while read nr sha1; do
+ blob=$(echo note $nr | git hash-object -w --stdin) &&
+ echo $sha1 | sed "s/^/0644 $blob 0 /"
+ done | git update-index --index-info &&
+ tree=$(git write-tree) &&
+ test_tick &&
+ commit=$(echo notes | git commit-tree $tree) &&
+ git update-ref refs/notes/commits $commit
+ } &&
+ git config core.notesRef refs/notes/commits
+ }
+}
+
+test_notes () {
+ count=$1 &&
+ git config core.notesRef refs/notes/commits &&
+ git log | grep "^ " > output &&
+ i=1 &&
+ while [ $i -le $count ]; do
+ echo " $(($count-$i))" &&
+ echo " note $i" &&
+ i=$(($i+1));
+ done > expect &&
+ git diff expect output
+}
+
+cat > time_notes << \EOF
+ mode=$1
+ i=1
+ while [ $i -lt $2 ]; do
+ case $1 in
+ no-notes)
+ export GIT_NOTES_REF=non-existing
+ ;;
+ notes)
+ unset GIT_NOTES_REF
+ ;;
+ esac
+ git log >/dev/null
+ i=$(($i+1))
+ done
+EOF
+
+time_notes () {
+ for mode in no-notes notes
+ do
+ echo $mode
+ /usr/bin/time sh ../time_notes $mode $1
+ done
+}
+
+for count in 10 100 1000 10000; do
+
+ mkdir $count
+ (cd $count;
+
+ test_expect_success "setup $count" "create_repo $count"
+
+ test_expect_success 'notes work' "test_notes $count"
+
+ test_expect_success 'notes timing' "time_notes 100"
+ )
+done
+
+test_done
--
1.6.1.rc3.412.ga72b
^ permalink raw reply related
* Git weekly links: 2008-51
From: Felipe Contreras @ 2008-12-20 12:16 UTC (permalink / raw)
To: git list
Hi,
This week tortoisegit stole the spotlight. Maybe there weren't many
other links, or maybe I failed to notice them. Also, many people liked
the comment of Linus Torvalds regarding C++ in git.
blog version:
http://gitlog.wordpress.com/2008/12/20/git-weekly-links-2008-51/
== Articles ==
Agile git and the story branch pattern
Practical explanation about how to use feature branches and why they are good.
http://blog.hasmanythrough.com/2008/12/18/agile-git-and-the-story-branch-pattern
Using Git to Maintain Your Website
http://dmiessler.com/blog/using-git-to-maintain-your-website
How I Turned Down $300,000 from Microsoft to go Full-Time on GitHub
http://mojombo.github.com/2008/10/18/how-i-turned-down-300k.html
Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Linus Torvalds creates some buzz
http://lwn.net/Articles/249460/
== General links ==
tortoisegit
http://code.google.com/p/tortoisegit/
Blog posts on Git (usage)
http://git.or.cz/gitwiki/BlogPosts
== My picks ==
Learning git-svn in 5min
http://tsunanet.blogspot.com/2007/07/learning-git-svn-in-5min.html
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 13:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3agj1gvp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
> > your topic branch, it is shown as well.
> >
> > ------------
> > -$ git show-branch --reflog='10,1 hour ago' --list master
> > +$ git show-branch --reflog="10,1 hour ago" --list master
> > ------------
>
> Is this just a personal taste, or a correction to typography?
When using single quotes, the manpage displayed backticks. I don't know
how to obtain single quotes in the manpage, if this is preferred. The
HTML page worked though: single quotes were translated to single quotes,
double quotes to double quotes.
> Other than this one, I did not find anything else in your patch that
> looked iffy. Thanks for lending a good set of eyeballs.
Thanks, this happens when reading a lot of documentation :)
^ permalink raw reply
* Applying patches from a patch set
From: Mark Ryden @ 2008-12-20 14:37 UTC (permalink / raw)
To: git
Hello,
I am subscribed to some linux kernel subsystem mailing list; in this
list there are sometimes patchsets with more than
30-40 patches.
I am using gmail web interface client.
In order to apply a patch set I copy and paste each patch from the
patchset into a file, and then apply that patch.
I assume that there is a better way.
Recently I encountered a fatal error when doing so (and I am not sure
what caused it).
So my question is: does anyone know a more elegant way of applying a
large patchset ?
Maybe there is better mail client with which this process can be done easily ?
(I remember there was something called git apply-mbox in the past).
Rgs,
Mark
^ permalink raw reply
* Re: rsync deprecated?
From: Miklos Vajna @ 2008-12-20 17:02 UTC (permalink / raw)
To: demerphq; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <9b18b3110812200212o46edf51eoaff43ec1b8fc3913@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
On Sat, Dec 20, 2008 at 11:12:11AM +0100, demerphq <demerphq@gmail.com> wrote:
> Is there a bug tracking tool that git uses? I asked on #git on irc and
> they said to just mail the list, but ive not seen any response to my
> mail at all and the timing of Junios comment makes me wonder if my
> report was seen by list regulars at all.
You did the right thing, just nobody who read your mail had enough
time/knowledge/motivation to reply something constructive for you.
Similar to patches, I think if you get no answer in 3 days, you can try
to reply to your own mail, bringing the topic up again.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: rsync deprecated?
From: demerphq @ 2008-12-20 17:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <20081220170219.GS21154@genesis.frugalware.org>
2008/12/20 Miklos Vajna <vmiklos@frugalware.org>:
> On Sat, Dec 20, 2008 at 11:12:11AM +0100, demerphq <demerphq@gmail.com> wrote:
>> Is there a bug tracking tool that git uses? I asked on #git on irc and
>> they said to just mail the list, but ive not seen any response to my
>> mail at all and the timing of Junios comment makes me wonder if my
>> report was seen by list regulars at all.
>
> You did the right thing, just nobody who read your mail had enough
> time/knowledge/motivation to reply something constructive for you.
>
> Similar to patches, I think if you get no answer in 3 days, you can try
> to reply to your own mail, bringing the topic up again.
Ah, yes. Being new on this list it is all too easy to suffer from
Warnock Dilemma.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Mark Burton @ 2008-12-20 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <20081220104232.5ff1b7c0@crow>
Hi,
On further studying, I see that 1aec7917dc (git log: don't do merge
diffs by default) makes git log only show the log message by default
for merges. OK, no problem with that.
However, in my mind, whatchanged is misleading when it doesn't output
anything (by default) for merges because, in my mind, that implies that
nothing has changed when, in fact, whole heaps of stuff could have been
merged in. So, if you forget to add the -m option, whatchanged will silently
ignore all the merged stuff and leave the poor user in the dark.
So, if changing the default behaviour is acceptable, I still think it would
be better if ignore_merges is set to 0 in cmd_whatchanged() but I guess an
alternative would be to set always_show_header, instead.
Any thoughts?
Cheers,
Mark
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: James Cloos @ 2008-12-20 17:32 UTC (permalink / raw)
To: Ivan Zorin; +Cc: git
In-Reply-To: <494BC89F.9070107@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
Here is the script I use:
[-- Attachment #2: git-need-pull-p --]
[-- Type: text/plain, Size: 168 bytes --]
#!/bin/bash
#
# does this git repo need a pull?
#
l=$(git log|head -1|awk '{print $NF}')
r=$(git ls-remote origin heads/master|awk '{print $1}')
test "${r}" != "${l}"
[-- Attachment #3: Type: text/plain, Size: 76 bytes --]
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* Re: Applying patches from a patch set
From: Jakub Narebski @ 2008-12-20 19:25 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812200637m49c71aa5x3c25010fa00f4a63@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> I am subscribed to some linux kernel subsystem mailing list; in this
> list there are sometimes patchsets with more than
> 30-40 patches.
I hope in proper patch series...
> I am using gmail web interface client.
Better use some standalone mail program. Patch series should be send
in thread, either as reply to the cover letter message, or threaded
each being reply to previous patch... beside being numbered; IIRC
GMail web interface doesn't have threading implemented...
> In order to apply a patch set I copy and paste each patch from the
> patchset into a file, and then apply that patch.
You use raw view, I assume? Otherwise you would fail afoul word
wrapping and other whitespace mangling, at least...
[...]
> (I remember there was something called git apply-mbox in the past).
You can use "git am" for that, which is modern equivalent, and which
can do (almost) everything git-apply-mbox did.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git weekly links: 2008-51
From: Jakub Narebski @ 2008-12-20 19:50 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812200416m1caa96f2je2bf478f65bd7d12@mail.gmail.com>
"Felipe Contreras" <felipe.contreras@gmail.com> writes:
> This week tortoisegit stole the spotlight. Maybe there weren't many
> other links, or maybe I failed to notice them. Also, many people liked
> the comment of Linus Torvalds regarding C++ in git.
>
> blog version:
> http://gitlog.wordpress.com/2008/12/20/git-weekly-links-2008-51/
>
> == Articles ==
>
> Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
> Linus Torvalds creates some buzz
> http://lwn.net/Articles/249460/
A not countered counter:
C++ is a horrible language
http://skepticalmethodologist.wordpress.com/2008/12/17/c-is-a-horrible-language/
> == General links ==
>
> tortoisegit
> http://code.google.com/p/tortoisegit/
What about "Git Extensions":
https://sourceforge.net/projects/gitextensions/
http://github.com/spdr870/gitextensions/
And "TortoiseGit Challenge":
http://github.com/blog/256-tortoisegit-challenge
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Junio C Hamano @ 2008-12-20 20:08 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812201418.38707.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Junio C Hamano, 20.12.2008:
>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>>
>> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
>> > your topic branch, it is shown as well.
>> >
>> > ------------
>> > -$ git show-branch --reflog='10,1 hour ago' --list master
>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>> > ------------
>>
>> Is this just a personal taste, or a correction to typography?
>
> When using single quotes, the manpage displayed backticks.
It does not seem to do that to me:
$ git help show-branch | grep 10,1 | od -bc
0000000 040 040 040 040 040 040 040 040 040 040 044 040 147 151 164 040
$ g i t
0000020 163 150 157 167 055 142 162 141 156 143 150 040 055 055 162 145
s h o w - b r a n c h - - r e
0000040 146 154 157 147 075 342 200 231 061 060 054 061 040 150 157 165
f l o g = 342 200 231 1 0 , 1 h o u
0000060 162 040 141 147 157 342 200 231 040 055 055 154 151 163 164 040
r a g o 342 200 231 - - l i s t
0000100 155 141 163 164 145 162 012
m a s t e r \n
It does not use ASCII single quote ' (\047) but the result still does
render well enough to keep anybody who are typing, following the printed
examples, from mistaking it from a backquote:
http://pics.livejournal.com/gitster/pic/00009pk0/g6
But in this particular case, because sq/dq does not make any difference to
the example, I am Ok to change it to dq. But I suspect there are many
other places that do need to use sq in examples, so...
^ permalink raw reply
* Re: Applying patches from a patch set
From: Junio C Hamano @ 2008-12-20 20:06 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812200637m49c71aa5x3c25010fa00f4a63@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> Hello,
> I am subscribed to some linux kernel subsystem mailing list; in this
> list there are sometimes patchsets with more than
> 30-40 patches.
> I am using gmail web interface client.
>
> In order to apply a patch set I copy and paste each patch from the
> patchset into a file, and then apply that patch.
> I assume that there is a better way.
> Recently I encountered a fatal error when doing so (and I am not sure
> what caused it).
>
> So my question is: does anyone know a more elegant way of applying a
> large patchset ?
> Maybe there is better mail client with which this process can be done easily ?
First mistake(?) is you seem to be doing copy&paste from browser. Don't.
It can easily damage whitespaces. Find out how your webmail interface
allows you to save selected messages in a mbox and let you download it.
Then
$ git am that-mbox-file
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081220104232.5ff1b7c0@crow>
Mark Burton <markb@ordern.com> writes:
> Is it just an accident of history or by design that whatchanged
> requires the -m option to show changes introduced by merges but
> diff and git log show those changes without requiring any extra
> options?
Mostly personal preference and inertia..
I personally do not see any reason for anybody to use whatchanged (what a
long single-word to type!) since around git version v1.0.0 or so. Back
then, whatchanged was a good way to satisfy "I want a quick sanity check,
but I want to see a bit more than just names of files to assure me. But I
want to get that without actually running the diffs or stats because I
consider that anything that takes more than half a second is too
expensive." But ever since we made the diff generation built-in, the
performance objection ceased to be an issue. These days I'd imagine that
"log --name-only" or even "log --stat" would be perfectly acceptable and
easier to explain alternative, especially if you happen to be a very early
adopter whose fingers are trained to type "whatchanged".
IOW, I consider "whatchanged" a command that is kept only for old timers'
sake. There is no reason to promote it, but there is no reason to
deprecate it, either. Which means the answer to this question...
> Would it not make more sense to have git whatchanged show the changes
> introduced by merges by default and then people can use the (already
> supported) --no-merges option to suppress that behaviour?
... is a NO spelled in capital letters.
^ permalink raw reply
* Re: [PATCH] git-mergetool: properly handle "git mergetool -- filename"
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <593cce2ad8b4d21995b24f0186e846d98306ae60.1229734788.git.davvid@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] Introduce commit notes
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Jeff King
Cc: Robin Rosenberg, Johannes Schindelin, Govind Salinas,
Git Mailing List
In-Reply-To: <20081220082304.GA5693@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Dec 20, 2008 at 12:17:46AM -0800, Junio C Hamano wrote:
>
>> > 1. git am /the/patch
>> > 2. patch -p1 <.git/rebase-apply/patch
>> > 3. manually inspect the results for sanity, and fix up the cache.h
>> > bit that failed totally
>> > 4. git add -u && git add notes.[ch]
>> > 5. git am --resolved
>>
>> I usually skip 2-4 and edit .git/rebase-apply/patch in place instead, and
>> run "git am" instead of step 5.
>
> How do you track down the source of the conflict to do the patch fixup?
Old fashioned way, by looking at the patch and the file that the patch is
supposed to apply and reading the contexts.
^ permalink raw reply
* Re: [PATCH] Remove the requirement opaquelocktoken uri scheme
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <1229753986-5193-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> ...
> This resulted in push failure (often resulted in "cannot lock existing
> info/refs" error message) when talking to a server that does not use
> opaquelocktoken URI scheme.
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Junio C Hamano @ 2008-12-20 20:09 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <loom.20081219T162504-25@post.gmane.org>
Matt Kraai <kraai@ftbfs.org> writes:
> Howdy,
>
> Wu Fengguang <fengguang.wu <at> intel.com> writes:
>> +sub split_addrs {
>> + return parse_line('\s*,\s*', 1, @_);
>> +}
>> +
>
> I'm not sure it's still a good idea to use parse_line. It should work OK for
> now, since split_addrs is only passed one string. If anyone ever tries to pass
> it a list of strings, however, parse_line will ignore all but the first.
Yikes, I should have caught this. As you point out, this is a breakage
waiting to happen until somebody restructures the callers. We should
futureproof it by using quotewords() instead.
^ permalink raw reply
* Re: RFC: Change whatchanged to report changes from merges by default?
From: Mark Burton @ 2008-12-20 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdtewqvy.fsf@gitster.siamese.dyndns.org>
On Sat, 20 Dec 2008 12:09:05 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> IOW, I consider "whatchanged" a command that is kept only for old timers'
> sake. There is no reason to promote it, but there is no reason to
> deprecate it, either. Which means the answer to this question...
>
> > Would it not make more sense to have git whatchanged show the changes
> > introduced by merges by default and then people can use the (already
> > supported) --no-merges option to suppress that behaviour?
>
> ... is a NO spelled in capital letters.
OK (spelled in capital letters), I won't submit the patch.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <7v3agiy5gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-20 12:08 -0800) wrote:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
>> Junio C Hamano, 20.12.2008:
>>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>>> > -$ git show-branch --reflog='10,1 hour ago' --list master
>>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>>> Is this just a personal taste, or a correction to typography?
>>
>> When using single quotes, the manpage displayed backticks.
>
> It does not seem to do that to me:
The single quote (') in asciidoc turns into \' in the man page
typesetting language and its meaning is acute accent (´, U+00B4). In
Ascii-only environment \' is displayed as a single quote but it is still
logically an acute accent. For example, my UTF-8 terminals as well as
Postscript output (man -Tps) display \' as acute accent.
To get the logical single quote the man page source should contain \(aq
or \[aq] . Don't know how to make asciidoc do this.
^ permalink raw reply
* [EGIT PATCH] Tell Eclipse not to convert some of the patch input files.
From: Robin Rosenberg @ 2008-12-20 20:42 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
By default Eclipse silently converts non-UTF-8 characters to
a surrogate code point when it encounters invalid UTF-8. Since
a few of the patch input files are meant to be read as bytes
it is more appropriate and safer to assume ISO-8859-1 which
can represent any byte sequence.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../.settings/org.eclipse.core.resources.prefs | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs b/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
index a2724ba..d691a8e 100644
--- a/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
+++ b/org.spearce.jgit.test/.settings/org.eclipse.core.resources.prefs
@@ -1,3 +1,6 @@
-#Mon Aug 11 16:05:15 PDT 2008
+#Sat Dec 20 21:21:24 CET 2008
eclipse.preferences.version=1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_BothISO88591.patch=ISO-8859-1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_Convert.patch=ISO-8859-1
+encoding//tst-rsrc/org/spearce/jgit/patch/testGetText_DiffCc.patch=ISO-8859-1
encoding/<project>=UTF-8
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 21:02 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Junio C Hamano, git
In-Reply-To: <87tz8yponl.fsf@iki.fi>
Teemu Likonen, 20.12.2008:
> Junio C Hamano (2008-12-20 12:08 -0800) wrote:
>
> > Markus Heidelberg <markus.heidelberg@web.de> writes:
> >
> >> Junio C Hamano, 20.12.2008:
> >>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> >>> > -$ git show-branch --reflog='10,1 hour ago' --list master
> >>> > +$ git show-branch --reflog="10,1 hour ago" --list master
>
> >>> Is this just a personal taste, or a correction to typography?
> >>
> >> When using single quotes, the manpage displayed backticks.
> >
> > It does not seem to do that to me:
>
> The single quote (') in asciidoc turns into \' in the man page
> typesetting language and its meaning is acute accent (´, U+00B4).
Oh, right, it's not a backtick for me, but this acute accent. The other
direction downwards.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Markus Heidelberg @ 2008-12-20 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3agiy5gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.12.2008:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > Junio C Hamano, 20.12.2008:
> >> Markus Heidelberg <markus.heidelberg@web.de> writes:
> >>
> >> > @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
> >> > your topic branch, it is shown as well.
> >> >
> >> > ------------
> >> > -$ git show-branch --reflog='10,1 hour ago' --list master
> >> > +$ git show-branch --reflog="10,1 hour ago" --list master
> >> > ------------
> >>
> >> Is this just a personal taste, or a correction to typography?
> >
> > When using single quotes, the manpage displayed backticks.
>
> It does not seem to do that to me:
>
> $ git help show-branch | grep 10,1 | od -bc
> 0000040 146 154 157 147 075 342 200 231 061 060 054 061 040 150 157 165
> f l o g = 342 200 231 1 0 , 1 h o u
I get this instead:
0000040 145 146 154 157 147 075 302 264 061 060 054 061 040 150 157 165
e f l o g = 302 264 1 0 , 1 h o u
> It does not use ASCII single quote ' (\047) but the result still does
> render well enough to keep anybody who are typing, following the printed
> examples, from mistaking it from a backquote:
>
> http://pics.livejournal.com/gitster/pic/00009pk0/g6
Yes, I was wrong, it wasn't a backtick.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <87tz8yponl.fsf@iki.fi>
Teemu Likonen (2008-12-20 22:39 +0200) wrote:
> To get the logical single quote the man page source should contain \(aq
> or \[aq] . Don't know how to make asciidoc do this.
But \(aq seems to be groff-specific and not necessarily portable. Oh
well, quotation marks are really a mess in man pages. Some reference:
http://www.mail-archive.com/groff@gnu.org/msg04150.html
But char " should be reliable anyway. It renders as Ascii double quote.
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Teemu Likonen @ 2008-12-20 21:37 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Junio C Hamano, git
In-Reply-To: <200812202213.45029.markus.heidelberg@web.de>
Markus Heidelberg (2008-12-20 22:13 +0100) wrote:
> Junio C Hamano, 20.12.2008:
>> f l o g = 342 200 231 1 0 , 1 h o u
^^^^^^^^^^^
This is $E2 $80 $99 in hex and it's the UTF-8 sequence for U+2019 RIGHT
SINGLE QUOTATION MARK (’).
> I get this instead:
> e f l o g = 302 264 1 0 , 1 h o u
^^^^^^^
And this is $C2 $B4 in hex and it's U+00B4 ACUTE ACCENT (´) in UTF-8
encoding. This is what I get too with groff, in terminal and PostScript.
Weird that Junio is getting different output for \' in the man page
source.
But this is nothing yet, Emacs' "M-x woman" renders them as _grave
accents_ aka backticks (`, U+0060 GRAVE ACCENT). Nice.
^ 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