Re: [PATCH] Limit the size of the data block passed to SHA1_Update()

On Sun, Nov 1, 2015 at 1:32 AM, wrote: > Some implementations of SHA_Updates have inherent limits > on the max chunk size. SHA1_MAX_BLOCK_SIZE can be defined > to set the max chunk size supported, if required. This is > enabled for OSX CommonCrypto library and set to 1GiB. >

Re: [PATCH v5 18/26] refs: move transaction functions into common code

On 10/28/2015 03:14 AM, David Turner wrote: > The common ref code will build up a ref transaction. Backends will > then commit it. So the transaction creation and update functions should > be in the common code. We also need to move the ref structs into > the common code so that alternate

[PATCH] Limit the size of the data block passed to SHA1_Update()

From: Atousa Pahlevan Duprat Some implementations of SHA_Updates have inherent limits on the max chunk size. SHA1_MAX_BLOCK_SIZE can be defined to set the max chunk size supported, if required. This is enabled for OSX CommonCrypto library and set to 1GiB. Signed-off-by:

Re: [PATCH] Allow hideRefs to match refs outside the namespace

On Sun, 01 Nov 2015 at 00:40:39, Lukas Fleischer wrote: > On Sat, 31 Oct 2015 at 18:31:23, Junio C Hamano wrote: > > [...] > > You earlier (re)discovered a good approach to introduce a new > > feature without breaking settings of existing users when we > > discussed a "whitelist". Since setting

Re: [PATCH] Limit the size of the data block passed to SHA1_Update()

>> +int git_SHA1_Update(SHA_CTX *c, const void *data, size_t len) >> +{ >> + size_t nr; >> + size_t total = 0; >> + char *cdata = (char*)data; > I am not sure about the cast > here, though. Doesn't the function SHA1_Update() you are going to > call in the body of the loop take "const

Re: [PATCH v2] ls-files: Add eol diagnostics

On 31.10.2015 11:25, Matthieu Moy wrote: >> ca:text-no-eol wt:text-no-eol t/t5100/empty >> ca:binarywt:binaryt/test-binary-2.png >> ca:text-lf wt:text-lf t/t5100/rfc2047-info-0007 >> ca:text-lf wt:text-crlf doit.bat >> ca:text-crlf-lf wt:text-crlf-lf

Re: [PATCH] Limit the size of the data block passed to SHA1_Update()

> Didn't we have this same issue with NonStop port about a year ago and > decided to provision this through the configure script? I'll be happy to look at it. Can you point me to the right email thread or location in the configure.ac file? Atousa -- To unsubscribe from this list: send the line

Re: [PATCH] stash: complain about unknown flags

Hello, On Wed, May 20, 2015 at 8:01 PM, Jeff King wrote: > The option parser for git-stash stuffs unknown flags into > the $FLAGS variable, where they can be accessed by the > individual commands. However, most commands do not even look > at these extra flags, leading to

Re: [PATCH 2/1] stash: recognize "--help" for subcommands

On Wed, May 20, 2015 at 8:17 PM, Jeff King wrote: > On Wed, May 20, 2015 at 02:01:32PM -0400, Jeff King wrote: > >> This takes away the immediate pain. We may also want to >> teach "--help" to the option. I guess we cannot do better >> than just having it run "git help stash" in

Re: [PATCHv2 8/8] clone: allow an explicit argument for parallel submodule clones

On Wed, Oct 28, 2015 at 7:21 PM, Stefan Beller wrote: > Just pass it along to "git submodule update", which may pick reasonable > defaults if you don't specify an explicit number. > > Signed-off-by: Stefan Beller > --- > @@ -724,8 +723,20 @@ static int

[PATCH v4] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH] mailinfo: fix passing wrong address to git_mailinfo_config

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

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 01, 2015 at 12:52:57PM -0500, Eric Sunshine wrote: > > diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt > > index e269fb1..93ba35a 100644 > > --- a/Documentation/git-checkout.txt > > +++ b/Documentation/git-checkout.txt > > @@ -107,6 +107,12 @@ OPTIONS > >

