Denton Liu writes:
> If commit.cleanup = scissors is specified, don't produce a scissors line
> if one already exists in the commit message.
It is good that you won't have two such lines in the end result, but
is this (1) hiding real problem under the rug? (2) losing information?
If the
On Wed, Nov 14, 2018 at 04:52:59PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > With this fix, the message becomes the following:
> >
> > Merge branch 'master' into new
> >
> > # >8
> > # Do not modify or remove the line
On Wed, Nov 14 2018, Stefan Beller wrote:
>> But maybe I'm being overly paranoid. What do those more familiar with
>> this think?
>
> I am not too worried,
> * as rebase is a main porcelain, that is even hard to use in a script.
> so any failures are not deep down in some automation,
> but
The rebase.useBuiltin variable introduced in 55071ea248 ("rebase:
start implementing it as a builtin", 2018-08-07) was turned on by
default in 5541bd5b8f ("rebase: default to using the builtin rebase",
2018-08-08), but had no documentation.
Let's document it so that users who run into any
Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
to running with rebase.useBuiltin=false. This is needed to spot that
we're not introducing any regressions in the legacy rebase version
while we're carrying both it and the new builtin version.
Signed-off-by: Ævar Arnfjörð
Matthieu Moy writes:
> "Junio C Hamano" wrote:
>
>> > Where 'topic' is a tracking branch of 'origin/master' (I use
>> > push.default=upstream). I only recently discovered that I could push to
>> > 'HEAD" to do the same thing. So one ulterior motive is to make that more
>> > prominent.
> [...]
Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
to running with rebase.useBuiltin=false. This is needed to spot that
we're not introducing any regressions in the legacy rebase version
while we're carrying both it and the new builtin version.
Signed-off-by: Ævar Arnfjörð
I was missing a "=" in the t/README docs in 2/2 in v1. Also move the
docs around slightly so this & my gettext series don't have conflicts.
*** BLURB HERE ***
Ævar Arnfjörð Bjarmason (2):
rebase doc: document rebase.useBuiltin
tests: add a special setup where rebase.useBuiltin is off
The rebase.useBuiltin variable introduced in 55071ea248 ("rebase:
start implementing it as a builtin", 2018-08-07) was turned on by
default in 5541bd5b8f ("rebase: default to using the builtin rebase",
2018-08-08), but had no documentation.
Let's document it so that users who run into any
Josh Steadmon writes:
> Fix several bugs identified in v3, clarify commit message, and clean up
> extern keyword in protocol.h.
It is good to descirbe the change relative to v3 here, which would
help those who are interested and reviewed v3.
To help those who missed the boat and v4 is their
cmd_clone() declares two strbufs 'key' and 'value' on the same line,
suggesting that they are used to contruct a config variable's name and
value. However, this is not the case: 'key' is used to construct the
names of multiple config variables, while 'value' is never used as a
value for any of
The initial fetch during a clone doesn't transfer refs matching
additional fetch refspecs given on the command line as configuration
variables, e.g. '-c remote.origin.fetch='. This contradicts
the documentation stating that configuration variables specified via
'git clone -c = ...' "take effect
Due to limitations in the current implementation, some configuration
variables specified via 'git clone -c var=val' (or 'git -c var=val
clone') are ignored during the initial fetch and checkout.
Let the users know which configuration variables are known to be
ignored ('remote.origin.mirror' and
The initial fetch during a clone doesn't transfer refs matching
additional fetch refspecs given on the command line as configuration
variables, e.g. '-c remote.origin.fetch='. This contradicts
the documentation stating that configuration variables specified via
'git clone -c = ...' "take effect
On Wed, Nov 14, 2018 at 11:44:51AM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> + if (tmp_allowed_versions[0] != config_version)
> >> + for (int i = 1; i < nr_allowed_versions; i++)
> >
> > We don't do C99 yet, thus the declaration of a loop variable like this
> > is not
On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
>
> On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
>
> > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > >
> > > Git Merge 2019 is happening on February 1st. There will be a
> > > Contributor's Summit the day before. Here are the
On Wed, Nov 14, 2018 at 12:31:22PM +, Luke Diamand wrote:
> On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
> >
> > On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
> >
> > > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > > >
> > > > Git Merge 2019 is happening on February
On Wed, Nov 14 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Add a new core.checkCollisions setting. On by default, it can be set
>> to 'false' to disable the check for existing objects in sha1_object().
>> ...
>> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
On Mon, Nov 12, 2018 at 05:48:37AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 832ede5099..1ea20dc2dc 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -51,7 +51,7 @@ export LSAN_OPTIONS
>
>
Nguyễn Thái Ngọc Duy writes:
> One of the problems with "git checkout" is that it does so many
> different things and could confuse people specially when we fail to
> handle ambiguation correctly.
You would have realized that this is way too noisy if you ran "make
test", which may have spewed
From: out0fmemory
---
INSTALL | 7 +++
1 file changed, 7 insertions(+)
diff --git a/INSTALL b/INSTALL
index c39006e8e7..b7bfb53c12 100644
--- a/INSTALL
+++ b/INSTALL
@@ -165,6 +165,9 @@ Issues of note:
use English. Under autoconf the configure script will do this
The command 'git ls-remote --sort=authordate ' segfaults when
run outside of a repository, ever since the introduction of its
'--sort' option in 1fb20dfd8e (ls-remote: create '--sort' option,
2018-04-09).
While in general the 'git ls-remote' command can be run outside of a
repository just fine,
On Wed, Nov 14, 2018 at 1:43 PM Martin Ågren wrote:
>
> On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
> wrote:
> > However, the `.lock` file was still open and on Windows that means
> > that it could not be deleted properly. This patch fixes that issue.
>
> Hmmm, doesn't the tempfile
From: out0fmemory
---
INSTALL | 7 +++
1 file changed, 7 insertions(+)
diff --git a/INSTALL b/INSTALL
index c39006e8e7..b7bfb53c12 100644
--- a/INSTALL
+++ b/INSTALL
@@ -165,6 +165,9 @@ Issues of note:
use English. Under autoconf the configure script will do this
Changes since v1:
*extend test to check whether git stash executes under valid ident
(and not under fallback one) when there is such present
*add prepare_fallback_ident() function to git-stash.sh to
provide fallback identity
Slavica Djukic (2):
The "git stash" command insists on having a usable user identity to
the same degree as the "git commit-tree" and "git commit" commands
do, because it uses the same codepath that creates commit objects
as these commands.
It is not strictly necesary to do so. Check if we will barf before
creating
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 1. Using multiple versions of Git on a single machine. For example,
>> some IDEs bundle a particular version of Git, which can be a
>> different version from the system copy, or on a Mac, /usr/bin/git
>> quickly goes out of sync
Hi Phillip,
On Mon, Nov 12, 2018 at 10:21 AM Phillip Wood wrote:
> >> -Flags only understood by the am backend:
> >> +The following options:
> >>
> >> * --committer-date-is-author-date
> >> * --ignore-date
> >> @@ -520,15 +512,12 @@ Flags only understood by the am backend:
> >> *
On Wed, Nov 14, 2018 at 11:17 AM SZEDER Gábor wrote:
> On Tue, Nov 13, 2018 at 04:25:53PM -0800, Elijah Newren wrote:
> > diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> > index af724e9937..b984a44224 100644
> > --- a/builtin/fast-export.c
> > +++ b/builtin/fast-export.c
> > @@
Hi,
Ben Peart wrote:
> There is no way to get multi-threaded reads and NOT get the scary message
> with older versions of git. Multi-threaded reads require the IEOT extension
> to be written into the index and the existence of the IEOT extension in the
> index will always generate the scary
I need am Honest Person to support and your cooperation with me in business of
$26,700,000.00 thanks.
Add test to document that stash fails if user.name and user.email
are not configured.
In the later commit, test will be updated to expect success.
Signed-off-by: Slavica Djukic
---
t/t3903-stash.sh | 23 +++
1 file changed, 23 insertions(+)
diff --git a/t/t3903-stash.sh
Hi Dscho,
On Mon, Nov 12, 2018 at 8:21 AM Johannes Schindelin
wrote:
> > t3425: topology linearization was inconsistent across flavors of rebase,
> > as already noted in a TODO comment in the testcase. This was not
> > considered a bug before, so getting a different
From: Stefan Xenos
This document describes what an obsolescence graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.
Signed-off-by: Stefan Xenos
---
Documentation/technical/evolve.txt | 885 +
1 file
On Wed, Nov 14, 2018 at 11:28 AM SZEDER Gábor wrote:
>
> On Tue, Nov 13, 2018 at 04:25:57PM -0800, Elijah Newren wrote:
> > diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> > index 2fef00436b..3cc98c31ad 100644
> > --- a/builtin/fast-export.c
> > +++ b/builtin/fast-export.c
> > @@
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > We really only need the test helpers in that case, but that is not what
> > we test for. So let's skip the test for now when we know that we want to
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/Makefile b/Makefile
> > index bbfbb4292d..5df0118ce9 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2590,6 +2590,7 @@ GIT-BUILD-OPTIONS: FORCE
> > @echo
Hi Ævar,
On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Nov 14 2018, Stefan Beller wrote:
>
> >> But maybe I'm being overly paranoid. What do those more familiar with
> >> this think?
> >
> > I am not too worried,
> > * as rebase is a main porcelain, that is even hard to use in a
Hi Peff,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Tue, Nov 13, 2018 at 04:38:24AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > Phillip Wood reported a problem where the built-in rebase did not understand
> > options like -C1, i.e. it did not expect the option argument.
> >
> >
Hi Ævar,
On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> The rebase.useBuiltin variable introduced in 55071ea248 ("rebase:
> start implementing it as a builtin", 2018-08-07) was turned on by
> default in 5541bd5b8f ("rebase: default to using the builtin rebase",
> 2018-08-08), but had no
Hi Phillip,
On Tue, 13 Nov 2018, Phillip Wood wrote:
> On 13/11/2018 19:21, Johannes Schindelin wrote:
> > Hi Phillip,
> >
> > On Tue, 13 Nov 2018, Phillip Wood wrote:
> >
> > > Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to
> > > break the error reporting
> > >
> >
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > It really makes very, very little sense to use a different git
> > executable than the one the caller indicated via setting the environment
> >
Hi Peff,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Mon, Nov 12, 2018 at 05:48:37AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 832ede5099..1ea20dc2dc 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -51,7 +51,7
Hi Ævar,
On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
> to running with rebase.useBuiltin=false. This is needed to spot that
> we're not introducing any regressions in the legacy rebase version
> while we're carrying
Back when bw/config-h was developed (and backported to Git for Windows), I
came up with a patch to use git_dir if commondir is NULL, and contributed
that as v1 of this patch. However, it was deemed a bug if that happens, so
let's instead detect that condition and report it.
Change since v1:
*
From: Johannes Schindelin
This did happen at some stage, and was fixed relatively quickly. Make
sure that we detect very quickly, too, should that happen again.
Signed-off-by: Johannes Schindelin
---
config.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.c b/config.c
index
On Wed, Nov 14 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
>> to running with rebase.useBuiltin=false. This is needed to spot that
>> we're not introducing any
Hi,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Agreed. I'm happy to see the test for-loop gone as I noted in
> > https://public-inbox.org/git/87d0rm7zeo@evledraar.gmail.com/ but as
> > noted in that v3 feedback the whole "why would anyone want this?"
+bmwill
On 2018-11-14, Michael Forney wrote:
> On 2018-10-25, Stefan Beller wrote:
>> I guess reverting that commit is not a good idea now, as
>> I would expect something to break.
>>
>> Maybe looking through the series 614ea03a71
>> (Merge branch 'bw/submodule-config-cleanup', 2017-08-26)
>>
On Wed, Nov 14, 2018 at 02:08:48PM -0800, Stefan Beller wrote:
> On Wed, Nov 14, 2018 at 1:43 PM Martin Ågren wrote:
> >
> > On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
> > wrote:
> > > However, the `.lock` file was still open and on Windows that means
> > > that it could not be
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
8:28:31 AM
On 2018-10-25, Stefan Beller wrote:
> On Thu, Oct 25, 2018 at 11:03 AM Michael Forney
> wrote:
>>
>> On 2018-03-16, Michael Forney wrote:
>> > Hi,
>> >
>> > In the past few months have noticed some confusing behavior with
>> > ignored submodules. I finally got around to bisecting this to commit
Hi!
yanke131...@gmail.com wrote:
> From: out0fmemory
>
> ---
> INSTALL | 7 +++
> 1 file changed, 7 insertions(+)
Thanks for writing. A few bits of administrivia, from
https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html:
Can we forge your sign-off? See the section
USLUGI REPETITORA 1-7 klass.
Nizkie ceni
10:58:04 AM
Hi Stefan,
On Tue, 13 Nov 2018, Stefan Beller wrote:
> On Tue, Nov 13, 2018 at 12:33 PM Gaël Lhez wrote:
> >
> > Hello,
> >
> > I don't know why I receive these message (and especially now given the time
> > at which I pushed this) but I suppose someone (Johannes Schindelin ?)
> > probably
On Wed, Nov 14, 2018 at 11:12 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > One of the problems with "git checkout" is that it does so many
> > different things and could confuse people specially when we fail to
> > handle ambiguation correctly.
>
> You would have realized
All config extensions are described in technical/repository-version.txt.
I made a mistake of adding it in config.txt instead. This patch moves
it back to where it belongs.
Since repository-version.txt is not part of officially generated
documents (it's not even part of DOC_HTML target), it's only
Johannes Schindelin writes:
>> The latter half of this change is a good one. Given what the
>> proposed log message of this patch says
>>
>> Note also: the many, many calls to `git this` and `git that` are
>> unaffected, as the regular PATH search will find the `.exe` files on
>>
Johannes Schindelin writes:
> It would make sense, but we don't know how to get that information, do we?
> ...
> And changing the code *now* to let us query Git where it thinks its
> templates should be won't work, as this patch is about using the installed
> Git (at whatever pre-compiled
And yet another patch coming through Git for Windows...
Change since v1:
* Using a better oneline now.
Gaël Lhez (1):
bundle: cleanup lock files on error
bundle.c| 7 ---
t/t5607-clone-bundle.sh | 4
2 files changed, 8 insertions(+), 3 deletions(-)
base-commit:
From: =?UTF-8?q?Ga=C3=ABl=20Lhez?=
When an user tries to create an empty bundle via `git bundle create
` where `` resolves to an empty list (for
example, like `master..master`), the command fails and warns the user
about how it does not want to create empty bundle.
However, the `.lock` file
Hi Ævar,
On Tue, 13 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Trivial updates since v4 addressing the feedback on that
> iteration. Hopefully this is the last one, range-diff with the last
> version:
This range-diff looks good to me.
Thanks,
Dscho
>
> 1: 5399e57513 = 1: f225173f43
Phillip Wood reported a problem where the built-in rebase did not understand
options like -C1, i.e. it did not expect the option argument.
While investigating how to address this best, I stumbled upon
OPT_PASSTHRU_ARGV (which I was so far happily unaware of).
Instead of just fixing the -C bug,
From: Johannes Schindelin
Currently, we parse the options intended for `git am` as if we wanted to
handle them in `git rebase`, and then reconstruct them painstakingly to
define the `git_am_opt` variable.
However, there is a much better way (that I was unaware of, at the time
when I mentored
From: Johannes Schindelin
It is a good idea to error out early upon seeing, say, `-Cbad`, rather
than starting the rebase only to have the `--am` backend complain later.
Let's do this.
The only options accepting parameters which we pass through to `git am`
(which may, or may not, forward them
From: Johannes Schindelin
We really only need the test helpers to be built in the worktree in that
case, but that is not what we test for.
On the other hand it is a perfect opportunity to verify that
`GIT_TEST_INSTALLED` points to a working Git.
So let's test the appropriate Git executable.
From: Johannes Schindelin
On Windows, when we refer to `/an/absolute/path/to/git`, it magically
resolves `git.exe` at that location. Except if something of the name
`git` exists next to that `git.exe`. So if we call `$BUILD_DIR/git`, it
will find `$BUILD_DIR/git.exe` *only* if there is not, say,
From: Johannes Schindelin
It makes very, very little sense to test the built git-sh-i18n when the
user asked specifically to test another one.
Signed-off-by: Johannes Schindelin
---
t/lib-gettext.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/lib-gettext.sh
From: Johannes Schindelin
It really makes very, very little sense to use a different git
executable than the one the caller indicated via setting the environment
variable GIT_TEST_INSTALLED.
Signed-off-by: Johannes Schindelin
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2
By setting the GIT_TEST_INSTALLED variable to the path of an installed Git
executable, it is possible to run the test suite also on a specific
installed version (as opposed to a version built from scratch).
The only thing this needs that is unlikely to be installed is the test
helper(s).
From: Johannes Schindelin
We really need to be able to find the test helpers... Really. This
change was forgotten when we moved the test helpers into t/helper/
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Johannes
Thanks for doing this, I think this patch is good. I've not checked the
first patch as I think it is the same as before judging from the
covering letter.
Best Wishes
Phillip
On 14/11/2018 16:25, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
It is a
On Tue, Nov 13, 2018 at 04:25:53PM -0800, Elijah Newren wrote:
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index af724e9937..b984a44224 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -774,9 +774,12 @@ static void handle_tag(const char *name, struct tag
On Tue, Nov 13, 2018 at 04:25:57PM -0800, Elijah Newren wrote:
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 2fef00436b..3cc98c31ad 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -37,6 +37,7 @@ static int fake_missing_tagger;
> static int
OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in
CFLAGS causes lots of build warnings. Using separate FUZZ_CXXFLAGS
avoids this.
Signed-off-by: Josh Steadmon
---
Since there's nothing else using CXXFLAGS, let's just make it explicit
that these apply to the fuzzers.
On 2018.11.14 19:22, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > Fix several bugs identified in v3, clarify commit message, and clean up
> > extern keyword in protocol.h.
>
> It is good to descirbe the change relative to v3 here, which would
> help those who are interested and reviewed
On 2018.11.14 11:38, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > On 2018.11.13 13:01, Junio C Hamano wrote:
> >> I am wondering if the code added by this patch outside this
> >> function, with if (strcmp(client_ad.buf, "version=0") sprinkled all
> >> over the place, works sensibly when
On Wed, Nov 14, 2018 at 05:06:32PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > If commit.cleanup = scissors is specified, don't produce a scissors line
> > if one already exists in the commit message.
>
> It is good that you won't have two such lines in the end result, but
> is this
On 11/13/2018 10:24 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
We cannot change the past, but for index extensions of the future,
there is a straightforward improvement: silence that message except
when tracing. This way, the message is still available when
debugging, but in
Am 13.11.2018 um 11:02 schrieb Ævar Arnfjörð Bjarmason:
> So here's the same test not against NFS, but the local ext4 fs (CO7;
> Linux 3.10) for sha1collisiondetection.git:
>
> Test origin/master
> peff/jk/loose-cache
On 11/13/2018 4:08 PM, Jonathan Nieder wrote:
Hi again,
Ben Peart wrote:
On 11/13/2018 1:18 PM, Jonathan Nieder wrote:
Ben Peart wrote:
Why introduce a new setting to disable writing the IEOT extension instead of
just using the existing index.threads setting? If index.threads=1 then
Hi Phillip,
On Wed, 14 Nov 2018, Phillip Wood wrote:
> Thanks for doing this, I think this patch is good.
Thanks!
> I've not checked the first patch as I think it is the same as before
> judging from the covering letter.
Indeed, that's what the range-diff said. Sorry for not stating this
On Wed, Nov 14, 2018 at 02:16:37PM +0100, Johannes Schindelin wrote:
> > Makes perfect sense. Shouldn't we be asking where the template
> > directory of the installed version is and using it instead of the
> > freshly built one, no?
>
> It would make sense, but we don't know how to get that
On Wed, Nov 14, 2018 at 05:59:02AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> This did happen at some stage, and was fixed relatively quickly. Make
> sure that we detect very quickly, too, should that happen again.
>
> Signed-off-by: Johannes Schindelin
On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
wrote:
> However, the `.lock` file was still open and on Windows that means
> that it could not be deleted properly. This patch fixes that issue.
Hmmm, doesn't the tempfile machinery remove the lock file when we die?
> ref_count =
85 matches
Mail list logo
