A release candidate preview Git v1.8.4-rc0 is now available for
testing at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
8e0d93653633fcaffc829f607bd8c1077a855c1d git-1.8.4.rc0.tar.gz
1e2b18ea855b3e06ab2e
6796d49 introduced a bug by making shared_path == ".git/hg' which
will most likely exist already, causing a new remote never to be
cloned and subsequently causing hg.share to fail with error msg:
"mercurial.error.RepoError: repository .git/hg not found"
Changing shared_path to ".git/hg/.shared" wi
On 25 Jul 2013, at 01:02, Junio C Hamano wrote:
> Joern Hees writes:
>>
>> Changing shared_path to ".git/hg/.shared" will solve this problem
>
> Here you say "shared" and the code says "share"; which one is
> preferred (I know either would work, but we would want to be
> consistent).
>
> I'd
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
Joern Hees writes:
> 6796d49 introduced a bug by making shared_path == ".git/hg' which
> will most likely exist already, causing a new remote never to be
> cloned and subsequently causing hg.share to fail with error msg:
> "mercurial.error.RepoError: repository .git/hg not found"
>
> Changing sha
Jörn Hees writes:
> On 24 Jul 2013, at 17:20, Junio C Hamano wrote:
>
>> Goes and looks...
>>
>> OK, the tracking branches for these are created under refs/hg/*
>> using the same name.
>> ...
>> A refname shouldn't begin or end with a dot, because the range
>> ... ellided a correct descrip
"Kyle J. McKay" writes:
> And hopefully Junio can add this as an incremental patch against next
> as it looks good to me.
Not likely to happen until the weekend.
If I had time for such a clean-up, I would rather be doing the
restructuring of the whole thing to make Peff's "git config --url
$U
Jonathon Mah writes:
> I always add --tags when I call git-describe. Is there any reason this
> shouldn't become the new default (quickly, before git 2.0 perhaps)?
The distinction is there for a reason--- annotated tags are meant
for the more "public" and "permanent" stuff, while you can do
lig
Daniele Segato writes:
> Annotated and Lightweight tags are not the same thing
> for git and you shouldn't mix them up. Annotated tags are meant for
> release while lightweight tags are meant to tag random commits.
Nicely explained.
This is one of those "we who worked on Git (not worked "with"
On Wed, Jul 24, 2013 at 11:10 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Tue, Jul 23, 2013 at 3:03 PM, Junio C Hamano wrote:
>>> SZEDER Gábor writes:
You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l >> Correct.
>>
>> Thanks, I like that better.
>>
>> Unfortun
On Jul 24, 2013, at 12:07, Ramsay Jones wrote:
Sparse issues an "non-ANSI function declaration of function 'main'"
warning when NO_CURL is set. In order to suppress the warning, we
simply add the function prototype.
When NO_CURL and USE_CURL_MULTI are not defined, then gcc issues the
following
Torsten Bögershausen wrote:
>
>> ml/cygwin-updates:
>> cygwin: stop forcing core.filemode=false
>
> I like that: cygwin behaves more like Unix/Linux.
>
> Just a side-comment: When working on NTFS, cygwin
> will set core.filemode=true, and as a result of that,
> the "cheating lstat" code is
Sparse issues an "non-ANSI function declaration of function 'main'"
warning when NO_CURL is set. In order to suppress the warning, we
simply add the function prototype.
When NO_CURL and USE_CURL_MULTI are not defined, then gcc issues the
following error:
CC test-url-normalize.o
test-url-
On Wed, Jul 24, 2013 at 12:01:26PM -0700, Kyle J. McKay wrote:
> Right now, the values are only available as various strings, ints,
> longs etc. which have to be formatted differently for output. The
> original string value they were converted from is gone. The snippet
> shown above only shows s
> Some git command (ex. git describe) by default only consider
> annotated tags.
I always add --tags when I call git-describe. Is there any reason this
shouldn't become the new default (quickly, before git 2.0 perhaps)? I wasn't
able to find any reason for the current behavior with just
On Jul 23, 2013, at 23:59, Jeff King wrote:
diff --git a/test-url-normalize.c b/test-url-normalize.c
new file mode 100644
index 000..f18bd88
--- /dev/null
+++ b/test-url-normalize.c
[...]
+ if (!strcmp("sslverify", opt_lc.buf))
+ printf("%s\n", curl_ssl_verify ? "true" :
On Jul 24, 2013, at 10:14, Junio C Hamano wrote:
Jeff King writes:
How hard would it be to convert the "-c" option of test-url-normalize
into something like:
git config --file=foo --url http noepsv $URL
which would look for http.$URL.noepsv matches.
Lovely.
[snip]
Another thing we may
I got more responses from people regarding the .mailmap file.
All added persons gave permission to add them to the .mailmap file.
Signed-off-by: Stefan Beller
---
.mailmap | 4
1 file changed, 4 insertions(+)
diff --git a/.mailmap b/.mailmap
index 57070b5..57551b0 100644
--- a/.mailmap
+++
Jeff King writes:
> That is, would a shell script ever want to say "what is the value of
> this config variable for url $X"? Certainly our test scripts want to,
> and having a test-* program covers that, but might user scripts want to
> do the same? Or even to introduce its own URL-matched config
Duy Nguyen napisał:
>On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki
> wrote:
>> (resending, as my phone mail client decided to send it in html, sorry
>> about that)
>>
>> On Wed, Jul 24, 2013 at 3:57 AM, Duy Nguyen
>wrote:
>>> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley
> wrote:
There
Matthew Wang writes:
> I noticed a change in commit 734b2f0 on
> contrib/completion/git-completion.bash which reverted a syntax fix for
> '+=' syntax [1], the syntax does not work for bash < 3.1. As far as I
> know, bash 3.0.x is still widely used on some old servers, could
> someone add the fix
On 24 Jul 2013, at 17:20, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
>>> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
I think the best way would be to create the shared repository in
.git/hg/$share, with $share being a
Antoine Pelisse writes:
> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
>> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>>> I think the best way would be to create the shared repository in
>>> .git/hg/$share, with $share being a path that can't be a remote name
>>> (so that it doesn't c
Eric Sunshine writes:
> On Tue, Jul 23, 2013 at 3:03 PM, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>> You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l > Correct.
>
> Thanks, I like that better.
>
> Unfortunately, what actually got queued on 'next', after applying this
> fix
Jeff King writes:
> 1. The explanation and special-casing of username is a little
> complicated to explain.
>
> 2. The behavior for resolving the value when faced with multiple
> possibilities is completely unlike the rest of the config system
> (both dropping last-one-wins, an
On 07/19/2013 12:34 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I sent the patch shortly before leaving for a trip so I didn't have time
>> to make it as complete as I would have liked. But given that the
>> problem was already in master, and the fix is pretty simple, I wanted to
>
6796d49 introduced a bug by making shared_path == ".git/hg' which
will most likely exist already, causing a new remote never to be
cloned and subsequently causing hg.share to fail with error msg:
"mercurial.error.RepoError: repository .git/hg not found"
Changing shared_path to ".git/hg/.shared" wi
On 24.07.2013, at 15:14, Antoine Pelisse wrote:
> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
>> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>>> I think the best way would be to create the shared repository in
>>> .git/hg/$share, with $share being a path that can't be a remote name
On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>> I think the best way would be to create the shared repository in
>> .git/hg/$share, with $share being a path that can't be a remote name
>> (so that it doesn't conflict with remote directories)
On Wed, 24 Jul 2013 16:46:46 +0400
Konstantin Konovalov wrote:
> During reading the online book (http://git-scm.com/book/ru - russian
> translation) I found some bugs.
[...]
Please report them at https://github.com/github/gitscm-next/issues
--
To unsubscribe from this list: send the line "unsubs
Since c7d67ab running "tig" with no options has failed with the
error "tig: No revisions match the given arguments." This was due
to a change in how the arguments for the back-end git call was
being constructed. This change caused the blank field left in
place of "(encoding_arg)" when it is empty t
Hello.
During reading the online book (http://git-scm.com/book/ru - russian
translation) I found some bugs.
1. Chapter 5.5
(http://git-scm.com/book/ru/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B9-Git-Maintaining-a-Project)
is original english (non translate
On 07/19/2013 12:07 AM, Jonas Fonseca wrote:
On Thu, Jul 18, 2013 at 9:30 AM, Drew Northup wrote:
Somehow this patch breaks the main view to not open the correct commit in diff view
when is pressed. Back to the debugger...
Does this (possibly white-space damaged) patch work for you?
It d
On Wed, Jul 24, 2013 at 3:30 PM, Piotr Krukowiecki
wrote:
> (resending, as my phone mail client decided to send it in html, sorry
> about that)
>
> On Wed, Jul 24, 2013 at 3:57 AM, Duy Nguyen wrote:
>> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley wrote:
>>> There have been comments on the git-
Hi,
I think there is an issue with the documentation of git tag, or with the
default being chosen for tags.
the git tag documentation say:
*
If one of -a, -s, or -u is passed, the command creates
a tag object, and requires a tag message. Unless -m or -F
is given, an editor is
Hi,
On 24.07.2013, at 10:52, Antoine Pelisse wrote:
> I think the best way would be to create the shared repository in
> .git/hg/$share, with $share being a path that can't be a remote name
> (so that it doesn't conflict with remote directories),
> and then apply the following patch (copied in gm
On Tue, Jul 23, 2013 at 11:40 PM, Joern Hees wrote:
> 6796d49 introduced a bug by making shared_path == ".git/hg' which
> will most likely exist already, causing a new remote never to be
> cloned and subsequently causing hg.share to fail with error msg:
> "mercurial.error.RepoError: repository .gi
(resending, as my phone mail client decided to send it in html, sorry
about that)
On Wed, Jul 24, 2013 at 3:57 AM, Duy Nguyen wrote:
> On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley wrote:
>> There have been comments on the git-user list about the
>> problem of accidental adding of large files w
This was added in ff5effd (include agent identifier in
capability string, 2012-08-03), but neither the syntax nor
the semantics were ever documented outside of the commit
message.
Signed-off-by: Jeff King
---
Documentation/technical/protocol-capabilities.txt | 17 -
1 file change
This was added in c207e34 (fix push --quiet: add 'quiet'
capability to receive-pack, 2012-01-08) but never
documented.
Signed-off-by: Jeff King
---
Documentation/technical/protocol-capabilities.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/tec
The protocol-capabilities documentation notes that any
capabilities not explicitly mentioned for receive-pack work
only for upload-pack.
Receive-pack has advertised and understood side-band-64k
since 38a81b4 (receive-pack: Wrap status reports inside
side-band-64k, 2010-02-05), but we do not mentio
The report-status capability is understood by receive-pack,
not upload-pack.
Signed-off-by: Jeff King
---
Documentation/technical/protocol-capabilities.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/techn
On Mon, Jul 15, 2013 at 07:25:19PM +0700, Nguyen Thai Ngoc Duy wrote:
> I noticed that "quiet" and "agent" capabilities were missing in
> protocol-capabilitities.txt. I have a rough idea what they do, but I
> think it's best to be documented by the authors. Maybe you have some
> time to make a pat
From: "Duy Nguyen"
Sent: Wednesday, July 24, 2013 2:57 AM
On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley
wrote:
In some sense a project with a sub-module is a narrow clone, split at
a
'commit' object.
Yes, except narrow clone is more flexible. You have to decide the
split boundary at commit
On Mon, Jul 22, 2013 at 05:56:41AM -0700, Kyle J. McKay wrote:
> +enum http_option_type {
> + OPT_POST_BUFFER,
> + OPT_MIN_SESSIONS,
> + OPT_SSL_VERIFY,
> + OPT_SSL_TRY,
> + OPT_SSL_CERT,
> + OPT_SSL_CAINFO,
> + OPT_LOW_SPEED,
> + OPT_LOW_TIME,
> + OPT_NO_EPSV,
On Mon, Jul 22, 2013 at 05:56:43AM -0700, Kyle J. McKay wrote:
> In order to perform sane URL matching for http..* options,
> http.c normalizes URLs before performing matches.
>
> A new test-url-normalize test program is introduced along with
> a new t5200-url-normalize.sh script to run the tests
46 matches
Mail list logo
