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:
> cSutM136nEEKg_mHNhShlyass6g
>
>
> Under
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
op
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
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 either way on it. Feel free to drop it, or
>>>
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 intermedia
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 rathe
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 system
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()
funct
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 | 3
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 Jone
On Mon, Feb 27, 2017 at 04:33:36PM -0800, Junio C Hamano wrote:
> A flag to affect the behaviour (as opposed to &flag 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
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(&resolved, path, 1);
+ strb
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 intrusive. It
> would go like "interp
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
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` can be signed (and indeed is
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 intrusive. It
> would go
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 makes me suspect tha
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 local
branch name because th
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), ti
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 ${GIT_QUIET:+-q} HEAD -- $(g
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 -1} would not mean
>
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 --error-unmatch
>> would have already given an error m
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
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 problem where Git's
> source code u
Junio C Hamano writes:
>> -unsigned long number = strtoul(date, &end, 10);
>> +time_t number = parse_timestamp(date, &end, 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 parse_timestamp()'
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 can later easily switch to use
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 ${GIT_QUIET:+-q} HEAD -- $(g
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.
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 config option
> > t
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 check_preimage(struct apply_state *state,
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 when it does not
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 are
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.
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 with a "delayed" st
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)
return 0;
-
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) ||
(!patch->is_new&& !pa
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 resolves to
> a
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, like
>
> error: paths
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} -- "$@"
> > + git c
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, either.
The latter shou
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:
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
l
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 do:
> >
> > git
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 match any file(s) known to
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),
th
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 time_t
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 to
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.
No, it _is_ ve
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 topic to be cooked longer.
>>
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
>
> ;-).
> Yes, this was a good one.
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):
> >
> >
> > http://public-inbox.org/git/1457
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 it was just a r
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 names.
Instead of this I would sugge
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, probably.
> or
>
>
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;
>>
>> -assert(patch->is_new <= 0);
>
> 5
> -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 February 2017 at 02:13, Jason Cooper 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
;-).
Yes, this was a good one.
> if you're interested. I don't know what problems were found back then,
> or w
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 "namelen" parameter
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.
>
> Signed-off-b
Thanks, makes sense.
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 to work in the submodules.
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 blindly dereference s
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 discussion and an RFC
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 workaround,
which is
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
+++ b/Documentation/config.txt
@@ -2844,6 +2844,18
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.
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 create
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 repos
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 because gitweb loads it
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
+++ b/Documentation/config.txt
@@ -2831,6 +2831,19
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 with "/i".
OK, I
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 .git/config.
> > +* Che
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
+++ b/t/t1700-split-index.s
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 co
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 pathspec struct in the
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 o
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 +++
config.c | 13 +
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 b/Documentation/config.txt
index 0e9982c5e3..2ccb
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 deletions(-)
diff --git a/rea
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 100644
--- a/cache.h
+++ b/c
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
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-i
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
in
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 has
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 a/t/t1700-split-index.sh b/t/t1700-
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 b/cache.h
index 014aa7ea11..955e
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
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
index 9054369dd0..99bc274b8d 1
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
@@ -334,6 +334,10 @@ core.trus
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
+++ b/t/t1700-split-index.sh
@@ -2
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
--- a/Documentation/git-update-index.txt
+++ b/Documentatio
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
---
builtin/update-index.c | 18 ++
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)
if (!strcasecmp
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 61fc86e6d7..014aa7ea11 100644
---
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 configurat
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 / notes / elaborations:
>
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? SHA
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 ob
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 w
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 a
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 commit you are analyz
1 - 100 of 119 matches
Mail list logo
