On Thu, Aug 30, 2012 at 09:33:48AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The script originally comes from here:
http://thread.gmane.org/gmane.comp.version-control.git/33566/focus=33852
and the discussion implies that the AUTHOR_DATEs were added to avoid
On Sat, Aug 11, 2012 at 11:37:05PM +0200, Sven Strickroth wrote:
Am 11.08.2012 22:53 schrieb René Scharfe:
The standard says we need to convert to CP437, or to UTF-8, or provide
both versions. A more interesting question is: What's supported by which
programs?
The ZIP functionality
On Fri, Aug 31, 2012 at 08:09:34PM +0200, Andreas Schwab wrote:
d...@cray.com writes:
Is status considered a plumbing layer command? Because I have often
wondered why it does not use the pager by default. I pipe it through
less all the time and it's kind of annoying that it works
On Sat, Sep 01, 2012 at 12:25:33AM -0400, Dan Johnson wrote:
diff --git a/builtin/fetch.c b/builtin/fetch.c
index bb9a074..c6bcbdc 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -857,6 +857,10 @@ static void add_options_to_argv(int *argc, const char
**argv)
, let's provide a sanctioned pop function to remove
elements from the end.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/api-argv-array.txt | 4
argv-array.c | 9 +
argv-array.h | 1 +
3 files changed, 14
, this technique is brittle and error-prone, so
let's replace it with a dynamic argv_array.
Signed-off-by: Jeff King p...@peff.net
---
Not very well tested by me, but hopefully it is simple enough that I
managed not to screw it up.
It may be that fetch_populated_submodules would also benefit from
,
but it can be slightly confusing to a reader.
Signed-off-by: Jeff King p...@peff.net
---
Noticed this while I was adding the other free in argv_array_pop...
argv-array.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/argv-array.c b/argv-array.c
index 55e8443..256741d 100644
On Sat, Sep 01, 2012 at 07:32:07AM -0400, Jeff King wrote:
Since the array struct stores a const char ** argv member
(for compatibility with most of our argv-taking functions),
we have to cast away the const-ness when freeing its
elements.
However, we used the wrong type when doing so
On Thu, Sep 06, 2012 at 09:02:17AM +0200, norbert.nemec wrote:
'git blame --follow' seems to be undocumented. The exact behavior is
not clear to me. Perhaps an alias for some combination of '-C' and
'-M'? It seems not be be fully consistent with 'git log --follow'.
Could someone clarify?
On Thu, Sep 06, 2012 at 02:34:00PM +0200, Thomas Gummerer wrote:
On 09/06, Jan-Marek Glogowski wrote:
This adds the test ID (t) prefix to the test result message of
all shell tests. This is especially useful when doing a parallel
check run, where it's currently quite hard to identify
On Thu, Sep 06, 2012 at 12:12:42PM +0200, norbert.nemec wrote:
The option should either be rejected or do *something* documented and
useful. Ideally, it should result in behavior that matches 'git log
--follow' as closely as possible. So maybe, it should be a synonym
for a certain number of
On Thu, Sep 06, 2012 at 02:01:30PM -0700, Jeffrey Middleton wrote:
I'm generally very happy with the fuzzy parsing. It's a great feature
that is designed to and in general does save users a lot of time and
thought. In this case I don't think it does. The problems are:
(1) It's not ignoring
On Sun, Sep 09, 2012 at 03:20:18AM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This patch series depends on the Add some string_list-related
functions series that I just submitted.
Makes sense. The only worry (without reading the series first) I
have is
On Sun, Sep 09, 2012 at 03:44:54PM +0100, David Gould wrote:
static void clear_child_for_cleanup(pid_t pid)
{
struct child_to_clean **last, *p;
last = children_to_clean;
for (p = children_to_clean; p; p = p-next) {
if (p-pid == pid) {
On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
The built-in binary attribute macro expands to -diff -text, so
that textual diff is not produced, and the contents will not go
through any CR/LF conversion ever. During a merge, it should also
choose the binary low-level merge
On Mon, Sep 10, 2012 at 03:58:40PM +0200, Erik Faye-Lund wrote:
for (... {
if (... {
...
}
last = p-next;
}
[...]
I feel like bikeshedding a bit today!
I tend to either prefer either the latter or something like this:
while (p) {
...
On Sat, Sep 08, 2012 at 09:20:48PM +0200, Jan Engelhardt wrote:
On Saturday 2012-09-08 20:59, Junio C Hamano wrote:
diff --git a/daemon.c b/daemon.c
index 4602b46..eaf08c2 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,4 @@
+#include stdbool.h
#include cache.h
#include
On Sun, Sep 09, 2012 at 12:24:58PM -0700, Junio C Hamano wrote:
Having said all that, I am not sure if the fixing is really the
right approach to begin with. Contrast these two:
$ git blame MakeFILE
$ git blame HEAD -- MakeFILE
The latter, regardless of core.ignorecase, should
On Fri, Sep 07, 2012 at 01:49:15PM -0700, Junio C Hamano wrote:
-- 8 --
gitcli: contrast wildcard given to shell and to git
People who are not used to working with shell may intellectually
understand how the command line argument is massaged by the shell
but still have a hard time
On Sat, Sep 08, 2012 at 04:10:59PM +0200, Robin Stocker wrote:
Maybe the solution is to detect if the original commit message
ends with a trailer and in that case keep the existing behavior
of not inserting a blank line?
Yeah, that sounds like a good change from this makes the
On Mon, Sep 10, 2012 at 09:24:17AM -0700, Junio C Hamano wrote:
While we're on the subject, it seems to me that documenting APIs like
these in separate files under Documentation/technical rather than in the
header files themselves
- makes the documentation for a particular function
On Mon, Sep 10, 2012 at 12:46:45PM -0400, Andrew Wong wrote:
Just edit may be a bit misleading, as we already have the edit
action inside the todolist. I'd call this --edit-list to avoid
ambiguity.
I thought that might be a bit confusing too. --edit-list doesn't
seem informative about
On Mon, Sep 10, 2012 at 10:09:43AM -0700, Junio C Hamano wrote:
Does it make sense to join that final paragraph into what is now the
third bullet, and then add your new text (the fourth bullet) after?
I am not sure. After re-reading it, I do not think the fileglob
discussion belongs to
On Mon, Sep 10, 2012 at 07:26:26PM +0200, Joachim Schmitz wrote:
as are non-const array intializers, e.g.:
const char *args[] = { editor, path, NULL };
^
.../git/editor.c, line 39: error(122): expression must have a
constant
On Mon, Sep 10, 2012 at 08:36:43PM +0200, Johannes Sixt wrote:
[1] It does preclude using --edit to make a note about a later commit
while you are in the middle of resolving a conflict or something.
You'd have to do it at the end. I don't know if anybody actually
cares about
On Mon, Sep 10, 2012 at 01:00:35PM -0700, Junio C Hamano wrote:
And to conclude my bikeshedding for the day: Shouldn't last ideally
be called something like prev instead? It's the previously visited
element, not the last element in the list.
It is the last element visited (just as last
On Mon, Sep 10, 2012 at 12:35:05PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I would argue the opposite; if it is about a specific point, then put it
with the point. Otherwise, you are asking the reader to remember back to
an earlier point (that they may not even have
On Mon, Sep 10, 2012 at 08:27:07PM +0200, Joachim Schmitz wrote:
I think it is a mistake to set -std=c89 (or whatever similar option your
compiler supports). Like I said, we are not interested in being strictly
C89-compliant. We are interested in working on real-world systems.
If your
On Mon, Sep 10, 2012 at 01:30:03PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
If the proposal were instead to add a certain type of pathspec that is
case-insensitive[2], that would make much more sense to me. It is not
violating git's case-sensitivity because
On Mon, Sep 10, 2012 at 02:38:08PM -0700, Junio C Hamano wrote:
Thanks, that helped. I got excited when I saw the icase in the
comments and thought it might already be implemented. But it looks like
it is still to be done. :)
Yeah, some are tongue-in-cheek (e.g. I do not know what
On Mon, Sep 10, 2012 at 09:21:12PM +0200, Michael Haggerty wrote:
I'm renaming this thread so that the bikeshedding can get over ASAP.
Thanks. :)
http://tomdoc.org/
Looks much nicer to me than most doxygen I've seen. But again, it's been
a while, so maybe doxygen is nicer than I
compromise; it makes it
clear from just the for loop that this is not an ordinary for-each
traversal. You could hoist the extra pointer out of the conditional and
save one set of parentheses in the if statement, but I don't think it
is a big deal either way.
Acked-by: Jeff King p...@peff.net
Thanks
On Wed, Sep 12, 2012 at 01:55:53AM -0700, Junio C Hamano wrote:
Yeah, that seems like the obviously correct thing to do. In practice,
most files would end up in the first few lines of ll_xdl_merge checking
buffer_is_binary anyway, so I think this would really only make a
difference when
On Wed, Sep 12, 2012 at 12:30:45PM +0200, Yann Droneaud wrote:
The SHA context is holding a temporary buffer for partial block.
This block must 64 bytes long. It is currently described as
an array of 16 integers.
Signed-off-by: Yann Droneaud ydrone...@opteya.com
---
block-sha1/sha1.h |
On Wed, Sep 12, 2012 at 11:32:22PM -0700, Junio C Hamano wrote:
git repack started giving the above warning, and I am guessing
that the recent 11e50b2 (attr: warn on inaccessible attribute files,
2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by
mistake before deciding to append
On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote:
FWIW, it was an output from git-pull-request, which fell back to the
equivalent branch. Usually I check it manually but I forgot it at
this time just before going to a meeting.
This was with git 1.7.11.5. I'll check
On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote:
I am so far taking the silence in the thread to mean they do not mind
seeing the diffstat summary untranslated and they do not mind seeing
it in Klingon, as long as the three numbers are there with (+) and (-)
markings.
On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote:
This reverts the i18n part of 7f81463 (Use correct grammar in diffstat
summary line - 2012-02-01) but still keeps the grammar correctness for
English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on
diffstat -
On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
But it should not be per-command, but per-message, and
should include all output that is not diagnostic and is not
machine-parseable (e.g., what I mentioned above,
On Thu, Sep 13, 2012 at 08:17:20PM +0200, Jens Bauer wrote:
In my home directory, I have a .gitconfig file, here's the interesting part:
[core]
editor = nano
excludesfile = /Users/jens/.gitexcludes
attributesfile = /Users/jens/.gitattributes
[filter cr]
On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
Interesting. I don't get any such warning on repack. And RelNotes points
to a file, so I'm not sure why stat() would make us think it was a dir.
Interesting. The command in question is
git-pack-objects --keep-true-parents
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I suspect we will end up with people not setting i18n.projectlang, and
getting Klingon diffstats on the list.
Yes, but when our starting point is that the diffstat summary is not
meant
On Fri, Sep 14, 2012 at 06:41:45PM +0200, Erik Faye-Lund wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 78c4286..7d1b34b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -129,6 +129,20 @@ export _x05 _x40 _z40 LF
# This test checks if command xyzzy does the right thing...
# '
On Mon, Sep 17, 2012 at 07:55:24PM +0200, Johannes Sixt wrote:
Am 17.09.2012 19:44, schrieb Jeff King:
Oh, bleh. Stupid automatic --tee for valgrind. Try this:
SHELL=/usr/bin/zsh -x ./t-basic.sh --valgrind
I am also doing my tests with dash as my shell. You might try setting
On Sun, Sep 16, 2012 at 09:48:43PM +0200, Erik Faye-Lund wrote:
git-upload-pack: error while loading shared libraries: libiconv.so.2:
cannot open shared object file: No such file or directory
fatal: The remote end hung up unexpectedly
[...]
No. This is not a Git for Windows issue. The
On Mon, Sep 17, 2012 at 03:10:07PM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
But how far should this policy be taken? It seems to me that strict
adherence to the policy would dictate that *.h files should *never*
include other git project files.
I
On Tue, Sep 18, 2012 at 12:11:58PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But even without that, I still think format-patch is a reasonable time
to do it. It is the time when I proof-read my commit message and patch
in its final form, and think do I really want
On Tue, Sep 18, 2012 at 12:47:36PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But even without that, I still think format-patch is a reasonable time
to do it. It is the time when I proof-read my commit message and patch
in its final form, and think do I really want
On Wed, Sep 19, 2012 at 07:08:09PM +0200, Felipe Contreras wrote:
On Tue, Jul 17, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -261,7 +261,12 @@ __gitcomp ()
__gitcomp_nl
On Wed, Sep 19, 2012 at 06:15:11PM +0100, Adam Spiers wrote:
test_failure_ () {
test_failure=$(($test_failure + 1))
- say_color error not ok - $test_count $1
+ say_color error not ok $test_count - $1
Interesting. I wondered what TAP had to say about this, and in fact we
were
On Wed, Sep 19, 2012 at 06:52:20PM +0700, Nguyen Thai Ngoc Duy wrote:
I find it easier to read git log --oneline when the subject lines
align, which they don't when the log is decorated because the
decoration stands before the subject line.
I like it. I turned on log.decorate some time ago,
On Tue, Sep 18, 2012 at 09:38:32PM -0700, Junio C Hamano wrote:
That is a totally wrong message to send. You failed to teach the
reader that there is no need to do anything special to tell the
command to follow per-line origin across renames.
So if anything, I would phrase it this way
On Wed, Sep 19, 2012 at 12:57:28PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We should also consider briefly whether anybody is relying on --oneline
for machine parsing. I think log --oneline is fair game, but I wonder
if people calling rev-list --decorate --oneline
On Wed, Sep 19, 2012 at 09:12:01PM +0100, Adam Spiers wrote:
Sounds reasonable, and I think the new output looks nice. I notice that
skipped tests are still in green. I wonder if they should be in yellow,
too.
What about blue instead? This would keep the colouring scheme more
On Wed, Sep 19, 2012 at 07:55:53PM -0700, Shawn O. Pearce wrote:
From: Shawn O. Pearce spea...@spearce.org
If the user doesn't want to use the dumb HTTP protocol, she may
set GIT_CURL_FALLBACK=0 in the environment before invoking a Git
protocol operation. This is mostly useful when testing
On Wed, Sep 19, 2012 at 08:22:58PM -0700, Shawn O. Pearce wrote:
On Wed, Sep 19, 2012 at 7:55 PM, Shawn O. Pearce spea...@spearce.org wrote:
From: Shawn O. Pearce spea...@spearce.org
I can't explain why git send-email did this. I obviously didn't need
the extra From header here.
On Wed, Sep 19, 2012 at 11:29:34PM -0700, Junio C Hamano wrote:
Shawn O. Pearce spea...@spearce.org writes:
This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.
Retrying without the query parameter was added as a workaround
for a single broken HTTP server at git.debian.org[1].
On Thu, Sep 20, 2012 at 12:24:56PM -0400, Jeff King wrote:
I think Shawn's revert is the right thing to do. But it is not complete
without the manual workaround. I'm putting that patch together now and
should have it out in a few minutes.
And here it is. This goes on top of Shawn's revert
We don't actually care whether the connection is http or
not; what we care about is whether it might be smart http.
Rename the variable to be more accurate, which will make it
easier to later make smart-http optional.
Signed-off-by: Jeff King p...@peff.net
---
remote-curl.c | 6 +++---
1 file
to the workaround. We
assume that the common case is that the server is either
smart-http or a reasonably configured dumb-http. If that is
not the case, we provide both a per-remote config option and
an environment variable with which the user can manually
work around the issue.
Signed-off-by: Jeff King p
On Wed, Sep 19, 2012 at 10:57:35PM -0700, Shawn O. Pearce wrote:
I have been looking into this recently, as well. GitHub does not allow
dumb http at all these days,
Interesting that GitHub doesn't support dumb transfer either.
Our objects are still in regular repos, and is served by
On Thu, Sep 20, 2012 at 10:53:15AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I added the config item as remote.foo.smarthttp. You could also allow
http.$url.smart (and just http.smart, for that matter), which could
be more flexible if you have multiple remotes pointing
On Thu, Sep 20, 2012 at 08:11:52PM +0200, SZEDER Gábor wrote:
In order to achieve that I took bash-completion's quote() function,
which is rather simple, and renamed it to __git_quote() as per Jeff
King's suggestion.
Solves the original problem for me.
Me too. Thanks.
On Thu, Sep 20, 2012 at 02:15:20PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I'm half-tempted to just drop the config entirely, leave
GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
Sounds like a very attractive minimalistic way to go forward
On Thu, Sep 20, 2012 at 04:05:03PM -0700, Shawn O. Pearce wrote:
But right now I am seeing failures in libcurl's SSL connection that
may also be causing the smart connection failures. For example this
trace, where libcurl was just not able to connect to respond to the
401 with a password. I
While we are on the subject of http user experience, I thought I'd
mention this patch to route more errors from index-pack back to the
user. We're not doing it yet at GitHub, but I plan to apply it soon.
The first patch is a cleanup and minor bug fix. The second is the
interesting one. The third
-off-by: Jeff King p...@peff.net
---
I've never actually seen this bug in practice, but I noticed it while
auditing the outputs of receive-pack's children recently.
builtin/receive-pack.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/receive-pack.c b/builtin
are crazy enough to enable it)
more in line with ssh. As a bonus for ssh users,
because the messages are now fed through the sideband
and printed by the local git, they will have remote:
prepended and be properly interleaved with any local
output to stderr.
Signed-off-by: Jeff
but the nested parentheses just make it look
ugly. Let's turn the final line into just:
! [remote rejected] HEAD - master (unpacker error)
Signed-off-by: Jeff King p...@peff.net
---
Maybe it is just me, but I have always found the n/a and extra
parentheses ugly and unnecessary. But obviously
On Thu, Sep 20, 2012 at 11:20:31PM -0400, Cristian Tibirna wrote:
Running the script in attachment produces a git repository in which were
operated a large number of file renames, in which many of the renamed files
(in this particular case all) have the same content but different names.
On Wed, Sep 19, 2012 at 09:24:23PM +0100, Adam Spiers wrote:
t/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5293830..78c88c2 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -182,13 +182,13 @@ then
On Fri, Sep 21, 2012 at 07:05:53AM -0700, Shawn O. Pearce wrote:
I have no further information about the potential GitTogether than
anyone else. IIRC there is a suggestion in this thread about hosting
something in the EU sometime in early next year, with someone at
GitHub acting as organizer.
On Fri, Sep 21, 2012 at 09:49:40AM -0700, Junio C Hamano wrote:
2. No matter what the cause, we are probably better off
showing the errors to the client. If the client and the
server admin are not the same entity, it is probably
much easier for the client to cut-and-paste
On Fri, Sep 21, 2012 at 10:34:22AM -0700, Junio C Hamano wrote:
I'm half-tempted to just drop the config entirely, leave
GIT_SMART_HTTP=false as an escape hatch, and see if anybody even cares.
Sounds like a very attractive minimalistic way to go forward. We
can always add per-remote
On Fri, Sep 21, 2012 at 10:13:09PM +0200, Stefano Lattarini wrote:
On 09/21/2012 09:58 PM, Ramkumar Ramachandra wrote:
Hi again,
Ramkumar Ramachandra wrote:
I was able to reproduce the problem on all my machines, and I consider
this very disturbing. However, I was successfully able
On Sat, Sep 22, 2012 at 02:22:46AM +0530, Ramkumar Ramachandra wrote:
Replace $SHELL with an explicit `/bin/sh`, as some shells do not
support all the features used in the script. For example, ZSH does
not respect IFS, which is used in line 478.
I don't think that is the right thing to do.
On Sat, Sep 22, 2012 at 02:37:38AM +0530, Ramkumar Ramachandra wrote:
I don't think that is the right thing to do. The point of SHELL is to
point at a bourne-compatible shell. On some systems, the main reason to
set it is that /bin/sh is _broken_, and we are trying to avoid it.
But
On Fri, Sep 21, 2012 at 11:08:34PM +0200, Andreas Schwab wrote:
Jeff King p...@peff.net writes:
A bigger question is: why are you setting SHELL=zsh in the first place?
SHELL is set to the login shell by default.
Yeah, sorry, I was thinking this was coming from our $SHELL_PATH
Makefile
On Sat, Sep 22, 2012 at 03:04:50AM +0530, Ramkumar Ramachandra wrote:
No, the #!-header is only information. When you run make test we
actually invoke the shell ourselves using $SHELL_PATH.
My SHELL_PATH is not set, and I can see SHELL_PATH ?= $(SHELL) in the
Makefile. Which shell is it
On Sat, Sep 22, 2012 at 09:37:38AM +1000, Paul J R wrote:
Im not sure if this is a bug, or just as implemented. But when
cloning from a repo sitting on a web site that uses basic auth, the
git client appears to forget its authentication info and ignores the
401's the server is sending back.
On Wed, Sep 19, 2012 at 10:31:58AM -0700, Junio C Hamano wrote:
Torsten Louland torsten.loul...@telenet.be writes:
Installing latest stable git on Mac OS X Mountain Lion is blocked
by Gatekeeper.
Could you provide an installer for latest stable git that is
signed with an Apple issued
On Sat, Sep 22, 2012 at 03:03:58PM +0200, Stefano Lattarini wrote:
On 09/21/2012 10:49 PM, Jeff King wrote:
Oh. It sounds like setting $SHELL to zsh is really the problem, then. If
it is not Bourne-compatible when called as zsh, then it really should
be called in a way that turns
On Mon, Sep 24, 2012 at 02:57:20PM +0200, Michael J Gruber wrote:
Currently, all paths in the config file are subject to tilde expansion
for user paths while the argument to --git-dir is not expanded, and
neither are paths in the environment such as GIT_DIR. From the user
perspective, though,
We've talked off and on about extending the --pretty=format specifiers
to something more flexible. There's also been talk recently of more
flexible commit-filtering (e.g., grepping individual notes). Rather
than invent a new Turing-complete language, I thought I'd try building
on somebody else's
This is a quick hack to make these functions available for
the lua code. It would be way cleaner to move all of the
incremental parsing bits to format-commit.[ch] and clean up
the names (e.g., struct chunk is not nearly descriptive
enough for a global).
Signed-off-by: Jeff King p...@peff.net
the incremental parsing used by the --format parser,
and lazily parse bits of the commit as the lua code requests
them.
Signed-off-by: Jeff King p...@peff.net
---
Set USE_LUA in your Makefile to turn it on.
Makefile | 7 +++
lua-commit.c | 166
With this patch, you can do:
git log --pretty=lua:'
return abbrev(hash()) .. ( .. author().email .. ) .. subject()
'
Signed-off-by: Jeff King p...@peff.net
---
commit.h | 1 +
log-tree.c | 3 ++-
pretty.c | 21 +++--
3 files changed, 22 insertions(+), 3 deletions
On Sun, Sep 23, 2012 at 01:17:43AM -0700, Junio C Hamano wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
... On the other hand, I don't
really wish to turn pretty format machinery into a full feature text
layout engine (by ripping of links/lynx?).
That is very true. We should
On Sat, Sep 22, 2012 at 01:23:56PM -0700, Junio C Hamano wrote:
Michael J Gruber g...@drmicha.warpmail.net writes:
On my mental scratch pad (yeah, that's where the bald spots are) I have
the following more general idea to enhance the revision parser:
--limit-run=script::
On Sun, Sep 23, 2012 at 05:07:04PM +0200, Michael J Gruber wrote:
If we linked with an embeddable scripting language interpreter
(e.g. lua, tcl, guile, ...), it may be a more practical enhancement,
though.
Yes, the idea is extend, don't embed the other way round, so to say. I
still
by git checkout.
While we're sorting out the correct solution, we are much
better with the original bug (people with metacharacters in
their completions occasionally see an error message) than
the current bug (ref completion does not work at all).
Signed-off-by: Jeff King p...@peff.net
---
contrib
On Tue, Sep 25, 2012 at 08:55:23AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Sep 25, 2012 at 7:25 AM, Jeff King p...@peff.net wrote:
+ifdef USE_LUA
+ BASIC_CFLAGS += -DUSE_LUA `pkg-config --cflags lua5.2`
+ EXTLIBS += `pkg-config --libs lua5.2`
+endif
+
I remember we
On Wed, Sep 26, 2012 at 12:37:25AM +0200, SZEDER Gábor wrote:
I looked into this issue, but quickly got lost in quoting-escaping
hell. Ideally we could do some quoting in __gitcomp_nl(), so it would
work for all kinds of input, but I couldn't come up with anything
working. Alternatively, we
We were not testing ref or tree completion at all. Let's
give them even basic sanity checks to avoid regressions.
Signed-off-by: Jeff King p...@peff.net
---
This would have caught the recent breakage, and also paves the way for
testing the new fix.
t/t9902-completion.sh | 41
We correctly handle completion items with spaces just fine,
since we pass the lists around with newline delimiters.
However, we do not handle filenames with shell
metacharacters, as compgen -W performs expansion on the
list we give it.
Signed-off-by: Jeff King p...@peff.net
---
Actually
side of compgen; the next
step will likely be handling the quoting on the output
side of compgen to yield a usable string for the
command line.
Signed-off-by: Jeff King p...@peff.net
---
contrib/completion/git-completion.bash | 14 +-
t/t9902-completion.sh
On Wed, Sep 26, 2012 at 05:51:19PM -0400, Jeff King wrote:
This is not a complete fix, as the completion result does
will still contain metacharacters, so it would need extra
quoting to actually be used on a command line. But it's
still a step in the right direction, because:
[...]
2. We
On Thu, Sep 27, 2012 at 02:37:51AM +0200, SZEDER Gábor wrote:
+# Quotes each element of an IFS-delimited list for shell reuse
+__git_quote()
+{
+ local i
+ local delim
+ for i in $1; do
+ local quoted=${i//\'/\'\\\'\'}
+ printf ${delim:+$IFS}'%s' $quoted
On Thu, Sep 27, 2012 at 02:28:55AM -0400, Jeff King wrote:
Thanks for reminding me to time. I noticed your a31e626 while digging in
the history, but forgot that I wanted to do a timing test. Sadly, the
results are very discouraging. Doing a similar test to your 10,000-refs,
I get:
$ refs
On Thu, Sep 27, 2012 at 07:17:42PM +0700, Nguyen Thai Ngoc Duy wrote:
Operation Index V2 Index VE003
Clone 37530ms (524.06 MiB) 82ms (524.06 MiB)
Fetch (1 commit back) 75ms 107ms
Fetch (10 commits back)
1501 - 1600 of 13736 matches
Mail list logo
