* 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: 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
* [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: 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
* 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] 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: [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 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] 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: 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: 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: [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: 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: 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: 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: 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: 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: 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
* 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: [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
* 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
* [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
* [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 2/4] Add a script to edit/inspect notes
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>
The script 'git notes' allows you to edit and show commit notes, by
calling either
git notes show <commit>
or
git notes edit <commit>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.gitignore | 1 +
Documentation/git-notes.txt | 46 ++++++++++++++++++++++++++++++
Makefile | 1 +
command-list.txt | 1 +
git-notes.sh | 65 +++++++++++++++++++++++++++++++++++++++++++
t/t3301-notes.sh | 65 +++++++++++++++++++++++++++++++++++++++++++
6 files changed, 179 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-notes.txt
create mode 100755 git-notes.sh
create mode 100755 t/t3301-notes.sh
diff --git a/.gitignore b/.gitignore
index 327e660..ac5fbf4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -82,6 +82,7 @@ git-mktag
git-mktree
git-name-rev
git-mv
+git-notes
git-pack-redundant
git-pack-objects
git-pack-refs
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
new file mode 100644
index 0000000..3d93625
--- /dev/null
+++ b/Documentation/git-notes.txt
@@ -0,0 +1,46 @@
+git-notes(1)
+============
+
+NAME
+----
+git-notes - Add/inspect commit notes
+
+SYNOPSIS
+--------
+[verse]
+'git-notes' (edit | show) [commit]
+
+DESCRIPTION
+-----------
+This command allows you to add notes to commit messages, without
+changing the commit. To discern these notes from the message stored
+in the commit object, the notes are indented like the message, after
+an unindented line saying "Notes:".
+
+To disable commit notes, you have to set the config variable
+core.notesRef to the empty string. Alternatively, you can set it
+to a different ref, something like "refs/notes/bugzilla". This setting
+can be overridden by the environment variable "GIT_NOTES_REF".
+
+
+SUBCOMMANDS
+-----------
+
+edit::
+ Edit the notes for a given commit (defaults to HEAD).
+
+show::
+ Show the notes for a given commit (defaults to HEAD).
+
+
+Author
+------
+Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
+Documentation
+-------------
+Documentation by Johannes Schindelin
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index dc0a324..5082f0f 100644
--- a/Makefile
+++ b/Makefile
@@ -258,6 +258,7 @@ SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
+SCRIPT_SH += git-notes.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
diff --git a/command-list.txt b/command-list.txt
index 3583a33..2dc2c33 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -73,6 +73,7 @@ git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
git-mv mainporcelain common
git-name-rev plumbinginterrogators
+git-notes mainporcelain
git-pack-objects plumbingmanipulators
git-pack-redundant plumbinginterrogators
git-pack-refs ancillarymanipulators
diff --git a/git-notes.sh b/git-notes.sh
new file mode 100755
index 0000000..bfdbaa8
--- /dev/null
+++ b/git-notes.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+
+USAGE="(edit | show) [commit]"
+. git-sh-setup
+
+test -n "$3" && usage
+
+test -z "$1" && usage
+ACTION="$1"; shift
+
+test -z "$GIT_NOTES_REF" && GIT_NOTES_REF="$(git config core.notesref)"
+test -z "$GIT_NOTES_REF" && GIT_NOTES_REF="refs/notes/commits"
+
+COMMIT=$(git rev-parse --verify --default HEAD "$@") ||
+die "Invalid commit: $@"
+
+MESSAGE="$GIT_DIR"/new-notes-$COMMIT
+trap '
+ test -f "$MESSAGE" && rm "$MESSAGE"
+' 0
+
+case "$ACTION" in
+edit)
+ GIT_NOTES_REF= git log -1 $COMMIT | sed "s/^/#/" > "$MESSAGE"
+
+ GIT_INDEX_FILE="$MESSAGE".idx
+ export GIT_INDEX_FILE
+
+ CURRENT_HEAD=$(git show-ref "$GIT_NOTES_REF" | cut -f 1 -d ' ')
+ if [ -z "$CURRENT_HEAD" ]; then
+ PARENT=
+ else
+ PARENT="-p $CURRENT_HEAD"
+ git read-tree "$GIT_NOTES_REF" || die "Could not read index"
+ git cat-file blob :$COMMIT >> "$MESSAGE" 2> /dev/null
+ fi
+
+ ${VISUAL:-${EDITOR:-vi}} "$MESSAGE"
+
+ grep -v ^# < "$MESSAGE" | git stripspace > "$MESSAGE".processed
+ mv "$MESSAGE".processed "$MESSAGE"
+ if [ -s "$MESSAGE" ]; then
+ BLOB=$(git hash-object -w "$MESSAGE") ||
+ die "Could not write into object database"
+ git update-index --add --cacheinfo 0644 $BLOB $COMMIT ||
+ die "Could not write index"
+ else
+ test -z "$CURRENT_HEAD" &&
+ die "Will not initialise with empty tree"
+ git update-index --force-remove $COMMIT ||
+ die "Could not update index"
+ fi
+
+ TREE=$(git write-tree) || die "Could not write tree"
+ NEW_HEAD=$(echo Annotate $COMMIT | git commit-tree $TREE $PARENT) ||
+ die "Could not annotate"
+ git update-ref -m "Annotate $COMMIT" \
+ "$GIT_NOTES_REF" $NEW_HEAD $CURRENT_HEAD
+;;
+show)
+ git show "$GIT_NOTES_REF":$COMMIT
+;;
+*)
+ usage
+esac
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
new file mode 100755
index 0000000..ba42c45
--- /dev/null
+++ b/t/t3301-notes.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='Test commit notes'
+
+. ./test-lib.sh
+
+cat > fake_editor.sh << \EOF
+echo "$MSG" > "$1"
+echo "$MSG" >& 2
+EOF
+chmod a+x fake_editor.sh
+VISUAL=./fake_editor.sh
+export VISUAL
+
+test_expect_success 'cannot annotate non-existing HEAD' '
+ ! MSG=3 git notes edit
+'
+
+test_expect_success setup '
+ : > a1 &&
+ git add a1 &&
+ test_tick &&
+ git commit -m 1st &&
+ : > a2 &&
+ git add a2 &&
+ test_tick &&
+ git commit -m 2nd
+'
+
+test_expect_success 'need valid notes ref' '
+ ! MSG=1 GIT_NOTES_REF='/' git notes edit &&
+ ! MSG=2 GIT_NOTES_REF='/' git notes show
+'
+
+test_expect_success 'create notes' '
+ git config core.notesRef refs/notes/commits &&
+ MSG=b1 git notes edit &&
+ test ! -f .git/new-notes &&
+ test 1 = $(git ls-tree refs/notes/commits | wc -l) &&
+ test b1 = $(git notes show) &&
+ git show HEAD^ &&
+ ! git notes show HEAD^
+'
+
+cat > expect << EOF
+commit 268048bfb8a1fb38e703baceb8ab235421bf80c5
+Author: A U Thor <author@example.com>
+Date: Thu Apr 7 15:14:13 2005 -0700
+
+ 2nd
+
+Notes:
+ b1
+EOF
+
+test_expect_success 'show notes' '
+ ! (git cat-file commit HEAD | grep b1) &&
+ git log -1 > output &&
+ git diff expect output
+'
+
+test_done
--
1.6.1.rc3.412.ga72b
^ permalink raw reply related
* [PATCH v2 1/4] Introduce commit notes
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>
Commit notes are blobs which are shown together with the commit
message. These blobs are taken from the notes ref, which you can
configure by the config variable core.notesRef, which in turn can
be overridden by the environment variable GIT_NOTES_REF.
The notes ref is a branch which contains "files" whose names are
the names of the corresponding commits (i.e. the SHA-1).
The rationale for putting this information into a ref is this: we
want to be able to fetch and possibly union-merge the notes,
maybe even look at the date when a note was introduced, and we
want to store them efficiently together with the other objects.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 15 ++++++++++
Makefile | 2 +
cache.h | 3 ++
commit.c | 1 +
config.c | 5 +++
environment.c | 1 +
notes.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++
notes.h | 7 +++++
pretty.c | 5 +++
9 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 notes.c
create mode 100644 notes.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21ea165..b35a32a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -422,6 +422,21 @@ relatively high IO latencies. With this set to 'true', git will do the
index comparison to the filesystem data in parallel, allowing
overlapping IO's.
+core.notesRef::
+ When showing commit messages, also show notes which are stored in
+ the given ref. This ref is expected to contain paths of the form
+ ??/*, where the directory name consists of the first two
+ characters of the commit name, and the base name consists of
+ the remaining 38 characters.
++
+If such a path exists in the given ref, the referenced blob is read, and
+appended to the commit message, separated by a "Notes:" line. If the
+given ref itself does not exist, it is not an error, but means that no
+notes should be print.
++
+This setting defaults to "refs/notes/commits", and can be overridden by
+the `GIT_NOTES_REF` environment variable.
+
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/Makefile b/Makefile
index 5fcff9a..dc0a324 100644
--- a/Makefile
+++ b/Makefile
@@ -370,6 +370,7 @@ LIB_H += ll-merge.h
LIB_H += log-tree.h
LIB_H += mailmap.h
LIB_H += merge-recursive.h
+LIB_H += notes.h
LIB_H += object.h
LIB_H += pack.h
LIB_H += pack-refs.h
@@ -451,6 +452,7 @@ LIB_OBJS += match-trees.o
LIB_OBJS += merge-file.o
LIB_OBJS += merge-recursive.o
LIB_OBJS += name-hash.o
+LIB_OBJS += notes.o
LIB_OBJS += object.o
LIB_OBJS += pack-check.o
LIB_OBJS += pack-refs.o
diff --git a/cache.h b/cache.h
index 9dabcc7..9192853 100644
--- a/cache.h
+++ b/cache.h
@@ -375,6 +375,8 @@ static inline enum object_type object_type(unsigned int mode)
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
#define ATTRIBUTE_MACRO_PREFIX "[attr]"
+#define GIT_NOTES_REF_ENVIRONMENT "GIT_NOTES_REF"
+#define GIT_NOTES_DEFAULT_REF "refs/notes/commits"
extern int is_bare_repository_cfg;
extern int is_bare_repository(void);
@@ -546,6 +548,7 @@ enum rebase_setup_type {
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
+extern char *notes_ref_name;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/commit.c b/commit.c
index c99db16..10e532a 100644
--- a/commit.c
+++ b/commit.c
@@ -5,6 +5,7 @@
#include "utf8.h"
#include "diff.h"
#include "revision.h"
+#include "notes.h"
int save_commit_buffer = 1;
diff --git a/config.c b/config.c
index 790405a..e5d5b4b 100644
--- a/config.c
+++ b/config.c
@@ -469,6 +469,11 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.notesref")) {
+ notes_ref_name = xstrdup(value);
+ return 0;
+ }
+
if (!strcmp(var, "core.pager"))
return git_config_string(&pager_program, var, value);
diff --git a/environment.c b/environment.c
index e278bce..0edae21 100644
--- a/environment.c
+++ b/environment.c
@@ -45,6 +45,7 @@ enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
/* Parallel index stat data preload? */
int core_preload_index = 0;
+char *notes_ref_name;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/notes.c b/notes.c
new file mode 100644
index 0000000..91ec77f
--- /dev/null
+++ b/notes.c
@@ -0,0 +1,68 @@
+#include "cache.h"
+#include "commit.h"
+#include "notes.h"
+#include "refs.h"
+#include "utf8.h"
+#include "strbuf.h"
+
+static int initialized;
+
+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];
+ char *msg;
+ unsigned long msgoffset, msglen;
+ enum object_type type;
+
+ if (!initialized) {
+ const char *env = getenv(GIT_NOTES_REF_ENVIRONMENT);
+ if (env)
+ 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;
+ 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))
+ return;
+
+ if (!(msg = read_sha1_file(sha1, &type, &msglen)) || !msglen ||
+ type != OBJ_BLOB)
+ return;
+
+ if (output_encoding && *output_encoding &&
+ strcmp(utf8, output_encoding)) {
+ char *reencoded = reencode_string(msg, output_encoding, utf8);
+ if (reencoded) {
+ free(msg);
+ msg = reencoded;
+ msglen = strlen(msg);
+ }
+ }
+
+ /* we will end the annotation by a newline anyway */
+ if (msglen && msg[msglen - 1] == '\n')
+ msglen--;
+
+ strbuf_addstr(sb, "\nNotes:\n");
+
+ for (msgoffset = 0; msgoffset < msglen;) {
+ int linelen = strchrnul(msg, '\n') - msg;
+
+ strbuf_addstr(sb, " ");
+ strbuf_add(sb, msg + msgoffset, linelen);
+ msgoffset += linelen;
+ }
+ free(msg);
+}
diff --git a/notes.h b/notes.h
new file mode 100644
index 0000000..79d21b6
--- /dev/null
+++ b/notes.h
@@ -0,0 +1,7 @@
+#ifndef NOTES_H
+#define NOTES_H
+
+void get_commit_notes(const struct commit *commit, struct strbuf *sb,
+ const char *output_encoding);
+
+#endif
diff --git a/pretty.c b/pretty.c
index f6ff312..2d2872f 100644
--- a/pretty.c
+++ b/pretty.c
@@ -6,6 +6,7 @@
#include "string-list.h"
#include "mailmap.h"
#include "log-tree.h"
+#include "notes.h"
static char *user_format;
@@ -881,5 +882,9 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
*/
if (fmt == CMIT_FMT_EMAIL && sb->len <= beginning_of_body)
strbuf_addch(sb, '\n');
+
+ if (fmt != CMIT_FMT_ONELINE)
+ get_commit_notes(commit, sb, encoding);
+
free(reencoded);
}
--
1.6.1.rc3.412.ga72b
^ permalink raw reply related
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