---
Documentation/SubmittingPatches | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches
b/Documentation/SubmittingPatches
index 98fc4cc..b2c7664 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -168,7 +168,9 @
Thanks for the quick reply.
Is there any documentation on which variables are muli-valued?
git -c credential.helper="store --file=creds" config --get credential.helper
only returns one value.
How can i even know if there are multiple set. I mean someone might
have just created an extra credenti
On Fri, Feb 26, 2016 at 12:17:49PM +0530, Guilherme wrote:
> I'm trying to use git in an integration test and i'm having trouble
> with configuration options.
>
> On windows developer machines we use wincred as our credenital helper
> and thus have it set in ~/.gitconfig
>
> For the integration
On Thu, Feb 25, 2016 at 10:07 PM, Jeff King wrote:
> Of the two you suggested, I think I like the here-doc better, as it does
> not leave any question to a reader that there is other interpolation
> going on.
>
> -Peff
Agreed. Since I forgot the parts about argc checking, I will do a
reroll with
Matthieu Moy:
> Using "git send-email" normally does the right thing. You may want to
> look at https://submitgit.herokuapp.com/ too.
git send-email does not work as my institute proxy does not allow
IMAP/SMTP connections. But I will take care of this from hence forward.
> The commit message shoul
On Fri, Feb 26, 2016 at 3:04 AM, Stephan Beyer wrote:
> Signed-off-by: Stephan Beyer
> ---
>
> To be honest: the test could be better, it could be more "targeted",
> i.e. the example commit history could be smaller and just consider
> all the cases and corner cases and whatever.
> However, I made
Hi!
I'm trying to use git in an integration test and i'm having trouble
with configuration options.
On windows developer machines we use wincred as our credenital helper
and thus have it set in ~/.gitconfig
For the integration test that is no use as it will make testing
unauthorized logging in i
On Thu, Feb 25, 2016 at 09:26:14PM -0500, Eric Sunshine wrote:
> On Thu, Feb 25, 2016 at 9:19 PM, Jacob Keller wrote:
> > On Thu, Feb 25, 2016 at 5:55 PM, Eric Sunshine
> > wrote:
> >> Not worth a re-roll, but these quote sequences are brain-melting.
> >> Easier would have been to double-quote
Stephan Beyer writes:
> It makes no sense that the argument for count_distance() and
> halfway() is a commit list when only its first commit is relevant.
>
> Signed-off-by: Stephan Beyer
> ---
>
> This is just some kind of minor code cleanup.
> The typical "while at it", you know it, I guess.
I
Stephan Beyer writes:
> The idea is to reverse the DAG and perform a modified breadth-first search
> on it, starting on all sources of the reversed DAG.
> Before each visit of a commit, its weight is induced.
> This only works for non-merge commits, so the BFS stops prematurely on
> merge commits
Thanks for the submission. Review comments below...
On Thu, Feb 25, 2016 at 9:57 PM, Pranit Bauva wrote:
> From c273a02fc9cab9305cedf6e37422e257a1cc3b1e Mon Sep 17 00:00:00 2001
> From: Pranit Bauva
> Date: Fri, 26 Feb 2016 07:14:18 +0530
> Subject: [PATCH/RFC] git-commit: add a commit.verbose c
On Thu, Feb 25, 2016 at 6:26 PM, Eric Sunshine wrote:
> One thing I elided accidentally was that when changing the second
> argument of test_expect_success to double-quotes, you would altogether
> drop the double-quotes around "helper" in:
>
> git -c credential.helper="helper" submodule--helpe
On Thu, Feb 25, 2016 at 9:19 PM, Jacob Keller wrote:
> On Thu, Feb 25, 2016 at 5:55 PM, Eric Sunshine
> wrote:
>> Not worth a re-roll, but these quote sequences are brain-melting.
>> Easier would have been to double-quote the second argument of
>> test_expect_success() and then do either:
>
> Th
On Thu, Feb 25, 2016 at 5:55 PM, Eric Sunshine wrote:
> Not worth a re-roll, but these quote sequences are brain-melting.
> Easier would have been to double-quote the second argument of
> test_expect_success() and then do either:
>
They are. I fiddled with things till I got it working. I wasn't s
On Thu, Feb 25, 2016 at 7:13 AM, Michael Procter wrote:
> Use the argv_array in the child_process structure, to avoid having to
> manually maintain an array size.
>
> Signed-off-by: Michael Procter
> ---
> diff --git a/upload-pack.c b/upload-pack.c
> @@ -90,35 +90,32 @@ static void create_pack_fi
This commit gets rid of the O(#commits) extra overhead of
the best_bisection() function.
Signed-off-by: Stephan Beyer
---
bisect.c | 43 ++-
1 file changed, 18 insertions(+), 25 deletions(-)
diff --git a/bisect.c b/bisect.c
index 827a82a..185a3cf 100644
-
The total number of commits in a bisect process is a property of
the bisect process. Making this property global helps to make the code
clearer.
Signed-off-by: Stephan Beyer
---
bisect.c | 74 ++--
1 file changed, 39 insertions(+), 35 d
This is a preparation for subsequent changes.
During a bisection process, we want to augment commits with
further information to improve speed.
Signed-off-by: Stephan Beyer
---
bisect.c | 61 ++---
1 file changed, 30 insertions(+), 31 delet
If DEBUG_BISECT is set to 1, bisect does not only show debug
information but also changes the algorithm behavior: halfway()
is always false.
This commit makes the algorithm independent of DEBUG_BISECT.
Signed-off-by: Stephan Beyer
---
bisect.c | 2 --
1 file changed, 2 deletions(-)
diff --git
The idea is to reverse the DAG and perform a modified breadth-first search
on it, starting on all sources of the reversed DAG.
Before each visit of a commit, its weight is induced.
This only works for non-merge commits, so the BFS stops prematurely on
merge commits (that are collected in a list).
M
This is a preparation commit with copy-and-paste involved.
The function do_find_bisection() is changed and copied to
two almost similar functions compute_all_weights() and
compute_relevant_weights().
The function compute_relevant_weights() stops when a
"halfway" commit is found.
To keep the code
Large repositories with a huge amount of merge commits in the
bisection process could lead to stack overflows in git bisect.
In order to prevent this, this commit uses an *iterative* version
for counting the number of ancestors of a commit.
Signed-off-by: Stephan Beyer
---
In the cover letter I
Mention `bisect next` in the documentation of bisect.
`bisect next` is only useful in rare cases and the result
can also be accomplished using other utilities (like reflog).
However, it is available as a bisect command and should hence be
documented.
Also mention the use case when no good commit i
Signed-off-by: Stephan Beyer
---
To be honest: the test could be better, it could be more "targeted",
i.e. the example commit history could be smaller and just consider
all the cases and corner cases and whatever.
However, I made it first to understand the algorithm and verify the
description of
Let us use the term "weight" for the number of ancestors
of each commit, and "distance" for the number
min{weight, #commits - weight}. (Bisect finds the commit
with maximum distance.)
In these terms, "count_distance()" is the wrong name of
the function. So it is renamed to "compute_weight()",
and
clear_distance() was a O(#commits)-time function to clear the COUNTED
flag from commits counted in count_distance().
The functions count_distance() and clear_distance() were called for
each merge commit.
This commit gets rid of the clear_distance() function by making
count_distance() use unique ma
Setting the macro DEBUG_BISECT to 1 enables debugging information
for the bisect algorithm. The code did not compile due to struct
changes.
Signed-off-by: Stephan Beyer
---
bisect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index 06ec54e..905e6
We introduce the concept of rising and falling distances
(in addition to a halfway distance).
This will be useful in subsequent commits.
Signed-off-by: Stephan Beyer
---
bisect.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/bisect.c b/bi
Signed-off-by: Stephan Beyer
---
We will also use that function more often later.
bisect.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/bisect.c b/bisect.c
index 76f2445..afdd1c4 100644
--- a/bisect.c
+++ b/bisect.c
@@ -38,6 +38,14 @@ static inline struc
It makes no sense that the argument for count_distance() and
halfway() is a commit list when only its first commit is relevant.
Signed-off-by: Stephan Beyer
---
This is just some kind of minor code cleanup.
The typical "while at it", you know it, I guess.
bisect.c | 16
1 file
Hi,
this set of patches provides improvements for git bisect.
Quick summary of changes
- relevant for users:
- `git bisect next` is documented and motivated
- git bisect implementation becomes much faster
(or: is now working) for big repositories**
- relevant for developers:
- a t
The documentation says that when the maximum possible distance
is found, the algorithm stops immediately. That feature is
reestablished by this commit.
Signed-off-by: Stephan Beyer
---
In my tests, I have not seen any gain of performance by
doing this... but it's fast now anyway, who cares ;-)
On Thu, Feb 25, 2016 at 10:57:12AM -0800, Jacob Keller wrote:
> [...]
> Replace all the calls to clear_local_git_env with a wrapped function
> that filters GIT_CONFIG_PARAMETERS using the new helper and then
> restores it to the filtered subset after clearing the rest of the
> environment.
>
> Sig
Duy Nguyen writes:
> On Fri, Feb 26, 2016 at 5:34 AM, Stefan Beller wrote:
>> In case the length of the buffer is zero, we do not need to call the
>> fwrite system call as a performance improvement.
>
> fwrite is a libc call, not system call. Are you sure it always calls
> write() (assuming buff
On Fri, Feb 26, 2016 at 5:34 AM, Stefan Beller wrote:
> In case the length of the buffer is zero, we do not need to call the
> fwrite system call as a performance improvement.
fwrite is a libc call, not system call. Are you sure it always calls
write() (assuming buffering is off)?
>
> Signed-off
Stefan Beller wrote:
> Thanks Jonathan (and all the other cc'd reviewers) for bearing
> yet another revision!
Thanks. This one looks good.
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More m
Expose possible parallelism either via the "--jobs" CLI parameter or
the "submodule.fetchJobs" setting.
By having the variable initialized to -1, we make sure 0 can be passed
into the parallel processing machine, which will then pick as many parallel
workers as there are CPUs.
Reviewed-by: Jonath
Reroute the error message for specified but initialized submodules
to stderr instead of stdout.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
git-submodule.sh | 4 ++--
t/t7400-submodule-basic.sh | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/
Currently submodule..update is only handled by git-submodule.sh.
C code will start to need to make use of that value as more of the
functionality of git-submodule.sh moves into library code in C.
Add the update field to 'struct submodule' and populate it so it can
be read as sm->update or from sm-
This allows to configure fetching and updating in parallel
without having the command line option.
This moved the responsibility to determine how many parallel processes
to start from builtin/fetch to submodule.c as we need a way to communicate
"The user did not specify the number of parallel proc
We want to reuse the error reporting facilities in a later patch.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 18 +-
run-command.h | 19 +++
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/run-command.c b/run-comm
As the strbufs passed around collect all output to the user, and there
is no post processing involved we need to care about the line ending
ourselves.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/run-command.c
Adhere to the common coding style of Git and not check explicitly
for NULL throughout the file. There are still other occurrences in the
code base but that is usually inside of conditions with side effects.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule-config.c | 6 +++
Just pass it along to "git submodule update", which may pick reasonable
defaults if you don't specify an explicit number.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
Documentation/git-clone.txt | 6 +-
builtin/clone.c | 19 +--
t/t7406-submodul
We do not want the output to be interrupted by a NUL byte, so we
cannot use raw fputs. Introduce strbuf_write to avoid having long
arguments in run-command.c.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 8
strbuf.c | 6 ++
strbuf.h | 6 ++
This introduces a new helper function in git submodule--helper
which takes care of cloning all submodules, which we want to
parallelize eventually.
Some tests (such as empty URL, update_mode=none) are required in the
helper to make the decision for cloning. These checks have been
moved into the C
The refs code has a similar pattern of passing around 'struct strbuf *err',
which is strictly used for error reporting. This is not the case here,
as the strbuf is used to accumulate all the output (whether it is error
or not) for the user. Rename it to 'out'.
Suggested-by: Jonathan Nieder
Review
Thanks Jonathan (and all the other cc'd reviewers) for bearing
yet another revision!
I changed the prefix handling back again as it is more consistent.
Once this series is landed, I plan to refactor the prefix handling for
all the submodule--helper commands.
Thanks,
Stefan
Interdiff to v18:
d
On Thu, Feb 25, 2016 at 3:41 PM, Junio C Hamano wrote:
> Actually, let's wait a bit to avoid unnecessary conflicts between topics.
> sb/submodule-fetch-nontip changes the way how these calls to "clean env"
> helper function are made.
Ya there will be some superficial conflicts with some of Stefan
On Thu, Feb 25, 2016 at 3:39 PM, Jacob Keller wrote:
>>
>> Ahh, the one you quoted does have a better log message. Let's
>> replace the ancieint one I have and use Jacob's 2/2 on top of it.
>>
>
> Agreed. I did not know the source of the issue, only what fixed it.
Actually, let's wait a bit to a
On Thu, Feb 25, 2016 at 3:35 PM, Jonathan Nieder wrote:
> Interesting --- git sets a GIT_PREFIX environment variable (in the
> same spirit as GIT_WORK_TREE) but doesn't read it.
I think that is because it is meant for helping end-user scripts that
are called by us;
they would not know where the e
On Thu, Feb 25, 2016 at 3:18 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Michael (cc'd) posted an identical patch with some more discussion back
>>> in May:
>>>
>>> http://article.gmane.org/gmane.comp.version-control.git/268770
>>>
>>> The series languished because none of the revi
Stefan Beller wrote:
> On Thu, Feb 25, 2016 at 3:19 PM, Jonathan Nieder wrote:
> > Now that I look around more, it seems that other submodule--helper
> > subcommands
> > have the same strange behavior of overwriting the 'prefix' var. So I take
> > back my suggestion of using a different variabl
Stefan Beller wrote:
> Interdiff to v17:
Except for the bit about 'prefix',
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 25, 2016 at 3:19 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> --- a/builtin/submodule--helper.c
>> +++ b/builtin/submodule--helper.c
>> @@ -465,14 +465,14 @@ static int update_clone(int argc, const char **argv,
>> const char *prefix)
>> NULL
>> };
>>
>> -
Stefan Beller wrote:
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -465,14 +465,14 @@ static int update_clone(int argc, const char **argv,
> const char *prefix)
> NULL
> };
>
> - argc = parse_options(argc, argv, prefix, module_update_clone_
Junio C Hamano writes:
>> Michael (cc'd) posted an identical patch with some more discussion back
>> in May:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/268770
>>
>> The series languished because none of the reviewers had systems that
>> reproduced the problem, and I think the
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King writes:
> On Thu, Feb 25, 2016 at 10:57:11AM -0800, Jacob Keller wrote:
>
>> From: Jacob Keller
>>
>> Since 2.4, apache will fail to load unless mod_unixd is loaded in order
>> to drop privileges.
>>
>> Signed-off-by: Jacob Keller
>> ---
>>
>> I am not sure why this wasn't there al
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.
You can find the changes described
On Thu, Feb 25, 2016 at 3:08 PM, Stefan Beller wrote:
Subject: Expose
... submodule parallelism to the user
Does git-send-email cache information after invoking it? i.e. Am I not supposed
to edit the patch files after invoking git send-mail, before
confirming to send them
out actually?
Thanks
Currently submodule..update is only handled by git-submodule.sh.
C code will start to need to make use of that value as more of the
functionality of git-submodule.sh moves into library code in C.
Add the update field to 'struct submodule' and populate it so it can
be read as sm->update or from sm-
This allows to configure fetching and updating in parallel
without having the command line option.
This moved the responsibility to determine how many parallel processes
to start from builtin/fetch to submodule.c as we need a way to communicate
"The user did not specify the number of parallel proc
We want to reuse the error reporting facilities in a later patch.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 18 +-
run-command.h | 19 +++
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/run-command.c b/run-comm
Reroute the error message for specified but initialized submodules
to stderr instead of stdout.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
git-submodule.sh | 4 ++--
t/t7400-submodule-basic.sh | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/
Just pass it along to "git submodule update", which may pick reasonable
defaults if you don't specify an explicit number.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
Documentation/git-clone.txt | 6 +-
builtin/clone.c | 19 +--
t/t7406-submodul
As the strbufs passed around collect all output to the user, and there
is no post processing involved we need to care about the line ending
ourselves.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/run-command.c
We do not want the output to be interrupted by a NUL byte, so we
cannot use raw fputs. Introduce strbuf_write to avoid having long
arguments in run-command.c.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
run-command.c | 8
strbuf.c | 6 ++
strbuf.h | 6 ++
Expose possible parallelism either via the "--jobs" CLI parameter or
the "submodule.fetchJobs" setting.
By having the variable initialized to -1, we make sure 0 can be passed
into the parallel processing machine, which will then pick as many parallel
workers as there are CPUs.
Reviewed-by: Jonath
* fixes the test breakage (which was caused by a last minute fix :/ to the
prefix variable handling)
* include the separately sent patch to not call fwrite in case of length 0
Thanks,
Stefan
Interdiff to v17:
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 9d94406.
Adhere to the common coding style of Git and not check explicitly
for NULL throughout the file. There are still other occurrences in the
code base but that is usually inside of conditions with side effects.
Reviewed-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
submodule-config.c | 6 +++
This introduces a new helper function in git submodule--helper
which takes care of cloning all submodules, which we want to
parallelize eventually.
Some tests (such as empty URL, update_mode=none) are required in the
helper to make the decision for cloning. These checks have been
moved into the C
The refs code has a similar pattern of passing around 'struct strbuf *err',
which is strictly used for error reporting. This is not the case here,
as the strbuf is used to accumulate all the output (whether it is error
or not) for the user. Rename it to 'out'.
Suggested-by: Jonathan Nieder
Review
On 25/02/16 21:39, Jeff King wrote:
> On Thu, Feb 25, 2016 at 12:20:12PM -0800, Junio C Hamano wrote:
>
>> Ramsay Jones writes:
>>
>>> Signed-off-by: Ramsay Jones
>>> ---
>>>
>>> Hi Jeff,
>>>
>>> If you need to re-roll your 'jk/epipe-in-async' branch, could you
>>> please squash this into the
Stefan Beller writes:
> In case the length of the buffer is zero, we do not need to call the
> fwrite system call as a performance improvement.
>
> Signed-off-by: Stefan Beller
> ---
>
> This applies on top of v17 for origin/sb/submodule-parallel-update.
>
> In case there are other reasons f
After the previous changes in this series there are only a handful of
$(__gitdir) command substitutions left in the completion script, but
there is still a bit of room for improvements:
1. The command substitution involves the forking of a subshell,
which has considerable overhead on some p
To prepare for caching the path to the repository in the following
commit, extract the repository discovering part of __gitdir() into the
__git_find_repo_path() helper function, which stores the found path in
the $__git_repo_path variable instead of printing it. Make __gitdir()
a wrapper around th
Three completion functions first run __gitdir() and check that the
path it outputs exists, i.e. that there is a git repository, and run a
git command only if there is one.
After the previous changes in this series there are no further uses of
__gitdir()'s output in these functions besides those ch
Outputting error messages during completion is bad: they disrupt the
command line, can't be deleted, and the user is forced to Ctrl-C and
start over most of the time. We already silence stderr of many git
commands in our Bash completion script, but there are still some in
there that can spew error
Several completion functions contain the following pattern to run git
commands respecting the path to the repository specified on the
command line:
git --git-dir="$(__gitdir)"
This imposes the overhead of fork()ing a subshell for the command
substitution and potentially fork()+exec()ing 'git
'git -C ' option(s) on the command line should be taken into
account during completion, because
- like '--git-dir=', it can lead us to a different repository,
and
- a few git commands executed in the completion script do actually
care about from which directory they are executed from.
The main git options '--git-dir', '-c', '-C', '--worktree' and
'--namespace' require an argument, but attempting completion right
after them lists git commands.
Don't offer anything right after these options, thus let Bash fall
back to filename completion, because
- the three options '--git-dir
The main completion function finds the name of the git command by
iterating through all the words on the command line in search for the
first non-option-looking word. As it is not aware of 'git -C's
mandatory path argument, if the '-C ' option is present, 'path'
will be the first such word and it
Check how __git_refs() lists refs in different scenarios, i.e.
- short and full refs,
- from a local or from a remote repository,
- remote specified via path, name or URL,
- with or without a repository specified on the command line,
- non-existing remote,
- unique remote branches for
Some scripts can benefit from not having to deal with the possibility
of relative paths to the repository, but the output of 'git rev-parse
--git-dir' can be a relative path. Case in point: supporting 'git -C
' in our Bash completion script turned out to be considerably
more difficult, error prone
e832f5c09680 (completion: avoid ls-remote in certain scenarios,
2013-05-28) turned a 'git ls-remote ' query into a 'git
for-each-ref refs/remotes//' to improve responsiveness of
remote refs completion by avoiding potential network communication.
However, it inadvertently made impossible to complete
When refs completion is attempted while not in a git repository, the
completion script offers 'HEAD' erroneously.
Check early in __git_refs() that there is either a repository or a
remote to work on, and exit early if neither is given.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-comp
If the remote given to __git_refs() happens to match both the name of
a configured remote and the name of a directory in the current working
directory, then that directory is assumed to be a git repository, and
listing refs from that directory will be attempted. This is wrong,
because in such a si
The __gitdir() helper function stays silent and returns with error
when it can't find a repository or when the repository given via
$GIT_DIR doesn't exist.
This is not the case, however, when the path in $__git_dir, i.e. the
path to the repository specified on the command line as 'git
--git-dir=',
The completion script already respects the path to the repository
specified on the command line most of the time, here we add the
necessary '--git-dir=$(__gitdir)' options to most of the places where
git was executed without it. The exceptions where said option is not
added are the git invocations
In __git_refs() the git commands listing refs, both short and full,
from a given remote repository are run without giving them the path to
the git repository which might have been specified on the command line
via 'git --git-dir='. This is bad, those git commands should
access the 'refs/remotes//'
The __gitdir() helper function shouldn't output anything if not in a
git repository. The relevant tests only checked its error code, so
extend them to ensure that there's no output.
Signed-off-by: SZEDER Gábor
---
t/t9902-completion.sh | 10 ++
1 file changed, 6 insertions(+), 4 deletio
Some tests of the __gitdir() helper function use the $TRASH_DIRECTORY
variable in direct path comparisons. In general this should be
avoided, because it might contain symbolic links. There happens to be
no issues with this here, however, because those tests use
$TRASH_DIRECTORY both for specifyin
The test helper functions test_gitcomp() and test_gitcomp_nl() leak
the $cur variable into the test environment. Since this variable has
a special role in the Bash completion script (it holds the word
currently being completed) it influences the behavior of most
completion functions and thus this
While preparing commits, three tests added newly created files to the
index using 'git add .', which added not only the files in question
but leftover test cruft from previous tests like the files 'expected'
and 'actual' as well. Luckily, this had no effect on the tests'
correctness.
Add only the
That "first argument is passed to __gitdir()" statement in particular
is not really helpful, and after this series it won't be the case
anyway.
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-completion.bash | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contr
Hi,
here is a big mixed bag of bugfixes, cleanups and optimizations mostly
related to how we find out the path to the repository and how we use
that path.
Noteworthier changes are the following:
- Patch 18 shuts up error messages from git commands. This is the
one I mentioned some days ag
In case the length of the buffer is zero, we do not need to call the
fwrite system call as a performance improvement.
Signed-off-by: Stefan Beller
---
This applies on top of v17 for origin/sb/submodule-parallel-update.
In case there are other reasons for origin/sb/submodule-parallel-update
Stefan Beller writes:
> This replaces origin/sb/submodule-parallel-update and applies on
> origin/sb/submodule-parallel-fetch.
This round, when applied directly on top of 62104ba1 (submodules:
allow parallel fetching, add tests and documentation, 2015-12-15),
seems to break 7400 (43, 45, 78) and
On Tue, Feb 23, 2016 at 5:25 AM, Mathias Nyman wrote:
> For recalling where a subtree came from; git-subtree operations 'add'
> and 'pull', when called with the parameter add this to the
> commit message:
> git-subtree-repo:
>
> Other operations that don't have the information, like
> 'merg
1 - 100 of 208 matches
Mail list logo
