Torsten Bögershausen writes:
> On 11.05.13 22:09, Junio C Hamano wrote:
>> Torsten Bögershausen writes:
>>
>>> I did,
>>> the interesting thing is that the test passes with and without your patch.
>>> (After enabling GIT_TEST_LONG and GIT_TEST_HTTPD in both cases)
>>
>> Strange. Do you see d
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If you are introducing "dotest exists but next/last may not be
>> present" as a valid new state, it probably should check the presence
>> and/or absence of them explicitly,
>
> Um, a test -f preceding the cat? Why, when cat implicitly check
Linus Torvalds writes:
> On Sat, May 11, 2013 at 2:49 PM, John Keeping wrote:
>>
>> Hmm... I hadn't realised that. Looking a bit closer, it looks like
>> init_patch_ids sets up its own diffopts so its not affected by the
>> command line (except for pathspecs which would be easy to check for).
>
Sorry for the late reply. I was able to reproduce the problem that you
were describing a while ago. And your patch indeed fixes it. It's a much
more elegant way of dealing with the "absolute vs relative" path problem
that I was trying to fix.
Thanks!
As for Pat, I'm not sure wha'ts going on with
Hi John & Linus,
On Sat, 11 May 2013, Linus Torvalds wrote:
> [...] I really think caching patch ID's should be something people
> should be aware of is fundamentally wrong, even if it might work.
Given the incredible performance win, I would say it is still worth
looking into.
If you store als
Junio C Hamano wrote:
> If you are introducing "dotest exists but next/last may not be
> present" as a valid new state, it probably should check the presence
> and/or absence of them explicitly,
Um, a test -f preceding the cat? Why, when cat implicitly checks
existence anyway?
> but more importa
On Sat, May 11, 2013 at 5:40 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Not really. If we need to avoid the \[\], it makes sense to have a
>> separate function, but what I meant is that this function should be
>> initially on the same file, and created in a separate patch.
>
> Wh
On Sat, May 11, 2013 at 2:49 PM, John Keeping wrote:
>
> Hmm... I hadn't realised that. Looking a bit closer, it looks like
> init_patch_ids sets up its own diffopts so its not affected by the
> command line (except for pathspecs which would be easy to check for).
> Of course that still means it
Felipe Contreras wrote:
> Not really. If we need to avoid the \[\], it makes sense to have a
> separate function, but what I meant is that this function should be
> initially on the same file, and created in a separate patch.
What are you saying?
1. It makes sense to have a separate function spec
On Sat, May 11, 2013 at 5:18 PM, Ramkumar Ramachandra
wrote:
> Add colors suitable for use in the ZSH prompt. Having learnt that the
> ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
> GIT_PS1_SHOWCOLORHINTS with ZSH.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> You like this
Add colors suitable for use in the ZSH prompt. Having learnt that the
ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
GIT_PS1_SHOWCOLORHINTS with ZSH.
Signed-off-by: Ramkumar Ramachandra
---
You like this more? I don't mind going either way.
contrib/completion/git-prompt.sh |
On Sat, May 11, 2013 at 02:10:01PM -0700, Linus Torvalds wrote:
> On Sat, May 11, 2013 at 12:54 PM, John Keeping wrote:
> > This adds a new configuration variable "patchid.cacheRef" which controls
> > whether (and where) patch IDs will be cached in a notes tree.
>
> Patch ID's aren't stable wrt d
On Sat, May 11, 2013 at 11:25 AM, Ramkumar Ramachandra
wrote:
> To facilitate a colored prompt in ZSH, write a thin wrapper around
> git-prompt.sh, factoring out and overriding the coloring logic. Since
> ZSH lacks a PROMPT_COMMAND, instruct the user to execute __git_ps1
> inside precmd().
I thi
On Sat, May 11, 2013 at 1:48 PM, Andrey Borzenkov wrote:
> В Sat, 11 May 2013 08:57:14 -0500
> Felipe Contreras пишет:
>
>> >
>> > The problem seems to be that git fast-export updates marks
>> > unconditionally, whether export actually applied or not. So next time
>> > it assumes everything is al
On Sat, May 11, 2013 at 12:54 PM, John Keeping wrote:
> This adds a new configuration variable "patchid.cacheRef" which controls
> whether (and where) patch IDs will be cached in a notes tree.
Patch ID's aren't stable wrt different diff options, so I think this
is potentially a very bad idea.
On 11.05.13 22:09, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> I did,
>> the interesting thing is that the test passes with and without your patch.
>> (After enabling GIT_TEST_LONG and GIT_TEST_HTTPD in both cases)
>
> Strange. Do you see differences between the produced packed-r
On 05/11/2013 03:25 PM, Torsten Bögershausen wrote:
Sorry, I forgot to mention that there is another test case that fails
in test-bzr.sh (Both Linux and MacOS):
Cloning into 'gitrepo'...
--- ../expected 2013-05-11 20:07:17.678360248 +
+++ actual 2013-05-11 20:07:21.510312073 +
@@ -1,
Torsten Bögershausen writes:
> I did,
> the interesting thing is that the test passes with and without your patch.
> (After enabling GIT_TEST_LONG and GIT_TEST_HTTPD in both cases)
Strange. Do you see differences between the produced packed-refs
file?
--
To unsubscribe from this list: send the
On 11.05.13 21:45, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Thanks. Is there another one in t/t5551-http-fetch.sh that checks
>> the tags?
>
> I think your sed will see the same breakage for the one in 5551 (my
> sed is unfortunately GNU and ".\+" does not break it). Could you
> tes
This adds a new configuration variable "patchid.cacheRef" which controls
whether (and where) patch IDs will be cached in a notes tree.
Caching patch IDs in this way results in a performance improvement in
every case I have tried, for example when comparing the git-gui tree to
git.git (where git-gu
Jeff King writes:
> On Fri, May 10, 2013 at 11:04:01AM -0700, Junio C Hamano wrote:
>
>> One thing to notice is that those accessing rev->pending before
>> calling prepare_revision_walk(), as opposed to those receiving
>> objects in rev->commits via get_revision(), are the only ones that
>> care
Junio C Hamano writes:
> Thanks. Is there another one in t/t5551-http-fetch.sh that checks
> the tags?
I think your sed will see the same breakage for the one in 5551 (my
sed is unfortunately GNU and ".\+" does not break it). Could you
test this patch with:
GIT_TEST_LONG=YesPlease GIT_TE
Hi,
today I'd like to introduce a new tool to manage Git hooks. It's called Mestral
and is available at GitHub: https://github.com/mestral/mestral
It is written in Ruby and inspired by Homebrew (http://brew.sh). It uses Git
itself to load and update hooks and aims to be easy to use for both users
Thomas Rast writes:
> In this case the matching up is trivial, but you can see that it clearly
> shows the added Signoffs and edited parts of message and patch.
>
> Have fun, and let me know if it breaks!
Nice.
I need to do this kind of comparison quite often, when a rerolled
series is received
Torsten Bögershausen writes:
> Using sed -e '/[0-9]\+//' to find "one ore more" digits
> is not portable.
> Use the Basic Regular Expression '/[0-9][0-9]*//' instead
>
> Signed-off-by: Torsten Bögershausen
Thanks. Is there another one in t/t5551-http-fetch.sh that checks
the tags?
> ---
> co
On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> > With the --merge-child option, "git merge-base" will pr
В Sat, 11 May 2013 08:57:14 -0500
Felipe Contreras пишет:
> >
> > The problem seems to be that git fast-export updates marks
> > unconditionally, whether export actually applied or not. So next time
> > it assumes everything is already exported and does nothing.
> >
> > Is it expected behavior?
>
Thanks, pulled.
--
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
John Keeping writes:
> This is helpful when examining branches with disjoint roots, for example
> because one is periodically merged into a subtree of the other.
>
> With the --merge-child option, "git merge-base" will print a
> first-parent ancestor of the first revision given, where the commit
Michael J Gruber writes:
>>> + if (!DIFF_OPT_TOUCHED(&rev->diffopt, ALLOW_TEXTCONV) ||
>>> + !DIFF_OPT_TST(&rev->diffopt, ALLOW_TEXTCONV))
>>> + return stream_blob_to_fd(1, sha1, NULL, 0);
>>
>> It is surprising that the necessary change is only this, but I think
>> it is corre
On Thu, May 9, 2013 at 11:40 AM, Martin Langhoff
wrote:
> With the exaction of the final destination, I want to expire reports
> that are old and successfully transferred.
OK, that took some effort to make work. Make sure you are not using
reflogs (or that reflogs are promptly expired).
# right
To facilitate a colored prompt in ZSH, write a thin wrapper around
git-prompt.sh, factoring out and overriding the coloring logic. Since
ZSH lacks a PROMPT_COMMAND, instruct the user to execute __git_ps1
inside precmd().
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-prompt.sh
Nobody has branch names that end with + or *. Then why put a space
after the branch name and before [*|+][=|<|>] in the prompt string?
Before this, your prompt might have looked like:
artagnon|master *=:~/src/git$
Now, it will look like:
artagnon|master*=:~/src/git$
Signed-off-by: Ram
Hi,
I was using ZSH's vcs_info until now, and just discovered
contrib/completion/git-prompt.sh. Other differences aside, it's
simple enough that I can hack on it.
The first patch strips a small whitespace (we can't waste valuable
real estate on unnecessary whitespace), and the second patch shoul
This patch adds the following patterns for expanding/shortening refs:
"refs/peers/%*"
"refs/peers/%1/tags/%*"
"refs/peers/%1/heads/%*"
These allow shorthand names like "origin/master" to expand to refs in
the refs/peers/* hierarchy (in this case, the likely expansion would be
by the middle
The current branch display code assumes all remote-tracking branches live
inside refs/remotes/*, and that their appropriate shorthand names can be
retrieved by simply stripping off the "refs/remotes/" prefix.
When we add remote-tracking branches in refs/peers/$remote/heads/*, the
code must not onl
When running "git branch -a" (instead of "git branch -r"), we prefix the
remote-tracking branches with "remotes/" to allow the user to more easily
tell them apart from the local branches.
The code that prepended "remotes/" to remote-tracking branches was
located in print_ref_item(), while the code
This adds a testcase for some behavior that I very nearly broke while
refactoring some stuff in builtin/branch.c.
Signed-off-by: Johan Herland
---
t/t3203-branch-output.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
ind
In preparation of a future patch which reorganizes how the display of the
ref_list is done.
Signed-off-by: Johan Herland
---
builtin/branch.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0836
These tests will be made to pass by subsequent patches.
Signed-off-by: Johan Herland
---
t/t7900-working-with-namespaced-remote-refs.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t7900-working-with-namespaced-remote-refs.sh
b/t/t7900-working-with-namespaced-rem
This patch is in preparation for extending the ways in which we expand
shorthand names into full refnames, and shorten full refnames into
unambiguous shorthand names.
We collect the logic for performing the expansion and shortening into two
functions: refname_expand() and refname_shorten(). refnam
Although we definitely support and encourage use of multi-level branch
names, we have never conciously tried to give support for multi-level
remote names. Currently, they are allowed, but there is no evidence that
they are commonly used.
Now, they do provide a source of problems when trying to exp
This test verifies that the following expressions all evaluate to the
full refname "refs/peers/origin/heads/master":
- refs/peers/origin/heads/master
- peers/origin/heads/master
- origin/heads/master
- origin/master
(We assume that there are no other conflicting refs for which the above
expre
Some users are interested in fetching remote refs into a separate namespace
in the local repo. E.g. instead of the usual remote config:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ...
they want to keep remote tags separate from local tags, and they may al
Hi,
Here is the second iteration of the current series for teaching git to
work with remote ref namespaces. This iteration is pretty much a full
rework of the first iteration, based on Junio's comments to the first
iteration, and discussion with other Git developers at the Git Merge
conference in
When we run a regular "git fetch" without arguments, we
update the tracking refs according to the configured
refspec. However, when we run "git fetch origin master" (or
"git pull origin master"), we do not look at the configured
refspecs at all, and just update FETCH_HEAD.
We miss an opportunity t
Each "struct ref" has a boolean flag that is set by the
fetch code to determine whether the ref should be marked as
"not-for-merge" or not when we write it out to FETCH_HEAD.
It would be useful to turn this boolean into a tri-state,
with the third state meaning "do not bother writing it out
to FET
From: Thomas Rast
The documentation erroneously used the same wording for both fetch and
pull, stating that something will be merged even in git-fetch(1).
In addition, saying that " is equivalent to :" doesn't
really help anyone who still needs to read manpages. Clarify what is
actually going o
We have three sequential tests for for whether tracking refs
are updated by various fetches and pulls; the first two
should not update the ref, and the third should. Each test
depends on the state left by the test before.
This is fragile (a failing early test will confuse later
tests), and means w
This is a cleaned-up version of the oft-discussed[1] concept that "git
pull origin master" should update "refs/remotes/origin/master".
It is a little bit of a risky change, in that anybody who deeply cares
about when their tracking ref branches are updated would be impacted.
But I think the genera
Thomas Rast writes:
> Hi,
>
> Spawned by discussion here at git-merge, I created a script that diffs
> the state of branches.
>
> You can grab it from
>
> https://github.com/trast/tbdiff.git
>
> The usage is
>
> git tbdiff A..B C..D
BTW, I should've mentioned this here too (it's in the READM
Hi,
Spawned by discussion here at git-merge, I created a script that diffs
the state of branches.
You can grab it from
https://github.com/trast/tbdiff.git
The usage is
git tbdiff A..B C..D
Make sure to pass two ranges; it doesn't check that at all, and just
hands it off to format-patch, s
> > (1) Very poor html formatting (document type "book" causes
> > ugly TOCs per section and there's a "Part I" without a "Part II")
> > (2) Partly outdated content
> > (3) Sub-optimal structuring (to-do list as part of the document,
> > glossary not at the end of the document)
> > (4) User-manua
On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov wrote:
> I noticed that using git-remote-bzr, but as far as I can tell this is
> generic for all transport helpers using fast-export.
>
>
>
> What happened was "git push" failed due to merge conflict. So far so
> good - but from now on git assumes
В Sat, 11 May 2013 13:36:26 +0100
John Keeping пишет:
> On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:
> > I noticed that using git-remote-bzr, but as far as I can tell this is
> > generic for all transport helpers using fast-export.
> >
> >
> >
> > What happened was "git pu
Using sed -e '/[0-9]\+//' to find "one ore more" digits
is not portable.
Use the Basic Regular Expression '/[0-9][0-9]*//' instead
Signed-off-by: Torsten Bögershausen
---
contrib/remote-helpers/test-bzr.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers
If a config parsing error in a file occurs we can die and let the user
fix the issue. This is different for the buf parsing function since it
can be used to parse blobs of .gitmodules files. If a parsing error
occurs here we should proceed since otherwise a database containing such
an error in a si
This can be used to read configuration values directly from git's
database. For example it is useful for reading to be checked out
.gitmodules files directly from the database.
Signed-off-by: Heiko Voigt
---
builtin/config.c | 31 +++---
cache.h| 6 +++-
config
To simplify adding other sources we extract all functions needed for
parsing into a list of callbacks. We implement those callbacks for the
current file parsing. A new source can implement its own set of callbacks.
Instead of storing the concrete FILE pointer for parsing we store a void
pointer. A
The global variable cf is set with an initialized value in all codepaths before
calling this function.
The complete call graph looks like this:
git_config_from_file
-> do_config_from
-> git_parse_file
-> get_next_char
-> get_value
-> get_next_char
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow new
sources of config data.
Signed-off-by: Heiko Voigt
---
config
Hi,
all the comments to the last iteration[1] incorporated.
You can also find this on my github[2]. This is only for review. I will
resubmit this once 1.8.3 is out.
Cheers Heiko
[1] http://article.gmane.org/gmane.comp.version-control.git/223743
[2] https://github.com/hvoigt/git/commits/hv/strbu
On Sat, May 11, 2013 at 04:29:36PM +0400, Andrey Borzenkov wrote:
> I noticed that using git-remote-bzr, but as far as I can tell this is
> generic for all transport helpers using fast-export.
>
>
>
> What happened was "git push" failed due to merge conflict. So far so
> good - but from now on g
I noticed that using git-remote-bzr, but as far as I can tell this is
generic for all transport helpers using fast-export.
What happened was "git push" failed due to merge conflict. So far so
good - but from now on git assumes everything is up to date.
bor@opensuse:/tmp/test/git> git push origi
This is helpful when examining branches with disjoint roots, for example
because one is periodically merged into a subtree of the other.
With the --merge-child option, "git merge-base" will print a
first-parent ancestor of the first revision given, where the commit
printed is either a merge-base o
This is the same as the in_commit_list function already in builtin/tag.c
so we also replace that by the new commit_list_contains function.
Signed-off-by: John Keeping
---
builtin/tag.c | 10 +-
commit.c | 8
commit.h | 1 +
3 files changed, 10 insertions(+), 9 deleti
This is helpful when examining branches with disjoint roots, for example
because one is periodically merged into a subtree of the other.
With the --merge-child option, "git merge-base" will print a
first-parent ancestor of the first revision given, where the commit
printed is either a merge-base o
Junio C Hamano wrote:
> But the output from passing "-v" before the test that breaks is not
> very useful for two reasons.
I sometimes checkout the Good branch in a different worktree, compare
the output/ state of the passing test with the failing one. I've
never really found the outputs from ear
From: "Thomas Ackermann"
Sent: Saturday, May 11, 2013 8:48 AM
W. Trevor King tremily.us> writes:
I'm also surprised that I couldn't find a more obvious link to the
manual from git-scm.com (I ended up taking a “See Also” link from
gittutorial(7) [3]). I'm not sure if this is intentional or n
I use my own integration branch manager[1] to manage my WIP changes to
various projects, including git.git and one of the features of this is a
--status option that shows whether anything that I'm tracking has been
merged to the base branch I'm building on top of. Since the commit IDs
will be diff
On Sat, May 11, 2013 at 11:59:36AM +0200, Jeff King wrote:
> On Sat, May 11, 2013 at 10:55:31AM +0200, Heiko Voigt wrote:
> > We where not outputting to stdout before so the test is correct there as
> > well. I extended the test when implementing the non-dying version of
> > git_config_with_options
On Sat, Apr 27, 2013 at 05:01:39PM -0500, Felipe Contreras wrote:
> git diff is perfectly able to do this with '-- files', no need for
> manual filtering.
>
> Signed-off-by: Felipe Contreras
Thanks, applied, with the commit message expanded to say that this
makes gettreediffs do the same as getb
On Sat, Apr 27, 2013 at 04:36:13PM +0200, Knut Franke wrote:
> Sometimes it's helpful (at least psychologically) to have this feature
> easily accessible. Code borrows heavily from cherrypick.
>
> Signed-off-by: Knut Franke
Thanks, applied, after undoing the linewrapping (done by your mailer?).
On Sat, May 11, 2013 at 10:55:31AM +0200, Heiko Voigt wrote:
> > > diff --git a/t/t1307-config-blob.sh b/t/t1307-config-blob.sh
> > > index fdc257e..a4929eb 100755
> > > --- a/t/t1307-config-blob.sh
> > > +++ b/t/t1307-config-blob.sh
> > > @@ -55,12 +55,17 @@ test_expect_success 'editing a blob is
On Sat, May 11, 2013 at 02:17:10AM -0700, David Aguilar wrote:
> Good catch. I had a config.mak without any -O flags in CFLAGS.
> Here are the timings with -O3. We're back to parity.
>
> $ time git rev-list --all --objects --verify-objects >/dev/null
>
> # CommonCrypto 28.95s user 4.62s system
How to get rid of reachability races?
This email is meant more as a basis for discussion (including at the
GitMerge conference that is currently running) than as a fully-baked
proposal.
A lot of reachability-related races have been discussed recently:
* If a reference is renamed while a prune is
On Fri, May 10, 2013 at 11:13:22PM -0700, Jonathan Nieder wrote:
> Paul Mackerras wrote:
>
> > I thought I had replied to this patch; maybe I only thought about it.
> >
> > Given that we already have a selector to choose between exact and
> > regexp matching, it seems more natural to use that rath
Junio C Hamano venit, vidit, dixit 10.05.2013 19:02:
> Michael J Gruber writes:
>
>> Currently, "diff" and "cat-file" for blobs honor "--textconv" options
>> (with the former defaulting to "--textconv" and the latter to
>> "--no-textconv") whereas "show" does not honor this option, even though
>>
On Sat, May 11, 2013 at 1:45 AM, Jeff King wrote:
> On Sat, May 11, 2013 at 01:38:32AM -0700, David Aguilar wrote:
>
>> > Adding "--verify-objects" would sha1 the blobs, too, which might be more
>> > reasonable (or running "git fsck"). Something like "git add" on a large
>> > blob would also be a
On Fri, May 10, 2013 at 12:39:37AM +0200, Jeff King wrote:
> On Thu, May 09, 2013 at 06:21:02PM +0200, Heiko Voigt wrote:
>
> > diff --git a/builtin/config.c b/builtin/config.c
> > index 8d01b7a..de32977 100644
> > --- a/builtin/config.c
> > +++ b/builtin/config.c
> > @@ -219,9 +219,11 @@ static i
On Sat, May 11, 2013 at 01:38:32AM -0700, David Aguilar wrote:
> > Adding "--verify-objects" would sha1 the blobs, too, which might be more
> > reasonable (or running "git fsck"). Something like "git add" on a large
> > blob would also be a good test.
>
> Thanks. Here are the numbers with --veri
On Sat, May 11, 2013 at 1:22 AM, Jeff King wrote:
> On Sat, May 11, 2013 at 12:11:05AM -0700, David Aguilar wrote:
>
>> > Does this perform better or worse than just setting
>> > BLK_SHA1=YesPlease? I'd naively think it could go either way: on one
>> > hand adding another library dependency can s
Mac OS X Mountain Lion warns that HMAC_Init() and friends are
deprecated. Use CommonCrypto's HMAC to eliminate the warnings.
Reviewed-by: Jonathan Nieder
Signed-off-by: David Aguilar
---
Rebased to 2/3.
Makefile| 5 +
imap-send.c | 10 ++
2 files changed, 15 insertions(+)
di
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().
Add a COMMON_DIGEST_SHA1 kno
t0070-fundamental.sh fails on Mac OS X 10.8:
$ uname -a
Darwin lustrous 12.2.0 Darwin Kernel Version 12.2.0:
Sat Aug 25 00:48:52 PDT 2012;
root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
$ ./t0070-fundamental.sh -v
fatal: regex bug confirmed: re-build g
On Sat, May 11, 2013 at 12:11:05AM -0700, David Aguilar wrote:
> > Does this perform better or worse than just setting
> > BLK_SHA1=YesPlease? I'd naively think it could go either way: on one
> > hand adding another library dependency can slow down startup, and on
> > the other hand the implement
On Sat, May 11, 2013 at 12:04 AM, Jonathan Nieder wrote:
> David Aguilar wrote:
>
>> expecting success:
>> # if this test fails, re-build git with NO_REGEX=1
>> test-regex
>>
>> fatal: regex bug confirmed: re-build git with NO_REGEX=1
>
> Thanks. Gah. That means that regcomp() with REG_NEWLINE i
W. Trevor King tremily.us> writes:
>
> I'm also surprised that I couldn't find a more obvious link to the
> manual from git-scm.com (I ended up taking a “See Also” link from
> gittutorial(7) [3]). I'm not sure if this is intentional or not,
> since git-scm.com does prominently link Pro Git, and
On Fri, May 10, 2013 at 11:23 PM, Jonathan Nieder wrote:
> 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
David Aguilar wrote:
> expecting success:
> # if this test fails, re-build git with NO_REGEX=1
> test-regex
>
> fatal: regex bug confirmed: re-build git with NO_REGEX=1
Thanks. Gah. That means that regcomp() with REG_NEWLINE is letting
[^={} \t]+
match the newline in
={}\nfre
90 matches
Mail list logo
