Hey,
Today I've spent a few hours to understand why git-completion doesn't work
in my zsh shell. It was because I thought ~/.zsh/_git should be a dictionary
with git-completion.zsh file.
I think this change may save some hours for someone else.
Maxim Belsky (1):
doc: Change zsh git completion
Hey,
Today I've spent a few hours to understand why git-completion doesn't work
in my zsh shell. It was because I thought ~/.zsh/_git should be a dictionary
with git-completion.zsh file.
I think this change may save some hours for someone else.
Maxim Belsky (1):
doc: Change zsh git completion
Hey,
Today I've spent a few hours to understand why git-completion doesn't work
in my zsh shell. It was because I thought ~/.zsh/_git should be a dictionary
with git-completion.zsh file.
I think this change may save some hours for someone else.
Maxim Belsky (1):
doc: Change zsh git completion
expense of runtime performance, which is usually the opposite of
someone who'd like "aggressive gc" wants.
But that's left us with a mostly-redundant configuration variable, so
let's clearly note in its documentation that it doesn't change the
default.
Amend the "PACKFILE OPTIMIZATION" section in "fast-import" to explain
that simply running "git gc --aggressive" after a "fast-import" should
properly optimize the repository. This is simpler and more effective
than the existing "repack" advice (which I'm keeping as it helps
explain things) because
expense of runtime performance, which is usually the opposite of
someone who'd like "aggressive gc" wants.
But that's left us with a mostly-redundant configuration variable, so
let's clearly note in its documentation that it doesn't change the
default.
Amend the "PACKFILE OPTIMIZATION" section in "fast-import" to explain
that simply running "git gc --aggressive" after a "fast-import" should
properly optimize the repository. This is simpler and more effective
than the existing "repack" advice (which I'm keeping as it helps
explain things) because
Amend the "PACKFILE OPTIMIZATION" section in "fast-import" to explain
that simply running "git gc --aggressive" after a "fast-import" should
properly optimize the repository. This is simpler and more effective
than the existing "repack" advice (which I'm keeping as it helps
explain things) because
expense of runtime performance, which is usually the opposite of
someone who'd like "aggressive gc" wants.
But that's left us with a mostly-redundant configuration variable, so
let's clearly note in its documentation that it doesn't change the
default.
On Wed, Mar 20, 2019 at 7:58 AM Duy Nguyen wrote:
>
> On Wed, Mar 20, 2019 at 8:53 PM Elijah Newren wrote:
> > So, I think we do need something (eventually at least). Would you
> > prefer we dropped this patch from Duy and instead made 'checkout -m'
> > abort when the index is dirty?
>
> I have
Elijah Newren writes:
> On Tue, Mar 19, 2019 at 7:50 PM Junio C Hamano wrote:
>>
>> Duy Nguyen writes:
>>
>> > Kinda. But "--force --merge" makes no sense. --force discards all
>> > local changes by definition, which means you can't have conflicts and
>> > will not need --merge. I think this is
On Wed, Mar 20, 2019 at 8:53 PM Elijah Newren wrote:
> So, I think we do need something (eventually at least). Would you
> prefer we dropped this patch from Duy and instead made 'checkout -m'
> abort when the index is dirty?
I have no problem with this. Still scratching my head wondering if
t720
On Tue, Mar 19, 2019 at 7:50 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > Kinda. But "--force --merge" makes no sense. --force discards all
> > local changes by definition, which means you can't have conflicts and
> > will not need --merge. I think this is the reason why we die() out
> >
Duy Nguyen writes:
> Kinda. But "--force --merge" makes no sense. --force discards all
> local changes by definition, which means you can't have conflicts and
> will not need --merge. I think this is the reason why we die() out
> when both are specified. So we need something like
> --discard-stag
On Wed, Mar 20, 2019 at 8:19 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> I think "checkout -m " with a dirty index should refuse
> >> to run; there is nothing to "continue" after such a failure, so I am
> >> not sure what you mean by "an option to continue" (iow, I do not see
> >> a ne
Duy Nguyen writes:
>> I think "checkout -m " with a dirty index should refuse
>> to run; there is nothing to "continue" after such a failure, so I am
>> not sure what you mean by "an option to continue" (iow, I do not see
>> a need for such an option, and if that option makes the whole notion
>>
On Wed, Mar 20, 2019 at 7:24 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > If you have staged changes in path A and perform 'checkout
> > --merge' (which could result in conflicts in a totally unrelated path
> > B), changes in A will be gone. Which is unexpected. We are suppose
Nguyễn Thái Ngọc Duy writes:
> If you have staged changes in path A and perform 'checkout
> --merge' (which could result in conflicts in a totally unrelated path
> B), changes in A will be gone. Which is unexpected. We are supposed
> to keep all changes, or kick and scream otherwise.
>
> This is
ue
--merge is very weird. Such an option would keep worktree changes, but
drop staged changes.
Because the problem has been with us since the introduction of --merge
and everybody has been pretty happy (except Phillip, who found this
problem), I'll just take a note here to acknowledge it and
ee changes, but
drop staged changes.
Because the problem has been with us since the introduction of --merge
and everybody has been pretty happy (except Phillip, who found this
problem), I'll just take a note here to acknowledge it and wait for
merge wizards to come in and work their magic. The
Poking this thread before it goes completely dead...
On Sat, Mar 2, 2019 at 12:34 AM Todd Zullinger wrote:
>
> The completion.commands config var must be set in either the system-wide
> or global config file. The completion script does not read a local
> repository config.
After the last discus
Jeff King writes:
> On Wed, Mar 06, 2019 at 03:52:38PM -0800, Taylor Blau wrote:
>
>> In 63e2a0f8e9 (builtin/config: introduce `color` type specifier,
>> 2018-04-09), `--type=color` was introduced and preferred to the
>> old-style `--get-color`.
>>
>> The two behave the same in almost every way,
On Wed, Mar 06, 2019 at 03:52:38PM -0800, Taylor Blau wrote:
> In 63e2a0f8e9 (builtin/config: introduce `color` type specifier,
> 2018-04-09), `--type=color` was introduced and preferred to the
> old-style `--get-color`.
>
> The two behave the same in almost every way, save for the fact that
> `-
d, if
there is no color configured for `name`.
+
-`--type=color [--default=]` is preferred over `--get-color`.
+`--type=color [--default=]` is preferred over `--get-color`
+(but note that `--get-color` will omit the trailing newline printed by
+`--type=color`).
-e::
--edit::
--
2.20.1
The completion.commands config var must be set in either the system-wide
or global config file. The completion script does not read a local
repository config.
Signed-off-by: Todd Zullinger
---
Documentation/config/completion.txt | 3 ++-
Documentation/git.txt | 3 ++-
2 files chan
ly part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.
The two branches "master" and "maint" are never rewound, and "next"
u
gt;> probably should have also been updated to note the stronger
>> incompatibility between git-am and directory rename detection. Update
>> it now.
>>
>> Signed-off-by: Elijah Newren
>> Signed-off-by: Johannes Sixt
>> ---
>> Documentation/git-r
On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>
> From: Elijah Newren
>
> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
> probably should have also been
From: Elijah Newren
In commit 6aba117d5cf7 ("am: avoid directory rename detection when
calling recursive merge machinery", 2018-08-29), the git-rebase manpage
probably should have also been updated to note the stronger
incompatibility between git-am and directory rename detection.
Filter is added in [2], it's
> added in between the two paragraphs. This makes the "this is non-repo
> level config" note incorrectly apply to allowFilter instead of
> packObjectsHook. Move allowFilter paragraph down to fix this.
Nice catch, and the patch looks obviously correct. Thanks.
-Peff
s non-repo
level config" note incorrectly apply to allowFilter instead of
packObjectsHook. Move allowFilter paragraph down to fix this.
[1] 20b20a22f8 (upload-pack: provide a hook for running pack-objects -
2016-05-18)
[2] 10ac85c785 (upload-pack: add object filtering for partial clone -
Hi Taylor,
On Wed, 19 Sep 2018 at 19:21, Taylor Blau wrote:
> I could take or leave 2/2, since I usually write ", (see: above)", but
> I'm not sure if that's grammatically correct or not.
Well, I sure ain't no grammar expert too... This is not a patch I feel
strongly about, so I'll be happy to d
Hi Martin,
On Wed, Sep 19, 2018 at 06:38:19PM +0200, Martin Ågren wrote:
> Rather than saying "(see: above)", drop the colon. Also drop the comma
> before this note.
>
> Signed-off-by: Martin Ågren
Thanks for both of these. I should have at least taken care of 1/2
myself,
Rather than saying "(see: above)", drop the colon. Also drop the comma
before this note.
Signed-off-by: Martin Ågren
---
Documentation/git-config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config
a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -211,6 +211,12 @@ would conflict the same way as the test merge you resolved
earlier.
'git rerere' will be run by 'git rebase' to help you resolve this
conflict.
+[NOTE] 'git rerere' relies on the conflic
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index f9efee0836..c07a6cd646 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1552,6 +1552,17 @@ static int verify_uptodate_sparse(const stru
have been worthy
of including in this changelog (but weren't). Instead of amending it
to include these, just note that future changes will be noted in the
log.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/technical/hash-function-transition.txt | 6 ++
1 file changed, 6 inse
as the
> abbreviated object name, use +1 digits. Note that 1 column
> is used for a caret to mark the boundary commit.
This is outside the scope of this patch, but is the above 7+1 still
current or do we need updating it for the (not so) recent change to
auto-scale the default ab
ecimal digits as the
abbreviated object name, use +1 digits. Note that 1 column
is used for a caret to mark the boundary commit.
++
+Because of this UI design, the only way to get the full SHA-1 of the
+boundary commit is to use the `--porcelain` format. With `--abbrev=40`
+only 39 characters of the
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const stru
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const stru
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const stru
Signed-off-by: Nguyễn Thái Ngọc Duy
---
unpack-trees.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/unpack-trees.c b/unpack-trees.c
index 3a85a02a77..5d06aa9c98 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1545,6 +1545,17 @@ static int verify_uptodate_sparse(const stru
Elijah Newren writes:
> In the 2.18 cycle, directory rename detection was merged, then reverted,
> then reworked in such a way to fix another prominent bug in addition to
> the original problem causing it to be reverted. When the reworked series
> was merged, we ended up with two nearly duplicat
On 05/30, brian m. carlson wrote:
> On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote:
> > Add a mention of the security mailing list to the README, and to
> > Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
> > git-secur...@googlegroups
In the 2.18 cycle, directory rename detection was merged, then reverted,
then reworked in such a way to fix another prominent bug in addition to
the original problem causing it to be reverted. When the reworked series
was merged, we ended up with two nearly duplicate release notes. Remove
the sec
On Wed, May 30, 2018 at 09:52:55PM +0100, Thomas Gummerer wrote:
> Add a mention of the security mailing list to the README, and to
> Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
> git-secur...@googlegroups.com", 2018-03-08) already added it to the
Add a mention of the security mailing list to the README, and to
Documentation/SubmittingPatches.. 2caa7b8d27 ("git manpage: note
git-secur...@googlegroups.com", 2018-03-08) already added it to the
man page, but for developers either the README, or the documentation
on how to
Thomas Gummerer wrote:
> Add a mention of the security mailing list to the README.
> 2caa7b8d27 ("git manpage: note git-secur...@googlegroups.com",
> 2018-03-08) already added it to the man page, but I suspect that for
> many developers, such as myself, the README would be t
Add a mention of the security mailing list to the README.
2caa7b8d27 ("git manpage: note git-secur...@googlegroups.com",
2018-03-08) already added it to the man page, but I suspect that for
many developers, such as myself, the README would be the first place
to go looking for it.
Us
This is another candidate for commit-slab. Keep Junio's observation in
code so we can search it later on when somebody wants to improve the
code.
---
builtin/show-branch.c | 5 +
object.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/builtin/show-branch.c b/builtin/show-br
/revisions.txt
@@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The
ones listed near the end of this list name trees and
blobs contained in a commit.
+NOTE: This document shows the "raw" syntax as seen by git. The shell
+and other UIs might require additional
Am 27.04.2018 um 19:36 schrieb Eric Sunshine:
> On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote:
>> Signed-off-by: Andreas Heiduk
>> Reviewed-by: Junio C Hamano
>> ---
>> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
>> @@ -186,6 +190,8 @@ existing tag object.
>> +
On Fri, Apr 27, 2018 at 1:04 PM, Andreas Heiduk wrote:
> Signed-off-by: Andreas Heiduk
> Reviewed-by: Junio C Hamano
> ---
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> @@ -186,6 +190,8 @@ existing tag object.
> + Depending on the given text the shell's word splitti
/revisions.txt
@@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The
ones listed near the end of this list name trees and
blobs contained in a commit.
+NOTE: This document shows the "raw" syntax as seen by git. The shell
+and other UIs might require additional
on/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -7,6 +7,10 @@ syntax. Here are various ways to spell object names. The
> ones listed near the end of this list name trees and
> blobs contained in a commit.
>
> +NOTE: This document shows the "raw" syntax as s
@@ syntax. Here are various ways to spell object names. The
ones listed near the end of this list name trees and
blobs contained in a commit.
+NOTE: This document shows the "raw" syntax as seen by git. The shell
+and other UIs might require additional quoting to protect special
+char
Ævar Arnfjörð Bjarmason writes:
> Add a mention of the security mailing list to the "Reporting Bugs"
> section. There's a mention of this list at
> https://git-scm.com/community but none in git.git itself.
This is quite a sensible thing to do.
>
> The copy is pasted from the git-scm.com websit
Add a mention of the security mailing list to the "Reporting Bugs"
section. There's a mention of this list at
https://git-scm.com/community but none in git.git itself.
The copy is pasted from the git-scm.com website. Let's use the same
wording in both places.
Signed-off-by: Ævar Arnfjörð Bjarmaso
; /* note: spare bits available! */
unsigned type:TYPE_BITS;
unsigned in_pack_type:TYPE_BITS; /* could be delta */
unsigned preferred_base:1; /*
--
2.16.2.873.g32ff258c87
; /* note: spare bits available! */
unsigned type:TYPE_BITS;
unsigned in_pack_type:TYPE_BITS; /* could be delta */
unsigned preferred_base:1; /*
--
2.16.1.435.g8f24da2e1a
; /* note: spare bits available! */
unsigned type:TYPE_BITS;
unsigned in_pack_type:TYPE_BITS; /* could be delta */
unsigned preferred_base:1; /*
--
2.16.1.435.g8f24da2e1a
te with '-x' without
needing a Bash version supporting BASH_XTRACEFD, remove the now
outdated caution note about non-Bash shells from the description of
the '-x' option.
Signed-off-by: SZEDER Gábor
---
t/README | 20 +---
1 file changed, 17 insertions(+), 3
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Will queue with the above typofix, together with the other one. I
>>> am not sure if we want to say "Before 2.17", though.
>>
>> I'm just keeping in mind the user who later on upgrades git from say
>> 2.14 to 2
Ævar Arnfjörð Bjarmason writes:
>> Will queue with the above typofix, together with the other one. I
>> am not sure if we want to say "Before 2.17", though.
>
> I'm just keeping in mind the user who later on upgrades git from say
> 2.14 to 2.18 or something, and is able to find in the docs when/
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> +Before 2.17, the untracked cache had a bug where replacing a directory
>> +with a symlink to another directory could cause it to incorrectly show
>> +files tracked by git as untracked. See the "status: add a fa
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> When users upgrade to 2.17 they're going to have git yelling at them
>> (as my users did) on existing checkouts, with no indication whatsoever
>> that it's due to the UC or how to fix it.
>
> Wait. Are you sayi
Ævar Arnfjörð Bjarmason writes:
> +Before 2.17, the untracked cache had a bug where replacing a directory
> +with a symlink to another directory could cause it to incorrectly show
> +files tracked by git as untracked. See the "status: add a failing test
> +showing a core.untrackedCache bug" comm
Ævar Arnfjörð Bjarmason writes:
> When users upgrade to 2.17 they're going to have git yelling at them
> (as my users did) on existing checkouts, with no indication whatsoever
> that it's due to the UC or how to fix it.
Wait. Are you saying that the new warning is "warning" against a
condition
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it
ilar ones when a newer iteration of the
> feature introduces, no?
Fair enough. I just wanted to make sure it had been seen. It wasn't
obvious whether it had just been missed since there was no follow-up
there or note in WC.
We were disagreeing to the extent that some of this should be
docum
Note the caveat where 2.17 is stricter about index validation
potentially causing "could not open directory" warnings when git is
upgraded. See the preceding "dir.c: stop ignoring opendir() error in
open_cached_dir()" change.
This caused some mayhem when I upgraded git to
From: Ævar Arnfjörð Bjarmason
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, an
--
Greetings,
Can you handle a transaction that involves the transfer of fund valued
15 million Euros into a foreign account. I will give you the full
detailed information as soon as I hear from you. Send me the
followings if you are willing and ready to work with me.
1)Full Names (2)Occupation (
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it
Ævar Arnfjörð Bjarmason writes:
> Document the bug tested for in my "status: add a failing test showing
> a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
> invalidation in untracked code".
>
> Since this is very likely something others will encounter in the
> future on olde
Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".
Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it
and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
A natural consequence of how "next&q
r notation 'r1\...r2' is called symmetric difference
> of 'r1' and 'r2' and is defined as
> 'r1 r2 --not $(git merge-base --all r1 r2)'.
> @@ -285,6 +285,15 @@ is a shorthand for 'HEAD..origin' and asks "What did the
> origin d
as
'r1 r2 --not $(git merge-base --all r1 r2)'.
@@ -285,6 +285,15 @@ is a shorthand for 'HEAD..origin' and asks "What did the
origin do since
I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an
empty range that is both reach
ng quietly dropped, and it caused more than just
minor frustration.
Maybe mention this in your maintainer's note, to help stave off such
problems?
Ciao,
Dscho
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
BCEAO BANK TOGO has agreed to wire USD$ 7,500.000.00,get in touch with
me by my private email immediately: (myemailcham...@gmail.com)for more
details
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
has
acquired a lock and didn't get around to releasing it before the fork.
This leaves the lock in a locked state in the resulting process with no
hope of it ever being released.
Add a note describing this potential pitfall before the call to 'fork()'
so people working in this section
has
acquired a lock and didn't get around to releasing it before the fork.
This leaves the lock in a locked state in the resulting process with no
hope of it ever being released.
Add a note describing this potential pitfall before the call to 'fork()'
so people working in this section
has
acquired a lock and didn't get around to releasing it before the fork.
This leaves the lock in a locked state in the resulting process with no
hope of it ever being released.
Add a note describing this potential pitfall before the call to 'fork()'
so people working in this section
has
acquired a lock and didn't get around to releasing it before the fork.
This leaves the lock in a locked state in the resulting process with no
hope of it ever being released.
Add a note describing this potential pitfall before the call to 'fork()'
so people working in this section
has
acquired a lock and didn't get around to releasing it before the fork.
This leaves the lock in a locked state in the resulting process with no
hope of it ever being released.
Add a note describing this potential pitfall before the call to 'fork()'
so people working in this section
Brandon Williams wrote:
> On 04/11, Eric Wong wrote:
> > On the other hand, I believe we should make run-command
> > vfork-compatible (and Brandon's series is a big (but incomplete)
> > step in the (IMHO) right direction); as anything which is
> > vfork-safe would also be safe in the presence of t
On 04/11, Eric Wong wrote:
> Jonathan Nieder wrote:
> > Why can't git use e.g. posix_spawn to avoid this?
>
> posix_spawn does not support chdir, and it seems we run non-git
> commands so no using "git -C" for those.
This is actually the biggest reason why I didn't go down that route from
the st
Eric Wong wrote:
> Jonathan Nieder wrote:
>> Why can't git use e.g. posix_spawn to avoid this?
>
> posix_spawn does not support chdir, and it seems we run non-git
> commands so no using "git -C" for those.
On the other hand, a number of the non-git commands we run are in a
shell. At the cost of
Jonathan Nieder wrote:
> Hi,
>
> Brandon Williams wrote:
>
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd)
> > argv_array_pushv(&argv, cmd->argv);
> > }
>
Hi,
Brandon Williams wrote:
> --- a/run-command.c
> +++ b/run-command.c
> @@ -458,6 +458,14 @@ int start_command(struct child_process *cmd)
> argv_array_pushv(&argv, cmd->argv);
> }
>
> + /*
> + * NOTE: In order to prevent deadloc
and.c
@@ -458,6 +458,14 @@ int start_command(struct child_process *cmd)
argv_array_pushv(&argv, cmd->argv);
}
+ /*
+ * NOTE: In order to prevent deadlocking when using threads special
+* care should be taken with the function calls made in
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.h | 4 ++--
t/t1405-main-ref-store.sh | 6 ++
t/t1406-submodule-ref-store.sh | 6 ++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/refs.h b/refs.h
index 1a07f9d86f..49e97d7d5f 100644
--- a/refs.h
+
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn
1 - 100 of 309 matches
Mail list logo
