> On 02 Mar 2016, at 18:33, Johannes Sixt wrote:
>
> Am 19.02.2016 um 10:16 schrieb larsxschnei...@gmail.com:
>> +test_expect_success '--show-origin with --list' '
>> +cat >expect <<-EOF &&
>> +file:$HOME/.gitconfig user.global=true
>> +file:$HOME/.gitconfig user.
Am 03.03.2016 um 02:04 schrieb Duy Nguyen:
> On Thu, Mar 3, 2016 at 7:07 AM, Christian Couder
> wrote:
>> Hi,
>>
>> It looks like commit 57ea7123c86771f47f34e7d92d1822d8b429897a (git.c:
>> make sure we do not leak GIT_* to alias scripts, Dec 20 14:50:19 2015)
>> broke "./t0001-init.sh --valgrind".
On 03/03/16 03:33, Ramsay Jones wrote:
>
>
> On 29/02/16 12:32, Ramsay Jones wrote:
>>
>>
>> On 29/02/16 10:40, Torsten Bögershausen wrote:
>>> That compiles OK, thanks.
>>>
>>>
>>> Sorry for high-jacking this thread, but while compiling under CYGWIN,
>>> found one warning:
>>>
>>>LINK git-
On Thu, Mar 3, 2016 at 9:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> would it be
>> ok if we introduced a minimal resumable download service via
>> git-daemon to enable this feature with very little setup? Like
>> git-shell, you can only download certain packfiles for this use case
>>
On 29/02/16 12:32, Ramsay Jones wrote:
>
>
> On 29/02/16 10:40, Torsten Bögershausen wrote:
>> That compiles OK, thanks.
>>
>>
>> Sorry for high-jacking this thread, but while compiling under CYGWIN,
>> found one warning:
>>
>>LINK git-credential-store.exe
>> CC daemon.o
>> daemon.c: In
Duy Nguyen writes:
> On Thu, Mar 3, 2016 at 7:07 AM, Christian Couder
> wrote:
>> Hi,
>>
>> It looks like commit 57ea7123c86771f47f34e7d92d1822d8b429897a (git.c:
>> make sure we do not leak GIT_* to alias scripts, Dec 20 14:50:19 2015)
>> broke "./t0001-init.sh --valgrind".
>
> Just wanted to co
Duy Nguyen writes:
> would it be
> ok if we introduced a minimal resumable download service via
> git-daemon to enable this feature with very little setup? Like
> git-shell, you can only download certain packfiles for this use case
> and nothing else with this service.
I think it is a matter of
On Thu, Mar 3, 2016 at 3:32 AM, Junio C Hamano wrote:
> - After arranging that packfile to be downloadable over popular
>transfer methods used for serving static files (such as HTTP or
>HTTPS) that are easily resumable as $URL/pack-$name.pack, a v3
>bundle file (call it $name.bndl) ca
On Thu, Mar 3, 2016 at 7:07 AM, Christian Couder
wrote:
> Hi,
>
> It looks like commit 57ea7123c86771f47f34e7d92d1822d8b429897a (git.c:
> make sure we do not leak GIT_* to alias scripts, Dec 20 14:50:19 2015)
> broke "./t0001-init.sh --valgrind".
Just wanted to confirm the problem. I will look at
Hi,
It looks like commit 57ea7123c86771f47f34e7d92d1822d8b429897a (git.c:
make sure we do not leak GIT_* to alias scripts, Dec 20 14:50:19 2015)
broke "./t0001-init.sh --valgrind".
I get:
expecting success:
(
env | sed -ne "/^GIT_/s/=.*//p" &&
echo GIT_PRE
Thanks for the thorough response. Here is some basic info:
$ git --version
git version 2.5.0
$ cat /etc/issue
Ubuntu 15.10
$ git config merge.tool
kdiff3
The issue seems as if it may be related to different renames of the
same file/folder in both the master branch and the feature branch.
I have
I'll add Jens, who has deep knowledge of submodules.
On Wed, Mar 2, 2016 at 8:52 AM, Joey Hess wrote:
> joey@darkstar:/tmp/empty>git init sub1
> Initialized empty Git repository in /tmp/empty/sub1/.git/
> joey@darkstar:/tmp/empty>git init sub2
> Initialized empty Git repository in /tmp/empty/sub2
This is earlier than usual by a few hours, but I'd like to make sure
everybody is aware of the topics that will be graduating from 'next'
to rc1, which are:
+ mg/httpd-tests-update-for-apache-2.4 02-25/03-01
#1
+ jk/pack-idx-corruption-safety
On Wed, Mar 02, 2016 at 12:32:40PM -0800, Junio C Hamano wrote:
> + free((void *)header->filename);
This cast is necessary, because...
> diff --git a/bundle.h b/bundle.h
> index f7ce23b..e059ccf 100644
> --- a/bundle.h
> +++ b/bundle.h
> @@ -10,12 +10,14 @@ struct ref_list {
> };
>
> str
Johannes Schindelin writes:
> The pthread_exit() function is not expected to return. Ever. On Windows,
> we call ExitThread() whose documentation claims: "Ends the calling
> thread", i.e. there is no condition in which this function simply
> returns: https://msdn.microsoft.com/en-us/library/windo
Here is a preview of the "split bundle" stuff that may serve as one
of the enabling technology to offload "git clone" traffic off of the
server core network to CDN.
Changes:
- The "checksum" bit about the in-bundle packdata, which was
incorrect, was dropped from the proposed log message of 1/
This will be necessary when we start reading from a split bundle
where the header and the thin-pack data live in different files.
The in-core bundle header will read from a file that has the header,
and will record the path to that file. We would find the name of
the file that hosts the thin-pack
The bundle header structure holds two lists of refs and object
names, which should be released when the user is done with it.
Signed-off-by: Junio C Hamano
---
bundle.c| 12
bundle.h| 1 +
transport.c | 1 +
3 files changed, 14 insertions(+)
diff --git a/bundle.c b/bundle
Even though the command does read the bundle header and checks to
see if it looks reasonable, the thin-pack data stream that follows
the header in the bundle file is not checked.
The documentation gives an incorrect impression that the data
contained in the bundle is validated, but the command is
The bundle v3 format introduces an ability to have the bundle header
(which describes what references in the bundled history can be
fetched, and what objects the receiving repository must have in
order to unbundle it successfully) in one file, and the bundled pack
stream data in a separate file.
A
The pthread_exit() function is not expected to return. Ever. On Windows,
we call ExitThread() whose documentation claims: "Ends the calling
thread", i.e. there is no condition in which this function simply
returns: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682659
While at it, fix
Hi,
On Tue, 1 Mar 2016, stefan.na...@atlas-elektronik.com wrote:
> Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
> > The pthread_exit() function is not expected to return. Ever. On Windows,
> > we call ExitThread() whose documentation claims: "This function does not
> > return a value.":
>
Hi,
On Tue, 1 Mar 2016, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
> >> The pthread_exit() function is not expected to return. Ever. On Windows,
> >> we call ExitThread() whose documentation claims: "This function does not
> >> return
Hi,
>
>Looking at the standard translations in Ubuntu [1],
>"command" is supposed to be translated as "Befehl" if
>it's the first part in the command line (the actual command)
>and "Kommando" if it's the second part (a subcommand).
>
>Currently we almost always translate as "Kommando", which,
>f
In my opinion I would like to see "z.B." in a monospaced environment
rather than "z. B.".
The correct way of separating those two is to use a thin space, which is
not possible in ASCII.
Look here for further information:
https://de.wikipedia.org/wiki/Schmales_Leerzeichen
Kind regards,
Matthias
Am 2. März 2016 um 18:46 schrieb Stefan Beller :
> On Wed, Mar 2, 2016 at 9:36 AM, Ralf Thielow wrote:
>> Signed-off-by: Ralf Thielow
>> ---
>> po/de.po | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/po/de.po b/po/de.po
>> index 8c5f05d..07b4456 100644
>> --- a/p
just subscribe to the mailing list,
by sending "subscribe git" to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 2, 2016 at 9:35 AM, Aditya Baderdinni
wrote:
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the b
--
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
Jeff King writes:
> On Tue, Mar 01, 2016 at 01:36:05PM -0800, Junio C Hamano wrote:
>
>> Even though the command does read the bundle header and checks to
>> see if it looks reasonable, the thin-pack data stream that follows
>> the header in the bundle file is not checked. More importantly,
>> b
Jeff King writes:
> On Tue, Mar 01, 2016 at 03:36:26PM -0800, Junio C Hamano wrote:
>
>> This will be necessary when we start reading from a split bundle
>> where the header and the thin-pack data live in different files.
>>
>> The in-core bundle header will read from a file that has the header,
Josh Triplett writes:
> That does help in the case of cloning torvalds/linux.git from
> kernel.org, and I'd love to see it used transparently.
>
> However, even with that, I still also see value in a resumable git clone
> (or git pull) for many other repositories elsewhere,...
By "transparently"
Signed-off-by: Ralf Thielow
---
po/de.po | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/po/de.po b/po/de.po
index a6b7bf3..9344a53 100644
--- a/po/de.po
+++ b/po/de.po
@@ -9145,7 +9145,7 @@ msgid ""
msgstr ""
"Aktualisierungen wurden zurückgewiesen, weil die Spitze Ih
On Wed, Mar 2, 2016 at 9:36 AM, Ralf Thielow wrote:
> Signed-off-by: Ralf Thielow
> ---
> po/de.po | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index 8c5f05d..07b4456 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -1950,8 +1950,8 @@ msgstr "Ke
Signed-off-by: Ralf Thielow
---
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index 8c5f05d..07b4456 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1950,8 +1950,8 @@ msgstr "Keine Kommandos ausgeführt."
#, c-format
msgid "Last command done (%d co
On Wed, Mar 2, 2016 at 9:21 AM, Johannes Sixt wrote:
> Am 13.02.2016 um 00:39 schrieb Stefan Beller:
>> @@ -289,4 +296,39 @@ test_git_path GIT_COMMON_DIR=bar config
>> bar/config
>> test_git_path GIT_COMMON_DIR=bar packed-refs bar/packed-refs
>> test_git_path GI
Am 19.02.2016 um 10:16 schrieb larsxschnei...@gmail.com:
+test_expect_success '--show-origin with --list' '
+ cat >expect <<-EOF &&
+ file:$HOME/.gitconfig user.global=true
+ file:$HOME/.gitconfig user.override=global
+ file:$HOME/.gitconfig
Signed-off-by: Ralf Thielow
---
po/de.po | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/po/de.po b/po/de.po
index 8c5f05d..0c38d36 100644
--- a/po/de.po
+++ b/po/de.po
@@ -9145,7 +9145,7 @@ msgid ""
msgstr ""
"Aktualisierungen wurden zurückgewiesen, weil die Spitze Ih
Am 13.02.2016 um 00:39 schrieb Stefan Beller:
> @@ -289,4 +296,39 @@ test_git_path GIT_COMMON_DIR=bar config
> bar/config
> test_git_path GIT_COMMON_DIR=bar packed-refs bar/packed-refs
> test_git_path GIT_COMMON_DIR=bar shallow bar/shallow
>
>
2016-03-02 12:46 GMT+01:00 Christoph Hoopmann :
> Signed-off-by: Christoph Hoopmann
> ---
>
> Changes since v1:
> * Imperative in commit subject
> * "Signed-off-by"-line inserted
> ---
> po/de.po | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/po/de.po b/po/de.po
> inde
On Wed, Mar 02, 2016 at 12:41:20AM -0800, Junio C Hamano wrote:
> Josh Triplett writes:
> > If you clone a repository, and the connection drops, the next attempt
> > will have to start from scratch. This can add significant time and
> > expense if you're on a low-bandwidth or metered connection t
joey@darkstar:/tmp/empty>git init sub1
Initialized empty Git repository in /tmp/empty/sub1/.git/
joey@darkstar:/tmp/empty>git init sub2
Initialized empty Git repository in /tmp/empty/sub2/.git/
joey@darkstar:/tmp/empty>cd sub1
joey@darkstar:/tmp/empty/sub1>date > f1 ; git add f1; git commit -m add
On Wed, Mar 02, 2016 at 12:31:16AM -0800, Junio C Hamano wrote:
> Josh Triplett writes:
> > I think several simpler optimizations seem
> > preferable, such as binary object names, and abbreviating complete
> > object sets ("I have these commits/trees and everything they need
> > recursively; I als
On Wed, Mar 02, 2016 at 03:22:17PM +0700, Duy Nguyen wrote:
> On Wed, Mar 2, 2016 at 3:13 PM, Josh Triplett wrote:
> > On Wed, Mar 02, 2016 at 02:30:24AM +, Al Viro wrote:
> >> On Tue, Mar 01, 2016 at 05:40:28PM -0800, Stefan Beller wrote:
> >>
> >> > So throwing away half finished stuff while
On Wed, Mar 02, 2016 at 12:41:20AM -0800, Junio C Hamano wrote:
> Josh Triplett writes:
>
> > If you clone a repository, and the connection drops, the next attempt
> > will have to start from scratch. This can add significant time and
> > expense if you're on a low-bandwidth or metered connectio
> On Wed, Mar 2, 2016 at 3:21 AM, Sidhant Sharma [:tk]
> wrote:
>> + struct option options[] = {
>> + OPT__QUIET(&quiet, N_("quiet")),
>> + OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
>> + OPT_HIDDEN_BOOL(0, "advertise-refs", &adverti
git commit has a --no-verify option to prevent the pre-commit hook from
running. When continuing a conflicted cherry-pick, git commit gets
executed which also causes the pre-commit hook to be run.
Add --no-verify and pass that through to the git commit command.
Signed-off-by: Kevin Daudt
---
Cha
Signed-off-by: Christoph Hoopmann
---
Changes since v1:
* Imperative in commit subject
* "Signed-off-by"-line inserted
---
po/de.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index 8c5f05d..a6b7bf3 100644
--- a/po/de.po
+++ b/po/de.po
@@ -12079,7 +1
Please use imperative form in the commit subject, like "l10n: de.po: fix typo".
2016-03-02 10:13 GMT+01:00 :
> From: Christoph Hoopmann
>
> ---
"Signed-off-by"-line is missing.
Thanks
> po/de.po | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/po/de.po b/po/de.po
> in
On 3/2/16 2:02 PM, Jeff King wrote:
On Wed, Mar 02, 2016 at 03:22:17PM +0700, Duy Nguyen wrote:
As a simple proposal, the server could send the list of hashes (in
approximately the same order it would send the pack), the client could
send back a bitmap where '0' means "send it" and '1' means "g
On Thu, Feb 25, 2016 at 5:31 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Feb 24, 2016 at 11:09 PM, Christian Couder
> wrote:
>
> [Resent because I was accidentally in GMail's HTML mode and the ML rejected
> it]
>
>> If there was a config option called maybe "rebase.taskset" or
>> "rebase.setcpu
On Wed, Mar 2, 2016 at 3:21 AM, Sidhant Sharma [:tk]
wrote:
> + struct option options[] = {
> + OPT__QUIET(&quiet, N_("quiet")),
> + OPT_HIDDEN_BOOL(0, "stateless-rpc", &stateless_rpc, NULL),
> + OPT_HIDDEN_BOOL(0, "advertise-refs", &advertise_refs,
On Wed, Mar 2, 2016 at 3:31 PM, Junio C Hamano wrote:
> Josh Triplett writes:
>
>> I don't think it's worth the trouble and ambiguity to send abbreviated
>> object names over the wire.
>
> Yup. My unscientific experiment was to show that the list would be
> far smaller than the actual transfer a
> On 02 Mar 2016, at 06:06, Luke Diamand wrote:
>
> On 1 March 2016 at 19:15, Eric Sunshine wrote:
>> On Tue, Mar 1, 2016 at 5:49 AM, wrote:
>>> Map a P4 user to a specific name and email address in Git with the
>>> "git-p4.mapUser" config. The config value must be a string adhering
>>> to th
On Tue, Mar 01, 2016 at 01:36:05PM -0800, Junio C Hamano wrote:
> Even though the command does read the bundle header and checks to
> see if it looks reasonable, the thin-pack data stream that follows
> the header in the bundle file is not checked. More importantly,
> because the thin-pack data d
From: Christoph Hoopmann
---
po/de.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index 8c5f05d..a6b7bf3 100644
--- a/po/de.po
+++ b/po/de.po
@@ -12079,7 +12079,7 @@ msgid ""
"option."
msgstr ""
"oder Sie sich unsicher sind, was das bedeutet, wählen
On Wed, Mar 02, 2016 at 01:00:38AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do find it hard to believe that the bundle code had to invent its own
> > ref storage data structure, and couldn't just use "struct ref" like all
> > of the other code. It doesn't look like we ever sort i
On Tue, Mar 01, 2016 at 03:36:26PM -0800, Junio C Hamano wrote:
> This will be necessary when we start reading from a split bundle
> where the header and the thin-pack data live in different files.
>
> The in-core bundle header will read from a file that has the header,
> and will record the path
Jeff King writes:
> I do find it hard to believe that the bundle code had to invent its own
> ref storage data structure, and couldn't just use "struct ref" like all
> of the other code. It doesn't look like we ever sort it or do
> non-sequential access. The linked-list "struct ref" probably woul
On Tue, Mar 01, 2016 at 03:35:34PM -0800, Junio C Hamano wrote:
> The bundle header structure holds two lists of refs and object
> names, which should be released when the user is done with it.
>
> Signed-off-by: Junio C Hamano
> ---
> bundle.c| 12
> bundle.h| 1 +
> tran
Sidhant Sharma writes:
>> Matthieu Moy writes:
>>
>>> Thanks. This version looks good to me.
>> I'll queue this with your "Reviewed-by:" to 'pu', just as a
>> Microproject reward ;-). Given that the program will never see an
>> interactive use from a command line, however, I am not sure if it i
On Tue, Mar 01, 2016 at 07:17:20PM -0400, Joey Hess wrote:
> Junio C Hamano wrote:
> > A more pertinent question may be which version of Git did the above
> > ever work, I guess. We fairly liberally chdir around and I do not
> > think we deliberately avoid assuming that "cd .git && cd .." might
>
Josh Triplett writes:
> If you clone a repository, and the connection drops, the next attempt
> will have to start from scratch. This can add significant time and
> expense if you're on a low-bandwidth or metered connection trying to
> clone something like Linux.
For this particular issue, your
On Wed, Mar 02, 2016 at 03:22:17PM +0700, Duy Nguyen wrote:
> > As a simple proposal, the server could send the list of hashes (in
> > approximately the same order it would send the pack), the client could
> > send back a bitmap where '0' means "send it" and '1' means "got that one
> > already", a
Josh Triplett writes:
> I don't think it's worth the trouble and ambiguity to send abbreviated
> object names over the wire.
Yup. My unscientific experiment was to show that the list would be
far smaller than the actual transfer and between full binary and
full textual object name representat
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> "Sidhant Sharma [:tk]" writes:
>>
>>> Make receive-pack use the parse_options API,
>>> bringing it more in line with send-pack and push.
>>
>> Thanks. This version looks good to me.
>
> I'll queue this with your "Reviewed-by:" to 'pu', just as
On Wed, Mar 2, 2016 at 3:13 PM, Josh Triplett wrote:
> On Wed, Mar 02, 2016 at 02:30:24AM +, Al Viro wrote:
>> On Tue, Mar 01, 2016 at 05:40:28PM -0800, Stefan Beller wrote:
>>
>> > So throwing away half finished stuff while keeping the front load?
>>
>> Throw away the object that got truncate
On Wed, Mar 2, 2016 at 9:30 AM, Al Viro wrote:
> IIRC, the objection had been that the organisation of the pack will lead
> to many cases when deltas are transferred *first*, with base object not
> getting there prior to disconnect. I suspect that fraction of the objects
> getting through would s
On Wed, Mar 02, 2016 at 02:30:24AM +, Al Viro wrote:
> On Tue, Mar 01, 2016 at 05:40:28PM -0800, Stefan Beller wrote:
>
> > So throwing away half finished stuff while keeping the front load?
>
> Throw away the object that got truncated and ones for which delta chain
> doesn't resolve entirely
68 matches
Mail list logo