[PATCH 1/5] read-cache: add watchman 'WAMA' extension

The extension contains a bitmap, one bit for each entry in the index. If the n-th bit is zero, the n-th entry is considered unchanged, we can ce_mark_uptodate() it without refreshing. If the bit is non-zero and we found out the corresponding file is clean after refresh, we can clear the bit. The

[PATCH 4/5] index-helper: use watchman to avoid refreshing index with lstat()

Watchman is hidden behind index-helper. Before git tries to read the index from shm, it notifies index-helper with SIGHUP and sleep, waiting for index-helper to prepare shm. index-helper then contacts watchman, updates 'WAMA' extension and put it in a separate shm and wakes git up with SIGHUP.

[PATCH 3/5] read-cache: allow index-helper to prepare shm before git reads it

If index-helper puts 'W' before pid in $GIT_DIR/index-helper.pid, then git will sleep for a while, expecting to be waken up by SIGUSR1 when index-helper has done shm preparation, or after the timeout. Signed-off-by: Nguyễn Thái Ngọc Duy --- read-cache.c | 14 -- 1

[PATCH 5/5] update-index: enable/disable watchman support

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/update-index.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/builtin/update-index.c b/builtin/update-index.c index 7431938..86aec21 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c @@ -903,6

[PATCH 2/5] Add watchman support to reduce index refresh cost

The previous patch has the logic to clear bits in 'WAMA' bitmap. This patch has logic to set bits as told by watchman. The missing bit, _using_ these bits, are not here yet. A lot of this code is written by David Turner originally, mostly from [1]. I'm just copying and polishing it a bit. [1]

[PATCH 0/5] Use watchman to reduce index refresh time

This series builds on top of the index-helper series I just sent and uses watchman to keep track of file changes in order to avoid lstat() at refresh time. The series can also be found at [1] When I started this work, watchman did not support Windows yet. It does now, even if still experimental

[PATCH] mailinfo: fix passing wrong address to git_mailinfo_config

git_mailinfo_config() expects "struct mailinfo *". But in setup_mailinfo(), "mi" is already "struct mailinfo *". would make it "struct mailinfo **" and git_mailinfo_config() would damage some other memory when it assigns some value to mi->use_scissors. This is caught by t4150.20.

Re: [PATCH v2] ls-files: Add eol diagnostics

Matthieu Moy writes: > Torsten Bögershausen writes: > >> ca:text-no-eol wt:text-no-eol t/t5100/empty >> ca:binarywt:binaryt/test-binary-2.png >> ca:text-lf wt:text-lf t/t5100/rfc2047-info-0007 >> ca:text-lf

RE: [PATCH 3/6] Facilitate debugging Git executables in tests with gdb

Hi Victor, On Sat, 31 Oct 2015, Victor Leschuk wrote: > > > +if test -n "$TEST_GDB_GIT" > > > +then > > > + exec gdb -args "${GIT_EXEC_PATH}/@@PROG@@" "$@" > > Maybe we could make $TEST_GDB_GIT not just a boolean flag? It would be > > useful > > to contain "gdb" executable name. It would

Re: [PATCH] checkout: add --progress option

On Sat, Oct 31, 2015 at 6:45 PM, Eric Sunshine wrote: > Patches in 'next' are pretty much set in stone, and those in 'master' > definitely are, but 'pu' is volatile, so just send the entire patch > revised, tagged v2 (or v3, etc.), rather than sending a patch to fix >

Re: [PATCH 3/5] wt-status: avoid building bogus branch name with detached HEAD

René Scharfe writes: > If we're on a detached HEAD then wt_shortstatus_print_tracking() takes > the string "HEAD (no branch)", translates it, skips the first eleven > characters and passes the result to branch_get(), which returns a bogus > result and accesses memory out of bounds

