On Thu, Dec 17, 2015 at 2:52 PM, Eric Sunshine wrote:
> On Wed, Dec 16, 2015 at 10:30 AM, Karthik Nayak wrote:
>> Introduce remote_ref_atom_parser() which will parse the '%(upstream)'
>> and '%(push)' atoms and store information into the 'used_atom'
>> structure based on the modifiers used along
On Wed, Dec 23, 2015 at 11:53 PM, Eric Sunshine wrote:
> On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder
> wrote:
>> Factor out code into new_untracked_cache(), which will be used
>> multiple times in a later commit.
>
> Odd indentation: s/^\s+//
Yeah, will fix.
>> Signed-off-by: Chri
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> In that case we can just check config once in read_index_from and
>> destroy UNTR extension. Or the middle ground, we check config once in
>> that place, make a note in struct index_state, and make invalidate_*
>> check that note instead of config
Michael Haggerty writes:
> You are answering "What is 'refs/' good for in the pathnames of files
> that store loose references?" I was asking "What is 'refs/' good for in
> the logical names of references?"
>
> It would have been totally possible to make the full name of a branch
> be, for exampl
Remove the suggestion for using a detached HEAD instead of a
temporary branch.
Signed-off-by: Stephen P. Smith
---
Notes:
A search of the user manual found only one location which refers to
temporary branches. This has to do with how Tony Luck uses them.
Even then there is a cl
On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder
wrote:
> Factor out code into new_untracked_cache(), which will be used
> multiple times in a later commit.
Odd indentation: s/^\s+//
> Signed-off-by: Christian Couder
> ---
> diff --git a/dir.c b/dir.c
> @@ -1938,16 +1938,20 @@ void add
On Wed, Dec 23, 2015 at 09:37:04PM +0100, Johannes Sixt wrote:
> >--- a/git.c
> >+++ b/git.c
> >@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
> > alias_argv[argc] = NULL;
> >
> > ret = run_command_v_opt(alias_argv, RUN_USING_SHE
It is not a good idea to compare kernel versions and disable
the untracked cache if it changes as people may upgrade and
still want the untracked cache to work. So let's just
compare work tree locations to decide if we should disable
it.
Also it's not useful to store many locations in the ident
fi
Factor out code into new_untracked_cache(), which will be used
multiple times in a later commit.
Signed-off-by: Christian Couder
---
dir.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/dir.c b/dir.c
index 0f7e293..4227ba6 100644
--- a/dir.c
+++
Factor out code into remove_untracked_cache(), which will be used
in a later commit.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 6 +-
dir.c | 9 +
dir.h | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin/
Signed-off-by: Christian Couder
---
t/t7063-status-untracked-cache.sh | 48 +--
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/t/t7063-status-untracked-cache.sh
b/t/t7063-status-untracked-cache.sh
index 253160a..f0af41c 100755
--- a/t/t7063-sta
When we know that mtime is fully supported by the environment, we
might want the untracked cache to be always used by default without
any mtime test or kernel version check being performed.
Also when we know that mtime is not supported by the environment,
for example because the repo is shared ove
Factor out code into add_untracked_cache(), which will be used
in a later commit.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 11 +--
dir.c | 14 ++
dir.h | 1 +
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git
It is nice to just be able to test if untracked cache is
supported without enabling it.
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 9 -
builtin/update-index.c | 5 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation
Signed-off-by: Christian Couder
---
builtin/update-index.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index c91e695..f667125 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1116,8 +1116,6 @@ int cmd_u
Attempting to flip the untracked-cache feature on for a random index
file with
cd /random/unrelated/place
git --git-dir=/somewhere/else/.git update-index --untracked-cache
would not work as you might expect. Because flipping the feature on
in the index also records the location of the cor
Signed-off-by: Christian Couder
---
builtin/update-index.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index a6fff87..1e546a3 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -35,6 +35,1
Signed-off-by: Christian Couder
---
builtin/update-index.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 7431938..a6fff87 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1123,6 +1123,7 @@ int cmd_update_index(int arg
Here is a new version of a patch series to improve the untracked cache
feature.
This v3 still implements core.untrackedCache as a simple bool config
variable. When it's true, Git should always try to use the untracked
cache, and when false, Git should never use it.
Patch 1/11 is a small bugfix th
Am 23.12.2015 um 10:37 schrieb Jeff King:
The second line comes from handle_alias itself. It calls
die_errno whenever run_command returns a negative value.
However, only -1 indicates a syscall error where errno has
something useful (note that it says the useless "success"
above). Instead, we trea
Rather than merely pointing readers at the 1.5 release notes to
learn about shallow clones, document them formally.
Signed-off-by: Stephen P. Smith
---
I replaced the paragraphs that I wrote with Eric Shunshine's since it
was cleaner.
I like the idea of linking to the preceeding effort, but
On Wed, Dec 23, 2015 at 8:51 AM, Michael Haggerty wrote:
> On 12/03/2015 01:35 AM, David Turner wrote:
>> + if (refs_backend_type && *refs_backend_type) {
>> + argv_array_push(&cp.args, "--refs-backend-type");
>> + argv_array_push(&cp.args, refs_backend_type);
>> +
On Wed, Dec 23, 2015 at 10:52:41AM +0100, Michael Haggerty wrote:
> On 12/05/2015 08:44 AM, Jeff King wrote:
> > [...]
> > I think the config option needs to be extensions.refsBackendType, too,
> > per the logic in 00a09d5 (introduce "extensions" form of
> > core.repositoryformatversion, 2015-06-2
Hi Daniel,
On Wed, 23 Dec 2015, Daniel Stenberg wrote:
> By re-using a very widely used, well developed and properly documented
> library [libcurl] (yeah, I claim it is but you don't need to take my
> word for it) that is available everywhere - git benefits.
For what it's worth, I fully agree. M
On Wed, Dec 23, 2015 at 4:37 AM, Jeff King wrote:
> Subject: [PATCH] avoid SIGPIPE warnings for aliases
>
> When git executes an alias that specifies an external
> command, it will complain if the alias dies due to a signal.
> This is usually a good thing, as signal deaths are
> unexpected. Howeve
On 12/03/2015 01:35 AM, David Turner wrote:
> Add a database backend for refs using LMDB. This backend runs git
> for-each-ref about 30% faster than the files backend with fully-packed
> refs on a repo with ~120k refs. It's also about 4x faster than using
> fully-unpacked refs. In addition, and
I am pleased to announce the immediate availability of Git 1.9 on CentOS
Linux 6 and 7 x86_64, delivered via a Software Collection (SCL) built by
the SCLo Special Interest Group
(https://wiki.centos.org/SpecialInterestGroup/SCLo).
QuickStart
--
You can get started in three easy steps:
On 12/03/2015 01:35 AM, David Turner wrote:
> Add a new option, --refs-backend-type, to allow the ref backend type to
> be set on new clones.
>
> Submodules must use the same ref backend as the parent repository, so
^^^ is this verified anywhere? Hint: if not, it probably should be. For
example,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
This patch series continues the changes introduced with the merge
6753d8a85d543253d95184ec2faad6dc197f248:
Merge branch 'ep/shell-command-substitution'
Adjust shell scripts to use $(cmd) instead of `cmd`.
This is the fourth serie, the other will be sent separately.
Elia Pinto (10):
On 12/03/2015 01:35 AM, David Turner wrote:
> git init learns a new argument --refs-backend-type. Presently, only
> "files" is supported, but later we will add other backends.
>
> When this argument is used, the repository's core.refsBackendType
> configuration value is set, and the refs backend'
Signed-off-by: Michael Haggerty
---
David, I think if you insert this patch before your
13/16 refs: allow ref backend to be set for clone
, then the hunk in builtin/clone.c:checkout() of your patch becomes
trivial:
if (refs_backend_type)
argv_array_pushf(&cmd.args, "--
On Wed, Dec 23, 2015 at 4:37 PM, Jeff King wrote:
> On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote:
>
>> > Another by the way, this "forcing aliases as external commands" now
>> > shows something like "error: git-log died of signal 13" when the pager
>> > exits early, for an alias
On Tue, 22 Dec 2015, Paul Smith wrote:
I grok that Git doesn't want to re-invent the wheel and that libcurl is
convenient. I just wonder if anyone knows of another wheel, that doesn't
come attached to an entire tractor-trailer, that could be used instead :).
But if you would consider another
On 12/05/2015 08:44 AM, Jeff King wrote:
> [...]
> I think the config option needs to be extensions.refsBackendType, too,
> per the logic in 00a09d5 (introduce "extensions" form of
> core.repositoryformatversion, 2015-06-23). And I guess it needs to bump
> core.repositoryformatversion to "1".
I th
On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote:
> > Another by the way, this "forcing aliases as external commands" now
> > shows something like "error: git-log died of signal 13" when the pager
> > exits early, for an alias like "l1 = log --oneline".
>
> ... and we do not show th
On Wed, Nov 25, 2015 at 10:10 AM, Jack Nagel wrote:
> When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the
> default) and specifying NO_OPENSSL=1, the resulting git uses the
> BLK_SHA1 implementation rather than the functions available in
> CommonCrypto.
>
> $ make NO_OPENSSL=1
> [...]
>
On 12/03/2015 01:35 AM, David Turner wrote:
> Always handle non-normal (per-worktree or pseudo) refs in the files
> backend instead of alternate backends.
>
> Sometimes a ref transaction will update both a per-worktree ref and a
> normal ref. For instance, an ordinary commit might update
> refs/h
47 matches
Mail list logo
