From: "Ævar Arnfjörð Bjarmason"
On Tue, Mar 27 2018, Jason Frey wrote:
While the impact of this bug is minimal, and git itself is not
affected, it can affect external tools that want to read the
.git/config file, expecting unique section names.
To reproduce:
Given the following example .git/
From: "Ævar Arnfjörð Bjarmason"
On Tue, Mar 27 2018, Jason Frey wrote:
While the impact of this bug is minimal, and git itself is not
affected, it can affect external tools that want to read the
.git/config file, expecting unique section names.
To reproduce:
Given the following example .git/
From: "Ævar Arnfjörð Bjarmason"
On Tue, Mar 27 2018, Jason Frey wrote:
While the impact of this bug is minimal, and git itself is not
affected, it can affect external tools that want to read the
.git/config file, expecting unique section names.
To reproduce:
Given the following example .git/
From: "Ævar Arnfjörð Bjarmason"
On Tue, Mar 27 2018, Jason Frey wrote:
While the impact of this bug is minimal, and git itself is not
affected, it can affect external tools that want to read the
.git/config file, expecting unique section names.
To reproduce:
Given the following example .git/
Contact for T & C.
On Sat, Mar 10, 2018 at 12:52:09PM +0100, Martin Ågren wrote:
> Someone trying this out might notice that `man git-shortlog` renders
> "\--" as "\--", which is not wanted. (Also visible on git-scm.com...)
> There is quite some history around such double-slashes and compatibility
> with AsciiDoc-ve
On Tue, Mar 27, 2018 at 07:09:36PM +0200, Duy Nguyen wrote:
> > I don't quite get why f57f37e2 doesn't want to call git_path(). Is it to
> > avoid the way the path is munged? Or is it to avoid some lazy-setup that
> > is triggered by calling get_git_dir() at all (which doesn't make much
> > sense
On Tue, Mar 27, 2018 at 07:30:24PM +0200, Duy Nguyen wrote:
> On Tue, Mar 27, 2018 at 07:09:36PM +0200, Duy Nguyen wrote:
> > I would rather have something like ref_store_reinit() in the same
> > spirit as the second call of set_git_dir() in setup_work_tree. It is
> > hacky, but it works and keeps
On Wed, Mar 28, 2018 at 11:52 AM, Jeff King wrote:
> On Tue, Mar 27, 2018 at 07:30:24PM +0200, Duy Nguyen wrote:
>
>> On Tue, Mar 27, 2018 at 07:09:36PM +0200, Duy Nguyen wrote:
>> > I would rather have something like ref_store_reinit() in the same
>> > spirit as the second call of set_git_dir() i
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
>> > Hi Sergey,
>> >
>>
>> [...]
>>
>> >> >> Reusing existing concepts where possible doesn`t have this problem.
>> >> >
>> >> > Existing concepts are great. As lo
Jacob Keller writes:
> On Tue, Mar 27, 2018 at 10:57 PM, Sergey Organov wrote:
>>
>> Hi Johannes,
>>
>> Johannes Schindelin writes:
[...]
> I'm pretty sure the fact has already been accepted, as he did indeed
> implement and develop a strategy for rebasing the merges (Phillip's
> strategy). H
On 28 March 2018 at 10:48, Jeff King wrote:
> On Sat, Mar 10, 2018 at 12:52:09PM +0100, Martin Ågren wrote:
>
>> Someone trying this out might notice that `man git-shortlog` renders
>> "\--" as "\--", which is not wanted. (Also visible on git-scm.com...)
>> There is quite some history around such
From: Jeff Hostetler
Please squash this onto the top of jh/json-writer.
Fix leading whitespace in t0019 using tricked suggested by Junio.
Fix unnecessary cast for intmax_t suggested by Wink.
Signed-off-by: Jeff Hostetler
---
json-writer.c | 4 ++--
t/t0019-json-writer.sh | 36 ++
Hi Stefan & Jason,
On Tue, 27 Mar 2018, Stefan Beller wrote:
> On Tue, Mar 27, 2018 at 1:41 PM Jason Frey wrote:
>
> > at which point you can see the duplicate sections (even though one is
> > empty). Also note that if you do the steps again, you will be left
> > with 3 sections, 2 of which ar
Hi Peff,
On Fri, 29 Mar 2013, Jeff King wrote:
> Subject: [PATCH] t1300: document some aesthetic failures of the config editor
>
> [...]
>
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 3c96fda..213e5a8 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
Stefan Beller writes:
>> Subject: [PATCH v2] submodule: check for NULL return of
> get_submodule_ref_store()
>
> Maybe more imperative, telling what we actually want
> to achieve instead of what we do?
>
>submodule: report deleted submodules as not initialized
>
>> If we can't find a ref stor
Johannes Schindelin writes:
>> Ideally, the existing one be annotated with prereq SHA1, and also
>> duplicated with a tweak to cause the same kind of (half-)collision
>> under the NewHash and be annotated with prereq NewHash.
>
> That's a good idea. I wonder whether we want to be a bit more speci
On Wed, Mar 28, 2018 at 9:52 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Subject: [PATCH v2] submodule: check for NULL return of
>> get_submodule_ref_store()
>>
>> Maybe more imperative, telling what we actually want
>> to achieve instead of what we do?
>>
>>submodule: report dele
Daniel Jacques writes:
> A simple grep suggests that the current test suite doesn't seem to have any
> RUNTIME_PREFIX-specific tests. When I've been running the test suites, I've
> been doing it with a "config.mak" file that explicitly enables
> RUNTIME_PREFIX to get the runtime prefix code teste
v2:
* addressed memleaks and messy code in patch 5
* removed the extern keyword where applicable
* extended the commit message, stating we want to rename submodule_free
in the future.
* picked up Jonathans patch and added it as a nice finish of the series.
I did not see the need or aesthetic de
At some point we may want to rename the function so that it describes what
it actually does as 'submodule_free' doesn't quite describe that this
clears a repository's submodule cache. But that's beyond the scope of
this series.
While at it remove the extern key word from its declaration.
Signed-
This continues the story of bf12fcdf5e (submodule-config: store
the_submodule_cache in the_repository, 2017-06-22).
The previous patch taught submodule_from_path to take a repository into
account, such that submodule_from_{path, cache} are the same now.
Remove submodule_from_cache, migrating all i
connect_work_tree_and_git_dir is used to connect a submodule worktree with
its git directory and vice versa after events that require a reconnection
such as moving around the working tree. As submodules can have nested
submodules themselves, we'd also want to fix the nested submodules when
asked to
The function connect_work_tree_and_git_dir is declared in both submodule.h
and dir.h, such that one of them is redundant. As the function is
implemented in dir.c, drop the declaration from submodule.h
Signed-off-by: Stefan Beller
---
submodule.h | 1 -
1 file changed, 1 deletion(-)
diff --git a
This enables submodule_from_{name, path} to handle arbitrary repositories.
All callers just pass in the_repository, a later patch will pass in other
repos.
While at it remove the extern key word from the declarations.
Reviewed-by: Jonathan Tan
Signed-off-by: Stefan Beller
---
builtin/submodule
From: Jonathan Tan
As part of commit f9ee2fcdfa ("grep: recurse in-process using 'struct
repository'", 2017-08-02), many functions in builtin/grep.c were
converted to also take "struct repository *" arguments. Among them were
grep_object() and grep_objects().
However, at least grep_objects() was
On 03/28, Stefan Beller wrote:
> connect_work_tree_and_git_dir is used to connect a submodule worktree with
> its git directory and vice versa after events that require a reconnection
> such as moving around the working tree. As submodules can have nested
> submodules themselves, we'd also want to
On Wed, Mar 28, 2018 at 12:10:21PM +0200, Duy Nguyen wrote:
> > I think it might be clearer if a single call is given both the old and
> > new paths. That requires the caller of chdir() storing getcwd() before
> > it moves, but I don't think that should be a big deal.
>
> The problem is switching
The set_git_dir() function returns an error if setenv()
fails, but there are zero callers who pay attention to this
return value. If this ever were to happen, it could cause
confusing results, as sub-processes would see a potentially
stale GIT_DIR (e.g., if it is relative and we chdir()-ed to
the r
If one part of the code does a permanent chdir(), then this
invalidates any relative paths that may be held by other
parts of the code. For example, setup_work_tree() moves us
to the top of the working tree, which may invalidate a
previously stored relative gitdir.
We've hacked around this case by
When we change to the top of the working tree, we manually
re-adjust $GIT_DIR and call set_git_dir() again, in order to
update any relative git-dir we'd compute earlier.
Instead of the work-tree code having to know to call the
git-dir code, let's use the new chdir_notify interface.
There are two s
Commit f57f37e2e1 (files-backend: remove the use of
git_path(), 2017-03-26) introduced a regression when a
relative $GIT_DIR is used in a working tree:
- when we initialize the ref backend, we make a copy of
get_git_dir(), which may be relative
- later, we may call setup_work_tree() and c
On Wed, 28 Mar 2018 10:24:48 -0700
Stefan Beller wrote:
> +static void connect_wt_gitdir_in_nested(const char *sub_worktree,
> + const char *sub_gitdir)
> +{
> + int i;
> + struct repository subrepo;
> + struct strbuf sub_wt = STRBUF_INIT;
> + s
On Wed, 28 Mar 2018 10:24:43 -0700
Stefan Beller wrote:
> * picked up Jonathans patch and added it as a nice finish of the series.
> I did not see the need or aesthetic desire to put that patch earlier
> in the series.
Thanks for picking up my patch. The aesthetic desire is to avoid what's
c
From: Duy Nguyen
This is just good cleanup and the logic will also be needed in new
patches.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
abspath.c | 4 +---
builtin/difftool.c | 6 ++
dir-iterator.c | 3 +--
path.c | 9 +++--
strbuf.c | 6 ++
strbuf.h
On Wed, Mar 28, 2018 at 7:36 PM, Jeff King wrote:
> On Wed, Mar 28, 2018 at 12:10:21PM +0200, Duy Nguyen wrote:
>
>> > I think it might be clearer if a single call is given both the old and
>> > new paths. That requires the caller of chdir() storing getcwd() before
>> > it moves, but I don't think
This is so that we can print traces based on this key outside trace.c.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
trace.c | 14 +++---
trace.h | 1 +
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/trace.c b/trace.c
index 7f3b08e148..fc623e91fd 100644
--- a/trace.c
+++ b/tra
From: Duy Nguyen
This function was added in 10c4c881c4 (Allow add_path() to add
non-existent directories to the path - 2008-07-21) because getcwd()
may fail on non-existing cwd and we want to construct non-existing
absolute paths sometimes.
The function was merged back in strbuf_add_absolute_pat
From: Duy Nguyen
When $CWD is moved, relative path must be updated to be relative to
the new $CWD. This function helps do that. The _in_place version is
just for convenient (and we will use it quite often in subsequent
patches).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 3 +++
setup.c
From: Duy Nguyen
When the current directory is moved, all relative paths may become
invalid because they are still relative to the old current
directory. At this point in setup_work_tree() many objects have been
initialized and some keep relative paths in their data structure.
$GIT_DIR and $GIT_
From: Duy Nguyen
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c| 10 ++
refs/files-backend.c | 15 +++
refs/packed-backend.c | 12
refs/refs-internal.h | 4
setup.c | 1 +
5 files changed, 42 insertions(+)
diff --git a/ref
From: Duy Nguyen
As noted in the previous patch, when $CWD is moved, we recognize the
problem with relative paths and update $GIT_WORK_TREE and $GIT_DIR
with new ones.
We have plenty more environment variables that can contain paths
though. If they are read and cached before setup_work_tree() is
From: Duy Nguyen
As noted in previous and previous patches, when setup_work_tree()
moves $CWD, it calls set_git_dir() with a new path to make sure
relative $GIT_DIR is still correct.
The same problem from the previous patch applies here: if
$GIT_ALTERNATE_OBJECT_DIRECTORIES or $GIT_OBJECT_DIRECT
On Wed, Mar 28, 2018 at 1:40 PM, Jeff King wrote:
> [...]
> Let's provide an API to let code that stores relative paths
> "subscribe" to updates to the current working directory.
> This means that callers of chdir() don't need to know about
> all subscribers ahead of time; they can simply consult
On Wed, Mar 28, 2018 at 06:33:55PM +0200, Johannes Schindelin wrote:
> On Fri, 29 Mar 2013, Jeff King wrote:
>
> > Subject: [PATCH] t1300: document some aesthetic failures of the config
> > editor
This is an old one. :) I had to go look up the old thread to refresh
myself.
> [...]
> Obviously,
On Wed, Mar 28, 2018 at 01:58:18PM -0400, Eric Sunshine wrote:
> On Wed, Mar 28, 2018 at 1:40 PM, Jeff King wrote:
> > [...]
> > Let's provide an API to let code that stores relative paths
> > "subscribe" to updates to the current working directory.
> > This means that callers of chdir() don't ne
On Wed, Mar 28, 2018 at 10:55 AM, Nguyễn Thái Ngọc Duy
wrote:
> +/**
> + * Return the current directory, fall back to $PWD if the
> + * current directory does not exist.
> + */
> +extern void strbuf_get_pwd_cwd(struct strbuf *sb);
Please see 89a9f2c862 (CodingGuidelines: mention "static" and "ext
On Wed, Mar 28, 2018 at 8:02 PM, Stefan Beller wrote:
> On Wed, Mar 28, 2018 at 10:55 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> +/**
>> + * Return the current directory, fall back to $PWD if the
>> + * current directory does not exist.
>> + */
>> +extern void strbuf_get_pwd_cwd(struct strbuf *sb);
>
>
On Wed, Mar 28, 2018 at 07:55:29PM +0200, Nguyễn Thái Ngọc Duy wrote:
> >> The problem is switching relative paths relies on the old $CWD if I'm
> >> not mistaken and we need getcwd() for this. I'd love to have one
> >> callback that says "$CWD has been switched from this path to that
> >> path,
On Wed, Mar 28, 2018 at 07:55:35PM +0200, Nguyễn Thái Ngọc Duy wrote:
> From: Duy Nguyen
>
> As noted in the previous patch, when $CWD is moved, we recognize the
> problem with relative paths and update $GIT_WORK_TREE and $GIT_DIR
> with new ones.
>
> We have plenty more environment variables t
--
Good-Day!
I am Malik Sanfo,I' m from Burkina Faso, I found your LinkedIn profile
suit for a business proposition which sufficient benefits. I shall
elaborate on this project upon your swift reply.
Sincerely
Mr. Malik Sanfo
--
Hi git Experts,
I believe we've encountered a bug in git. I built the latest, git 2.16.3, and
it still appears to be a problem. I'm not a git expert and my C is
ridiculously rusty but I think a co-worker and I figured it out... apologies if
we are incorrect in any assumptions (as I do not wi
From: René Scharfe
If we can't find a ref store for a submodule then assume it the latter
is not initialized (or was removed). Print a status line accordingly
instead of causing a segmentation fault by passing NULL as the first
parameter of refs_head_ref().
Reported-by: Jeremy Feusi
Signed-off
On Wed, Mar 28, 2018 at 8:30 PM, Jeff King wrote:
> On Wed, Mar 28, 2018 at 07:55:35PM +0200, Nguyễn Thái Ngọc Duy wrote:
>
>> From: Duy Nguyen
>>
>> As noted in the previous patch, when $CWD is moved, we recognize the
>> problem with relative paths and update $GIT_WORK_TREE and $GIT_DIR
>> with
On Wed, Mar 28, 2018 at 06:26:08PM +, Erik Brady -X (brady - ROBERT HALF
INTERNATIONAL INC at Cisco) wrote:
> The location of the problem is in credential.c, run_credential_helper()...
> this code:
>
>...
> fp = xfdopen(helper.in, "w");
> credential_write(c, fp);
> fclose(fp
On Wed, Mar 28, 2018 at 2:38 PM, Stefan Beller wrote:
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> @@ -821,6 +821,18 @@ test_expect_success 'moving the superproject does not
> break submodules' '
> +test_expect_success 'moving the submodule does not break the superproj
>> + if (repo_init(&subrepo, sub_gitdir, sub_worktree))
>> + return;
>
> Note that in Duy's object-store series he made this function private
> (IIRC) so this will result in some clash of the two series.
>
Yes, that is the case.
I wonder if I'd rather revert to v1 where we only use
On 2018-03-28 00:56, Stefan Beller wrote:
> On Tue, Mar 27, 2018 at 12:55 PM Peter Oberndorfer
> wrote:
Hi,
as expected your patch fixed the BUG output.
Thanks!
>> 2) Should "git submodule deinit" work on submodules that were removed by
> upstream already?
>
> To answer the question "Is this a
A release candidate Git v2.17.0-rc2 is now available for testing
at the usual places. It is comprised of 499 non-merge commits
since v2.16.0, contributed by 62 people, 19 of which are new faces.
I am hoping that we can have the final version tagged at the end of
coming weekend, before I fly out t
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.
Git 2.17 final is expected to be t
On Wed, Mar 28, 2018 at 11:57 AM, Eric Sunshine wrote:
> On Wed, Mar 28, 2018 at 2:38 PM, Stefan Beller wrote:
>> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
>> @@ -821,6 +821,18 @@ test_expect_success 'moving the superproject does not
>> break submodules' '
>> +test_exp
On Wed, Mar 28, 2018 at 4:08 PM, Stefan Beller wrote:
> On Wed, Mar 28, 2018 at 11:57 AM, Eric Sunshine
> wrote:
>>> +test_expect_success 'moving the submodule does not break the superproject'
>>> '
>>> + (
>>> + cd addtest2 &&
>>> +
>>> + mv repo repo.bak &&
>
On 03/28, Junio C Hamano wrote:
> * bw/protocol-v2 (2018-03-15) 35 commits
> - remote-curl: don't request v2 when pushing
> - remote-curl: implement stateless-connect command
> - http: eliminate "# service" line when using protocol v2
> - http: don't always add Git-Protocol header
> - http: al
When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12,
2017-12-08), it was guarded by the uploadpack.allowFilter config item
to allow server operators to control when they start supporting it.
That config item didn't go far enough, though: it controls whether the
'filter' capability
Sure, I can submit a patch if the change looks good to you (with my lack of
experience in the git source and very rusty C I would, of course, defer to an
expert in the area on exactly where to place the SIGPIPE ignore push and pop
and such... but what's below seems to avoid the race for us s
On Wed, Mar 28, 2018 at 12:58 PM, Junio C Hamano wrote:
>
> * ab/doc-hash-brokenness (2018-03-27) 2 commits
> - doc hash-function-transition: clarify what SHAttered means
> - doc hash-function-transition: clarify how older gits die on NewHash
This looked ready for next to me.
>
> * jk/branch-l
On Wed, Mar 28, 2018 at 1:21 PM, Eric Sunshine wrote:
> Or, even simpler:
>
> mv addtest2/repo addtest2/repo.bak &&
> test_when_finished "mv addtest2/repo.bak addtest2/repo" &&
> git -C addtest2 submodule status >actual &&
> grep -e "^-" -e repo actual
I like this!
Time permittin
Am 28.03.2018 um 22:21 schrieb Eric Sunshine:
> On Wed, Mar 28, 2018 at 4:08 PM, Stefan Beller wrote:
>> On Wed, Mar 28, 2018 at 11:57 AM, Eric Sunshine
>> wrote:
+test_expect_success 'moving the submodule does not break the
superproject' '
+ (
+ cd addte
On Wed, Mar 28, 2018 at 12:37 PM, Peter Oberndorfer wrote:
>>> 2) Should "git submodule deinit" work on submodules that were removed by
>> upstream already?
>>
>> To answer the question "Is this a submodule that upstream removed
>> (recently)?"
>> we'd have to put in some effort, essentially chec
> This looks nicer here in the script, but doesn't test exactly what users
> type most of the time, I suppose.
>
> So how about this?
Looks good to me, though I had a nagging feeling at first that the
regex could be made more concise.
Why do we need the optional "[^ ]" inside \1 ?
> + sed -
Jonathan Nieder writes:
> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12,
> 2017-12-08), it was guarded by the uploadpack.allowFilter config item
> to allow server operators to control when they start supporting it.
>
> That config item didn't go far enough, though: it contro
Add the drop and clear commands to the builtin helper. These two
are each simple, but are being added together as they are quite
related.
We have to unfortunately keep the drop and clear functions in the
shell script as functions are called with parameters internally
that are not valid when the co
credential.c, run_credential_helper(): now ignores SIGPIPE
when writing to credential helper. Avoids problem with race
where cred helper exits very quickly and, after, git tries
to write to it, generating SIGPIPE and crashing git. To
reproduce this the cred helper must not read from STDIN.
This
I've been working on converting all of git stash to be a
builtin, however it's hard to get it all working at once with
limited time, so I've moved around half of it to a new
stash--helper builtin and called these functions from the shell
script. Once this is stabalized, it should be easier to conve
In preparation for converting the stash command incrementally to
a builtin command, this patch improves test coverage of the option
parsing. Both for having too many paramerters, or too few.
Signed-off-by: Joel Teichroeb
---
t/t3903-stash.sh | 16
1 file changed, 16 insertions(+
Add stash pop to the helper and delete the pop_stash, drop_stash,
assert_stash_ref and pop_stash functions from the shell script
now that they are no longer needed.
Signed-off-by: Joel Teichroeb
---
builtin/stash--helper.c | 41
git-stash.sh|
Add a bulitin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
let conversion get started without the other command being
finished.
The helper is being implemented as a drop in replacement for
stash so that when it is complete it can s
Add stash branch to the helper and delete the apply_to_branch
function from the shell script.
Signed-off-by: Joel Teichroeb
---
builtin/stash--helper.c | 47 +++
git-stash.sh| 17 ++---
2 files changed, 49 insertions(+), 15 dele
Nguyễn Thái Ngọc Duy writes:
> This is what I got, which is slightly different from your series
> because I want to call set_git_dir() just one time (by
> setup_git_directory) and never again. I think the API looks close
> enough.
>
> I will probably rework on top of your chdir-notify instead (a
Am 28.03.2018 um 23:37 schrieb Stefan Beller:
>> This looks nicer here in the script, but doesn't test exactly what users
>> type most of the time, I suppose.
>>
>> So how about this?
>
> Looks good to me, though I had a nagging feeling at first that the
> regex could be made more concise.
> Why d
Stefan Beller writes:
>> This looks nicer here in the script, but doesn't test exactly what users
>> type most of the time, I suppose.
>>
>> So how about this?
>
> Looks good to me, though I had a nagging feeling at first that the
> regex could be made more concise.
> Why do we need the optional
The function connect_work_tree_and_git_dir is declared in both submodule.h
and dir.h, such that one of them is redundant. As the function is
implemented in dir.c, drop the declaration from submodule.h
Signed-off-by: Stefan Beller
---
submodule.h | 1 -
1 file changed, 1 deletion(-)
diff --git a
This continues the story of bf12fcdf5e (submodule-config: store
the_submodule_cache in the_repository, 2017-06-22).
The previous patch taught submodule_from_path to take a repository into
account, such that submodule_from_{path, cache} are the same now.
Remove submodule_from_cache, migrating all i
connect_work_tree_and_git_dir is used to connect a submodule worktree with
its git directory and vice versa after events that require a reconnection
such as moving around the working tree. As submodules can have nested
submodules themselves, we'd also want to fix the nested submodules when
asked to
From: Jonathan Tan
As part of commit f9ee2fcdfa ("grep: recurse in-process using 'struct
repository'", 2017-08-02), many functions in builtin/grep.c were
converted to also take "struct repository *" arguments. Among them were
grep_object() and grep_objects().
However, at least grep_objects() was
At some point we may want to rename the function so that it describes what
it actually does as 'submodule_free' doesn't quite describe that this
clears a repository's submodule cache. But that's beyond the scope of
this series.
While at it remove the extern key word from its declaration.
Signed-
This enables submodule_from_{name, path} to handle arbitrary repositories.
All callers just pass in the_repository, a later patch will pass in other
repos.
While at it remove the extern key word from the declarations.
Reviewed-by: Jonathan Tan
Signed-off-by: Stefan Beller
---
builtin/submodule
v3:
* reordered patches to have Jonathans patch before submodule_free
* addressed Jonathans comments on patch 5.
* rebased on origin/sb/object-store to resolve a visibility conflict
about repo_init being exposed outside of repository.c
v2:
* addressed memleaks and messy code in patch 5
* removed
>> * sb/packfiles-in-repository (2018-03-26) 12 commits
> ...
>>
>> (this branch uses nd/remove-ignore-env-field and sb/object-store.)
>>
>> Refactoring of the internal global data structure continues.
>>
>> Waiting for a follow-up discussion.
>
> I'll review this one more closely and start a di
On Wed, 28 Mar 2018 15:35:25 -0700
Stefan Beller wrote:
> v3:
> * reordered patches to have Jonathans patch before submodule_free
> * addressed Jonathans comments on patch 5.
> * rebased on origin/sb/object-store to resolve a visibility conflict
> about repo_init being exposed outside of reposi
Quick note: I did submit the patch, look for subject line " [PATCH] credential:
cred helper fast exit can cause SIGPIPE, crash".
Thanks again Jeff,
Erik
`git config` has long allowed the ability for callers to provide a 'type
specifier', which instructs `git config` to (1) ensure that incoming
values are satisfiable under that type, and (2) that outgoing values are
canonicalized under that type.
In another series, we propose to add extend this fun
For some use cases, callers of the `git-config(1)` builtin would like to
fallback to default values when the slot asked for does not exist. In
addition, users would like to use existing type specifiers to ensure
that values are parsed correctly when they do exist in the
configuration.
For example,
Hi all,
Attached is 'v3' of my patch series to add a `--default` option to `git config`.
The most notable change since the last reroll is that this series is now based
upon tb/config-type-specifier-option [1], with discussion about that change here
[2]. This was motivated by my and Peff's shared
As of this commit, the canonical way to retreive an ANSI-compatible
color escape sequence from a configuration file is with the
`--get-color` action.
This is to allow Git to "fall back" on a default value for the color
should the given section not exist in the specified configuration(s).
With the
In preparation for adding `--color` to the `git-config(1)` builtin,
let's introduce a color parsing utility, `git_config_color` in a similar
fashion to `git_config_`.
Signed-off-by: Taylor Blau
---
config.c | 10 ++
config.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/config.
On Wed, Mar 28, 2018 at 06:16:31PM -0700, Taylor Blau wrote:
> Attached is 'v3' of my patch series to add a `--default` option to `git
> config`.
My apologies, this patch series is only 3 long, so the subject line of
this message is incorrect.
Thanks,
Taylor
On Mon, Mar 26, 2018 at 04:34:42AM -0400, Jeff King wrote:
> > diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
> > index e09ed5d7d..d9e389a33 100644
> > --- a/Documentation/git-config.txt
> > +++ b/Documentation/git-config.txt
> > @@ -233,8 +233,10 @@ See also <>.
> > u
On Mon, Mar 26, 2018 at 04:55:56AM -0400, Jeff King wrote:
> In fact, that kind of makes me wonder if this "type" list should not
> exist at all. If we instead grouped the options and said "these are the
> type options", then we'd only need one list.
>
> I'm OK to punt on that for now, though, in t
On Mon, Mar 26, 2018 at 05:16:45AM -0400, Jeff King wrote:
> On Fri, Mar 23, 2018 at 08:55:56PM -0400, Taylor Blau wrote:
>
> > As of this commit, the canonical way to retreive an ANSI-compatible
> > color escape sequence from a configuration file is with the
> > `--get-color` action.
>
> s/retreiv
1 - 100 of 103 matches
Mail list logo
