Hi,
René Scharfe wrote:
[Subject: t5004: resurrect original empty tar archive test]
[...]
The different approaches test different things: The existing one is
for empty trees, for which we know the exact expected output and thus
we can simply check it without extracting; the new one is for
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 rather than add a
new selector entry. Arguably the IgnCase option should be
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().
David Aguilar wrote:
Mac OS X Mountain Lion warns that HMAC_Init() and friends are
deprecated. Use CommonCrypto's HMAC to eliminate the warnings.
Makes sense, and if the #define trick stops working some day
due to some conflicting macro in an openssl header some day, it
would just break the
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
On Fri, May 10, 2013 at 11:31 PM, Jonathan Nieder jrnie...@gmail.com wrote:
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?
[..snip...]
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
={}\nfred
On Fri, May 10, 2013 at 11:23 PM, Jonathan Nieder jrnie...@gmail.com 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
W. Trevor King wking at 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,
On Sat, May 11, 2013 at 12:04 AM, Jonathan Nieder jrnie...@gmail.com 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
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 implementation
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
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
On Sat, May 11, 2013 at 1:22 AM, Jeff King p...@peff.net 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
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 --verify-objects:
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 int
On Sat, May 11, 2013 at 1:45 AM, Jeff King p...@peff.net 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
Junio C Hamano venit, vidit, dixit 10.05.2013 19:02:
Michael J Gruber g...@drmicha.warpmail.net 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
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 rather than
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
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 99%
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 an error' '
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 knut.fra...@gmx.de
Thanks, applied, after undoing the linewrapping (done by
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 felipe.contre...@gmail.com
Thanks, applied, with the commit message expanded to say that this
makes
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() so
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
From: Thomas Ackermann th.ac...@arcor.de
Sent: Saturday, May 11, 2013 8:48 AM
W. Trevor King wking at 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
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
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 of
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 j...@keeping.me.uk
---
builtin/tag.c | 10 +-
commit.c | 8
commit.h | 1 +
3 files changed, 10
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 of
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 origin
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 git
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]
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
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
-
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.
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 hvo...@hvoigt.net
---
builtin/config.c | 31 +++---
cache.h
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
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 tbo...@web.de
---
contrib/remote-helpers/test-bzr.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sat, May 11, 2013 at 7:29 AM, Andrey Borzenkov arvidj...@gmail.com 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
(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-manual.PDF uses an
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,
Thomas Rast tr...@inf.ethz.ch 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
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 general
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
From: Thomas Rast tr...@inf.ethz.ch
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 ref is equivalent to ref: doesn't
really help anyone who still needs to read manpages. Clarify
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
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 to
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
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
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
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().
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
These tests will be made to pass by subsequent patches.
Signed-off-by: Johan Herland jo...@herland.net
---
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
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 jo...@herland.net
---
t/t3203-branch-output.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3203-branch-output.sh
In preparation of a future patch which reorganizes how the display of the
ref_list is done.
Signed-off-by: Johan Herland jo...@herland.net
---
builtin/branch.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/builtin/branch.c
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 that
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 only
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 rule
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
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:
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 artag...@gmail.com
---
On Thu, May 9, 2013 at 11:40 AM, Martin Langhoff
martin.langh...@gmail.com 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
Michael J Gruber g...@drmicha.warpmail.net 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
John Keeping j...@keeping.me.uk 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
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
В Sat, 11 May 2013 08:57:14 -0500
Felipe Contreras felipe.contre...@gmail.com пишет:
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
On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Torsten Bögershausen tbo...@web.de 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 tbo...@web.de
Thanks. Is there another one in t/t5551-http-fetch.sh that checks
Thomas Rast tr...@inf.ethz.ch 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
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
Junio C Hamano gits...@pobox.com 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:
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-gui
On 11.05.13 21:45, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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
Torsten Bögershausen tbo...@web.de 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
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 +
@@
On 11.05.13 22:09, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de 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
On Sat, May 11, 2013 at 12:54 PM, John Keeping j...@keeping.me.uk 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
On Sat, May 11, 2013 at 1:48 PM, Andrey Borzenkov arvidj...@gmail.com wrote:
В Sat, 11 May 2013 08:57:14 -0500
Felipe Contreras felipe.contre...@gmail.com пишет:
The problem seems to be that git fast-export updates marks
unconditionally, whether export actually applied or not. So next
On Sat, May 11, 2013 at 11:25 AM, Ramkumar Ramachandra
artag...@gmail.com 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
On Sat, May 11, 2013 at 02:10:01PM -0700, Linus Torvalds wrote:
On Sat, May 11, 2013 at 12:54 PM, John Keeping j...@keeping.me.uk 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
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 artag...@gmail.com
---
You like this more? I don't mind going either way.
On Sat, May 11, 2013 at 5:18 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk 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
On Sat, May 11, 2013 at 5:40 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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 importantly,
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 also
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
Linus Torvalds torva...@linux-foundation.org writes:
On Sat, May 11, 2013 at 2:49 PM, John Keeping j...@keeping.me.uk 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
Ramkumar Ramachandra artag...@gmail.com 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
Torsten Bögershausen tbo...@web.de writes:
On 11.05.13 22:09, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de 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
93 matches
Mail list logo
