Re: [RFC] - url-safe base64 commit-id's

On Mon, Feb 27, 2017 at 6:27 PM, G. Sylvie Davies wrote: > Is there any appetite for base64'd commit-id's, using the url-safe > variant (e.g. RFC 4648 [1] with padding removed)? > > And so this: > 712bad335dfa9c410a83f9873614a19726acb3a8 > > Becomes this: >

Git has been accepted as a GSoC 2017 mentor organization!

Hi everyone, I am happy to let you know that Git has been accepted as a GSoC mentor organization again this year. https://summerofcode.withgoogle.com/organizations/ I invited Dscho and Stefan as potential mentors for Git. I also invited Junio to give him access to students proposals and the

Typesafer git hash patch

So because of the whole SHA1 discussion, I started looking at what it would involve to turn unsigned char *sha1 style arguments (and various structure members) in the git source into typedef struct { ... } hash_t; hash_t *hash; The answer is that it's pretty painful - more so than I

Re: [PATCH 4/4] ident: do not ignore empty config name/email

On Mon, Feb 27, 2017 at 9:42 PM, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > >> On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: >>> On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: >>> >>> > > So I dunno. I could really go

[PATCH] http: attempt updating base URL only if no error

http.c supports HTTP redirects of the form http://foo/info/refs?service=git-upload-pack -> http://anything -> http://bar/info/refs?service=git-upload-pack (that is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the

What's cooking in git.git (Feb 2017, #09; Mon, 27)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The first batch post 2.12 is

[RFC] - url-safe base64 commit-id's

Is there any appetite for base64'd commit-id's, using the url-safe variant (e.g. RFC 4648 [1] with padding removed)? And so this: 712bad335dfa9c410a83f9873614a19726acb3a8 Becomes this: cSutM136nEEKg_mHNhShlyass6g Under the hood things cannot change (e.g., ".git/objects/71/") because file

[PATCH 2/2] wrapper.c: remove unused gitmkstemps() function

