On Fri, Oct 10, 2014 at 02:21:56AM -0400, Jeff King wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index a60ec75..81ceb23 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -237,7 +237,11 @@ do
> shift ;;
> -x)
> test_eval_start_='set -x'
> -
Hi Ray,
On Fri, 10 Oct 2014, Ray Donnelly wrote:
> On Thu, Oct 9, 2014 at 8:47 PM, Johannes Schindelin <
> johannes.schinde...@gmx.de> wrote:
> >
> > On Thu, 9 Oct 2014, Ray Donnelly wrote:
> >
> >> On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
> >> wrote:
> >> >
> >> > On Wed, 8 Oct 2014,
On Fri, Oct 10, 2014 at 02:13:55AM -0400, Jeff King wrote:
> + -x)
> + test_eval_start_='set -x'
> [...]
> + eval "$test_eval_start_ $*"
> +}
Hmph. I had originally intended to make this "set -x;" with a semicolon,
to keep it split from $*. But I forgot to, and much to my surp
On Fri, Oct 10, 2014 at 02:13:55AM -0400, Jeff King wrote:
> Having finally figured out how to drop the "set +x" from the output, I
> have noticed that I kind of liked the "test_eval_ret=$?" part of the
> trace (which is now gone, too), because it pretty explicitly tells you
> that the last traced
Usually running a test under "-v" makes it clear which
command is failing. However, sometimes it can be useful to
also see a complete trace of the shell commands being run in
the test. You can do so without any support from the test
suite by running "sh -x t-foo.sh". However, this
produces quit
For small outputs, we sometimes use:
test "$(some_cmd)" = "something we expect"
instead of a full test_cmp. The downside of this is that
when it fails, there is no output at all from the script.
Let's introduce a small helper to make tests easier to
debug.
Signed-off-by: Jeff King
---
I kind
These patches are pulled out of the prune-mtime series I posted
earlier[1]. The discussion veered off and there's no reason that the two
topics need to be part of the same series.
The first patch is the same cleanup as before.
The second one uses Michael's suggested "verbose" function, like:
$
This is slightly more robust (checking "! test -f" would not
notice a directory of the same name, though that is not
likely to happen here). It also makes debugging easier, as
the test script will output a message on failure.
Signed-off-by: Jeff King
---
t/t5304-prune.sh | 46 +++
Advertise that the svn-remote..pushurl config key allows specifying
the commit URL for the entire SVN repository in the documenation of git
svn's dcommit command.
Signed-off-by: Sveinung Kvilhaugsvik
---
Documentation/git-svn.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentat
On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano wrote:
> Actually the patch was slightly wrong. It did not quite matter as
> "cd ''" is a no-op, but "git -C '' cmd" is not that lenient (which
> may be something we may want to fix) and breaks t9902 by exposing
> an existing breakage in the callchai
Brandon Turner writes:
> On Thu, Oct 9, 2014 at 3:45 PM, Junio C Hamano wrote:
>>
>> Bugs are mine; as I do not use zsh myself, some testing is very much
>> appreciated.
>
> I've tested this patch in zsh and it fixes the original problem. I've
> also tested various scenarios in bash and zsh (CD
On 2014-10-09 06:27, Jess Austin wrote:
> On Thu, Oct 9, 2014 at 12:37 AM, Richard Hansen wrote:
>> On 2014-10-08 17:37, Jess Austin wrote:
>>> On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen wrote:
On 2014-10-08 15:04, Jess Austin wrote:
> Introduce a new environmental variable, GIT_PS1_
On Thu, Oct 9, 2014 at 3:45 PM, Junio C Hamano wrote:
>
> Bugs are mine; as I do not use zsh myself, some testing is very much
> appreciated.
I've tested this patch in zsh and it fixes the original problem. I've
also tested various scenarios in bash and zsh (CDPATH set, different
places within r
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Brandon Turner writes:
> As Øystein pointed out, on zsh we can use "cd -q" to ignore
> chpwd_functions.
>
> Junio - from my testing, unsetting CDPATH is sufficient on zsh.
Let's do this instead, though.
Bugs are mine; as I do not use zsh myself, some testing is very much
appreciated.
Thanks.
Fabian Ruch writes:
>> The interface to "git-merge-$strategy" is designed in such a way
>> that each strategy should be capable of taking _no_ base at all.
>
> The merge strategies "resolve" and "octopus" seem to refuse to run if no
> base is specified. The former silently exits if no bases are g
René Scharfe writes:
> I didn't think much about the performance implications. skip_prefix()
> doesn't call strlen(3), though.
Ah, OK.
> The code handles millions of ref strings per second before and after
> the change, and with the change it's faster. I hope the results are
> reproducible an
Am 07.10.2014 um 20:23 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> @@ -335,20 +337,18 @@ static int append_ref(const char *refname, const
>> unsigned char *sha1, int flags,
>> static struct {
>> int kind;
>> const char *prefix;
>> -int pfxlen;
>
Øystein Walle writes:
> BUT: Over a year ago Git learned the -C argument. Couldn't we use that
> here? That way we would not have to unset CDPATH and can get rid of the
> subshell and cd -q. If we allow the other functions to use several
> arguments to pass options with we can get rid of the whol
Hi Junio,
On 10/09/2014 09:05 PM, Junio C Hamano wrote:
> Fabian Ruch writes:
>> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
>> index d3fb67d..3f754ae 100644
>> --- a/git-rebase--merge.sh
>> +++ b/git-rebase--merge.sh
>> @@ -67,7 +67,13 @@ call_merge () {
>> GIT_MERGE_VE
Hi Ray,
On Thu, 9 Oct 2014, Ray Donnelly wrote:
> On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
> wrote:
> >
> > On Wed, 8 Oct 2014, Marat Radchenko wrote:
> >
> >> +CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2>/dev/null || echo not')
> >
> > There is a rather huge problem with that. The
Brandon Turner brandonturner.net> writes:
> +__git_ls_files_helper ()
> +{
> + (
> + test -n "${CDPATH+set}" && unset CDPATH
> + cd -q "$1"
> + if [ "$2" == "--committable" ]; then
> + git diff-index --name-only --relative HEAD
> +
:) Wasn't proposing a patch, that's for sure, was just evincing the
change that worked for me.
I agree INSTALL instructions should be fixed up and/or the
DOCBOOK2X_TEXI should be conditionally assigned in a sane manner.
I'd first want to inspect upstream docbook2X build process and Fedora
docbook
On Thu, Oct 09, 2014 at 12:53:33PM -0500, Derek Moore wrote:
> Following the INSTALL doc, I was building git with:
>
> make prefix=/usr/local all doc info
I wonder if it is actually sane to recommend building "info" for
newcomers in INSTALL. I do not know if many of the list regulars do so
(I ce
> I don't see a big problem with that. But I wonder if we would do better
> to introduce arbitrary strftime-like formatting, so we do not have to
> keep adding new formats.
My thoughts exactly...
This list seems to be a prove-yourself-with-patches sorta place. If I
can find the time, I'll try att
On Thu, Oct 09, 2014 at 03:24:28PM -0400, Jeff King wrote:
> On Thu, Oct 09, 2014 at 11:19:36AM -0500, Derek Moore wrote:
>
> > PRETTY FORMATS' format: documentation says, "%ad: author date
> > (format respects --date= option)", and similarly for %cd.
> >
> > But git-archive does not support the
On Thu, Oct 9, 2014 at 8:22 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Wed, 8 Oct 2014, Marat Radchenko wrote:
>
>> +CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2>/dev/null || echo not')
>
> There is a rather huge problem with that. The latest mingw-w64 release,
> 4.9.1, does not do what you exp
On Thu, Oct 09, 2014 at 11:19:36AM -0500, Derek Moore wrote:
> PRETTY FORMATS' format: documentation says, "%ad: author date
> (format respects --date= option)", and similarly for %cd.
>
> But git-archive does not support the --date= option for changing the
> date format in $Format:%ad$ or $Forma
Hi,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
> +CC_MACH := $(shell sh -c '$(CC) -dumpmachine 2>/dev/null || echo not')
There is a rather huge problem with that. The latest mingw-w64 release,
4.9.1, does not do what you expect here: while '.../mingw32/bin/gcc -m32
-o 32.exe test.c' and '.../min
Junio C Hamano pobox.com> writes:
>
> Øystein Walle gmail.com> writes:
>
> > Brandon Turner brandonturner.net> writes:
> >
> >>
> >> Software, such as RVM (ruby version manager), may set chpwd functions
> >> that result in an endless loop when cding. chpwd functions should be
> >> ignored.
On 10/09/2014 01:50 PM, Fabian Ruch wrote:
Hi David,
I don't think you made a mistake at all. If I understand the --merge
mode of git-rebase correctly there is no need to require a parent.
The error occurs when the script tries to determine the changes your
merge commit introduces, which include
Thanks, Jeff,
I may look into cleaning up your patch to propose a proper solution to
this list, as time allows.
Incidentally, I did stumble across:
http://git.kernel.org/cgit/git/git.git/commit/?id=5b16360330822527eac1fa84131d185ff784c9fb
which also references you, but I forgot to mention it.
On Thu, Oct 09, 2014 at 12:42:39PM -0500, Derek Moore wrote:
> As far as I've tested it would seem only %N doesn't resolve inside of
> $Format:$, until I maybe do unit tests for this to identify any
> others.
Yes, %N is somewhat special in that the calling code needs to initialize
the notes tree
Should perhaps you be using some symbolic method of referencing the
empty tree instead of referencing a magic number?
E.g.,
https://git.wiki.kernel.org/index.php/Aliases#Obtaining_the_Empty_Tree_SHA1
On Thu, Oct 9, 2014 at 1:50 PM, Fabian Ruch wrote:
> When the user specifies a merge strategy,
Fabian Ruch writes:
> diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
> index d3fb67d..3f754ae 100644
> --- a/git-rebase--merge.sh
> +++ b/git-rebase--merge.sh
> @@ -67,7 +67,13 @@ call_merge () {
> GIT_MERGE_VERBOSITY=1 && export GIT_MERGE_VERBOSITY
> fi
> test
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
As I've only seen this so far on ZSH, I'm applying this change only to
the git-completion.zsh overrides.
Signed-off-by: Brandon Turner
---
As Øyste
When the user specifies a merge strategy, `git-merge-$strategy` is
used in non-interactive mode to replay the changes introduced by the
current branch relative to some upstream. Specifically, for each
commit `c` that is not in upstream the changes that led from `c^` to
`c` are reapplied.
If the cu
David Aguilar writes:
> Avoid filenames with multiple dots so that overly-picky tools do
> not misinterpret their extension.
>
> Previously, foo/bar.ext in the worktree would result in e.g.
>
> foo/bar.ext.BASE.1234.ext
>
> This can be improved by having only a single .ext and using
> under
Øystein Walle writes:
> Brandon Turner brandonturner.net> writes:
>
>>
>> Software, such as RVM (ruby version manager), may set chpwd functions
>> that result in an endless loop when cding. chpwd functions should be
>> ignored.
>
> Now that it has moved to the zsh-specific script you can achie
Duy Nguyen writes:
> On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > Hmm.. Junio already did most of the work in 051e400 (helping
>> > smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
>> > do is enable uploadpack.allowtipsha1inwa
Following the INSTALL doc, I was building git with:
make prefix=/usr/local all doc info
Even after installing docbook2X, I couldn't get past the first DB2TEXI
build step until I discovered that 'docbook2x-texi' is named
'db2x_docbook2texi' in Fedora 21 using the latest upstream docbook2X
0.8.8.
On Thu, Oct 9, 2014 at 10:56 AM, Derek Moore wrote:
> I first noticed this using the system git provided in Fedora 21, so I
> cloned the official git repo, built from source, and it would appear
> there are even more options that don't work with export-subst in the
> latest code.
I'm a dumb ass.
PRETTY FORMATS' format: documentation says, "%ad: author date
(format respects --date= option)", and similarly for %cd.
But git-archive does not support the --date= option for changing the
date format in $Format:%ad$ or $Format:%cd$ substitution strings.
Relatedly, I want a short RFC date, not a
I first noticed this using the system git provided in Fedora 21, so I
cloned the official git repo, built from source, and it would appear
there are even more options that don't work with export-subst in the
latest code.
I tested this under commit 63a45136a329bab550425c3142db6071434d935e
(HEAD, or
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please
read and reply I would be grateful. Jose Calvache
--
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-
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
> I didn't mean multiple uses of ?= for the same variable. I meant
> multiple uses of (references to) the variable. I.e. wouldn't FOO and
> BAR behave differently below?
>
> FOO := $(shell random)
> BAR = $(shell random)
> all::
>echo $(FOO
Well. after about 15 to 30 minutes it began to download the repository
finishing with "error: bad file descriptor" on git-svn. It checked r1
to r50+ with took some time.
The unit-tests where successful so i think the broken pipe was not an
issue in the end.
Sorry for disturbing you.
Freundlic
Hi
I'm unable to checkout this subversion repository with git. Can
somebody help me?
svn co http://svn.apache.org/repos/asf/ofbiz/branches/release13.07 ofbiz.13.07
Yes i can clone it with SVN and add it to git. But this disturbes the
workflow and causes problems when someone commits to this bran
Hi Marat,
On Thu, 9 Oct 2014, Marat Radchenko wrote:
> On Thu, Oct 09, 2014 at 12:11:01PM +0200, Johannes Schindelin wrote:
> > I also added one patch I find highly convenient:
> >
> > https://github.com/dscho/git/commit/29749c7d7b4638c63369d6cf067f5d524d0092f9
>
> There already were two attemp
On Thu, Oct 09, 2014 at 12:11:01PM +0200, Johannes Schindelin wrote:
> I also added one patch I find highly convenient:
>
> https://github.com/dscho/git/commit/29749c7d7b4638c63369d6cf067f5d524d0092f9
There already were two attempts to this issue:
1. http://www.spinics.net/lists/git/msg230028.h
On Thu, Oct 9, 2014 at 12:37 AM, Richard Hansen wrote:
> On 2014-10-08 17:37, Jess Austin wrote:
>> On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen wrote:
>>> On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to dis
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
> Isn't the primary reason we use colon-assign to avoid running the same
> $(shell) over and over again every time $(uname_?) gets referenced? How
> would it work with ?= ???
I was under the impression that ?= would only define the variable onc
Hi all,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
> This patch series fixes building on modern MinGW and MinGW-W64
> (including x86_64).
To make it more convenient to work on this patch series using Git, I
pushed this branch to
https://github.com/dscho/git/compare/git:master...w64-slon
On Thu, Oct 09, 2014 at 12:34:25AM -0700, Junio C Hamano wrote:
> No, and I do not quite see why you even need to look at -dumbmachine
> output when your goal is to make this command line
>
> >>$ make uname_O=MINGW uname_S=MINGW
>
> work sensibly. Wouldn't it be more like a series of
>
>
We checked the first file descriptor for errors twice, instead of
checking both file descriptors.
Signed-off-by: Ralph Loader
---
While this appears utterly trivial, I noticed this reading the code not
running it - I do not have the relevant OS to compile and test on.
compat/mingw.c | 2 +-
1 f
Hi Junio,
On Thu, 9 Oct 2014, Junio C Hamano wrote:
> Marat Radchenko writes:
>
> > On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
> > ...
> >> What I am wondering is if it is a better solution to make it easier
> >> to allow somebody who is cross compiling to express "Mr. Mak
Marat Radchenko writes:
> On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
> ...
>> What I am wondering is if it is a better solution to make it easier
>> to allow somebody who is cross compiling to express "Mr. Makefile,
>> we know better than you and want you to do a MINGW build
Brandon Turner brandonturner.net> writes:
>
> Software, such as RVM (ruby version manager), may set chpwd functions
> that result in an endless loop when cding. chpwd functions should be
> ignored.
Now that it has moved to the zsh-specific script you can achieve this more
simply by using cd -q
Marat Radchenko writes:
> On Wed, Oct 08, 2014 at 01:02:10PM -0700, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> > Marat Radchenko writes:
>> >
>> >> Signed-off-by: Marat Radchenko
>> >> ---
>> >> git-compat-util.h | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>>
Hi Marat,
On Thu, 9 Oct 2014, Marat Radchenko wrote:
> On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
> > Marat Radchenko writes:
> >
> > > When crosscompiling, one cannot rely on `uname` from host system.
> >
> > That may well be true, but is that limited to cross-compiling t
60 matches
Mail list logo
