On Sun, Jun 10 2018, Todd Zullinger wrote:
>> I added 'use autodie;' without realizing it had external dependencies.
>> According to the documentation
>> http://perldoc.perl.org/autodie.html
>> it's a pragma since perl 5.10.1
>> Removing 'use autodie;' should be fine: it's not critical.
>
> I
Am 10.06.2018 um 12:56 schrieb René Scharfe:
> Am 10.11.2017 um 20:05 schrieb Elijah Newren:
>> +static struct dir_rename_entry *check_dir_renamed(const char *path,
>> + struct hashmap *dir_renames) {
>> +char temp[PATH_MAX];
>> +char *end;
>> +
Pozdravte vás,
Peniaze, ktoré sú k dispozícii ľuďom. Získajte peniaze / pôžičku, ktoré
potrebujete pri financovaní financií Trusts. Sme súkromní veritelia / investori
a ponúkame tak osobné úvery, počiatočnú pôžičku, vzdelávací / poľnohospodársky
úver, nehnuteľný / stavebný úver, majetkový
Am 10.11.2017 um 20:05 schrieb Elijah Newren:
> +static struct dir_rename_entry *check_dir_renamed(const char *path,
> + struct hashmap *dir_renames) {
> + char temp[PATH_MAX];
> + char *end;
> + struct dir_rename_entry *entry;
> +
> +
Added test shows remote with two tag objects pointing to a blob and a
tree. The tag objects themselves are referenced from under regular
refs/tags/* namespace. If test_expect_failure is changed to
test_expect_success the test fails:
Initialized empty Git repository in
"Hello,
Please let me know if you can be part of our supply.Get back to me for
more info if interested:chengsc...@gmail.com
From cheng chan",
--
"Hello,
Please let me know if you can be part of our supply.Get back to me for
more info if interested:chengsc...@gmail.com
On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote:
> On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote:
>> +env \
>> +CONTENT_TYPE=application/x-git-upload-pack-request \
>> +QUERY_STRING=/repo.git/git-upload-pack \
>> +
On Sat, Jun 09, 2018 at 09:01:54PM +0200, Christoph Böhmwalder wrote:
> Hi,
>
> Since this is a use case that actually comes up quite often in
> day-to-day use, especially among git beginners, I was wondering: is
> there a specific reason why a command like "fetch changes from remote,
>
On Sun, Jun 10, 2018 at 2:04 AM, 陶青云 wrote:
> Sorry to intrude, but I can't send a patch to the maillist using
> qq.com and 163.com SMTP server.
Do you have a git with this patch: http://github.com/git/git/commit/5453b83bdf ?
It worked for 赵小强 on 163.com, maybe it'll work for you too.
Hi Elijah
On 07/06/18 06:07, Elijah Newren wrote:
Signed-off-by: Elijah Newren
---
git-rebase.sh | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 40be59ecc4..a56b286372 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -276,6 +276,7
http-backend reads whole input until EOF. However, the RFC 3875 specifies
that a script must read only as many bytes as specified by CONTENT_LENGTH
environment variable. Web server may exercise the specification by not closing
the script's standard input after writing content. In that case
On Tue, Jun 05, 2018 at 01:18:08AM +0300, Max Kirillov wrote:
> On Mon, Jun 04, 2018 at 12:44:09AM -0400, Jeff King wrote:
>> Since this is slightly less efficient, and because it only matters if
>> the web server does not already close the pipe, should this have a
>> run-time configuration knob,
As explained in [1], we should not assume the reason why the writing has
failed, and even if the reason is that child has existed not the reason
why it have done so. So instead just say that writing has failed.
[1] https://public-inbox.org/git/20180604044408.gd14...@sigill.intra.peff.net/
Did the fixes proposed for v7
Max Kirillov (3):
http-backend: cleanup writing to child process
http-backend: respect CONTENT_LENGTH as specified by rfc3875
http-backend: respect CONTENT_LENGTH for receive-pack
config.c | 2 +-
config.h
Push passes to another commands, as described in
https://public-inbox.org/git/20171129032214.gb32...@sigill.intra.peff.net/
As it gets complicated to correctly track the data length, instead transfer
the data through parent process and cut the pipe as the specified length is
reached. Do it only
When replacing files with new content during checkout, we do not write
to them in-place. Instead we unlink and re-create the files in order to
let the system figure out ownership and permissions for the new file,
taking umask into account.
It is safe to do this on Linux file systems, even if open
On 07/06/18 06:06, Elijah Newren wrote:
git rebase has three different types: am, merge, and interactive, all of
which are implemented in terms of separate scripts. am builds on git-am,
merge builds on git-merge-recursive, and interactive builds on
git-cherry-pick. We make use of features in
On Sun, Jun 10, 2018 at 12:56:31PM +0200, René Scharfe wrote:
> The value of PATH_MAX is platform-dependent, so it's easy to exceed when
> doing cross-platform development. It's also not a hard limit on most
> operating systems, not even on Windows. Further reading:
>
>
On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b6cb997164..17af0fe163 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -923,6 +923,14 @@ core.sparseCheckout::
> Enable
On Sun, Jun 10, 2018 at 02:32:57PM +, Kirill Smelkov wrote:
> Added test shows remote with two tag objects pointing to a blob and a
> tree. The tag objects themselves are referenced from under regular
> refs/tags/* namespace. If test_expect_failure is changed to
> test_expect_success the test
On Mon, Jun 11, 2018 at 12:20:16AM -0400, Jeff King wrote:
> Doubly interesting, it looks like this case _used_ to work, but was
> broken by 5f0fc64513 (fetch-pack: eliminate spurious error messages,
> 2012-09-09). Which only changed the fetch-pack side. It moved the
> handling of --all so that
On Mon, Jun 11, 2018 at 12:47 AM, Jeff King wrote:
> Subject: fetch-pack: don't try to fetch peeled values with --all
> [...]
> Original report and test from Kirill Smelkov.
>
> Signed-off-by: Kirill Smelkov
> Signed-off-by: Jeff King
> ---
> diff --git a/t/t5500-fetch-pack.sh
On Mon, Jun 11, 2018 at 01:28:23AM -0400, Eric Sunshine wrote:
> On Mon, Jun 11, 2018 at 12:47 AM, Jeff King wrote:
> > Subject: fetch-pack: don't try to fetch peeled values with --all
> > [...]
> > Original report and test from Kirill Smelkov.
> >
> > Signed-off-by: Kirill Smelkov
> >
On Sat, Jun 09, 2018 at 10:05:49PM +0200, Johannes Schindelin wrote:
> > E.g., could we have a flag or environment variable to have the existing
> > traces output JSON? I guess right now they're inherently free-form via
> > trace_printf, so it would involve adding some structured interface
> >
24 matches
Mail list logo