Guess you are fine? I have been trying to reach you!
s is that we are just exposing a pre-existing bug in our Solaris
build of libpcre. Unaligned memory accesses on x86 / x86_64 "only" cause
performance issues rather than fatal signals so even if the same bug
exists on Linux it probably has no noticeable effect (or at least no
noticed effect).
Charles.
From: Charles Bailey <cbaile...@bloomberg.net>
If you have a pcre1 library which is compiled with JIT enabled then
PCRE_STUDY_JIT_COMPILE will be defined whether or not the
NO_LIBPCRE1_JIT configuration is set.
This means that we enable JIT functionality when calling pcre_stud
From: Charles Bailey <cbaile...@bloomberg.net>
The test for '--abbrev' in t4201-shortlog.sh assumes that the commits
generated in the test can always be uniquely abbreviated to 5 hex digits
but this is not always the case. If you were unlucky and happened to run
the test at (say) Thu Jun 22
Hi ,
Would you be interested in the "Attendees list of Society for Neuroscience -
SfN-2017"
Let me know your interest to send you the number of Attendees and cost .
Regards,
Donald Charles,
If you do not wish to receive future emails from us, please reply as 'leave
out'.
<>
use it co-operates with the mailing list
conventions a lot better.
In this case, this is a follow on from a cbaile...@bloomberg.net patch
so crediting that address seems the more appropriate option.
Charles.
and http.sslKey, I see no reason that they
shouldn't also use git_config_pathname. If I'd been more thorough I
would have proposed this at the time.
Charles.
to think about any projects which you would like tackled at
this event. Obviously, projects should be completable by small teams
inside of a weekend.
Charles.
---
Git was the first project for which we hosted an "Open Source Day" and
since then we've learned a lot and would like to revisit
are closer to New
York or London and if you have any date restrictions.
Charles.
---
Git was the first project for which we hosted an "Open Source Day" and
since then we've learned a lot and would like to revisit Git again.
The event will involve volunteers who are usually competent p
On Thu, Jul 07, 2016 at 02:21:28PM -0700, Junio C Hamano wrote:
> Charles Bailey <char...@hashpling.org> writes:
>
> > I just wanted to clarify what was actually fixed. The actual bug that
> > was reported and fixed was the fact that 'git grep' (without --cached)
> >
On Wed, Jul 06, 2016 at 02:39:26PM -0700, Junio C Hamano wrote:
> * nd/ita-cleanup (2016-07-01) 3 commits
> (merged to 'next' on 2016-07-06 at f15aeba)
> + grep: fix grepping for "intent to add" files
> + t7810-grep.sh: fix a whitespace inconsistency
> + t7810-grep.sh: fix duplicated test
Signed-off-by: Charles Bailey <char...@hashpling.org>
---
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1e72971..c4302ed 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -353,7 +353,7 @@ test_expect_success
r for
something. In effect, we are applying the "contents indeterminate" state
of the index to the working tree file.
Charles Bailey (3):
t7810-grep.sh: fix duplicated test name
t7810-grep.sh: fix a whitespace inconsistency
grep: fix grepping for "intent to add" files
Signed-off-by: Charles Bailey <char...@hashpling.org>
---
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index c4302ed..6e6eaa4 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -175,7 +175,7
From: Charles Bailey <cbaile...@bloomberg.net>
This reverts commit 4d5520053 (grep: make it clear i-t-a entries are
ignored, 2015-12-27) and adds an alternative fix to maintain the -L
--cached behavior.
4d5520053 caused 'git grep' to no longer find matches in new files in
the working tree
Signed-off-by: Charles Bailey <char...@hashpling.org>
---
Spotted while testing t7810-grep and grep "i-t-a" fixes.
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1e72971..c4302ed 100755
--- a/t/t7810
From: Charles Bailey <cbaile...@bloomberg.net>
This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e and adds an
alternative fix to maintain the -L --cached behavior.
4d5520053 caused 'git grep' to no longer find matches in new files in
the working tree where the corresponding index
On Thu, Jun 16, 2016 at 05:57:18PM +0700, Duy Nguyen wrote:
>
> "git grep --cached" searches file content that will be committed by
> "git commit" (no -a). An i-t-a entry will not be committed (you would
> need "git add" first, or do "git commit -a"). So if I say "search
> among the
tand.)
I would have thought that grepping the empty SHA-1 would be correct for
with or without -v. An "intent to add" file has no content in the index
so I would expect it to have zero matching and zero non-matching lines
for any grep --cached query?
Or is this an efficiency and not a corr
From: Charles Bailey <cbaile...@bloomberg.net>
This reverts commit 4d552005323034c1d6311796ac1074e9a4b4b57e.
This commit caused 'git grep' to no longer find matches in new files in
the working tree where the corresponding index entry had the "intent to
add" bit set.
Add tests to
way, of course, I'd like for it to not change back and forth
between
releases :).
Perhaps just an announcement of the new behavior would suffice - 2.7.0
has been
out for a while anyway. If people were going to complain, I figure they
would
have done so by now.
-Charles
On Fri, Mar 4, 2016, at 07
t directory foo/bar
/*
!/foo
/foo/*
!/foo/bar
Note the /foo/*, explicitly ignoring the entries below /foo.
This wasn't always the case, though, so I'd love to hear if it was
intentional
(or if I've lost my mind, which is quite possible).
-Charles
On Fri, Mar 4, 2016, at 12:51 AM
, is there
an
announcement explaining this change?
-Charles
(.gitignore is as follows)
*
!/.Xdefaults
!/.Xresources
!/.ackrc
!/.bash_profile
!/.config
!/.config/dunst
!/.config/dunst/dunstrc
!/.config/taffybar
!/.config/taffybar/taffybar.hs
!/.config/taffybar/taffybar.rc
!/.ctags
!/.gdb
!/.gdb
%2fProjectName.git
I tried changing the %2f by / inside the git.store file and also tried // but
it's still showing the same fatal error.
Perhaps I don't use the host= property correctly.
May I ask you helping me with this ?
Best Regards,
Charles Belanger
--
To unsubscribe from this list: send
On Mon, Dec 07, 2015 at 11:52:28AM -0500, Alex Jones wrote:
> git branch -a output:
>
> ajonespro:Deploy_Script ajones$ git branch -a
>
> * DWH_concurrent_api
> Email_No_Error_If_No_Old_Version
> IT/configs_in_app_support
> PHP_Build_Repo
> master
> remotes/origin/DWH_concurrent_api
>
On Mon, Dec 07, 2015 at 04:58:10PM +, Charles Bailey wrote:
>
> Looking at the two outputs, you are seeing the shell's glob expansion of
> the '*' current branch marker. You probably want to quote the command
> expansion to prevent this:
>
> echo "$(git branch
On Fri, Dec 04, 2015 at 01:05:20PM -0800, Junio C Hamano wrote:
> Do you want to sign-off this patch?
>
> Thanks.
Oops, yes please.
Signed-off-by: Charles Bailey <cbaile...@bloomberg.net>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
From: Charles Bailey <cbaile...@bloomberg.net>
---
t/t3404-rebase-interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
If you are using bash (at least 4.3.30 or 4.3.42) this actually causes
an error due to an "ambiguous redirect" because there is a space in
From: Charles Bailey <cbaile...@bloomberg.net>
This enables ~ and ~user expansion for these config options.
Signed-off-by: Charles Bailey <cbaile...@bloomberg.net>
---
In the only place that we (optionally) test https specifically, we also
turn off SSL verification so I couldn't se
From: Charles Bailey cbaile...@bloomberg.net
According to POSIX specification uname must return -1 on failure and a
non-negative value on success. Although many implementations do return 0
on success it is valid to return any positive value for success. In
particular, Solaris returns 1.
Signed
a negative value which
isn't -1, but if we ever do it is probably safer to fail. I'll send and
update.
Charles.
--
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
From: Charles Bailey cbaile...@bloomberg.net
According to POSIX specification uname must return -1 on failure and a
non-negative value on success. Although many implementations do return 0
on success it is valid to return any positive value for success. In
particular, Solaris returns 1.
Signed
From: Charles Bailey cbaile...@bloomberg.net
The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.
Non-gcc builds need this macro to expand to 0 as well. The current
From: Charles Bailey cbaile...@bloomberg.net
The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.
Non-gcc builds need this macro to expand to 0 as well. The current
On Mon, Jun 22, 2015 at 03:17:40PM +0200, Bastien Traverse wrote:
test case:
$ mkdir accent-test cd !$
$ git init
$ touch rêve réunion
$ git status
On branch master
Initial commit
Untracked files:
(use git add file... to include in what will be committed)
r\303\251union
that
for_each_packed_object is buggy, IMHO. I'll send a patch.
Here's that patch. And since I did not want to pile work on Charles, I
went ahead and just implemented the patches I suggested in the other
email.
I have to say that I think that adding this functionality to cat-file
makes a lot of sense
On Mon, Jun 22, 2015 at 07:06:32AM -0400, Jeff King wrote:
On Mon, Jun 22, 2015 at 06:33:21AM -0400, Jeff King wrote:
By the way, in addition to not showing objects in order,
list-all-objects (and my cat-file option) may show duplicates. Do we
want to sort -u for the user? It might be
On 22 Jun 2015, at 23:09, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
- marginally improved the opterror message on failed parses
I'd queue with s/a integer/a non-negative integer/.
Ha! That's what I had before I submitted, but then the source
On Mon, Jun 22, 2015 at 04:38:22AM -0400, Jeff King wrote:
On Sun, Jun 21, 2015 at 08:20:31PM +0100, Charles Bailey wrote:
+ prepare_packed_git();
+ for (p = packed_git; p; p = p-next) {
+ open_pack_index(p);
+ }
Yikes. The fact that you need to do this means
From: Charles Bailey cbaile...@bloomberg.net
This fixes two instances where a -chain was broken in the subtree
tests and fixes a test error that was revealed because of this.
Many tests in t7900-subtree.sh make a commit and then use 'undo' to
reset the state for the next test. In the 'check hash
From: Charles Bailey cbaile...@bloomberg.net
Although subtrees tests uses more spaces for indentation than tabs,
there are still quite a lot of lines indented with tabs. As tabs conform
with Git coding guidelines resolve the inconsistency in favour of tabs.
Signed-off-by: Charles Bailey cbaile
From: Charles Bailey cbaile...@bloomberg.net
There's no need to switch branches to parse another branch's ancestry.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
contrib/subtree/t/t7900-subtree.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/contrib/subtree
On Sun, Jun 21, 2015 at 07:25:44PM +0100, Charles Bailey wrote:
From: Charles Bailey cbaile...@bloomberg.net
diff --git a/parse-options.c b/parse-options.c
index 80106c0..101b649 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -180,6 +180,23 @@ static int get_value(struct
From: Charles Bailey cbaile...@bloomberg.net
Fix the printf specification to treat 'integer' as the signed type that
it is and add a test that checks that we parse negative option
arguments.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
t/t0040-parse-options.sh | 2 ++
test-parse
From: Charles Bailey cbaile...@bloomberg.net
The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing)
is more widely applicable. Add support for OPT_MAGNITUDE to
parse-options.h and change pack-objects.c use this support.
The error behavior on parse errors follows
This is a re-roll of the first two patches in my previous series which used to
include filter-objects which is now a separate topic.
[PATCH 1/2] Correct test-parse-options to handle negative ints
The first one has changed only in that I've moved the additional test to a more
logical place in the
This is a re-casting of my previous filter-objects command but without
any of the filtering so it is now just list-all-objects.
I have retained the --verbose option which outputs the same format as
the default cat-file --batch-check as it provides a useful performance
gain to filtering though
From: Charles Bailey cbaile...@bloomberg.net
list-all-objects is a command to print the ids of all objects in the
object database of a repository. It is designed as a low overhead
interface for scripts that want to analyse all objects but don't require
the ordering implied by a revision walk
On Fri, Jun 19, 2015 at 10:58:51AM -0700, Junio C Hamano wrote:
Charles Bailey char...@hashpling.org writes:
Please place it immediately after INTEGER, as they are conceptually
siblings---group similar things together.
Sorry, this is a bad habit from working on projects where changing
From: Charles Bailey cbaile...@bloomberg.net
filter-objects is a command to scan all objects in the object database
for the repository and print the ids of those which match the given
criteria.
The current supported criteria are object type and the minimum size of
the object.
The guiding use
On Fri, Jun 19, 2015 at 06:10:10AM -0400, Jeff King wrote:
On Fri, Jun 19, 2015 at 10:10:59AM +0100, Charles Bailey wrote:
filter-objects is a command to scan all objects in the object database
for the repository and print the ids of those which match the given
criteria.
The current
On Fri, Jun 19, 2015 at 01:03:25PM +0200, Remi Galan Alfonso wrote:
It's trivial matter but the line:
+ output 2 output.err
should be written:
+ output 2output.err
It was incorrectly written before but since
you are modifying the line, it might be a
good thing to change it now.
From: Charles Bailey cbaile...@bloomberg.net
The unsigned long option parsing (including 'k'/'m'/'g' suffix parsing)
is more widely applicable. Add support for OPT_ULONG to parse-options.h
and change pack-objects.c use this support.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
In my team we've been looking for a fast way to check a large number of
repositories for large files, which are typically unintentionally checked in
binaries, so that we can warn repository owners and help them tidy up as
desired.
There seem to be two main approaches to scripting this. The first
From: Charles Bailey cbaile...@bloomberg.net
Fix the printf specification to treat 'integer' as the signed type that
it is and add a test that checks that we parse negative option
arguments.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
t/t0040-parse-options.sh | 2 ++
test-parse
On Mon, Apr 20, 2015 at 09:22:47PM +0530, karthik nayak wrote:
On 04/20/2015 02:49 PM, Charles Bailey wrote:
As far as I could tell - and please correct me if I've misunderstood,
cat-file's literally is about dealing with unrecognized types whereas
hash-object's --literally is about both
is about dealing with unrecognized types whereas
hash-object's --literally is about both creating objects with bad types
and invalid objects of recognized types. This latter scenario is where
the option name literally makes the most sense.
Charles.
--
To unsubscribe from this list: send the line
On 20 Apr 2015, at 06:30, Junio C Hamano gits...@pobox.com wrote:
Charles Bailey char...@hashpling.org writes:
The option isn't a true opposite of hash-object's --literally because
that also allows the creation of known types with invalid contents (e.g.
corrupt trees) whereas cat-file
) whereas cat-file is quite happy to show the _contents_ of
such corrupt objects even without --literally.
Charles.
--
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
On Tue, Jan 27, 2015 at 01:12:21PM -0500, Jeff King wrote:
On Tue, Jan 27, 2015 at 03:20:41PM +, Charles Bailey wrote:
From: Charles Bailey cbaile...@bloomberg.net
When objects are spread across multiple packs, if an initial fetch does
require all pack files, a subsequent fetch
On Tue, Jan 27, 2015 at 03:02:27PM -0500, Jeff King wrote:
Discovery and tests by Charles Bailey char...@hashpling.org.
Signed-off-by: Jeff King p...@peff.net
---
I'm happy to flip the authorship on this. You have more lines in it than
I do. :)
No, I'm happy with you taking the blame
From: Charles Bailey cbaile...@bloomberg.net
When objects are spread across multiple packs, if an initial fetch does
require all pack files, a subsequent fetch for objects in packs not
retrieved in the initial fetch will fail.
---
I'm not very familiar with the http client code so this analysis
I am writing some higher level git commands for
https://github.com/Originate/git-town and would like some additional
plumbing commands that can tell me
1. is there a merge in progress?
2. is there a rebase in progress?
3. is there a cherry-pick in progress?
4. are there unmerged paths?
Currently
On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote:
Hash: SHA1
I'm having an issue in that 'git ls-files -o' seems to ignore
[parts of] .gitignore whereas other commands, such as 'git status'
seem fine.
This is, as far as I am aware, by design. If you want to apply the
standard
On 11 Oct 2014, at 09:29, David Aguilar dav...@gmail.com wrote:
Thanks for the heads-up.
I tested mergetool and it seems fine but indeed there's an
`if test -e $GIT_DIR/MERGE_RR` in there that is surely not
working as intended.
One solution would be to move the work done in the test
While you have the lid of this section of code, should we consider
(optionally?) using a tmpdir to alleviate the eclipse issue where it wants
temporary merge files to be the canonical locations for definitions of things
that it finds when scanning source files in the project tree?
[Apologies
On 10 Oct 2014, at 09:51, David Aguilar dav...@gmail.com wrote:
Changes since v1:
NONGIT_OK=Yes was added to make it actually work outside of a git repo.
Does this actually work? The reason that I haven't got around to resending my
re-roll is that I found that I needed changes to
On Fri, Aug 08, 2014 at 03:18:11PM -0700, Junio C Hamano wrote:
* cb/mergetool-difftool (2014-07-21) 2 commits
- difftool: don't assume that default sh is sane
- mergetool: don't require a work tree for --tool-help
Update the way the difftool --help shows the help message that is
shared
of the LGPL.
I found the source code of Apple's Git builds here:
http://www.opensource.apple.com/source/Git/
Mine happens to be Git-48. I'm not sure how to tell what version you
have if it is prompting you to accept a licence first.
Charles.
--
To unsubscribe from this list: send the line unsubscribe git
From: Charles Bailey cbaile...@bloomberg.net
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
The main Git Makefile does this, but not the contrib/subtree Makefile.
SHELL_PATH should be respected if set (especially on Solaris where
/bin/sh is very legacy).
The sed command is a copy
From: Charles Bailey cbaile...@bloomberg.net
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
You can call git difftool --tool-help outside of a work tree but not
mergetool --tool-help but there's not real reason for this restriction
and it can be easily relaxed by deferring
From: Charles Bailey cbaile...@bloomberg.net
git-difftool used to create a command list script containing $( ... )
and explicitly call sh -c with this list.
Instead, allow mergetool --tool-help to take a mode parameter and call
mergetool directly to invoke the show_tool_help function. This mode
On Sat, Jul 19, 2014 at 06:21:32PM +0100, John Keeping wrote:
What's the reason for forcing `--tool-help` to be the last option?
Wouldn't it be simpler to just change the top-level case statement to:
--tool-help=*)
TOOL_MODE=${1#--tool-help=}
On Mon, Jun 30, 2014 at 10:20:27PM +0100, Charles Bailey wrote:
From: Charles Bailey cbaile...@bloomberg.net
This change ensure that duplicate parents are pruned before the parent
filter and ensures that --prune-empty is idempotent, removing all
empty non-merge commits in a singe pass.
s
From: Charles Bailey cbaile...@bloomberg.net
When multiple parents of a merge commit get mapped to the same commit,
filter-branch used to pass all instances of the parent commit to the
parent and commit filters and to git commit-tree or
git_commit_non_empty_tree.
This can often happen when
The git submodule sync command supports the --recursive flag, but
the documentation does not mention this. That flag is useful, for
example when a remote is changed in a submodule of a submodule.
Signed-off-by: Matthew Chen charlesmc...@gmail.com
---
Documentation/git-submodule.txt | 2 +-
1
Thanks for taking time to understand, let me make it more clear
Le 12 juin 2014 à 17:25, Fredrik Gustafsson iv...@iveqy.com a écrit :
So let me see if I understand you correctly.
On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote:
Hi,
I'm banging my head on this problem
explain what's going on? And how can I get my submodule in the
working copy?
git version 1.9.2.msysgit.0 on Windows 7 SP1 64 bit
Thanks,
—-
Charles
--
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
-remote-hg solved
the problem.
Best regards,
Charles--
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
Hello,
I have the following error while pushing to an hg repository though the remote
translator:
$ git remote -v
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (push)
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (fetch)
$ git push origin
Password
we could use macros specific to
GIT?
Let me follow up with an alternative patch.
Charles.
--
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
---
compat/bswap.h | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 120c6c1..f08a9fe 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)
On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote:
Charles Bailey cbaile...@bloomberg.net writes:
---
Please sign-off your patches ;-)
Oops! Please consider this patch...
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
This swaps the precedence of BYTE_ORDER
On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote:
So,... I am inclined to queue this on top of your patch at least for
now, before I go into incommunicado-mode to finish preparing -rc2.
Yes, I'd agree with that.
--
To unsubscribe from this list: send the line unsubscribe git in
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
The endian detection added in 7e3dae494 isn't sufficient for the Solaris
Studio compilers. This adds some fallback logic which works for Solaris
but would also work for AIX and Linux if it were needed.
compat/bswap.h | 21
On Tue, Apr 22, 2014 at 02:56:22AM -0500, Felipe Contreras wrote:
An explicitly set mergetool.prompt = true would override the default. See the
patch.
I have had a chance to test the patch now and it looks good. I think
when glancing at it before I missed the change that dropped || echo
true
users as well on other projects),
but setting up a dedicated TFS server isn't an option, hence why I'm
looking into this.
Thanks in advance,
Charles
--
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
On Mon, Apr 21, 2014 at 09:59:52PM -0700, David Aguilar wrote:
[Cc:ing Charles in case he has an opinion, this behavior dates back to the
original MT]
On Sun, Apr 20, 2014 at 07:17:34PM -0500, Felipe Contreras wrote:
It's annoying to see the prompt:
Hit return to start merge
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
Was the merge successful? [y/n]
Does this happen now even with merge tools for which we do trust the
exit code? If so, my original
On Tue, Apr 22, 2014 at 01:53:46AM -0500, Felipe Contreras wrote:
Charles Bailey wrote:
On Tue, Apr 22, 2014 at 01:24:09AM -0500, Felipe Contreras wrote:
This is what I get when a tool is not working:
Documentation/config.txt seems unchanged.
Was the merge successful? [y/n
.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
t/t3600-rm.sh | 5 ++---
t/t7001-mv.sh | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 3d30581..23eed17 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -709,10 +709,9
Now that it calls a static inline function, it cannot be an inline
definition with external linkage. Remove inline and make it an
external definition.
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
---
dir.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dir.c b
low level tests (t0020-crlf and
t0022-crlf-rename) fail (and perhaps later tests, too) unless I
de-inline ce_path_match and dir_path_match from dir.h but as I cannot
yet explain what the issue is or why this is a fix, I'm holding onto
this one for now.
Charles.
--
To unsubscribe from this list: send
On Sat, Mar 29, 2014 at 04:48:44PM +0100, Jens Lehmann wrote:
Am 29.03.2014 16:39, schrieb Charles Bailey:
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 3d30581..23eed17 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -709,10 +709,9 @@ test_expect_success 'checking out a commit
expect
+ git log -1 --format=%ad $commit actual
+ test_cmp expect actual
+'
Git on AIX seems happy to convert this to Thu Oct 24 18:46:39
162396404 -0700. I don't know if this is correct for the given input
but the test fails.
Charles.
--
To unsubscribe from this list: send the line
while longer. Splitting things
out from the test is giving me some inconsistent results, there may be
something else going wrong in our environment here.
Charles.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Wed, Mar 26, 2014 at 04:38:30PM -0400, Jeff King wrote:
By the way, can you confirm that this is a 64-bit system? On a 32-bit
system, we should be triggering different code paths (we fail at the
strtoul level). Those should be checked by the previous tests, but I'd
like to make sure.
1fc17e734e4487c31bdfe05bb3d15618b69c4dca
commit 1fc17e734e4487c31bdfe05bb3d15618b69c4dca
Author: A U Thor aut...@example.com
Date: (null)
foo
Charles.
--
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
:39 -1126091476 -0700
99 Thu Oct 24 18:46:39 1623969404 -0700
So, very bogus values.
Charles.
--
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
On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote:
Jonathan Nieder jrnie...@gmail.com writes:
And for experienced users, this would be a bad regression.
Backward incompatibility is a real concern.
It might be best if git reset (with _no_ option) be made to error out,
so all
1 - 100 of 110 matches
Mail list logo