Re: [PATCH] Limit the size of the data block passed to SHA1_Update()

atous...@gmail.com writes: > diff --git a/cache.h b/cache.h > index 79066e5..ec84b16 100644 > --- a/cache.h > +++ b/cache.h > @@ -14,7 +14,12 @@ > #ifndef git_SHA_CTX > #define git_SHA_CTX SHA_CTX > #define git_SHA1_InitSHA1_Init > -#define git_SHA1_Update SHA1_Update > +#ifdef

Re: [PATCH v5] checkout: add --progress option

Oh, man... I'm sorry... I didn't notice them. Let me go over them to see what we can do. On Sun, Nov 1, 2015 at 1:13 PM, Eric Sunshine wrote: > I'll assume that you simply overlooked the remainder of my v4 review > comments, so I'll merely provide a reference to them[1]

[PATCH v4 0/9] Reduce index load time

This is the rebased version since last time [1] with s/free_index_shm/release_index_shm/ as suggested by David Turner. It introduces a daemon that can cache index data in memory so that subsequent git processes can avoid reading (and more importantly, verifying) the index from disk. Together with

Re: [PATCH 4/5] wt-status: don't skip a magical number of characters blindly

René Scharfe writes: > Use the variable branch_name, which already has "refs/heads/" removed, > instead of blindly advancing in the ->branch string by 11 bytes. This > is safer and less magical. > > Signed-off-by: Rene Scharfe > --- > wt-status.c | 2 +- > 1 file

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 12:47 PM, Edmundo Carmona Antoranz wrote: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal.

[PATCH v5] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH 3/5] wt-status: avoid building bogus branch name with detached HEAD

Am 01.11.2015 um 18:50 schrieb Junio C Hamano: René Scharfe writes: If we're on a detached HEAD then wt_shortstatus_print_tracking() takes the string "HEAD (no branch)", translates it, skips the first eleven characters and passes the result to branch_get(), which returns a bogus

Re: [PATCH v2] ls-files: Add eol diagnostics

Sebastian Schuberth writes: > However, the commit message says "to check if text files are stored > normalized in the *repository*", yet the output refers to the index / > cache. Is there a (potential) difference between line endings in the > index and repo? There is when

Re: [PATCH v2] ls-files: Add eol diagnostics

Junio C Hamano writes: > i/ and w/ have been used to denote the "i"ndex and "w"orktree > versions for the past 7 years with diff.mnemonicprefix option, > which you may want to match. Indeed. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list:

[PATCH v4 4/9] index-helper: new daemon for caching index and related stuff

Instead of reading the index from disk and worrying about disk corruption, the index is cached in memory (memory bit-flips happen too, but hopefully less often). The result is faster read. Read time is reduced by 70%. The biggest gain is not having to verify the trailing SHA-1, which takes lots

[PATCH v3] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. ---

Re: [PATCH 4/5] wt-status: don't skip a magical number of characters blindly

