On Mon, Nov 10, 2014 at 03:41:09PM +0100, Johannes Schindelin wrote:
> > However, start_command() will set "env" to env_array.argv only if "env"
> > was unset to begin with, and if it was already set, the caller will need
> > the original value. Therefore, we need to be very careful only to reset
On Mon, Nov 10, 2014 at 01:44:24PM -0800, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > In start_command(), unset "env" fields are initialized via "env_array". In
> > finish_command(), the "env_array" is cleared, therefore the "env" field
> > will point to free()d data.
> >
> > Howev
On Tue, Nov 11, 2014 at 12:20:56AM +0100, Manzur Mukhitdinov wrote:
> When object is replaced with itself git shows unhelpful messages like(git
> log):
> "fatal: replace depth too high for object "
>
> Prevents user from replacing object with itself(with test for checking
> this case).
Than
On Mon, Nov 10, 2014 at 02:43:10PM -0800, Junio C Hamano wrote:
> > Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
> > take no parameters instead of leaving their parameter list empty and
> > thus unspecified.
> [...]
>
> I was kind of surprised after running a git blame to
On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote:
> > This and all other failures are due to the output of 'wc -l', which on
> > Mac is "{whitespace}1" rather than just "1" as it is on other
> > platforms. fbe4f748 added quotes around the $(... | wc -l) invocation
> > which caused the
奇摩超級商城裡格最優惠的優良店家「寵物家族」再此為您服務
您需求的數千種寵物用品都在這裡，非常歡迎您的蒞臨
更多好康，請點擊下網址參觀(不定期超多優惠折扣快來搶購)：
http://ow.ly/DIjY5
pvxep樊珊芳
--
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://vg
On Tue, Nov 11, 2014 at 2:07 AM, Eric Sunshine wrote:
> On Mon, Nov 10, 2014 at 8:04 PM, Johan Herland wrote:
>> On Mon, Nov 10, 2014 at 9:42 PM, Junio C Hamano wrote:
>>> Johan Herland writes:
>>>
Make this test script appear somewhat less old-fashioned:
- Use test helper functions:
If quoting is generally preferred as a best practice, we could force
wc to behave more consistently before we start testing
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 0d93e33..57ed608 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -515,6 +515,14 @@
On Tue, Nov 11, 2014 at 2:19 AM, Eric Sunshine wrote:
> On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume wrote:
>> the commit modernizing test 3301
>> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
>> on my mac
>>
>> $ ./t3301-notes.sh -v
>> expecting success:
>> MSG=b4 git
On Mon, Nov 10, 2014 at 7:17 PM, Michael Blume wrote:
> the commit modernizing test 3301
> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
> on my mac
>
> $ ./t3301-notes.sh -v
> expecting success:
> MSG=b4 git notes add &&
> test_path_is_missing .git/NOTES_EDITMSG &&
> test
On Mon, Nov 10, 2014 at 8:04 PM, Johan Herland wrote:
> On Mon, Nov 10, 2014 at 9:42 PM, Junio C Hamano wrote:
>> Johan Herland writes:
>>
>>> Make this test script appear somewhat less old-fashioned:
>>> - Use test helper functions:
>>> - write_script
>>> - test_commit
>>> - test_w
On Mon, Nov 10, 2014 at 9:42 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Make this test script appear somewhat less old-fashioned:
>> - Use test helper functions:
>> - write_script
>> - test_commit
>> - test_write_lines
>> - test_config
>> - test_unconfig
>> -
On Mon, Nov 10, 2014 at 9:36 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Signed-off-by: Johan Herland
>> ---
>> builtin/notes.c | 12 +---
>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/builtin/notes.c b/builtin/notes.c
>> index 1017472..f1480cf 100644
my first thought was that this might be a bash versioning issue, since
the commit in question basically refactors the script, and macs ship
with an archaic version of bash, but I have the same problem with bash
4.3.30
On Mon, Nov 10, 2014 at 4:23 PM, Michael Blume wrote:
> (to be clear: I ran git
(to be clear: I ran git bisect, and traced the problem to the modernize commit)
On Mon, Nov 10, 2014 at 4:17 PM, Michael Blume wrote:
> the commit modernizing test 3301
> (https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
> on my mac
>
> Verbose output follows:
>
> $ ./t3301-n
the commit modernizing test 3301
(https://github.com/git/git/commit/fbe4f74865acfd) appears to break it
on my mac
Verbose output follows:
$ ./t3301-notes.sh -v
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash directory.t3301-notes/.git/
expecting success:
test_must_f
When object is replaced with itself git shows unhelpful messages like(git log):
"fatal: replace depth too high for object "
Prevents user from replacing object with itself(with test for checking
this case).
---
builtin/replace.c | 8 +++-
t/t6050-replace.sh | 8
2 files changed,
René Scharfe writes:
> Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
> take no parameters instead of leaving their parameter list empty and
> thus unspecified.
>
> Signed-off-by: Rene Scharfe
> ---
Thanks.
I was kind of surprised after running a git blame to find that th
Johannes Schindelin writes:
> In start_command(), unset "env" fields are initialized via "env_array". In
> finish_command(), the "env_array" is cleared, therefore the "env" field
> will point to free()d data.
>
> However, start_command() will set "env" to env_array.argv only if "env"
> was unset
Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
take no parameters instead of leaving their parameter list empty and
thus unspecified.
Signed-off-by: Rene Scharfe
---
run-command.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-co
On 11/10/2014 12:47 AM, Duy Nguyen wrote:
Some updates from the test lab, Windows 7
"Working" means git update-index --untracked-cache reports Testing...OK
"Rejected" means "..does not change.."
cygwin + NTFS: Working
cygwin + VFAT: Rejected
The same good news for Msysgit, running your github br
Johan Herland writes:
> Make this test script appear somewhat less old-fashioned:
> - Use test helper functions:
> - write_script
> - test_commit
> - test_write_lines
> - test_config
> - test_unconfig
> - test_path_is_missing
> - Remove whitespace between redirection ope
Johan Herland writes:
> Signed-off-by: Johan Herland
> ---
> builtin/notes.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/builtin/notes.c b/builtin/notes.c
> index 1017472..f1480cf 100644
> --- a/builtin/notes.c
> +++ b/builtin/notes.c
> @@ -399,7 +399,7
Johan Herland writes:
> On Fri, Nov 7, 2014 at 7:04 PM, Junio C Hamano wrote:
>
>> In other words, I have this suspicion that create_note() that
>> removes is a wrong interface in the first place, and giving it
>> a new allow_empty parameter to conditionally perform removal is
>> making it worse
Christian Couder writes:
> From: Junio C Hamano
> Subject: Re: [PATCH v2 4/5] trailer: reuse ignore_non_trailer() to ignore
> conflict lines
> Date: Mon, 10 Nov 2014 09:49:34 -0800
>
>> Christian Couder writes:
>>
>>> Make sure we look for trailers before any conflict line
>>> by reusing the
Junio C Hamano writes:
> Dying when "update-index --refresh" signals a difference is an
> attempt to mimic #1, but it is in line with the spirit of the reason
> why a user would want to use updateInstead, I think. The situation
> is more like the person who pushed into your repository from
> sid
From: Junio C Hamano
Subject: Re: [PATCH v2 4/5] trailer: reuse ignore_non_trailer() to ignore
conflict lines
Date: Mon, 10 Nov 2014 09:49:34 -0800
> Christian Couder writes:
>
>> Make sure we look for trailers before any conflict line
>> by reusing the ignore_non_trailer() function.
>>
>> Hel
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Couder writes:
> Make sure we look for trailers before any conflict line
> by reusing the ignore_non_trailer() function.
>
> Helped-by: Junio C Hamano
> Signed-off-by: Christian Couder
> ---
It makes sense to unify the logic to decide where the trailer block
is, I would think. I how
Bernhard Reiter writes:
> Am 2014-11-09 um 14:00 schrieb Torsten Bögershausen:
>> On 2014-08-27 00.40, Bernhard Reiter wrote:
>>> Use libcurl's high-level API functions to implement git-imap-send
>>> instead of the previous low-level OpenSSL-based functions.
>>>
>> This doesn't seem to fully work
Torsten Bögershausen writes:
>> * jt/timer-settime (2014-08-29) 6 commits
>> - use timer_settime() for new platforms
>> - autoconf: check for timer_settime()
>> - autoconf: check for struct itimerspec
>> - autoconf: check for struct sigevent
>> - autoconf: check for struct timespec
>> - aut
Thomas Quinot writes:
> * Jeff King, 2014-11-10 :
>
>> I think this version looks good. Thanks for working on it.
>
> Thanks!
>
>> Two style micro-nits (that I do not think even merit a re-roll by
>> themselves, but Junio may want to mark up as he applies):
>
> OK, committed locally, I can resend
Hi again,
oops, I realized that my MUA mangled the patch, even though it
shouldn't. Here it is again, with a bit more description.
---
During 'rebase -i', one wrong edit in a long rebase session might
inadvertently drop commits. This change shows the total number of
commits in the comments below
Johannes Schindelin writes:
>> I do not think of a good justification of detachInstead offhand, but
>> you must have thought things through a lot more than I did, so you
>> can come up with a work flow description that is more usable by mere
>> mortals to justify that mode.
>
> The main justifica
Johannes Schindelin writes:
>> By the way, if the expected use case of updateInstead is what I
>> outlined in the previous message, would it make more sense not to
>> fail with "update-index --refresh" failure (i.e. the working tree
>> files have no changes since the index)?
>>
>> Thinking about
Hi,
On Mon, 10 Nov 2014, Johannes Schindelin wrote:
> In start_command(), unset "env" fields are initialized via "env_array". In
> finish_command(), the "env_array" is cleared, therefore the "env" field
> will point to free()d data.
>
> However, start_command() will set "env" to env_array.argv o
When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the use
In start_command(), unset "env" fields are initialized via "env_array". In
finish_command(), the "env_array" is cleared, therefore the "env" field
will point to free()d data.
However, start_command() will set "env" to env_array.argv only if "env"
was unset to begin with, and if it was already set,
This patch series adds support for two new receive.denyCurrentBranch settings:
one to update the working directory (which must be clean, i.e. there must not
be any uncommitted changes) when pushing into the current branch, the other
setting detaches the HEAD instead.
The scenario in which in parti
For projects with separate history lines and, thus, multiple root-commits, the
linear arrangement of `git log --graph --oneline` does not allow the user to
spot where the sequence ends, giving the impression that it's a contiguous
history. E.g.
History sequence A: a1 -- a2 -- a3 (root-commit)
Hist
Hi Jens,
On Sun, 9 Nov 2014, Jens Lehmann wrote:
> Am 07.11.2014 um 20:20 schrieb Junio C Hamano:
> > Johannes Schindelin writes:
> >
> > > Signed-off-by: Johannes Schindelin
> > > ---
> > > builtin/receive-pack.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff -
Hi Peff,
On Sat, 8 Nov 2014, Jeff King wrote:
> On Fri, Nov 07, 2014 at 02:58:17PM +0100, Johannes Schindelin wrote:
>
> > Under certain circumstances, it makes a *lot* of sense to allow pushing
> > into the current branch. For example, when two machines with different
> > Operating Systems are
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Signed-off-by: Johannes Schindelin
> > ---
> > builtin/receive-pack.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > inde
Hi Junio,
On Fri, 7 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Under certain circumstances, it makes a *lot* of sense to allow pushing
> > into the current branch. For example, when two machines with different
> > Operating Systems are required for testing, it makes muc
On Mon, Nov 10, 2014 at 8:31 PM, Jeff King wrote:
> On Mon, Nov 10, 2014 at 07:51:00PM +1100, Bryan Turner wrote:
>
>> Second change: git gc --auto now fails if there are loose empty blobs.
>>
>> We have a test which just touched empty files in objects/17 to trigger
>> the gc --auto preconditions
On Mon, Nov 10, 2014 at 8:22 PM, Jeff King wrote:
> On Mon, Nov 10, 2014 at 07:47:32PM +1100, Bryan Turner wrote:
>
>> First change: git update-ref -d /refs/heads/nonexistent
>> now produces an error about ref locking that it
>> didn't produce before
>>
>> Git 2.1.x and prior produced this output
http://git.661346.n2.nabble.com/PATCH-Custom-prompt-colors-td7620939.html
“Art has no limits.
Just like me!”
by Ponce
On Mon, Nov 10, 2014 at 10:42 AM, Vanja Radovanović wrote:
> From 41e9edae533306b4a50570e32dbbdd291a4a5fbf Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Vanja=20Radovanovi=C4=87?=
>From 41e9edae533306b4a50570e32dbbdd291a4a5fbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vanja=20Radovanovi=C4=87?=
Date: Sun, 9 Nov 2014 20:05:48 +0100
Subject: [PATCH] contrib/completion: custom git prompt colors
Allow git prompt colors to be customized.
Accept globally set colors, use defaults
On Mon, Nov 10, 2014 at 07:51:00PM +1100, Bryan Turner wrote:
> Second change: git gc --auto now fails if there are loose empty blobs.
>
> We have a test which just touched empty files in objects/17 to trigger
> the gc --auto preconditions (Note: I realize this is completely
> invalid, and I've c
On Mon, Nov 10, 2014 at 07:47:32PM +1100, Bryan Turner wrote:
> First change: git update-ref -d /refs/heads/nonexistent
> now produces an error about ref locking that it
> didn't produce before
>
> Git 2.1.x and prior produced this output:
> error: unable to resolve reference refs/heads/nonexist
I've been running a test suite we use to verify Git behaviors across
versions, and the 2.2.0 RCs (0 and 1 both) have a couple of small
behavioral differences. I'm sending them in separate e-mails just to
make the contents easier to grok.
Important: It's entirely possible neither of these is a _bug
I've been running a test suite we use to verify Git behaviors across
versions, and the 2.2.0 RCs (0 and 1 both) have a couple of small
behavioral differences. I'm sending them in separate e-mails just to
make the contents easier to grok.
Important: It's entirely possible neither of these is a _bug
* Jeff King, 2014-11-10 :
> I think this version looks good. Thanks for working on it.
Thanks!
> Two style micro-nits (that I do not think even merit a re-roll by
> themselves, but Junio may want to mark up as he applies):
OK, committed locally, I can resend a PATCH v5 if that's more
convenient
53 matches
Mail list logo