The last call to the mkstemps() function was removed in commit 659488326 ("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order to support platforms without mkstemps(), this functionality was provided, along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps()

[PATCH 1/2] wrapper.c: remove unused git_mkstemp() function

The last caller of git_mkstemp() was removed in commit 6fec0a89 ("verify_signed_buffer: use tempfile object", 16-06-2016). Since the introduction of the 'tempfile' APIs, along with git_mkstemp_mode, it is unlikely that new callers will materialize. Remove the dead code. Signed-off-by: Ramsay

[PATCH 0/2] remove unused 'mkstemp(s)' code

I promised the first of these patches on 18th June last year! ;-) (In response to Jeff's 'jk/gpg-interface-cleanup' branch). Ramsay Jones (2): wrapper.c: remove unused git_mkstemp() function wrapper.c: remove unused gitmkstemps() function Makefile | 5 - cache.h |

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote: > A flag to affect the behaviour (as opposed to as a secondary > return value, like Peff's patch does) can be made to work. Perhaps > a flag that says "keep the input as is if the result is not a local > branch name" would pass an

Re: [PATCH] strbuf: add strbuf_add_real_path()

Am 27.02.2017 um 19:22 schrieb Brandon Williams: On 02/25, René Scharfe wrote: +void strbuf_add_real_path(struct strbuf *sb, const char *path) +{ + if (sb->len) { + struct strbuf resolved = STRBUF_INIT; + strbuf_realpath(, path, 1); +

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 2:28 PM, Junio C Hamano wrote: > Jeff King writes: > >> I guess something like the patch below works, but I wonder if there is a >> less-horrible way to accomplish the same thing. > > I suspect that a less-horrible would be a lot more

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 03:05:37PM -0800, Jacob Keller wrote: > > Perhaps with s/not_in_refs_heads/not_a_branch_name/ (or swapping > > polarity, "is_a_branch_name"), the resulting code may not be too > > hard to read? > > What about changing interpret-branch-name gains a flag to return a > fully

Re: [PATCH 0/6] Use time_t

Johannes Schindelin writes: > One notable fallout of this patch series is that on 64-bit Linux (and > other platforms where `unsigned long` is 64-bit), we now limit the range > of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be > done as `time_t`

Re: [BUG] branch renamed to 'HEAD'

On Mon, Feb 27, 2017 at 02:28:09PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I guess something like the patch below works, but I wonder if there is a > > less-horrible way to accomplish the same thing. > > I suspect that a less-horrible would be a lot more

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

Torsten, you've been quite active in fixing various glitches around the EOL conversion in the latter half of last year. Have any thoughts to share on this topic? Thanks. Mike Crowe writes: > On Monday 20 February 2017 at 13:25:01 -0800, Junio C Hamano wrote: >> This almost

Re: [BUG] branch renamed to 'HEAD'

Jacob Keller writes: > What about changing interpret-branch-name gains a flag to return a > fully qualified ref rather than returning just the name? That seems > like it would be more reasonable behavior. There are two kinds of callers to i-b-n. The ones that want a

[PATCH 6/6] Use time_t where appropriate

Git's source code assumes that unsigned long is at least as precise as time_t. That causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use time_t instead. Note that in some systems (most notably 32-bit Linux),

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > if test -z "$patch_mode" > then > - git reset --hard ${GIT_QUIET:+-q} > + if test $# != 0 > + then > + git reset ${GIT_QUIET:+-q} -- "$@" > + git checkout

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

On Mon, Feb 27, 2017 at 01:44:26PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > ... I suspect that calling interpret_empty_at() from > > that function is fundamentally flawed. The "@" end user types never > > means refs/heads/HEAD, and HEAD@{either reflog or

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > On 02/27, Junio C Hamano wrote: >> Thomas Gummerer writes: >> >> > + test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null >> > || exit 1 >> >> This silent "exit 1" made me scratch my head, but

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

Am 27.02.2017 um 23:27 schrieb Jakub Narębski: W dniu 25.02.2017 o 20:27, René Scharfe pisze: Both standard_header_field() and excluded_header_field() check if there's a space after the buffer that's handed to them. We already check in the caller if that space is present. Don't bother calling

Re: [PATCH 1/6] t0006 & t5000: prepare for 64-bit time_t

Johannes Schindelin writes: > This quick fix, however, tests for *long* to be 64-bit or not. What we > need, though, is a test that says whether *whatever data type we use for > timestamps* is 64-bit or not. > > The same quick fix was used to handle the similar

Re: [PATCH 2/6] Specify explicitly where we parse timestamps

Junio C Hamano writes: >> -unsigned long number = strtoul(date, , 10); >> +time_t number = parse_timestamp(date, , 10); > > This hunk does not belong to this step. Everybody else in this step obviously I meant "the left half of this hunk" ;-) > still receives

Re: [PATCH 2/6] Specify explicitly where we parse timestamps

Johannes Schindelin writes: > Currently, Git's source code represents all timestamps as `unsigned > long`. In preparation for using `time_t` instead, let's introduce a > symbol `parse_timestamp` (currently being defined to `strtoul`) where > appropriate, so that we

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > if test -z "$patch_mode" > then > - git reset --hard ${GIT_QUIET:+-q} > + if test $# != 0 > + then > + git reset ${GIT_QUIET:+-q} -- "$@" > + git checkout

Re: Reference for quote "creating branch is not the issue, merging is", in context of Subversion/Git

W dniu 26.02.2017 o 16:19, Igor Djordjevic pisze: > Hello Michael, > > On 26/02/2017 12:40, Michael Hüttermann wrote: >> Linus Torvalds made a statement regarding merging/branching and stated >> (as far as I know) that "creating branch is not the issue, merge is", in >> context of Subversion/Git.

Re: [PATCH 05/10] submodule--helper: add is_active command

On 02/23, Stefan Beller wrote: > On Thu, Feb 23, 2017 at 3:47 PM, Brandon Williams wrote: > > There are a lot of places where an explicit check for > > submodule."".url is done to see if a submodule exists. In order > > to more easily facilitate the use of the submodule.active

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe writes: > Am 27.02.2017 um 21:04 schrieb Junio C Hamano: >> René Scharfe writes: >> diff --git a/apply.c b/apply.c index cbf7cc7f2..9219d2737 100644 --- a/apply.c +++ b/apply.c @@ -3652,7 +3652,6 @@ static int

Re: [BUG] branch renamed to 'HEAD'

Jeff King writes: > I guess something like the patch below works, but I wonder if there is a > less-horrible way to accomplish the same thing. I suspect that a less-horrible would be a lot more intrusive. It would go like "interpret-branch-name only gives local branch name, and

Re: [PATCH 2/2] commit: don't check for space twice when looking for header

W dniu 25.02.2017 o 20:27, René Scharfe pisze: > Both standard_header_field() and excluded_header_field() check if > there's a space after the buffer that's handed to them. We already > check in the caller if that space is present. Don't bother calling > the functions if it's missing, as they

[PATCH 1/6] t0006 & t5000: prepare for 64-bit time_t

Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers.

Re: [PATCH v2] convert: add "status=delayed" to filter process protocol

W dniu 27.02.2017 o 11:32, Lars Schneider pisze: > >> On 27 Feb 2017, at 10:58, Jeff King wrote: >> >> On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote: >> >>> +If the request cannot be fulfilled within a reasonable amount of time >>> +then the filter can respond

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 27.02.2017 um 21:04 schrieb Junio C Hamano: René Scharfe writes: diff --git a/apply.c b/apply.c index cbf7cc7f2..9219d2737 100644 --- a/apply.c +++ b/apply.c @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, if (!old_name)

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

Am 27.02.2017 um 21:10 schrieb Junio C Hamano: René Scharfe writes: Would it make sense to mirror the previously existing condition and check for is_new instead? I.e.: if ((!patch->is_delete && !patch->new_name) ||

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > The "other" stuff could sometimes be useful, I guess. It's not _always_ > wrong to do: > > git branch -f @{upstream} foo > > It depends on what your @{upstream} resolves to. Switching to just using > interpret_nth_prior_checkout() would break the case when it

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

On 02/27, Junio C Hamano wrote: > Thomas Gummerer writes: > > > + test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null > > || exit 1 > > This silent "exit 1" made me scratch my head, but --error-unmatch > would have already given an error message,

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

On 02/27, Junio C Hamano wrote: > Thomas Gummerer writes: > > > if test -z "$patch_mode" > > then > > - git reset --hard ${GIT_QUIET:+-q} > > + if test $# != 0 > > + then > > + git reset ${GIT_QUIET:+-q} -- "$@" > > +

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Junio C Hamano writes: > ... I suspect that calling interpret_empty_at() from > that function is fundamentally flawed. The "@" end user types never > means refs/heads/HEAD, and HEAD@{either reflog or -1} would not mean > anything that should be taken as a branch_name,

[PATCH 2/6] Specify explicitly where we parse timestamps

Currently, Git's source code represents all timestamps as `unsigned long`. In preparation for using `time_t` instead, let's introduce a symbol `parse_timestamp` (currently being defined to `strtoul`) where appropriate, so that we can later easily switch to use `strtoull()` instead. Signed-off-by:

[PATCH 0/6] Use time_t

Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can do much better than that, as `time_t` exists, and at

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

On Mon, Feb 27, 2017 at 01:19:29PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I suspect there are a lot of other places that are less clear cut. E.g., > > I think just: > > > > git branch foo bar > > > > will put "foo" through the same interpretation. So you could

Re: [PATCH v7 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

Thomas Gummerer writes: > + test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null > || exit 1 This silent "exit 1" made me scratch my head, but --error-unmatch would have already given an error message, like error: pathspec 'no such' did not

[PATCH 5/6] ref-filter: avoid using `unsigned long` for catch-all data type

In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because it may be 32-bit even when `time_t` is 64-bit),

[PATCH 3/6] Introduce a new "printf format" for timestamps

Currently, Git's source code treats all timestamps as if they were unsigned longs. Therefore, it is okay to write "%lu" when printing them. There is a substantial problem with that, though: at least on Windows, time_t is *larger* than unsigned long, and hence we will want to switch to using

[PATCH 4/6] Prepare for timestamps to use 64-bit signed types

Currently, Git's source code uses the unsigned long type to represent timestamps. However, this type is limited to 32-bit e.g. on 64-bit Windows. Hence it is a suboptimal type for this use case. In any case, we need to use the time_t type to represent timestamps since we often send those values

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > I suspect there are a lot of other places that are less clear cut. E.g., > I think just: > > git branch foo bar > > will put "foo" through the same interpretation. So you could do: > > git branch -f @{-1} bar > > Is that insane? Maybe. But it does work now.

Re: [PATCH 4/4] ident: do not ignore empty config name/email

Dennis Kaarsemaker writes: > On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: >> On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: >> >> > > So I dunno. I could really go either way on it. Feel free to drop it, or >> > > even move it into a separate

Re: show all merge conflicts

On Mon, Feb 27, 2017 at 11:45:31AM -0800, Junio C Hamano wrote: > Michael J Gruber writes: > > > If you're curious, I kept rebasing Thomas' remerge-diff (on top of our > > next) so far. You can find it at > > > > https://github.com/mjg/git/tree/remerge-diff > > ;-).

Re: git-clone --config order & fetching extra refs during initial clone

On Mon, Feb 27, 2017 at 11:16:35AM -0800, Junio C Hamano wrote: > >> TL;DR: git-clone ignores any fetch specs passed via --config. > > > > I agree that this is a bug. There's some previous discussion and an RFC > > patch from lat March (author cc'd): > > > > > >

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

On Mon, Feb 27, 2017 at 11:33:23AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > This comes originally from Junio's 84679d470. I cannot see how naming > > the new branch HEAD would make any difference to the test, but perhaps I > > am missing something. > > Nah, I think

Re: Transition plan for git to move to a new hash function

Ian Jackson wrote: A few questions and one or two suggestions... > TEXTUAL SYNTAX > == > > We also reserve the following syntax for private experiments: > E[A-Z]+[0-9a-z]+ > We declare that public releases of git will never accept such > object

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

René Scharfe writes: > Would it make sense to mirror the previously existing condition and > check for is_new instead? I.e.: > > if ((!patch->is_delete && !patch->new_name) || > (!patch->is_new&& !patch->old_name)) { > Yes,

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe writes: >> diff --git a/apply.c b/apply.c >> index cbf7cc7f2..9219d2737 100644 >> --- a/apply.c >> +++ b/apply.c >> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, >> if (!old_name) >> return 0; >> >> -

RE: Unconventional roles of git

> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of ankostis > Sent: February 26, 2017 6:52 AM > To: Git Mailing List > Cc: Jason Cooper > Subject: Unconventional roles of git > > On 26

Re: show all merge conflicts

Michael J Gruber writes: > If you're curious, I kept rebasing Thomas' remerge-diff (on top of our > next) so far. You can find it at > > https://github.com/mjg/git/tree/remerge-diff ;-). Yes, this was a good one. > if you're interested. I don't know what problems

Re: [PATCH] interpret_branch_name(): handle auto-namelen for @{-1}

Jeff King writes: > On Mon, Feb 27, 2017 at 04:25:40AM -0500, Jeff King wrote: > >> However, before we do that auto-namelen magic, we call >> interpret_nth_prior_checkout(), which gets fed the bogus >> "0". This was broken by 8cd4249c4 (interpret_branch_name: >> always respect

Re: [PATCH 1/2] commit: be more precise when searching for headers

René Scharfe writes: > Search for a space character only within the current line in > read_commit_extra_header_lines() instead of searching in the whole > buffer (and possibly beyond, if it's not NUL-terminated) and then > discarding any results after the end of the current line. >

Re: [PATCH] cvs tests: When root, skip tests that call "cvs commit"

Thanks, makes sense.

Re: 'git submodules update' ignores credential.helper config of the parent repository

On Mon, Feb 27, 2017 at 5:33 AM, Dmitry Neverov wrote:> > git -c credential.helper= submodule update > > Is it by design? A similar question came up w.r.t. submodule configuration recently. It is about url..insteadOf[1] that is set in the super project and is expected

Re: [PATCH] t6300: avoid creating refs/heads/HEAD

Jeff King writes: > This comes originally from Junio's 84679d470. I cannot see how naming > the new branch HEAD would make any difference to the test, but perhaps I > am missing something. Nah, I think it was just a random string that came to mind and the topic being "ah we

Re: git-clone --config order & fetching extra refs during initial clone

Jeff King writes: > [Re-sending, as I used an old address for Gábor on the original] > > On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote: > >> TL;DR: git-clone ignores any fetch specs passed via --config. > > I agree that this is a bug. There's some previous

Re: [PATCH] http: add an "auto" mode for http.emptyauth

Jeff King writes: > The auto mode may incur an extra round-trip over setting > http.emptyauth=true, because part of the emptyauth hack is > to feed this blank password to curl even before we've made a > single request. IOW, people who care about an extra round-trip have this

[PATCH v4 21/22] Documentation/config: add splitIndex.sharedIndexExpire

Signed-off-by: Christian Couder --- Documentation/config.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 8e745bda52..0e9982c5e3 100644 --- a/Documentation/config.txt +++

[PATCH v4 15/22] read-cache: touch shared index files when used

When a split-index file is created, let's update the mtime of the shared index file that the split-index file is referencing. In a following commit we will make shared index file expire depending on their mtime, so updating the mtime makes sure that the shared index file will not be deleted soon.

[PATCH v4 17/22] read-cache: unlink old sharedindex files

Everytime split index is turned on, it creates a "sharedindex." file in the git directory. This change makes sure that shared index files that haven't been used for a long time are removed when a new shared index file is created. The new "splitIndex.sharedIndexExpire" config variable is

Re: [PATCH 0/5] recursing submodules with relative pathspec (grep and ls-files)

On 02/24, Brandon Williams wrote: > It was discovered that when using the --recurse-submodules flag with `git > grep` > and `git ls-files` and specifying a relative path when not at the root causes > the child processes spawned to error out with an error like: > > fatal: ..: '..' is outside

Re: [PATCH] gitweb tests: Skip tests when we don't have Time::HiRes

On Mon, Feb 27, 2017 at 6:48 PM, Jakub Narębski wrote: > W dniu 27.02.2017 o 13:37, Ævar Arnfjörð Bjarmason pisze: >> Change the gitweb tests to skip when we can't load the Time::HiRes >> module. > > Could you tell us in the commit message why this module is needed? > Is it

[PATCH v4 13/22] Documentation/config: add splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- Documentation/config.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 61a863adeb..8e745bda52 100644 --- a/Documentation/config.txt +++

Re: [PATCH v5 1/1] config: add conditional include

Jeff King writes: > I don't think driving that with a two-entry table is the right thing > here. We are as likely to add another "foobar:" entry as we are to add > another modifier "/i" modifier to "gitdir:", and it is unclear whether > that modifier would be mutually exclusive

Re: [PATCH 10/10] submodule--helper clone: check for configured submodules using helper

On 02/23, Stefan Beller wrote: > On Thu, Feb 23, 2017 at 3:47 PM, Brandon Williams wrote: > > > @@ -795,14 +794,11 @@ static int prepare_to_clone_next_submodule(const > > struct cache_entry *ce, > > } > > > > /* > > -* Looking up the url in

[PATCH v4 18/22] t1700: test shared index file expiration

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 44 1 file changed, 44 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index 21f43903f8..480d3a8dc3 100755 --- a/t/t1700-split-index.sh

Re: [PATCH] strbuf: add strbuf_add_real_path()

On 02/25, René Scharfe wrote: > Add a function for appending the canonized absolute pathname of a given > path to a strbuf. It keeps the existing contents intact, as expected of > a function of the strbuf_add() family, while avoiding copying the result > if the given strbuf is empty. It's more

Re: [PATCH 1/5] grep: illustrate bug when recursing with relative pathspec

On 02/26, Duy Nguyen wrote: > On Sat, Feb 25, 2017 at 6:50 AM, Brandon Williams wrote: > > When using the --recurse-submodules flag with a relative pathspec which > > includes "..", an error is produced inside the child process spawned for > > a submodule. When creating the

[PATCH v4 20/22] read-cache: use freshen_shared_index() in read_index_from()

This way a share index file will not be garbage collected if we still read from an index it is based from. As we need to read the current index before creating a new one, the tests have to be adjusted, so that we don't expect an old shared index file to be deleted right away when we create a new

[PATCH v4 16/22] config: add git_config_get_expiry() from gc.c

This function will be used in a following commit to get the expiration time of the shared index files from the config, and it is generic enough to be put in "config.c". Signed-off-by: Christian Couder --- builtin/gc.c | 15 ++- cache.h | 3 +++

[PATCH v4 22/22] Documentation/git-update-index: explain splitIndex.*

Signed-off-by: Christian Couder --- Documentation/config.txt | 2 +- Documentation/git-update-index.txt | 37 + 2 files changed, 30 insertions(+), 9 deletions(-) diff --git a/Documentation/config.txt

[PATCH v4 19/22] read-cache: refactor read_index_from()

It looks better and is simpler to review when we don't compute the same things many times in the function. It will also help make the following commit simpler. Signed-off-by: Christian Couder --- read-cache.c | 14 -- 1 file changed, 8 insertions(+), 6

[PATCH v4 14/22] sha1_file: make check_and_freshen_file() non static

This function will be used in a commit soon, so let's make it available globally. Signed-off-by: Christian Couder --- cache.h | 3 +++ sha1_file.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index 955e80913e..6b25b50aab

[PATCH v4 12/22] t1700: add tests for splitIndex.maxPercentChange

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 72 ++ 1 file changed, 72 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index df19b812fd..21f43903f8 100755 ---

[PATCH v4 11/22] read-cache: regenerate shared index if necessary

When writing a new split-index and there is a big number of cache entries in the split-index compared to the shared index, it is a good idea to regenerate the shared index. By default when the ratio reaches 20%, we will push back all the entries from the split-index into a new shared index file

[PATCH v4 00/22] Add configuration options for split-index

Goal We want to make it possible to use the split-index feature automatically by just setting a new "core.splitIndex" configuration variable to true. This can be valuable as split-index can help significantly speed up `git rebase` especially along with the work to libify `git apply` that

[PATCH v4 02/22] t1700: change here document style

This improves test indentation by getting rid of the outdated here document style. Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 170 - 1 file changed, 85 insertions(+), 85 deletions(-) diff --git

[PATCH v4 10/22] config: add git_config_get_max_percent_split_change()

This new function will be used in a following commit to get the value of the "splitIndex.maxPercentChange" config variable. Signed-off-by: Christian Couder --- cache.h | 1 + config.c | 15 +++ 2 files changed, 16 insertions(+) diff --git a/cache.h

[PATCH v4 06/22] update-index: warn in case of split-index incoherency

When users are using `git update-index --(no-)split-index`, they may expect the split-index feature to be used or not according to the option they just used, but this might not be the case if the new "core.splitIndex" config variable has been set. In this case let's warn about what will happen and

[PATCH v4 05/22] read-cache: add and then use tweak_split_index()

This will make us use the split-index feature or not depending on the value of the "core.splitIndex" config variable. Signed-off-by: Christian Couder --- read-cache.c | 17 + 1 file changed, 17 insertions(+) diff --git a/read-cache.c b/read-cache.c

[PATCH v4 08/22] Documentation/config: add information for core.splitIndex

Signed-off-by: Christian Couder --- Documentation/config.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 015346c417..61a863adeb 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@

[PATCH v4 07/22] t1700: add tests for core.splitIndex

Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 37 + 1 file changed, 37 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index cb68b8dc1e..1659986d8d 100755 --- a/t/t1700-split-index.sh +++

[PATCH v4 09/22] Documentation/git-update-index: talk about core.splitIndex config var

Signed-off-by: Christian Couder --- Documentation/git-update-index.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93162..e091b2a409 100644 ---

[PATCH v4 04/22] split-index: add {add,remove}_split_index() functions

Also use the functions in cmd_update_index() in builtin/update-index.c. These functions will be used in a following commit to tweak our use of the split-index feature depending on the setting of a configuration variable. Signed-off-by: Christian Couder ---

[PATCH v4 01/22] config: mark an error message up for translation

Signed-off-by: Christian Couder --- config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.c b/config.c index c6b874a7bf..2ac1aa19b0 100644 --- a/config.c +++ b/config.c @@ -1728,8 +1728,8 @@ int git_config_get_untracked_cache(void)

[PATCH v4 03/22] config: add git_config_get_split_index()

This new function will be used in a following commit to know if we want to use the split index feature or not. Signed-off-by: Christian Couder --- cache.h | 1 + config.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/cache.h b/cache.h index

Re: [PATCH] gitweb tests: Skip tests when we don't have Time::HiRes

W dniu 27.02.2017 o 13:37, Ævar Arnfjörð Bjarmason pisze: > Change the gitweb tests to skip when we can't load the Time::HiRes > module. Could you tell us in the commit message why this module is needed? Is it because gitweb loads it unconditionally, or does that at least in the default

Re: [ANNOUNCE] Git v2.12.0

On Fri, Feb 24, 2017 at 8:28 PM, Junio C Hamano wrote: > The latest feature release Git v2.12.0 is now available at the > usual places. It is comprised of 517 non-merge commits since > v2.11.0, contributed by 80 people, 24 of which are new faces. Yay, some explanations /

Re: Why BLAKE2?

Markus Trippelsdorf writes ("Re: Why BLAKE2?"): > On 2017.02.27 at 13:00 +, Ian Jackson wrote: > > For brevity I will write `SHA' for hashing with SHA-1, using current > > unqualified object names, and `BLAKE' for hasing with BLAKE2b, using > > H object names. > > Why do you choose BLAKE2?

Re: Why BLAKE2?

On 2017.02.27 at 13:00 +, Ian Jackson wrote: > > For brevity I will write `SHA' for hashing with SHA-1, using current > unqualified object names, and `BLAKE' for hasing with BLAKE2b, using > H object names. Why do you choose BLAKE2? SHA-2 is generally considered still fine and would be the

Re: [PATCH 4/4] ident: do not ignore empty config name/email

On Thu, 2017-02-23 at 23:18 -0500, Jeff King wrote: > On Thu, Feb 23, 2017 at 08:11:11PM -0800, Junio C Hamano wrote: > > > > So I dunno. I could really go either way on it. Feel free to drop it, or > > > even move it into a separate topic to be cooked longer. > > > > If it were 5 years ago, it

Bug: "git worktree add" Unable to checkout a branch with no local ref

git version 2.10.2.windows.1: If a remote branch has never been checked out locally (its ref only exists in remotes// directory), "git worktree add" command is unable to check it out by its normal short name (not prefixed by remotes/), while "git checkout" command has been able to handle such

Re: show all merge conflicts

G. Sylvie Davies venit, vidit, dixit 29.01.2017 07:45: > On Sat, Jan 28, 2017 at 6:28 AM, Jeff King wrote: >> On Fri, Jan 27, 2017 at 09:42:41PM -0800, G. Sylvie Davies wrote: >> >>> Aside from the usual "git log -cc", I think this should work (replace >>> HEAD with whichever

  1   2   >