Junio C Hamano writes: >> diff --git a/wt-status.c b/wt-status.c >> index e206cc9..42ea15e 100644 >> --- a/wt-status.c >> +++ b/wt-status.c >> @@ -1656,7 +1656,7 @@ static void wt_shortstatus_print_tracking(struct >> wt_status *s) >> if (starts_with(branch_name,

Re: [PATCH] Limit the size of the data block passed to SHA1_Update()

Atousa Duprat writes: > Indeed, the declaration needs a const void *; but I need to advance by > a specific number of bytes in each iteration of the loop. Hence the > cast. Ah, of course you are right. Silly me. Thanks. -- To unsubscribe from this list: send the line

Re: [PATCH v5] checkout: add --progress option

On Sun, Nov 1, 2015 at 1:03 PM, Edmundo Carmona Antoranz wrote: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal.

[PATCH v4 6/9] index-helper: add --strict

There's are "holes" in the index-helper approach because the shared memory is not verified again by git. If $USER is compromised, shared memory could be modified. But then they can already modify $GIT_DIR/index. A more realistic risk is some bugs in index-helper produce corrupt shared memory.

[PATCH v4 5/9] trace.c: add GIT_TRACE_INDEX_STATS for index statistics

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git.txt | 1 + cache.h | 1 + read-cache.c | 16 trace.c | 5 - 4 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/git.txt

[PATCH v4 7/9] daemonize(): set a flag before exiting the main process

This allows signal handlers and atexit functions to realize this situation and not clean up. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/gc.c | 2 +- cache.h | 2 +- daemon.c | 2 +- setup.c | 4 +++- 4 files changed, 6 insertions(+), 4 deletions(-) diff

[PATCH v4 9/9] index-helper: add Windows support

Windows supports shared memory, but the semantics is a bit different than POSIX shm. The most noticeable thing is there's no way to get the shared memory's size by the reader, and wrapping fstat to do that would be hell. So the shm size is added near the end, hidden away from shm users (storing it

[PATCH v4 8/9] index-helper: add --detach

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-index-helper.txt | 3 +++ index-helper.c | 10 -- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Documentation/git-index-helper.txt b/Documentation/git-index-helper.txt

[PATCH v4 3/9] read-cache: allow to keep mmap'd memory after reading

Signed-off-by: Nguyễn Thái Ngọc Duy --- cache.h | 3 +++ read-cache.c | 13 - 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index 8791dbc..89e9aaf 100644 --- a/cache.h +++ b/cache.h @@ -311,11 +311,14 @@ struct index_state {

[PATCH v4 1/9] trace.c: add GIT_TRACE_PACK_STATS for pack usage statistics

trace_stats() is intended for GIT_TRACE_*_STATS variable group and GIT_TRACE_PACK_STATS is more like an example how new vars can be added. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git.txt | 3 +++ cache.h | 2 ++ git.c | 1 +

[PATCH v4 2/9] read-cache.c: fix constness of verify_hdr()

Signed-off-by: Nguyễn Thái Ngọc Duy --- read-cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/read-cache.c b/read-cache.c index 84616c8..a76c789 100644 --- a/read-cache.c +++ b/read-cache.c @@ -1345,7 +1345,7 @@ struct ondisk_cache_entry_extended {

Re: [PATCH v3] checkout: add --progress option

On Sun, Nov 1, 2015 at 11:22 AM, Edmundo Carmona Antoranz wrote: > + /* > +* Final processing of show_progress > +* - User selected --progress: show progress > +* - user selected --no-progress: skip progress > +* - User didn't specify: >

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 11:52 AM, Eric Sunshine wrote: >> + if (opts.quiet) { >> + opts.show_progress = 0; >> + } else { >> + opts.show_progress = isatty(2); >> + } > > Style: drop

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 2:19 PM, Jeff King wrote: > On Sun, Nov 01, 2015 at 12:52:57PM -0500, Eric Sunshine wrote: >> > +--progress:: >> > + Progress status is reported on the standard error stream >> > + by default when it is attached to a terminal, unless -q >> > +

Re: [PATCH v2] http.c: use CURLOPT_RANGE for range requests

On Fri, 30 Oct 2015, Jeff King wrote: The goal makes sense. Why weren't we using CURLOPT_RANGE before? Did it not exist (or otherwise have limitations) in 2005, and if so, when did it become usable? Do we need to protect this with an #ifdef for the curl version? CURLOPT_RANGE existed already

git.git as of tonight

I've merged a handful of topics to 'next', and hoping that many of them can be merged to 'master' before I'll go offline for a few weeks starting on the week #7 of the cycle (starting Nov 9th). As I hate sending out the whole text back to back (the last one was issued on the last Friday), here is

RE: [PATCH v4] Add git-grep threads param

Hello all, do we have any objections on this patch? -- Best Regards, Victor From: Victor Leschuk [vlesc...@gmail.com] Sent: Tuesday, October 27, 2015 14:22 To: git@vger.kernel.org Cc: Victor Leschuk Subject: [PATCH v4] Add git-grep threads param Make

Re: [PATCH v2] http.c: use CURLOPT_RANGE for range requests

On Mon, Nov 02, 2015 at 12:00:42AM +0100, Daniel Stenberg wrote: > On Fri, 30 Oct 2015, Jeff King wrote: > > >The goal makes sense. Why weren't we using CURLOPT_RANGE before? Did it > >not exist (or otherwise have limitations) in 2005, and if so, when did it > >become usable? Do we need to

Re: [PATCH v2] ls-files: Add eol diagnostics

On Sun, Nov 1, 2015 at 7:40 PM, Matthieu Moy wrote: >> Any I find it a bit confusing to refer to the index where, as e.g. for >> a freshly cloned repo the index should be empty, > > No it is not. The index is a complete snapshot of your working tree. > When you have

[PATCH v8] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

configure: -lpthread doesn't belong in CFLAGS

Hi, some linkers, namely the one on IRIX are rather strict concerning the order or arguments for symbol resolution, i.e. no libraries listed before objects or other libraries on the command line are considered for symbol resolution. That means that -lpthread can't work if it's put in CFLAGS,

Re: [PATCH] Allow hideRefs to match refs outside the namespace

Lukas Fleischer writes: > Now, this cannot be intended behavior and I do not think this is > something we want to retain when improving that feature. Yup, that makes me suspect that namespace support with hiderefs was done without giving much thought even stronger than

[PATCH v7] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH v6] checkout: add --progress option

On Sun, Nov 1, 2015 at 3:06 PM, Eric Sunshine wrote: >> +--[no-]progress:: >> + Progress status is reported on the standard error stream >> + by default when it is attached to a terminal, unless --quiet >> + is specified. This flag enables progress

[PATCH 3/4] Add support for matching full refs in hideRefs

In addition to matching stripped refs, one can now add hideRefs patterns that the full (unstripped) ref is matched against. To distinguish between stripped and full matches, those new patterns must be prefixed with a circumflex (^). This commit also removes support for the undocumented and

[PATCH 1/4] Document the semantics of hideRefs with namespaces

Right now, there is no clear definition of how transfer.hideRefs should behave when a namespace is set. Explain that hideRefs prefixes match stripped names in that case. This is how hideRefs patterns are currently handled in receive-pack. Signed-off-by: Lukas Fleischer ---

[PATCH 4/4] t5509: add basic tests for hideRefs

Test whether regular and full hideRefs patterns work as expected when namespaces are used. Signed-off-by: Lukas Fleischer --- t/t5509-fetch-push-namespaces.sh | 29 + 1 file changed, 29 insertions(+) diff --git a/t/t5509-fetch-push-namespaces.sh

[PATCH 2/4] upload-pack: strip refs before calling ref_is_hidden()

Make hideRefs handling in upload-pack consistent with the behavior described in the documentation by stripping refs before comparing them with prefixes in hideRefs. Signed-off-by: Lukas Fleischer --- upload-pack.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 2:35 PM, Edmundo Carmona Antoranz wrote: > On Sun, Nov 1, 2015 at 1:29 PM, Eric Sunshine wrote: > +--progress:: > + Progress status is reported on the standard error stream > + by default when it is

Re: [PATCH 4/4] t5509: add basic tests for hideRefs

On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote: > Test whether regular and full hideRefs patterns work as expected when > namespaces are used. > > Signed-off-by: Lukas Fleischer > --- > diff --git a/t/t5509-fetch-push-namespaces.sh >

Re: [PATCH v7] checkout: add --progress option

On Sun, Nov 1, 2015 at 4:12 PM, Edmundo Carmona Antoranz wrote: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal.

[PATCH 0/4] Improve hideRefs when used with namespaces

This is a first set of patches improving documentation and behavior of the transfer.hideRefs feature as discussed in [1]. In particular, hideRefs is changed to generally match stripped refs by default and match full refs when prefixed with "^". The documentation is updated accordingly. Basic tests

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 1:29 PM, Eric Sunshine wrote: >>> > +--progress:: >>> > + Progress status is reported on the standard error stream >>> > + by default when it is attached to a terminal, unless -q >>> > + is specified. This flag forces progress

[PATCH v6] checkout: add --progress option

Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal. This option allows progress to be forced even if not using a terminal. Also, progress can be skipped if using option --no-progress. Signed-off-by: Edmundo Carmona

Re: [PATCH v4] checkout: add --progress option

On Sun, Nov 1, 2015 at 2:15 PM, Eric Sunshine wrote: > > Progress status is reported on the standard error stream by > default when it is attached to a terminal, unless `--quiet` is > specified. This flag enables progress reporting even if not > attached

Re: [PATCH v6] checkout: add --progress option

On Sun, Nov 1, 2015 at 3:27 PM, Edmundo Carmona Antoranz wrote: > Under normal circumstances, and like other git commands, > git checkout will write progress info to stderr if > attached to a terminal. This option allows progress > to be forced even if not using a terminal.

Re: [PATCH v7] checkout: add --progress option

On Sun, Nov 1, 2015 at 3:15 PM, Eric Sunshine wrote: >> +--[no-]progress:: >> + Progress status is reported on the standard error stream >> + by default when it is attached to a terminal, unless `--quiet` >> + is specified. This flag enables progress

Re: [PATCH 3/4] Add support for matching full refs in hideRefs

On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote: > In addition to matching stripped refs, one can now add hideRefs patterns > that the full (unstripped) ref is matched against. To distinguish > between stripped and full matches, those new patterns must be prefixed > with

Re: [PATCH 4/4] t5509: add basic tests for hideRefs

On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote: > On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote: > > Test whether regular and full hideRefs patterns work as expected when > > namespaces are used. > > > > Signed-off-by: Lukas Fleischer > > ---

Re: [PATCH 4/4] t5509: add basic tests for hideRefs

On Mon, Nov 2, 2015 at 1:25 AM, Lukas Fleischer wrote: > On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote: >> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote: >> > + cd pushee && >> > + test_config transfer.hideRefs refs/tags && >> >

Cloning of submodule with --depth should follow the branch option

Hi, I have an issue with git 2.4.3 when trying to limit the amount of data fetched when cloning submodules. The --depth option is useful, but when .gitmodules specifies a non-default branch, the submodule repository clone invocation (which is a single-branch clone due to --depth) fetches master

Git potential bug with fork-point

Hello, my name is Jim Stenberg and I'm a developer, albeit not that experienced with Git. Please note that I'm not a native English speaker. If there is anything unclear or lacking, feel free to ask me on this email address. My problem: "Git merge-base --fork-point" acts unexpected when I refer

Re: [PATCH v2] http.c: use CURLOPT_RANGE for range requests

On Sun, 1 Nov 2015, Jeff King wrote: While I have your attention, Daniel, am I correct in assuming that performing a second unrelated request with the same CURL object will need an explicit: curl_easy_setopt(curl, CURLOPT_RANGE, NULL); to avoid using the range twice? Correct. As the

When a file was locked by some program, git will work stupidly

To be specific In my Unity project, there is a native plugin, and plugin's extension is .dll, and this plugin is under git version control, when Unity is running, the plugin file will be locked. If i merge another branch, which contains modification of the plugin, git will report error, looks

Re: [PATCH 3/4] Add support for matching full refs in hideRefs

On Sun, 01 Nov 2015 at 21:42:37, Eric Sunshine wrote: > On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote: > > In addition to matching stripped refs, one can now add hideRefs patterns > > that the full (unstripped) ref is matched against. To distinguish > > between