Hi,
David Aguilar wrote:
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the Common Digest SHA-1
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
the build, so this should be safe. For what it's
worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
[...]
This builds upon the patch I sent earlier, so technically it's 2/2
I'm less sure about whether patch 1/2 is a good idea. Luckily the
conflicts when trying to untangle the two are only
David Aguilar wrote:
t0070-fundamental.sh fails on Mac OS X 10.8 by default.
Fix it by using Git's regex library.
Can you say more about the failure? What does
./t0070-fundamental.sh -v
say?
Curious,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the
with NO_REGEX=1 and uname -a output,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Do you know if this has been reported to Apple and
openradar.appspot.com?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Paul Mackerras wrote:
How about changing lines matching:?
Sorry for the slow response. Sounds perfect.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Martin Langhoff wrote:
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?. Then git log -S finds
Hi Eric,
I last sent these patches as an RFC a year and a half or so ago[1].
Nathan seemed to like them and they still seem valid, so thought
I'd resubmit. :)
Thoughts of all kinds welcome, as always.
Jonathan Nieder (1):
git-svn: clarify explanation of --destination argument
Nathan Gray (1
Subversion repositories. Add a note to the
configuration section documenting how this works.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
As before.
Documentation/git-svn.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git
Gray n8g...@n8gray.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Thanks for reading.
Documentation/git-svn.txt | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 6c0988e..68c706d 100644
Ramkumar Ramachandra wrote:
I still don't know exactly what -G and -S do.
If you've been following recent gitk development (or this thread)
closely, you'll know that git log -S finds commits adding/removing a
string, while git log -G finds commits changing lines matching a
regex.
Examples for
Ramkumar Ramachandra wrote:
I've
never really found the outputs from earlier tests enlightening.
If the test suite would automatically use set -x when appropriate
so output for each command was preceded by the command being run,
that
Ramkumar Ramachandra wrote:
What can we do to improve the interface?
Write a better shell? Teach git gui blame to blame on arbitrary
regions instead of single lines? I'm not sure what you're asking,
mostly because I'm not sure who we is.
--
To unsubscribe from this list: send the line
Ramkumar Ramachandra wrote:
Should we mention in the -S documentation that temporary shell script
is the way to get multi-line input?
No, because for almost everyone it isn't.
An example in the EXAMPLES section including an aside that you might
have to hit ^V to enter a tab could be useful,
-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Toralf,
Toralf Förster wrote:
When run that command immediate after git bisect start somebody sees
the full commit range as defined in git bisect start.
However running that command later after few git bisect steps somebody
is just presented with the remaining commit interval.
Is this
Matthieu Moy wrote:
Benoit Person benoit.per...@gmail.com writes:
For now, if the tests suite is run without the fix, the new test
introduces an infinite loop. I am not sure if this should be handled ?
(a timeout of some kind maybe ?)
If the patch fix this, then it's not a really big
What's cooking in git.git (Sep 2013, #07; Mon, 23)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The fifth batch of topics are in
Hi,
Michael S. Tsirkin wrote:
On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
A problem with both schemes, though, is that they are not
backwards-compatible with existing git-patch-id implementations.
[...]
It may be esoteric enough not to worry about, though.
Yeah, I think it
Stefan Beller wrote:
On 09/23/2013 11:10 PM, Jonathan Nieder wrote:
https://repo.or.cz/r/git/jrn.git
[...]
How would I get these changes?
A plain
git fetch https://repo.or.cz/r/git/jrn.git
doesn't work, as it yields:
fatal: unable to access 'https://repo.or.cz/r/git/jrn.git
Stefan Beller wrote:
git fetch https://repo.or.cz/r/git/jrn.git
doesn't work, as it yields:
fatal: unable to access 'https://repo.or.cz/r/git/jrn.git/': server
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
CRLfile: none
Ah, figured it out.
Jeff King wrote:
On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Are these the best definitions of those shortcuts? It seems[1] that some
people define ci as commit -a,
(cc-ing Jeff King, git clone -c inventor)
Hi,
Amit Bakshi wrote:
I'm trying to use this to create a shared repo (group r/w), but it's
not working as expected. The help for git clone says Set a
configuration variable in the newly-created repository; this takes
effect immediately after the
Johan Herland wrote:
Signed-off-by: Johan Herland jo...@herland.net
Thanks.
What symptoms does this alleviate? Is this to allow configurations like
[hooks]
allowNonAscii = 1
and
[hooks]
allowNonAscii
to do the expected thing,
Michael S. Tsirkin wrote:
On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
a) When asked to compute the patch-id of a seekable file, use the
current streaming implementation until you notice a filename that
is out of order. Then start over with sorted hunks
Michael S. Tsirkin wrote:
On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
Then start over with sorted hunks (for example
building a table of offsets within the patch for each hunk to
support this).
[...]
Well, then the result is not compatible
Michael S. Tsirkin wrote:
On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote:
Michael S. Tsirkin wrote:
Just making sure: is it correct that there's no requirement to use same
algorithm between patch-ids.c and builtin/patch-id.c ?
I think so,
[...]
(They already differ
Michael S. Tsirkin wrote:
Subject: [PATCH] doc: don't claim that cherry-pick calls patch-id
s/cherry-pick/cherry/
The id is already different for binary files.
Let's document that they are similar, not identical.
Thanks.
[...]
--- a/Documentation/git-cherry.txt
+++
Michael S. Tsirkin wrote:
On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
Michael S. Tsirkin wrote:
-The commits are compared with their 'patch id', obtained from
-the 'git patch-id' program.
+The diffs are compared with their diff id (sha1) calculated after removing
+any
Michael S. Tsirkin wrote:
See v2 that I sent, maybe that's clear enough.
Yep, looks sensible. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Stefan Näwe wrote:
Stefan Näwe stefan.naewe at atlas-elektronik.com writes:
6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
And to answer myself once more:
That's fixed in
6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not
specified
Sorry for
(cc-ing the Git for Windows maintainers)
Hi,
Wataru Noguchi wrote:
Git for Windows crashes when clone Japanese multibyte repository.
- Japanese Base Encoding is Shift-JIS.
- It happens Japanese multibyte directory name and too-long directory path
- Linux(ex. Ubuntu 13.04 amd64) can clone
Hi,
Keshav Kini wrote:
The man page for `git svn` describes a situation in which 'git svn'
will not be able to rebuild your .git/svn/**/.rev_map files, but no
mention is made of in what circumstances `git svn` *will* be able to do
so, or how to get `git svn` to do so.
This patch adds some
Hi,
Matthieu Moy wrote:
The -- notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
Hm. I am not sure that was just an implementation side-effect.
Normally 'git checkout branch
Hi,
Matthieu Moy wrote:
error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any file(s) known to git.
error: pathspec '--' did not match any file(s) known to git.
This patch fixes it by walking through the argument list to find the
--, and now
What's cooking in git.git (Sep 2013, #08; Wed, 25)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The fifth batch of topics are in
Keshav Kini wrote:
I changed the wording of your first paragraph a bit according to what I
thought it meant. Does it still convey what you wanted to convey, and is
it still correct?
Mapping between Subversion revision numbers and Git commit
names. In a repository where the
(cc-ing Duy, who knows the setup code well)
Manish Gill wrote:
I have a git repository with lots of submodules. In one particular
submodule, I'm having the following problem:
If I try to switch branches at the top-level of that submodule, I succeed.
But, if I try to switch branches in any
Manish Gill wrote:
Jonathan Nieder wrote:
What is the exact command you use to get the above output?
git checkout branch_name
Is branch_name a normal branch, a remote-tracking branch, or a
branch that doesn't exist yet?
[...]
I should mention what *exactly* happened that led to this. I
John Keeping wrote:
The diff-algorithm option to the recursive merge strategy takes the
name of the algorithm as an option, but it uses strcmp on the option
string to check if it starts with diff-algorithm=, meaning that this
options cannot actually be used.
Fix this by switching to
Eric S. Raymond wrote:
Stefan Beller stefanbel...@googlemail.com:
According to
http://thread.gmane.org/gmane.comp.version-control.git/212649
Eric, the original author of ciabot, doesn't want the ciabot
no longer be included in git.git, hence the removal of the
whole directory.
Note: I was
Philip Oakley wrote:
Jonathan,
Did you spot my recent
http://thread.gmane.org/gmane.comp.version-control.git/235127?
Will take a look. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
not use C function names as struct members
mailmap: handle mailmap blobs without trailing newlines
Jharrod LaFon (1):
avoid segfault on submodule.*.path set to an empty true
Johannes Sixt (1):
stream_to_pack: xread does not guarantee to read all requested bytes
Jonathan Nieder (1
Marc Branchaud wrote:
On 13-09-27 02:52 PM, Jonathan Nieder wrote:
The following public repositories all have a copy of the v1.8.4.1
tag and the maint branch that the tag points at:
url = https://googlers.googlesource.com/jrn/git
url = git://repo.or.cz/git/jrn.git
url = git
Nguyễn Thái Ngọc Duy wrote:
commit 6000334 (clone: allow cloning local paths with colons in them -
2013-05-04) is added to make it possible to specify a path that has
colons in it without file://, e.g. ../foo:bar/somewhere. But the check
is a bit loose.
[...]
Make sure we only check so when
Johannes Sixt wrote:
Am 9/27/2013 14:10, schrieb Ramkumar Ramachandra:
+v-s = xstrdup(buf);
+}
These strdupped strings are leaked, right?
The convention seems to be that each refinfo owns its atom_value,
which owns its string
Philip Oakley wrote:
In Junio's recent patch series ([PATCH v3 0/7] Removing the guesswork
of HEAD in clone $gmane/234950), his first patch updated t5505: 'fix
set-head --auto with ambiguous HEAD test'.
A quick look at the git remote man page showed that --auto was not
documented, nor
Keshav Kini wrote:
Jakub Narebski jna...@gmail.com writes:
Matthieu Moy matthieu@imag.fr writes:
* git status now omits the prefix to make its output a comment in a
commit log editor, which is not necessary for human consumption.
+ Scripts that parse the output of git status are
Matthieu Moy wrote:
This file isn't really harmful, but isn't useful either, and can create
minor annoyance for the user:
Would something like the following make sense, to ensure the gc.pid file is
always removed on normal exit?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
diff --git c
Hi,
Stefan Beller wrote:
--- a/Makefile
+++ b/Makefile
@@ -349,7 +349,7 @@ GIT-VERSION-FILE: FORCE
# CFLAGS and LDFLAGS are for the users to override from the command line.
-CFLAGS = -g -O2 -Wall
+CFLAGS = -g -O2 -Wall -Wno-format-zero-length
Thanks for taking this on. Two
Hi,
Marc Strapetz wrote:
On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
I'm looking for a specification or guidelines on how a Git client should
integrate with bug tracking systems.
[...]
Finally, I've created a minimal spec which is sufficient to parse and
display issue
catch. For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Keshav Kini wrote:
Keshav Kini (4):
git-svn.txt: fix AsciiDoc formatting error
git-svn.txt: reword description of gc command
git-svn.txt: replace .git with $GIT_DIR
git-svn.txt: elaborate on rev_map files
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the
Michael Haggerty wrote:
That being said, independent of aliases, there are many other config
settings that can affect commands that might be used in documentation or
scripts, and which also could be the source of errors for the non-vigilent.
Yep, this is a problem, too (I'm looking at you,
Jeff King wrote:
I think we'd be better off to
simply mark up the few callsites. Workarounds are here:
http://article.gmane.org/gmane.comp.version-control.git/230026
Yeah, that looks okay (ugly but tolerable). It's tempting to do
something like
Kirill A. Shutemov wrote:
collapse_todo_ids() uses `git rev-parse --short=7' to abbrev commit ids.
Let's drop argument from --short to use default (7) or config value
instead.
Since the todo ids are expanded immediately after the editor exits,
there is not much risk of accidental hash
John Keeping wrote:
On my system this is in /usr/share/asciidoc/dblatex not
/etc/asciidoc/dblatex. Extract this portion of the path to a variable
so that is can be set in config.mak.
Signed-off-by: John Keeping j...@keeping.me.uk
Thanks. Looks good.
--
To unsubscribe from this list: send
Hi,
Marc Branchaud wrote:
On 13-09-30 10:31 PM, Lucas Sandery [three am design] wrote:
The next and prev buttons are lacking consistency and logic. For LTR
languages previous is almost always on the left, and next on the right. The
words are contradictory, next actually goes to backwards
Hi,
Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
Sign-off?
[...]
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -369,7 +369,10 @@ sub find_netrc_entry {
{
my
Ted Zlatanov wrote:
On Tue, 8 Oct 2013 12:41:47 -0700 Jonathan Nieder jrnie...@gmail.com wrote:
JN Ted Zlatanov wrote:
Simple patch to avoid unitialized warning and log what we'll do.
JN Sign-off?
I didn't realize it was a requirement, must I?
See Documentation/SubmittingPatches, section
Duy Nguyen wrote:
Or maybe it's not that late. How about you go with your patch and add
thin-pack capability to receive-pack too?
When new git push is used against old server, thin pack is disabled.
But that's not a big deal (I hope).
Could we have separate patches to introduce the
Hi Bartek,
bpuzon wrote:
I was wondering if a patch that adds the tag information (something
like what git log --decorate produces) to the git status would
be welcome?
It would slow down git status a little. I haven't thought carefully
about whether that cost is worth it --- it's hard to
Stefan Beller wrote:
On 10/09/2013 09:39 PM, Jonathan Nieder wrote:
Stefan Beller wrote:
This test was put in, but commented out in fed1b5ca (2007-11-09,
git-checkout: Test for relative path use.)
It's been a while since 2007 and the intended test case works now.
(I could not find
Jeff King wrote:
3. The pain in doing the big rebase-test-deploy cycle meant that we
often delayed it, keeping us several versions behind upstream.
This is bad not only for the end product (you aren't getting other
bugfixes from upstream as quickly), but also because the
in test
commands'
+ fi
+}
+
test_run_ () {
+ check_command_chaining_ $1
test_cleanup=:
expecting_failure=$2
setup_malloc_check
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
t/t7512-status
brian m. carlson wrote:
When using GSS-Negotiate authentication with libcurl, the authentication
provided will change every time, and so the probe that git uses to determine
if
authentication is needed is not sufficient to guarantee that data can be sent.
If the data fits entirely in
brian m. carlson wrote:
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1516,6 +1516,15 @@ http.postBuffer::
massive pack file locally. Default is 1 MiB, which is
sufficient for most requests.
+http.continue::
+ Ensure that authentication succeeds
Stefan Saasen wrote:
Signed-off-by: Stefan Saasen ssaa...@atlassian.com
Acked-by: David Aguilar dav...@gmail.com
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi,
David Aguilar wrote:
Felipe Contreras felipe.contre...@gmail.com wrote:
Virtually all packaging guidelines would prefer 1.8.4~rc1, over
1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
In particular, the only packaging we provide, git.spec, generates a
wrong version,
Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
Existing gitk chokes on 'gitk -S foo', but works with 'git -Sfoo'.
I somehow thought that we encourage the stuck/sticked form, to
reduce things the users need to remember to cope better with
Matthieu Moy wrote:
Jens Lehmann jens.lehm...@web.de writes:
static struct lock_file lock_file;
+#define SUBMODULE_WITH_GITDIR ((const char *)1)
I don't like very much hardcoded addresses like this. Are you 100% sure
address 1 will never be returned by xstrdup on any platform? The risk is
Hi,
arnaud.brej...@gmail.com wrote:
Signed-off-by: Arnaud Brejeon arnaud.brejeon at gmail.com
Thanks.
Can you say a little more about the context? Do you run a script that
wants to pass a password to 'git svn', do you type it each time on the
command line, or something else? Is it ok that
Stefan Beller wrote:
On 10/12/2013 09:07 AM, Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Not sure if it's worth by a newcomer. ;)
A second set of eyes is always welcome.
My thoughts: I have to admit I don't see much value in mechanical
replacements
Nicolas Vigier wrote:
the option is optional was confusing as it is not the option but its
argument which is optional.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Thanks.
[...]
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -259,9 +259,10 @@ Each
Nicolas Vigier wrote:
The description of the user.signingkey option only mentioned its use
when creating a signed tag. Make it clear that is is also used when
creating signed commits.
---
Documentation/config.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Thanks.
Ramsay Jones wrote:
These patches don't have too much in common, hence the subject
line, except perhaps that 4 of them fix sparse warnings.
Thanks. These look good.
I tweaked the descriptions a bit to focus on what sparse was warning
about instead of our having quieted sparse. :)
--
To
What's cooking in git.git (Oct 2013, #02; Mon, 14)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Tying up loose ends before the hand-off.
Junio C Hamano wrote:
I'll try:
- slurping your integration branches,
- teasing the topics apart out of your 'pu',
- populating my rerere database to match your confict resolution,
- reconstructing the Meta/Reintegrate insn for 'pu', and
- rebuilding 'pu' to make sure the end result
Jens Lehmann wrote:
Am 15.10.2013 21:16, schrieb Jonathan Nieder:
So I suspect this will fix more scripts than it breaks, though it may
still break some. :/
Hmm, I'm really not sure if we should do this or not.
What convinced me was Anders's observation that the current behavior
can have
Nicolas Vigier wrote:
$ cat /tmp/opt.sh
#!/bin/sh
OPTIONS_SPEC=\
git [options]
--
q,quiet be quiet
S,gpg-sign? GPG-sign commit
echo $OPTIONS_SPEC | git rev-parse --parseopt $parseopt_extra -- $@
Then the following two commands give us the same result :
$
changed, 5 insertions(+), 5 deletions(-)
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
[...]
--- a/compat/regex/regcomp.c
+++ b/compat/regex/regcomp.c
@@ -339,7 +339,7 @@ re_compile_fastmap_iter (regex_t *bufp, const
re_dfastate_t *init_state,
p = buf
Junio C Hamano wrote:
You just made these two that the user clearly meant to express two
different things indistinguishable.
opt.sh -S
opt.sh -S ''
[...]
And that is exactly why gitcli.txt tells users to use the 'sticked'
form, and ends the bullet point with:
An option
importantly, it says why it is failing the test when it fails.)
With or without the changes mentioned above,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks.
diff --git i/t/t3600-rm.sh w/t/t3600-rm.sh
index 8386b54..540c49b 100755
--- i/t/t3600-rm.sh
+++ w/t/t3600-rm.sh
@@ -240,7 +240,7
Hi,
John Keeping wrote:
Since commit d44e712 (pull: support
rebased upstream + fetch + pull --rebase, 2009-07-19), pull has actually
chosen the most recent reflog entry which is an ancestor of the current
branch if it can find one.
Change rebase so that
Hi Andrew,
Andrew Ardill wrote:
There has been plenty of comments lately about how certain features
will be released in 2.0
Have these features been tied together anywhere yet?
They're in Junio's jch branch:
https://github.com/gitster/git/commits/jch
If not, when might such an integration
Nicolas Vigier wrote:
I'm thinking about a patch to add the following two options to rev-parse :
--sticked-opt-args::
Only meaningful in --parseopt mode. Tells the options parser to
output options with optional arguments in sticked form. The
default is to output them in
Philip Oakley wrote:
Would this be a good time to suggest a specific wording should be
proposed (or a reminder of what was proposed repeated) for the
documentation of this option. It will be the documentation that
users will refer to when they need to know, rather than the list
discussions.
). If so, this patch can safely be
reverted. For now, let's not bother the users.
Explained-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Improved-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Junio C Hamano wrote:
Has anything further happened
a pass to
clean up the style of the rest of the script anyway.
The patch as-is is obviously good. Thanks again for the quick
diagnosis and fix.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Philip Oakley wrote:
A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
directly uses `git rev-parse --show-toplevel`, which simply returns
work_tree (static char *work_tree; in environment.c, with comment /*
This is set by setup_git_dir_gently() and/or git_default_config()
Hi,
Anders Waldenborg wrote:
diff.orderfile acts as a default for the -O command line option.
Signed-off-by: Anders Waldenborg and...@0x63.nu
Thanks.
[...]
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -98,6 +98,10 @@ diff.mnemonicprefix::
diff.noprefix::
Junio C Hamano wrote:
+http.continue::
+ Ensure that authentication succeeds before sending the pack data when
+ POSTing data using the smart HTTP transport.
I think we always do that (since v1.7.5-rc0~82^2~1, smart-http: Don't
use Expect: 100-Continue, 2011-02-15), in
Jonathan Nieder wrote:
This series seems to be instead about ensuring that authentication
succeeds before proceding, within the same connection.
(I mean within handling of the same request, not the same connection.)
Using Expect: 100-Continue would also be an alternative way to
support large
-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
() {
$PERL_PATH -pe 'y/\000/Q/'
}
So in practice the PERL prereq just means NO_PERL wasn't set, or
in other words, commands that use perl work. Maybe something
like the following would help?
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
diff --git i/t/README w/t/README
index 2167125
to find POSIXy equivalents). Update the test documentation to
clarify this.
Reported-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+ - PERL
+
+ Git wasn't compiled with NO_PERL=YesPlease
Jeff King wrote:
Speaking of which, is there any reason to use the ugly $PERL_PATH
everywhere, and not simply do:
perl () {
$PERL_PATH $@
}
in test-lib.sh?
Sounds like a nice potential improvement to me. :)
Thanks,
Jonathan
--
To unsubscribe from this list: send the line
...@tuxfamily.org
---
builtin/remote.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
Makes sense. Thanks for noticing.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Hi,
Christian Couder wrote:
Now has_suffix() returns 1 when the suffix is present and 0 otherwise.
Ok. My only worry is that the function is less discoverable since
its name is so different from prefixcmp(), which might cause someone
to invent yet another postfixcmp.
The old name followed
Max Horn wrote:
Well, unlike suffixcmp, it is transitive, so it could be used for sorting.
It is not antisymmetric.
prefixcmp(foo, foobar) 0
prefixcmp(foobar, foo) == 0
I can see how it's possible to care about the sign of the return
value, but it's equally possible to care
Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Specifically:
+ When push.default is set to 'matching', git will push all local
branches\n
+ to the remote branches with the same (matching) name.
invites those who do not read documentation to mistake it with using
an
1201 - 1300 of 2895 matches
Mail list logo
