* Re: [PATCH] Speedup prefixcmp() common case
From: Junio C Hamano @ 2007-12-29 19:32 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550712291001q5f246ceah6700b98308fb96f1@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 79eb10e..e26b684 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -398,6 +398,10 @@ static inline int sane_case
>
> static inline int prefixcmp(const char *str, const char *prefix)
> {
> + // shortcut common case of a single char prefix
> + if (prefix && *(prefix + 1) == '\0' && str)
> + return *str - *prefix;
> +
Why isn't it like this?
if (!prefix[1])
return *str - *prefix;
> return strncmp(str, prefix, strlen(prefix));
> }
>
> --
> 1.5.4.rc2-dirty
^ permalink raw reply
* Re: On the many files problem
From: Junio C Hamano @ 2007-12-29 19:27 UTC (permalink / raw)
To: Yannick Gingras; +Cc: git
In-Reply-To: <87y7bdweca.fsf@enceladus.ygingras.net>
Yannick Gingras <ygingras@ygingras.net> writes:
> Greetings Git hackers,
>
> No doubt, you guys must have discussed this problem before but I will
> pretend that I can't find the relevant threads in the archive because
> Marc's search is kind of crude.
>
> I'm coding an application that will potentially store quite a bunch of
> files in the same directory so I wondered how I should do it. I tried
> a few different files systems and I tried path hashing, that is,
> storing the file that hashes to d3b07384d113 in d/d3/d3b07384d113. As
> far as I can tell, that's what Git does. It turned out to be slower
> than anything except ext3 without dir_index.
We hash like d3/b07384d113, but your understanding of we do is
more or less right.
If we never introduced packed object storage, this issue may
have mattered and we might have looked into it further to
improve the loose object access performance. But in reality, no
sane git user would keep millions of loose objects unpacked.
And changing the layout would mean a backward incompatible
change for dumb transport clients. There is practically no
upside and are downsides to change it now.
Traditionally, avoiding large directories when dealing with a
large number of files by path hashing was a tried and proven
wisdom in many applications (e.g. web proxies, news servers).
Newer filesystems do have tricks to let you quickly access a
large number of files in a single directory, and that lessens
the need for the applications to play path hashing games.
That is a good thing, but if that trick makes the traditional
way of dealing with a large number of files _too costly_, it may
be striking the balance at a wrong point. That is favoring
newly written applications that assume that large directories
are Ok (or ones written by people who do not know the historical
behaviour of filesystems), by punishing existing practices too
heavily.
The person who is guilty of introducing the hashed loose object
store is intimately familiar with Linux. I do not speak for
him, but if I have to guess, the reason he originally chose the
path hashing was because he just followed the tradition, and he
did not want to make the system too dependent on Linux or a
particular feature of underlying filesystems.
^ permalink raw reply
* [PATCH] Optimize prefixcmp()
From: Johannes Schindelin @ 2007-12-29 19:22 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550712291001q5f246ceah6700b98308fb96f1@mail.gmail.com>
Certain codepaths (notably "git log --pretty=format...") use
prefixcmp() extensively, with very short prefixes. In those cases,
calling strlen() is a wasteful operation, so avoid it.
Initial patch by Marco Costalba.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 29 Dec 2007, Marco Costalba wrote:
> In case the prefix string is a single char avoid a costly call
> to strlen() + strncmp()
Could you test this patch, please?
Not only does it avoid the strlen() call also for longer prefixes;
it also avoids a C++ comment.
git-compat-util.h | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..7059cbd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -398,7 +398,11 @@ static inline int sane_case(int x, int high)
static inline int prefixcmp(const char *str, const char *prefix)
{
- return strncmp(str, prefix, strlen(prefix));
+ for (; ; str++, prefix++)
+ if (!*prefix)
+ return 0;
+ else if (*str != *prefix)
+ return (unsigned char)*prefix - (unsigned char)*str;
}
static inline int strtoul_ui(char const *s, int base, unsigned int *result)
--
1.5.2.rc0.4321.gd618
^ permalink raw reply related
* Re: On the many files problem
From: Linus Torvalds @ 2007-12-29 19:12 UTC (permalink / raw)
To: Yannick Gingras; +Cc: git
In-Reply-To: <87y7bdweca.fsf@enceladus.ygingras.net>
On Sat, 29 Dec 2007, Yannick Gingras wrote:
>
> I'm coding an application that will potentially store quite a bunch of
> files in the same directory so I wondered how I should do it. I tried
> a few different files systems and I tried path hashing, that is,
> storing the file that hashes to d3b07384d113 in d/d3/d3b07384d113. As
> far as I can tell, that's what Git does. It turned out to be slower
> than anything except ext3 without dir_index.
Note that git doesn't hash paths because it *wants* to, but because it
*needs* to.
Basically, what git very fundamnentally wants as the basic operation, is
to look up a SHA1 hashed object.
> Quick like that, I would be tempted to say that hashing paths always
> makes things slower but the Git development team includes people with
> really intimate knowledge of several file system implementations so
> I'm tempted to say that you guys know something that I don't.
No, no. The fastest way to store a bunch of files is to basically:
- make the filenames as small as possible
This improves density, and thus performance. You'll get more files to
fit in a smaller directory, and filename compares etc will be faster
too.
If you don't need hashes, but can do with smaller names (for example,
your names are really just sequential, and you can use some base-64
encoding to make them smaller than numbers), you'll always be better
off.
- store them in a good final order. This is debatable, but depending on
your load and the filesystem, it can be better to make sure that you
create all files in order, because performance can plummet if you start
removing files later.
I suspect your benchmark *only* tested this case, but if you want to
check odder cases, try creating a huge directory, and then deleting
most files, and then adding a few new ones. Some filesystems will take
a huge hit because they'll still scan the whole directory, even though
it's mostly empty!
(Also, a "readdir() + stat()" loop will often get *much* worse access
patterns if you've mixed deletions and creations)
- it's generally *much* more efficient to have one large file that you
read and seek in than having many small ones, so if you can change your
load so that you don't have tons of files at all, you'll probably be
better off.
Anyway, git is not a good thing to look at for "lots of files" performance
if you have any options. The reasons git does what it does is:
- as mentioned, the SHA1 hash is the fundamental unit of lookup, so the
name *must* be the hash, since that's all we ever have!
- If you don't have indexing, you really *really* don't want to have a
flat file structure (as your benchmark found out). And git didn't want
to assume you have indexing, since a lot of filesystems don't (I
suspect a lot of ext3 installations _still_ don't enable it, for
example, even if the capability is there!)
So the first point explains the use of hashes for filenames, and the
second point explains the use of a single level of indexing. But neither
of them are about absolute performance per se, both are about basic
requirements.
For good performance, look at the git pack-files. Those are designed to be
data-dense, and only a few files that can be opened and mapped just once.
There, performance was one of the guiding goals (along with the ability to
also use them for streaming, and still being *reasonably* simple, of
course).
Linus
^ permalink raw reply
* Re: [RFH] git-log vs git-rev-list performance
From: Linus Torvalds @ 2007-12-29 18:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550712290418h22d7f7edqda519e7f4dcd25b8@mail.gmail.com>
On Sat, 29 Dec 2007, Marco Costalba wrote:
>
> [marco@localhost linux-2.6]$ time git log --topo-order --no-color
> --parents --boundary -z --log-size
> --pretty=format:"%m%HX%PX%n%an<%ae>%n%at%n%s%n%b" HEAD > /dev/null
Don't compare "--pretty=format" to the pre-formatted versions.
Use "--pretty=raw" for "git log" if you want to approximate "git
rev-list --header".
Or alternatively use the same "--pretty=format:" for git-rev-list.
If you start using anything else, you only have yourself to blame. OF
COURSE it's more expensive to pretty-format the messages.
I get
[torvalds@woody linux]$ time git rev-list \
--pretty=format:"%m%HX%PX%n%an<%ae>%n%at%n%s%n%b" \
--topo-order --parents --boundary --header \
--log-size HEAD > /dev/null
real 0m1.596s
user 0m1.556s
sys 0m0.040s
[torvalds@woody linux]$ time git log \
--pretty=format:"%m%HX%PX%n%an<%ae>%n%at%n%s%n%b" \
--topo-order --parents --boundary \
--log-size HEAD > /dev/null
real 0m1.597s
user 0m1.548s
sys 0m0.048s
so I'd say that with the same output, the timings are pretty much the
same (except "git log" is more capable - "--log-size" does nothing for
"git rev-list", for example).
But if you ask for different formats, they'll have different performance,
even if you then use the same command (ie "git log" will be slower than
"git log" depending on the command line arguments!)
Linus
^ permalink raw reply
* On the many files problem
From: Yannick Gingras @ 2007-12-29 18:22 UTC (permalink / raw)
To: git
Greetings Git hackers,
No doubt, you guys must have discussed this problem before but I will
pretend that I can't find the relevant threads in the archive because
Marc's search is kind of crude.
I'm coding an application that will potentially store quite a bunch of
files in the same directory so I wondered how I should do it. I tried
a few different files systems and I tried path hashing, that is,
storing the file that hashes to d3b07384d113 in d/d3/d3b07384d113. As
far as I can tell, that's what Git does. It turned out to be slower
than anything except ext3 without dir_index. You can see my results
and the benchmarking code that I used here:
http://ygingras.net/b/2007/12/too-many-files:-reiser-fs-vs-hashed-paths
Quick like that, I would be tempted to say that hashing paths always
makes things slower but the Git development team includes people with
really intimate knowledge of several file system implementations so
I'm tempted to say that you guys know something that I don't.
Can you describe how you hash the paths and what trick is done to
ensure fast creating and access to the subdirectories? Is path
hashing generally faster or are you trying to avoid problems for
people using git on baroque file systems?
Best regards,
--
Yannick Gingras
^ permalink raw reply
* [PATCH] Speedup prefixcmp() common case
From: Marco Costalba @ 2007-12-29 18:01 UTC (permalink / raw)
To: Git Mailing List
In case the prefix string is a single char avoid a
costly call to strlen() + strncmp()
With this patch git log with --pretty=format option
is 10% faster
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Some profiling of git-log shows that strbuf_expand() is
called for each commit, and every time checks the
placeholders vector against the current one.
This check is done calling prefixcmp() in a tight loop.
Speeding up prefixcmp() speeds up the whole git-log thing.
NOTE I: I have tried to perform the single char check
directly in the loop, so to avoid to modify prefixcmp()
but the results, although better then the vanilla case,
are not so good. This means that there are other fast
paths that benefit from this optimization of prefixcmp().
NOTE II: currently for _each_ commit is done the whole
check of the --pretty=format against the placeholders vector.
This is clearly suboptimal because the custom format
_never changes_ for the whole git-log run, so some
caching of the parsed format would be surely effective.
Anyhow, as I said before, this change seems to positively
impact other paths apart from the loop in strbuf_expand()
so it seems worth to have anyway.
git-compat-util.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..e26b684 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -398,6 +398,10 @@ static inline int sane_case
static inline int prefixcmp(const char *str, const char *prefix)
{
+ // shortcut common case of a single char prefix
+ if (prefix && *(prefix + 1) == '\0' && str)
+ return *str - *prefix;
+
return strncmp(str, prefix, strlen(prefix));
}
--
1.5.4.rc2-dirty
^ permalink raw reply related
* [PATCH] Documentation: rename gitlink macro to linkgit
From: Dan McGee @ 2007-12-29 16:34 UTC (permalink / raw)
Cc: Miklos Vajna, Junio C Hamano, Eric Hanchrow, git
In-Reply-To: <449c10960712290824yd2c5783l8d0ba91bbad95789@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9586 bytes --]
On 12/29/2007 10:24 AM, Dan McGee wrote:
> On Dec 29, 2007 9:57 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b3c6bdda38f7e370e1f80f02a61f1d3f08c1b57d
>>
>> here is the commit that fixed the problem for pacman. what do you think,
>> should we rename gitlink to something else, too - or should we contact
>> upstream to notify them about they caused a breakage?
>
> I've tried twice now to send a patch to the list...please let me know
> if it isn't working, because I am getting CCed on the send, and the
> mailing list address is set in the sendemail.to variable. I did notice
> that send-email doesn't even prompt you for confirmation of the
> default "to" address if you have this variable set, so I'm not sure if
> something weird is happening there.
>
> -Dan
>From 68bf426e810e732ff3f9f75ffcd69f777b538685 Mon Sep 17 00:00:00 2001
From: Dan McGee <dpmcgee@gmail.com>
Date: Sat, 29 Dec 2007 00:20:38 -0600
Subject: [PATCH] Documentation: rename gitlink macro to linkgit
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
---
Documentation/asciidoc.conf | 8 +-
Documentation/blame-options.txt | 2 +-
Documentation/cmd-list.perl | 2 +-
Documentation/config.txt | 126 +++++++++++++++---------------
Documentation/cvs-migration.txt | 10 +-
Documentation/diff-options.txt | 4 +-
Documentation/everyday.txt | 48 ++++++------
Documentation/fetch-options.txt | 2 +-
Documentation/git-add.txt | 16 ++--
Documentation/git-am.txt | 16 ++--
Documentation/git-annotate.txt | 4 +-
Documentation/git-apply.txt | 12 ++--
Documentation/git-archimport.txt | 2 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-bisect.txt | 2 +-
Documentation/git-blame.txt | 8 +-
Documentation/git-branch.txt | 12 ++--
Documentation/git-bundle.txt | 10 +-
Documentation/git-cat-file.txt | 4 +-
Documentation/git-check-attr.txt | 4 +-
Documentation/git-check-ref-format.txt | 6 +-
Documentation/git-checkout-index.txt | 2 +-
Documentation/git-checkout.txt | 4 +-
Documentation/git-cherry-pick.txt | 4 +-
Documentation/git-cherry.txt | 2 +-
Documentation/git-citool.txt | 6 +-
Documentation/git-clean.txt | 4 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-commit-tree.txt | 6 +-
Documentation/git-commit.txt | 30 ++++----
Documentation/git-config.txt | 2 +-
Documentation/git-count-objects.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/git-cvsimport.txt | 4 +-
Documentation/git-cvsserver.txt | 4 +-
Documentation/git-daemon.txt | 2 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-diff-files.txt | 2 +-
Documentation/git-diff-index.txt | 2 +-
Documentation/git-diff-tree.txt | 2 +-
Documentation/git-diff.txt | 8 +-
Documentation/git-fast-export.txt | 12 ++--
Documentation/git-fast-import.txt | 18 ++--
Documentation/git-fetch-pack.txt | 4 +-
Documentation/git-fetch.txt | 4 +-
Documentation/git-filter-branch.txt | 16 ++--
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-format-patch.txt | 8 +-
Documentation/git-fsck-objects.txt | 2 +-
Documentation/git-fsck.txt | 2 +-
Documentation/git-gc.txt | 14 ++--
Documentation/git-get-tar-commit-id.txt | 4 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-gui.txt | 4 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-help.txt | 6 +-
Documentation/git-http-fetch.txt | 2 +-
Documentation/git-http-push.txt | 2 +-
Documentation/git-imap-send.txt | 2 +-
Documentation/git-index-pack.txt | 10 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 2 +-
Documentation/git-instaweb.txt | 2 +-
Documentation/git-log.txt | 10 +-
Documentation/git-lost-found.txt | 4 +-
Documentation/git-ls-files.txt | 8 +-
Documentation/git-ls-remote.txt | 4 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/git-mailinfo.txt | 4 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge-base.txt | 2 +-
Documentation/git-merge-file.txt | 4 +-
Documentation/git-merge-index.txt | 2 +-
Documentation/git-merge-one-file.txt | 2 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-merge.txt | 8 +-
Documentation/git-mergetool.txt | 4 +-
Documentation/git-mktag.txt | 2 +-
Documentation/git-mktree.txt | 2 +-
Documentation/git-mv.txt | 2 +-
Documentation/git-name-rev.txt | 4 +-
Documentation/git-pack-objects.txt | 10 +-
Documentation/git-pack-redundant.txt | 8 +-
Documentation/git-pack-refs.txt | 2 +-
Documentation/git-parse-remote.txt | 2 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/git-peek-remote.txt | 2 +-
Documentation/git-prune-packed.txt | 6 +-
Documentation/git-prune.txt | 2 +-
Documentation/git-pull.txt | 10 +-
Documentation/git-push.txt | 4 +-
Documentation/git-quiltimport.txt | 2 +-
Documentation/git-read-tree.txt | 8 +-
Documentation/git-rebase.txt | 10 +-
Documentation/git-receive-pack.txt | 4 +-
Documentation/git-reflog.txt | 8 +-
Documentation/git-relink.txt | 2 +-
Documentation/git-remote.txt | 12 ++--
Documentation/git-repack.txt | 14 ++--
Documentation/git-repo-config.txt | 2 +-
Documentation/git-request-pull.txt | 2 +-
Documentation/git-rerere.txt | 4 +-
Documentation/git-reset.txt | 8 +-
Documentation/git-rev-list.txt | 20 +++---
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-revert.txt | 4 +-
Documentation/git-rm.txt | 4 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 6 +-
Documentation/git-sh-setup.txt | 2 +-
Documentation/git-shell.txt | 2 +-
Documentation/git-shortlog.txt | 2 +-
Documentation/git-show-branch.txt | 2 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-show-ref.txt | 6 +-
Documentation/git-show.txt | 8 +-
Documentation/git-stash.txt | 10 +-
Documentation/git-status.txt | 6 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 6 +-
Documentation/git-svn.txt | 12 ++--
Documentation/git-symbolic-ref.txt | 2 +-
Documentation/git-tag.txt | 2 +-
Documentation/git-tar-tree.txt | 2 +-
Documentation/git-unpack-file.txt | 2 +-
Documentation/git-unpack-objects.txt | 2 +-
Documentation/git-update-index.txt | 12 ++--
Documentation/git-update-ref.txt | 2 +-
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 8 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-whatchanged.txt | 2 +-
Documentation/git-write-tree.txt | 2 +-
Documentation/git.txt | 20 +++---
Documentation/gitattributes.txt | 10 +-
Documentation/gitcli.txt | 2 +-
Documentation/gitignore.txt | 6 +-
Documentation/gitk.txt | 6 +-
Documentation/gitmodules.txt | 6 +-
Documentation/glossary.txt | 18 ++--
143 files changed, 460 insertions(+), 460 deletions(-)
Looks like the patch was bigger than I thought. Gzipped and attached if that is acceptable.
[-- Attachment #2: 0001-Documentation-rename-gitlink-macro-to-linkgit.patch.gz --]
[-- Type: application/x-gzip, Size: 36244 bytes --]
^ permalink raw reply
* RE: libcrypto error
From: Hwasung Mars Lee @ 2007-12-29 16:20 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP13D19EDB82ED1407AC5886AE560@CEZ.ICE>
Actually, it appears that the server has libcrypto.so.0.9.8 installed. ldd $(which git-upload-pack) gives:
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7f39000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7dff000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ccd000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7cc9000)
/lib/ld-linux.so.2 (0xb7f67000)
I don't have a clue where something went wrong. Actually, it used to work but doesn't any more.
Mars
----------------------------------------
> Date: Sat, 29 Dec 2007 10:50:22 -0500
> From: seanlkml@sympatico.ca
> To: hwasungmars@hotmail.com
> CC: git@vger.kernel.org
> Subject: Re: libcrypto error
>
> On Sat, 29 Dec 2007 15:05:58 +0000
> Hwasung Mars Lee wrote:
>
>> I have some problems when using git remotely. When I git clone from Ubuntu or Mac to Debian, I get the following message:
>>
>> git-upload-pack: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
>> fatal: unexpected EOF
>> fetch-pack from 'maths:~/Desktop/TeX' failed.
>>
>
> Mars,
>
> It appears the machine from which you're trying to clone is missing the proper libcrypto
> library. You'll need to ensure it is installed using whatever package manager is
> appropriate for your Linux distribution.
>
> The following command will show you which libraries git-upload-pack is using (and missing):
>
> ldd $(which git-upload-pack)
>
> That will likely report that the libcrypto library can't be found and needs to be
> installed.
>
> Good luck,
> Sean
_________________________________________________________________
Telly addicts unite!
http://www.searchgamesbox.com/tvtown.shtml
^ permalink raw reply
* Re: generated HTML contains broken links
From: Dan McGee @ 2007-12-29 16:24 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Eric Hanchrow, git
In-Reply-To: <20071229155705.GA23659@genesis.frugalware.org>
On Dec 29, 2007 9:57 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Dec 28, 2007 at 09:01:17PM -0600, Dan McGee <dpmcgee@gmail.com> wrote:
> > Generated man pages from Junio:
> > HOOKS
> > This command can run commit-msg, pre-commit, and post-commit hooks. See
> > [1]hooks for more information.
> >
> > SEE ALSO
> > git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
> >
> > AUTHOR
> > Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
> > <junkio@cox.net>
> >
> > GIT
> > Part of the git(7) suite
> >
> > Man pages generated locally (with Asciidoc 8.2.3 or 8.2.5):
> > HOOKS
> > This command can run commit-msg, pre-commit, and post-commit hooks. See
> > hooks[5] for more information.
> >
> > SEE ALSO
> > git1[1], git1[2], git1[8], git1[6], git1[9]
> >
> > AUTHOR
> > Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
> > <junkio@cox.net>
> >
> > GIT
> > Part of the git7[10] suite
>
> http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b3c6bdda38f7e370e1f80f02a61f1d3f08c1b57d
>
> here is the commit that fixed the problem for pacman. what do you think,
> should we rename gitlink to something else, too - or should we contact
> upstream to notify them about they caused a breakage?
I've tried twice now to send a patch to the list...please let me know
if it isn't working, because I am getting CCed on the send, and the
mailing list address is set in the sendemail.to variable. I did notice
that send-email doesn't even prompt you for confirmation of the
default "to" address if you have this variable set, so I'm not sure if
something weird is happening there.
-Dan
^ permalink raw reply
* Re: generated HTML contains broken links
From: Miklos Vajna @ 2007-12-29 15:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan McGee, Eric Hanchrow, git
In-Reply-To: <4775B87D.4010507@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On Fri, Dec 28, 2007 at 09:01:17PM -0600, Dan McGee <dpmcgee@gmail.com> wrote:
> Generated man pages from Junio:
> HOOKS
> This command can run commit-msg, pre-commit, and post-commit hooks. See
> [1]hooks for more information.
>
> SEE ALSO
> git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
>
> AUTHOR
> Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
> <junkio@cox.net>
>
> GIT
> Part of the git(7) suite
>
> Man pages generated locally (with Asciidoc 8.2.3 or 8.2.5):
> HOOKS
> This command can run commit-msg, pre-commit, and post-commit hooks. See
> hooks[5] for more information.
>
> SEE ALSO
> git1[1], git1[2], git1[8], git1[6], git1[9]
>
> AUTHOR
> Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
> <junkio@cox.net>
>
> GIT
> Part of the git7[10] suite
http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b3c6bdda38f7e370e1f80f02a61f1d3f08c1b57d
here is the commit that fixed the problem for pacman. what do you think,
should we rename gitlink to something else, too - or should we contact
upstream to notify them about they caused a breakage?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: libcrypto error
From: Sean @ 2007-12-29 15:50 UTC (permalink / raw)
To: Hwasung Mars Lee; +Cc: git
In-Reply-To: <BLU129-W145F3EAD72285347BFF215B3560@phx.gbl>
On Sat, 29 Dec 2007 15:05:58 +0000
Hwasung Mars Lee <hwasungmars@hotmail.com> wrote:
> I have some problems when using git remotely. When I git clone from Ubuntu or Mac to Debian, I get the following message:
>
> git-upload-pack: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
> fatal: unexpected EOF
> fetch-pack from 'maths:~/Desktop/TeX' failed.
>
Mars,
It appears the machine from which you're trying to clone is missing the proper libcrypto
library. You'll need to ensure it is installed using whatever package manager is
appropriate for your Linux distribution.
The following command will show you which libraries git-upload-pack is using (and missing):
ldd $(which git-upload-pack)
That will likely report that the libcrypto library can't be found and needs to be
installed.
Good luck,
Sean
^ permalink raw reply
* libcrypto error
From: Hwasung Mars Lee @ 2007-12-29 15:05 UTC (permalink / raw)
To: git
Hello,
I have some problems when using git remotely. When I git clone from Ubuntu or Mac to Debian, I get the following message:
git-upload-pack: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
fatal: unexpected EOF
fetch-pack from 'maths:~/Desktop/TeX' failed.
I tried googling and the FAQ but nothing helped. Can somebody help me out?
Thanks, Mars.
---
Hwasung Mars Lee
Mathematical Institute,
Oxford University,
24-29 St Giles',
Oxford, OX1 3LB,
United Kingdom
It is by logic that we prove,
but by intuition that we discover.
- Henri Poincaré
_________________________________________________________________
Fancy some celeb spotting?
https://www.celebmashup.com
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Johannes Schindelin @ 2007-12-29 13:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Bernt Hansen, git
In-Reply-To: <7v4pe5nt8m.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 26 Dec 2007, Junio C Hamano wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 090c3e5..d0d83c3 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -215,15 +215,17 @@ make_squash_message () {
> COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
> < "$SQUASH_MSG" | tail -n 1)+1))
> echo "# This is a combination of $COUNT commits."
> - sed -n "2,\$p" < "$SQUASH_MSG"
> + sed -e 1d -e '2,/^./{
> + /^$/d
> + }' <"$SQUASH_MSG"
If I read this correctly (haven't tested), then _all_ empty lines are
removed from the SQUASH_MSG, right? This is not what I want.
I had something like this in mind, rather:
-e '\$s/\n*$/\n/'
This is completely untested, but should show the idea. However, the same
must go into this clause:
> else
> COUNT=2
> echo "# This is a combination of two commits."
> echo "# The first commit's message is:"
> echo
> git cat-file commit HEAD | sed -e '1,/^$/d'
Unfortunately, I am unable to provide a proper patch with proper testing
right now, since my family threatens me with physical violence, should I
not leave the keyboard right n.. OUCH!
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Johannes Schindelin @ 2007-12-29 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Bernt Hansen, git
In-Reply-To: <7vr6h9m2zb.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 26 Dec 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > # commit if necessary
> >
> > Ok, the user has prepared the index for us, and we are going to do some
> > tests and conditionally create commit.
> >
> > git rev-parse --verify HEAD > /dev/null &&
> >
> > Do we have HEAD commit? Why check this --- we do not want to rebase
> > from the beginning of time? No, that's not it. If this fails, there is
> > something seriously wrong. This is not about "will we make a commit?"
> > check at all. This is a basic sanity check and if it fails we must
> > abort, not just skip.
Right. My intention was to have a "|| die" at the end of the && cascade.
> >
> > git update-index --refresh &&
> > git diff-files --quiet &&
> >
> > Is the work tree clean with respect to the index? Why check this --- we
> > want to skip the commit if work tree is dirty? Or is this trying to
> > enforce the invariant that during the rebase the work tree and index and
> > HEAD should all match? If the latter, failure from this again is a
> > reason to abort.
Exactly. I wanted to make sure that the working directory is not
different from what is in the index.
> > ! git diff-index --cached --quiet HEAD -- &&
> >
> > Do we have something to commit? This needs to be checked so that we can
> > skip a commit that results in emptyness, so using this as a check to see
> > if we should commit makes sense.
> >
> > . "$DOTEST"/author-script && {
> > test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> > } &&
> >
> > Find GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The
> > failure from this is a grave problem and reason to abort, isn't it?
> >
> > export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> > git commit --no-verify -F "$DOTEST"/message -e
> >
> > Then we go on to create commit. As you said, failure from this is a
> > grave error.
>
> Any response to this or problems in the clean-up patch?
>
> > ---
> > git-rebase--interactive.sh | 29 +++++++++++++++++++----------
> > 1 files changed, 19 insertions(+), 10 deletions(-)
> >
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 090c3e5..7aa4278 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -363,17 +363,26 @@ do
> >
> > test -d "$DOTEST" || die "No interactive rebase running"
> >
> > - # commit if necessary
> > - git rev-parse --verify HEAD > /dev/null &&
> > - git update-index --refresh &&
> > - git diff-files --quiet &&
> > - ! git diff-index --cached --quiet HEAD -- &&
> > - . "$DOTEST"/author-script && {
> > - test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> > - } &&
> > - export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> > - if ! git commit --no-verify -F "$DOTEST"/message -e
> > + # Sanity check
> > + git rev-parse --verify HEAD >/dev/null ||
> > + die "Cannot read HEAD"
> > + git update-index --refresh && git diff-files --quiet ||
> > + die "Working tree is dirty"
> > +
> > + # do we have anything to commit?
> > + if git diff-index --cached --quiet HEAD --
> > then
> > + : Nothing to commit -- skip this
> > + else
> > + . "$DOTEST"/author-script ||
> > + die "Cannot find the author identity"
> > + if test -f "$DOTEST"/amend
> > + then
> > + git reset --soft HEAD^ ||
> > + die "Cannot rewind the HEAD"
> > + fi
> > + export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> > + git commit --no-verify -F "$DOTEST"/message -e ||
> > die "Could not commit staged changes."
> > fi
Looks good to me! And I'm sorry for taking so long to respond.
Ciao,
Dscho
^ permalink raw reply
* [RFH] git-log vs git-rev-list performance
From: Marco Costalba @ 2007-12-29 12:18 UTC (permalink / raw)
To: Git Mailing List
Hi all,
perhaps this will turn out to be a bit academic, anyway...
I'm almost ready to release qgit-2.1, a lot of improvements went in
but still I cannot beat the speed of stable qgit-1.5 series.
I really profiled this puppy and I think qgit-2.1 is _internally_ much
faster then qgit-1.5, but at the end of the day qgit-1.5 is about 13%
faster then the new 2.1 at loading repositories.
The loading speed is the sum of two factors:
- speed of underlying git-rev-list / git-log command
- qgit overhead in parsing and storing the git plumbing outpt
I think qgit-2.0 code is much more efficient then the old one because
the overhead went down from 17% of qgit-1.5 to current 6% of qgit-2.1,
it means that opening and loading a repository with qgit-2.1 is only
6% slower then running the underlying git command from the command
line.
So the problem seems to be in the underlying command that for qgit-1.5
is git-rev-list while for new qgit-2.1 is git-log
To have some numbers I have tested on the Linux repository with the
actual git commands used by the two versions of qgit:
[marco@localhost linux-2.6]$ git --version
git version 1.5.4-rc1.GIT
[marco@localhost linux-2.6]$ time git log --topo-order --no-color
--parents --boundary -z --log-size
--pretty=format:"%m%HX%PX%n%an<%ae>%n%at%n%s%n%b" HEAD > /dev/null
3.60user 0.09system 0:03.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+27156minor)pagefaults 0swaps
[marco@localhost linux-2.6]$ time git rev-list --topo-order --no-color
--parents --boundary -z --header HEAD > /dev/null
2.89user 0.08system 0:02.98elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+27156minor)pagefaults 0swaps
[ BTW, yes I have a new laptop! ;-) ]
Note that the output is smaller for git-log because --pretty=format
asks for less info then the --header option used by git-rev-list. To
be precise, output is 57.113.153 bytes for git-rev-list against
41.755.328 bytes for git-log.
So the bottom line is that git-log is 24% slower then git-rev-list
although size of its output is 36% smaller!
Could someone be so kind to explain me why these differences? I'm not
so confident with git-log /git-rev-list internals.
Thanks
Marco
^ permalink raw reply
* [PATCH] user-manual: fix typo
From: Gustaf Hendeby @ 2007-12-29 9:52 UTC (permalink / raw)
To: gitster; +Cc: git, Gustaf Hendeby
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f2b4206..3f552e9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -74,7 +74,7 @@ version is called a <<def_commit,commit>>.
Those snapshots aren't necessarily all arranged in a single line from
oldest to newest; instead, work may simultaneously proceed along
-parallel lines of development, called <def_branch,branches>>, which may
+parallel lines of development, called <<def_branch,branches>>, which may
merge and diverge.
A single git repository can track development on multiple branches. It
--
1.5.4.rc2.1.g4bcdb
^ permalink raw reply related
* Re: NIST's policy: sha-1 until 2010, after 2010 sha-2.
From: David Brown @ 2007-12-29 5:07 UTC (permalink / raw)
To: David Symonds; +Cc: J.C. Pizarro, Linus Torvalds, git
In-Reply-To: <ee77f5c20712282045ha230f42n3e68477229deb199@mail.gmail.com>
On Sat, Dec 29, 2007 at 03:45:35PM +1100, David Symonds wrote:
>On Dec 29, 2007 3:27 PM, J.C. Pizarro <jcpiza@gmail.com> wrote:
>> Dear Linus Torvalds,
>>
>> What do you think to do when your git has to change from SHA-1 to SHA-2
>> because of the weaker collision-resistance of SHA-1 in the next years?
>>
>> (e.g. from an damn developer trying to commit a collisioned-SHA-1 file)
>
>It's a non-issue. The closest-to-practical attack method on SHA-1 is a
>collision-finding attack, not a second pre-image attack, which means
>you can find two messages with the same hash. As far as I know,
>there's no significant weakness known for finding a pre-image, which
>would be the most practical way of weakening Git's "security" via
>SHA-1 substitution.
<http://en.wikipedia.org/wiki/Birthday_attack> has some good background on
the "problem".
I suppose when SHA-1 is broken and people can generate arbitrary files with
the same hash, it would be possible to use this to make files that were
annoying to try and use with Git. Git wouldn't have any problem with
normal colliding files, since it hashes the files with a prefix, so the
files would have to be generated specifically for git.
>Regardless, the use of SHA-1 in Git isn't primarily for security,
>though it is a nice side-effect. The SHA-1 is there for reliability in
>addressing and as a good hash.
Given a method for producing a colliding pair for SHA1, it would be
possible to check in a version of a file and later replace it in a
repository with the other version without detection. The current pairs for
MD5 contain blocks of binary data, so this would be fairly obvious if it
got checked into source code.
It would also only replace the blob on a compromised machine. Anyone who
has already pulled the blob wouldn't download the new one.
As far as a collision occurring accidentally, according to the Wiki page
(the math looks right), for a 128-bit hash, 820 billion objects would have
a 10^(-15) probability of a collision. SHA-1 is 160 bits, so the
probability is even lower.
The possible (or even likely) breaking of SHA-1 is only for intentional
collisions. SHA-1 as a non-colliding hash function should be good for
trillions of objects, and that's all in the same repo.
It might be worth tossing around ideas for using a larger hash in a fairly
long-term future, though.
Dave
^ permalink raw reply
* Re: NIST's policy: sha-1 until 2010, after 2010 sha-2.
From: David Symonds @ 2007-12-29 4:45 UTC (permalink / raw)
To: J.C. Pizarro; +Cc: Linus Torvalds, git
In-Reply-To: <998d0e4a0712282027y6e625141jcef90bd38fb83b75@mail.gmail.com>
On Dec 29, 2007 3:27 PM, J.C. Pizarro <jcpiza@gmail.com> wrote:
> Dear Linus Torvalds,
>
> What do you think to do when your git has to change from SHA-1 to SHA-2
> because of the weaker collision-resistance of SHA-1 in the next years?
>
> (e.g. from an damn developer trying to commit a collisioned-SHA-1 file)
It's a non-issue. The closest-to-practical attack method on SHA-1 is a
collision-finding attack, not a second pre-image attack, which means
you can find two messages with the same hash. As far as I know,
there's no significant weakness known for finding a pre-image, which
would be the most practical way of weakening Git's "security" via
SHA-1 substitution.
Regardless, the use of SHA-1 in Git isn't primarily for security,
though it is a nice side-effect. The SHA-1 is there for reliability in
addressing and as a good hash.
Dave.
^ permalink raw reply
* NIST's policy: sha-1 until 2010, after 2010 sha-2.
From: J.C. Pizarro @ 2007-12-29 4:27 UTC (permalink / raw)
To: Linus Torvalds, git
Dear Linus Torvalds,
What do you think to do when your git has to change from SHA-1 to SHA-2
because of the weaker collision-resistance of SHA-1 in the next years?
(e.g. from an damn developer trying to commit a collisioned-SHA-1 file)
http://csrc.nist.gov/groups/ST/hash/policy.html says
NIST's Policy on Hash Functions
-------------------------------
March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224,
SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all
applications using secure hash algorithms. Federal agencies should
stop using SHA-1 for digital signatures, digital time stamping and
other applications that require collision resistance as soon as
practical, and must use the SHA-2 family of hash functions for these
applications after 2010. After 2010, Federal agencies may use SHA-1
only for the following applications: hash-based message authentication
codes (HMACs); key derivation functions (KDFs); and random number
generators (RNGs). Regardless of use, NIST encourages application and
protocol designers to use the SHA-2 family of hash functions for all
new applications and protocols.
^ permalink raw reply
* Re: generated HTML contains broken links
From: Dan McGee @ 2007-12-29 3:01 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: git
In-Reply-To: <87sl1mqt10.fsf@offby1.atm01.sea.blarg.net>
On 12/28/2007 05:49 PM, Eric Hanchrow wrote:
> I'm just starting to play with git, and have checked it out (with "git
> clone git://git.kernel.org/pub/scm/git/git.git"), and built the
> documentation (cd Documentation; make), on Cygwin. I notice that the
> generated HTML docs are full of broken links -- for example, my file
> C:/cygwin/usr/local/src/git/Documentation/git.html includes this:
>
> git<a href="git-instaweb">1</a>
>
> but there is no document named "git-instaweb" on my disk; instead,
> it's named "git-instaweb.html".
>
> I'm using asciidoc version 8.2.4, if it matters.
We noticed this with the upgrade from Asciidoc 8.2.2 -> 8.2.3 on our project. It is broken in both the manpages and the HTML generated documentation. I've included an example below. So far, I haven't had luck tracking down the reason but I am looking into trying to fix this tonight. If anyone else is better with this stuff, it would be great if you could take a look.
Relevant email on the pacman-dev list [1]:
On Nov 9, 2007 4:05 PM, Andrew Fyfe <andrew@neptune-one.net> wrote:
> Did little digging, the breakage/change is in now asciidoc converts from asciidoc to xml (so it's
> not docbook-xsl). In 8.2.2 manlink:pacman.conf[5] expands to
>
> <citerefentry><refentrytitle>pacman.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
>
> in 8.2.3 it expands to
>
> man<ulink url="pacman.conf">5</ulink>,
Note that manlink is basically just a renamed gitlink, and can be found here:
<http://projects.archlinux.org/git/?p=pacman.git;a=blob;f=doc/asciidoc.conf>
-Dan
[1] <http://archlinux.org/pipermail/pacman-dev/2007-November/009937.html>
Generated man pages from Junio:
HOOKS
This command can run commit-msg, pre-commit, and post-commit hooks. See
[1]hooks for more information.
SEE ALSO
git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)
AUTHOR
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
<junkio@cox.net>
GIT
Part of the git(7) suite
Man pages generated locally (with Asciidoc 8.2.3 or 8.2.5):
HOOKS
This command can run commit-msg, pre-commit, and post-commit hooks. See
hooks[5] for more information.
SEE ALSO
git1[1], git1[2], git1[8], git1[6], git1[9]
AUTHOR
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
<junkio@cox.net>
GIT
Part of the git7[10] suite
^ permalink raw reply
* generated HTML contains broken links
From: Eric Hanchrow @ 2007-12-28 23:49 UTC (permalink / raw)
To: git
I'm just starting to play with git, and have checked it out (with "git
clone git://git.kernel.org/pub/scm/git/git.git"), and built the
documentation (cd Documentation; make), on Cygwin. I notice that the
generated HTML docs are full of broken links -- for example, my file
C:/cygwin/usr/local/src/git/Documentation/git.html includes this:
git<a href="git-instaweb">1</a>
but there is no document named "git-instaweb" on my disk; instead,
it's named "git-instaweb.html".
I'm using asciidoc version 8.2.4, if it matters.
--
I write [from 5 AM to 7 AM] to discover what I think. After
all, the bars aren't open that early.
-- Daniel Boorstin, former Librarian of Congress
^ permalink raw reply
* [PATCH] git-sh-setup: document git_editor() and get_author_ident_from_commit()
From: Miklos Vajna @ 2007-12-29 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vlk7ecp58.fsf@gitster.siamese.dyndns.org>
These 2 functions were missing from the manpage.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Dec 28, 2007 at 04:37:07PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> unusable, so I'd reword it like this:
here it is.
VMiklos
Documentation/git-sh-setup.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index 1ea1faa..505b4c9 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -44,6 +44,11 @@ set_reflog_action::
end-user action in the reflog, when the script updates a
ref.
+git_editor::
+ runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or
+ EDITOR) on a given file, but error out if no editor is specified
+ and the terminal is dumb.
+
is_bare_repository::
outputs `true` or `false` to the standard output stream
to indicate if the repository is a bare repository
@@ -57,6 +62,10 @@ require_work_tree::
if so. Used by scripts that require working tree
(e.g. `checkout`).
+get_author_ident_from_commit::
+ outputs code for use with eval to set the GIT_AUTHOR_NAME,
+ GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
+
Author
------
--
1.5.4.rc2-dirty
^ permalink raw reply related
* Re: [PATCH] git-sh-setup: document git_editor() and get_author_ident_from_commit()
From: Junio C Hamano @ 2007-12-29 0:37 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1198880739-8480-1-git-send-email-vmiklos@frugalware.org>
Thanks.
"proper editor" felt a bit funny, and also it needs to be
documented that it refuses to proceed when the default editor is
unusable, so I'd reword it like this:
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index 1ea1faa..505b4c9 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -44,6 +44,11 @@ set_reflog_action::
end-user action in the reflog, when the script updates a
ref.
+git_editor::
+ runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or
+ EDITOR) on a given file, but error out if no editor is specified
+ and the terminal is dumb.
+
is_bare_repository::
outputs `true` or `false` to the standard output stream
to indicate if the repository is a bare repository
^ permalink raw reply related
* Re: reflog weirdness
From: Junio C Hamano @ 2007-12-29 0:06 UTC (permalink / raw)
To: Thien-Thi Nguyen; +Cc: git
In-Reply-To: <87fxxme8x9.fsf@ambire.localdomain>
Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> () Junio C Hamano <gitster@pobox.com>
> () Fri, 28 Dec 2007 14:01:55 -0800
>
> Was it a buggy "git commit" command, or a bad commit log
> message was fed to "git commit" by the user, and there is
> nothing for me to worry about?
>
> i'm sorry, even though it was only a couple days ago, the actual
> events are far back in my memory, so i can't say. i wouldn't
> worry about it -- probably user error. (i'm new w/ git. most of
> the time i drive it from w/in emacs, which is well behaved; it is
> when i leave that comparative safety to do some flailing from the
> command-line that things go weird.)
>
> i suppose one way to improve git would be to test how it handles
> interruption (control-c in the middle of a commit, for example).
> a bit tricky to arrange (reproducibly), though...
>
> now i go search the docs for how to replace that log message.
"git-rebase -i"
^ 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