On Wed, Oct 23, 2019 at 07:22:12AM +, Aleksey Mikhaylov wrote:
> "Could not access submodule" error when pulling recursively with Git 2.22.0.
> This issue causes if there is submodule in submodule.
> Please use my simple test repository to reproduce the problem:
&
PROBLEM DESCRIPTION
"Could not access submodule" error when pulling recursively with Git 2.22.0.
This issue causes if there is submodule in submodule.
At first, we reported this problem for Git for Windows:
https://github.com/git-for-windows/git/issues/2361
But we received the answer t
sing). And most don't, leading to segfault
fixes like the one in c77722b3ea (use get_tagged_oid(), 2019-09-05).
Let's address this more centrally, by returning an error code from the
parse itself, which most callers would already notice (adventurous
callers are free to ignore the error an
_hash_algo->hexsz + 7;
+ struct tree *tree;
if (item->object.parsed)
return 0;
@@ -412,7 +413,12 @@ int parse_commit_buffer(struct repository *r, struct
commit *item, const void *b
if (get_oid_hex(bufptr + 5, &parent) < 0
While parsing the parents of a commit, if we are able to parse an actual
oid but lookup_commit() fails on it (because we previously saw it in
this process as a different object type), we silently omit the parent
and do not report any error to the caller.
The caller has no way of knowing this
> restrictions that match no path.
But why erroring out only on completely empty tree? Why not requiring that
_every_ line in .git/info/sparse-checkout should match at least one file?
Would make no sense, right?
> We can at least give an error in that case.
Why must this be a fatal error? W
nshallow" results in:
fatal: error in object: unshallow
Re-packing with "git repack -d" sorts it all out, but my question is: is this
a bug, or is it instead down to something like the server-side version of
git that created the pack being outdated or similar?
Cheers,
Francis
[1]
gt;
>( cd $WD
> mkdir -p path/of/file/which/I/want/to
> echo huhuh >path/of/file/which/I/want/to/create
> git --work-tree $WD --git-dir $GD add path/of/file/which/I/want/to/create
> git --work-tree $WD --git-dir $GD commit
> git --work-tree $WD --g
rked command errors out with
"error: Sparse checkout leaves no entry on working directory"
and won't create/switch to the branch that is to be modified.
Why is this an error? Since there are no matching files, an empty worktree
is EXACTLY what I wanted. Why will the "git ch
g this as a bug
instead of providing a patch is probably just as "lame"... :-)
> can we get an absolute path on this message in future git versions, eg:
>
> Not a git repository (or any of the parent directories): /home/ubuntu/xyz/.git
Just clone https://github.com/git/git
when running git commands outside of a git repo, we often see:
fatal: Not a git repository (or any of the parent directories): .git
such a lame message lol.
can we get an absolute path on this message in future git versions, eg:
Not a git repository (or any of the parent directories): /home/ubun
From: Arash Bannazadeh-Mahani
The change is stemmed from a problem on the MacOS where, if --all
is passed to gitk it should show all the refs/commits graphically.
However, on really large git repos, in my instance a git repo with
over 52,000 commits, gitk will report an error,
"Error exec
gitk: no need to specify all refs, since git log --all is the same as list
is all the refs/commit ids. Also Mac OS has a limit on size of the list of
params for a command line
Arash Bannazadeh-Mahani (1):
gitk: Addressing error running on MacOS with large repos.
gitk-git/gitk | 7 ++-
1
pcpq-9fvw1lnocqkrfsof4bpj3gjd9+en43ve...@mail.gmail.com/
but there are many cases to audit, so for now just make sure we handle
both cases with and without a trailing slash.
The reason the code worked despite this sometimes-off-by-one error was
that the subsequent code immediately checked wheth
Denton Liu writes:
> Break `--default` and `--branch` into their own separate invocations to
> make it obvious that these options are mutually exclusive.
That sounds even clearer than what the original wanted to do. Very
good idea.
> diff --git a/Documentation/git-submodule.txt b/Documentation
t-submodule.txt: fix AsciiDoc formatting error
@@ Commit message
instead of
-set-branch (-d|--default)|(-b|--branch ) [--]
+set-branch ((-d|--default)|(-b|--branch )) [--]
-Remove surrounding parentheses so that the "inde
From: Jon Simons
The sparse:oid filter has two error modes: we might fail to resolve the
name to an OID, or we might fail to parse the contents of that OID. In
the latter case, let's give a less generic error message, and mention
the OID we did find.
While we're here, let's
Denton Liu writes:
>> > -set-branch ((-d|--default)|(-b|--branch )) [--] ::
>>
>> I say "almost", as it gives a wrong impression that you can give
>> "-b" without "" X-<.
>>
>> Now what does the updated text say to us?
>>
>> > +set-branch (-d|--default)|(-b|--branch ) [--] ::
>>
>> I think th
On Fri, Sep 13, 2019 at 11:03:39AM -0700, Junio C Hamano wrote:
> Denton Liu writes:
>
> > Remove surrounding parentheses so that the "index term" syntax is not
> > triggered (and because it looks nicer without them anyway ;) ).
>
> "Correct" always trumps "nicer", though ;-)
>
> The $USAGE str
Elijah Newren writes:
> For a pathspec like 'foo/bar' comparing against a path named "foo/",
> namelen will be 4, and match[namelen] will be 'b'. The correct location
> of the directory separator is namelen-1.
And the reason why name[namelen-1] may not be slash, in which case
your new code make
Denton Liu writes:
> Remove surrounding parentheses so that the "index term" syntax is not
> triggered (and because it looks nicer without them anyway ;) ).
"Correct" always trumps "nicer", though ;-)
The $USAGE string in the script describes the available options to
this subcommand like so:
For a pathspec like 'foo/bar' comparing against a path named "foo/",
namelen will be 4, and match[namelen] will be 'b'. The correct location
of the directory separator is namelen-1.
The reason the code worked anyway was that the following code immediately
checked whether the first matchlen charac
Hi Eugen,
On Thu, 12 Sep 2019, Eugen Konkov wrote:
> $ git --version
> git version 2.20.1
First thing to try is whether Git v2.23.0 still exposes that bug.
Ciao,
Johannes
On Wed, Sep 11, 2019 at 05:12:31PM +0200, Johannes Schindelin wrote:
> On Tue, 10 Sep 2019, SZEDER Gábor wrote:
>
> > On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote:
> > > On Fri, 6 Sep 2019, SZEDER Gábor wrote:
> > >
> > > > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gá
Hello Git,
Next commands cause the error:
$ git pull
fatal: It seems that there is already a rebase-apply directory, and
I wonder if you are in the middle of another rebase. If that is the
case, please try
git rebase (--continue | --abort | --skip)
If that is not the case, please
A literal "{" should now be escaped in a pattern starting from perl versions
>= v5.26. In perl v5.22, using a literal { in a regular expression was
deprecated, and will emit a warning if it isn't escaped: {. In v5.26, this
won't just warn, it'll cause a syntax error.
(
rom: Dominic Winkler
>
> A literal "{" should now be escaped in a pattern starting from perl
> versions >= v5.26. In perl v5.22, using a literal { in a regular
> expression was deprecated, and will emit a warning if it isn't escaped: \{.
> In v5.26, this won
Hi,
On Tue, 10 Sep 2019, SZEDER Gábor wrote:
> On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote:
> > On Fri, 6 Sep 2019, SZEDER Gábor wrote:
> >
> > > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
>
> > > > Let's install P4 from the package repository, because t
In b57e8119e6 (submodule: teach set-branch subcommand, 2019-02-08), the
`set-branch` subcommand was added for submodules. When the documentation
was written, the syntax for a "index term" in AsciiDoc was
accidentally used. This caused the documentation to be rendered as
set-branch -d|--def
On Tue, Sep 10, 2019 at 12:51:01AM +0200, Johannes Schindelin wrote:
> On Fri, 6 Sep 2019, SZEDER Gábor wrote:
>
> > On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> > > To test 'git-p4' in the Linux Clang and GCC build jobs we used to
> > > install the 'p4' and 'p4d' binaries by di
hat "fetch> done" pkt-line is
> > > > immediately after the "fetch> ".
>
> Thanks for all of your persistent digging on this.
Yeah, I can be easily distracted by an interesting looking bug... was
told it's a character flaw ;)
> I had forgotte
A literal "{" should now be escaped in a pattern starting from perl versions
>= v5.26. In perl v5.22, using a literal { in a regular expression was
deprecated, and will emit a warning if it isn't escaped: {. In v5.26, this
won't just warn, it'll cause a syntax error.
(
From: Dominic Winkler
A literal "{" should now be escaped in a pattern starting from perl
versions >= v5.26. In perl v5.22, using a literal { in a regular
expression was deprecated, and will emit a warning if it isn't escaped: \{.
In v5.26, this won't just warn, it'll
Hi,
On Fri, 6 Sep 2019, SZEDER Gábor wrote:
> On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> > To test 'git-p4' in the Linux Clang and GCC build jobs we used to
> > install the 'p4' and 'p4d' binaries by directly downloading those
> > binaries from a Perforce filehost. This has
On Fri, Sep 06, 2019 at 12:27:11PM +0200, SZEDER Gábor wrote:
> To test 'git-p4' in the Linux Clang and GCC build jobs we used to
> install the 'p4' and 'p4d' binaries by directly downloading those
> binaries from a Perforce filehost. This has worked just fine ever
> since we started using Travis
To test 'git-p4' in the Linux Clang and GCC build jobs we used to
install the 'p4' and 'p4d' binaries by directly downloading those
binaries from a Perforce filehost. This has worked just fine ever
since we started using Travis CI [1], but during the last day or so
that filehost appeared to be gon
For a pathspec like 'foo/bar' comparing against a path named "foo/",
namelen will be 4, and match[namelen] will be 'b'. The correct location
of the directory separator is namelen-1.
The reason the code worked anyway was that the following code immediately
checked whether the first matchlen charac
k>
> > > packet:fetch> done
> > >
> > > In the avarage successful run that "fetch> done" pkt-line is
> > > immediately after the "fetch> ".
Thanks for all of your persistent digging on this. I had forgotten about
been able to reproduce the issue.
> >
> > It's the "done" line:
> >
> > + cat trace-packet
[...]
> > packet: upload-pack>
> > packet:fetch> done
> >
> > In the avarage successful run that "fetch> done&qu
strepo/.git $SHA1_2 &&
git cat-file commit $SHA1_2 &&
test_must_fail env GIT_TEST_PROTOCOL_VERSION= \
+ GIT_TRACE_PACKET="$(pwd)/trace-packet" \
git fetch ../testrepo/.git $SHA1_3 2>err &&
+ cat trace-packet &&
test_i18ngrep "remote error:.*not our ref.*$SHA1_3\$"
err
)
'
On Thu, Aug 29, 2019 at 10:38:05AM -0400, Jeff King wrote:
> So any fixes there have to happen on the client side. I am still
> confused about why the client is writing in this case, per the argument
> in 014ade7484 (upload-pack: send ERR packet for non-tip objects,
> 2019-04-13). It would be nice
Hi Mike
On 29/08/2019 00:25, Mike Hommey wrote:
Hi,
This just happened to me while cherry-pick'ing:
$ git cherry-pick HEAD@{1}
error: could not apply 614fe5e629b84... try
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm &#
g the message twice, one of which
> > comes from the packet.
>
> The problem the flush() was trying to solve was the new "Broken pipe" error,
> which I had assumed was due to a communication race. (Looking at the message
> more closely now, I see that Szeder was able to repro t
not writing out the packet at all. But
> your whole problem is that we're writing the message twice, one of which
> comes from the packet.
The problem the flush() was trying to solve was the new "Broken pipe" error,
which I had assumed was due to a communication race. (Looking at
ssage twice, one of which
comes from the packet.
Second is that this is not "flush the output stream", but "write a flush
packet". The packet_writer_error() function immediately calls write()
without buffering. And no matter where we are in the conversation, a
flush packet would
I was away for keyboard for over an hour and let it run on
> 'master', but it didn't fail. Then I figured that I give it a try
> with Derrick's patch, because, well, why not, and then I got this
> broken pipe error in ~150 repetitions. Run it again, same error after
&
Hi,
This just happened to me while cherry-pick'ing:
$ git cherry-pick HEAD@{1}
error: could not apply 614fe5e629b84... try
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git
27;s different.
>
> Are you running the tip of master?
Yeah, but this seems to be one of those "you have to be really lucky,
even with --stress" cases.
So... I was away for keyboard for over an hour and let it run on
'master', but it didn't fail. Then I figured t
On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
> > Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
> > --stress' to try to reproduce a failure caused by those mingled
> > messages, the same check only failed for a different reason so far
> > (both on Linux and macO
On Wed, Aug 28, 2019 at 11:34:08AM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 06:43:29PM -0700, Derrick Stolee via GitGitGadget
> wrote:
> > Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
> > allowtipsha1inwant=true' that checks stderr for
On Tue, Aug 27, 2019 at 06:43:29PM -0700, Derrick Stolee via GitGitGadget wrote:
> Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
> allowtipsha1inwant=true' that checks stderr for a specific error
> string from the remote. In some build environments the er
From: Derrick Stolee
Test t5516-fetch-push.sh has a test 'deny fetch unreachable SHA1,
allowtipsha1inwant=true' that checks stderr for a specific error
string from the remote. In some build environments the error sent
over the remote connection gets mingled with the error fr
lt = 1;
> strbuf_addf(err,
> - _("Could not access submodule
> '%s'"),
> + _("error: could not access
> submodule '%s'\n"),
> ce->name);
> }
> }
On Wed, Aug 14, 2019 at 09:57:50AM +, Paolo Pettinato (ppettina) wrote:
> Could not access submodule 'sm' # fails, plus no newline here :P!
This part seems easy enough to fix.
-- >8 --
Subject: get_next_submodule(): format error string as an error
The run_processes_para
Eric Sunshine writes:
> On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
>> To avoid data loss, 'git worktree remove' refuses to delete a worktree
>> if it's dirty or contains untracked files. However, the error message
>> only mentions that the worktree
On Tue, Aug 13, 2019 at 2:04 PM SZEDER Gábor wrote:
> To avoid data loss, 'git worktree remove' refuses to delete a worktree
> if it's dirty or contains untracked files. However, the error message
> only mentions that the worktree "is dirty", even if the workt
To avoid data loss, 'git worktree remove' refuses to delete a worktree
if it's dirty or contains untracked files. However, the error message
only mentions that the worktree "is dirty", even if the worktree in
question is in fact clean, but contains untracked files:
From: Jeff Hostetler
Avoid creating unnecessary trailing whitespace in normal
target format error messages when the message is omitted.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_normal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/trace2/tr2_tgt_normal.c
From: Jeff Hostetler
Avoid creating unnecessary trailing whitespace in normal
target format error messages when the message is omitted.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_normal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/trace2/tr2_tgt_normal.c
Carlo Arenas writes:
> * code is suspiciously similar to one[2] that was rejected, but
> hopefully commit message is better
> ...
> [2] https://public-inbox.org/git/20181209230024.43444-3-care...@gmail.com/
I do not recall ever rejecting that one.
It did not come with a good proposed log messag
bjects/info/commit-graph': No such file or
> > directory
> >
> > Check that all input records are indeed valid commit object ids and
> > return with error otherwise, the same way '--stdin-packs' handles
> > invalid input; see e103f7276f (commit-grap
mmit-graph write --stdin-commits
> $ echo $?
> 0
> $ ls -l .git/objects/info/commit-graph
> ls: cannot access '.git/objects/info/commit-graph': No such file or
> directory
>
> Check that all input records are indeed valid commit object ids and
> return with
On Mon, Aug 05, 2019 at 10:02:37AM +0200, SZEDER Gábor wrote:
> While 'git commit-graph write --stdin-commits' expects commit object
> ids as input, it accepts and silently skips over any invalid commit
> object ids, and still exits with success:
>
> $ echo not-a-commit-oid | git commit-graph wr
27;.git/objects/info/commit-graph': No such file or directory
Check that all input records are indeed valid commit object ids and
return with error otherwise, the same way '--stdin-packs' handles
invalid input; see e103f7276f (commit-graph: return with errors during
write, 2019-06-
se 'test_expect_code'
commit-graph: turn a group of write-related macro flags into an enum
commit-graph: error out on invalid commit oids in 'write
--stdin-commits'
builtin/commit-graph.c | 10 ++
builtin/gc.c| 2 +-
commit-graph.c | 40
PROs:
* it works (only for PCRE2) and tested in OpenBSD, NetBSD, macOS, Linux (Debian)
* it applies everywhere (even pu) without conflicts
* it doesn't introduce any regressions in tests (tested in Debian with
SElinux in enforcing mode)
* it is simple
CONs:
* HardenedBSD still segfaults (bugfix pr
interpreter could be used as a fallback
in cases where JIT was not available because of a security policy.
To be conservative, we are restricting initially the error to the
known error that would be returned in that case (and to be documented
as such in a future release of PCRE) and printing a
From: Johannes Schindelin
One time too many did this developer call the `generate` script passing
a `--make-out=` option that was happily ignored (because there
should be a space, not an equal sign, between `--make-out` and the
path).
And one time too many, this script not only ignored it but di
From: Philip Oakley
The error message talked about a "lib option", but it clearly referred
to a link option.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
contrib/buildsystems/engine.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
he above
> justification does not make much sense to me. The original code
> returned an error when buf is NULL, so there is no leak returning
> directly, without jumping to free_buf: label (whose only effect is
> to free(buf) and return the value in ret).
>
> The real value of thi
to the patch text, but the above
> justification does not make much sense to me. The original code
> returned an error when buf is NULL, so there is no leak returning
> directly, without jumping to free_buf: label (whose only effect is
> to free(buf) and return the value in ret).
>
> The re
returned an error when buf is NULL, so there is no leak returning
directly, without jumping to free_buf: label (whose only effect is
to free(buf) and return the value in ret).
The real value of this change is it may future-proof the codepath by
making sure that everybody after an error goes to the
Returning before freeing the allocated buffer is suboptimal; as with
elsewhere in the same function, make sure buf gets free'd.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
ind
Returning before freeing the allocated buffer is suboptimal; as with
elsewhere in the same function, make sure buf gets free'd.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
ind
Jeff King writes:
> ...
> At which point I do wonder if this is better handled by a wrapper
> process which simply reaps everything. And indeed, people have already
> come up with similar solutions for containers:
>
> https://github.com/Yelp/dumb-init
>
> So I dunno. I am not really opposed to
e the OP saw, but Git is quite happy to die() in
various code-paths when it encounters an error.
Rather than try to annotate every possible exit, atexit() might be a
better solution. But isn't this a more general problem even than that?
Lots of parts of Git may spawn a sub-process and assume
thibault.ja...@gmail.com writes:
> Subject: Re: [PATCH] Close transport helper on protocol error
Perhaps
Subject: transport: close helper on protocol error
> +static int disconnect_helper(struct transport *transport);
> +
> +static int disconnect_helper_data(struct helpe
abled. Please ask the owner to check their
account.
fatal: unable to access 'https://github.example.com/org/repo/': The requested
URL returned error: 403
and the code exits inside function get_refs_list
In container contexts, there might not be such an init process
to take care of
Johannes Schindelin writes:
> On Thu, 18 Jul 2019, Junio C Hamano wrote:
>
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>> > From: Johannes Schindelin
>> >
>> > Without an error message when `lstat()` failed, `git clean
Hi Junio,
On Thu, 18 Jul 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > Without an error message when `lstat()` failed, `git clean` would
> > abort without an error message, lea
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Without an error message when `lstat()` failed, `git clean` would
> abort without an error message, leaving the user quite puzzled.
Let's drop the first three words ;-) Sorry for
From: Philip Oakley
The error message talked about a "lib option", but it clearly referred
to a link option.
Signed-off-by: Philip Oakley
Signed-off-by: Johannes Schindelin
---
contrib/buildsystems/engine.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Johannes Schindelin
One time too many did this developer call the `generate` script passing
a `--make-out=` option that was happily ignored (because there
should be a space, not an equal sign, between `--make-out` and the
path).
And one time too many, this script not only ignored it but di
From: Johannes Schindelin
Without an error message when `lstat()` failed, `git clean` would
abort without an error message, leaving the user quite puzzled.
In particular on Windows, where the default maximum path length is quite
small (yet there are ways to circumvent that limit in many cases
of grep to avoid localization problems.
* Add helpful comments.
* The commit message now talks about lstat() instead of stat().
* The commit message also explains where that core.longpaths comes from.
Johannes Schindelin (1):
clean: show an error message when the path is too l
Hi,
On Wed, 17 Jul 2019, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> The other warnings in that function are issued using
> >> warning_errno() (shorter code, consistency is enforced) and
> >> messages are marked for translation. That would be nice to have
> >> here as well, no?
> >
>
rno(), to match
the other warning message.
I also saved one (or perhaps two) fork(s) from the test script ;-)
and added a portability note there.
1: d93f701a2e ! 1: b1e100aa6a clean: show an error message when the path is
too long
@@ Metadata
## Commit message ##
clean: show an e
René Scharfe writes:
>> diff --git a/builtin/clean.c b/builtin/clean.c
>> index aaba4af3c2..7be689f480 100644
>> --- a/builtin/clean.c
>> +++ b/builtin/clean.c
>> @@ -194,7 +194,8 @@ static int remove_dirs(struct strbuf *path, const char
>> *prefix, int force_flag,
>> strbuf_setlen(
On Tue, Jul 16, 2019 at 07:04:23AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> +test_expect_success MINGW 'handle clean & core.longpaths = false nicely' '
> + git config core.longpaths false &&
> + test_when_finished git config --unset core.longpaths &&
'test_config core.longpath
Am 16.07.19 um 16:04 schrieb Johannes Schindelin via GitGitGadget:
> From: Johannes Schindelin
>
> Without an error message when stat() failed, e.g. `git clean` would
> abort without an error message, leaving the user quite puzzled.
>
> In particular on Windows, where the de
This is particularly important on Windows, where PATH_MAX is very small
compared to Unix/Linux.
Johannes Schindelin (1):
clean: show an error message when the path is too long
builtin/clean.c | 3 ++-
t/t7300-clean.sh | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
base
From: Johannes Schindelin
Without an error message when stat() failed, e.g. `git clean` would
abort without an error message, leaving the user quite puzzled.
In particular on Windows, where the default maximum path length is quite
small (yet there are ways to circumvent that limit in many cases
Move the check that filter_options->choice is set to higher in the call
stack. This can only be set when the gentle parse function is called
from one of the two call sites.
This is important because in an upcoming patch this may or may not be an
error, and whether it is an error is only known
d_object_info_extended(struct repository *r, const
struct object_id *oid,
!already_retried && r == the_repository &&
!(flags & OBJECT_INFO_SKIP_FETCH_OBJECT)) {
/*
-* TODO Investigate having fetc
nt, and then
selectively "add -p" the various parts).
Direction (1) seems quite sensible to me, though.
Now that we try harder to clean up the sequencer state I wonder if that
would just cover up bugs where the state has not been removed when it
should have been.
When I wrote that
hub.com/asottile-archive/git-windows-branch-test
> > > * [new branch] master -> origin/master
> > > error: cannot lock ref 'refs/remotes/origin/pr/aux': Unable to create
> > > 'C:/Users/IEUser/x/x/.git/refs/remotes/origin/pr/aux.lock': N
On 18/06/2019 18:01, Eric Sunshine wrote:
On Tue, Jun 18, 2019 at 12:39 PM Anthony Sottile wrote:
+ git fetch origin --tags
Unpacking objects: 100% (10/10), done.
From https://github.com/asottile-archive/git-windows-branch-test
* [new branch] master -> origin/master
error: can
t; * [new branch] master -> origin/master
> > error: cannot lock ref 'refs/remotes/origin/pr/aux': Unable to create
> > 'C:/Users/IEUser/x/x/.git/refs/remotes/origin/pr/aux.lock': No such
> > file or directory
> > ! [new branch] pr/aux
On Tue, Jun 18, 2019 at 12:39 PM Anthony Sottile wrote:
> + git fetch origin --tags
> Unpacking objects: 100% (10/10), done.
> From https://github.com/asottile-archive/git-windows-branch-test
> * [new branch] master -> origin/master
> error: cannot lock ref 'ref
% (4/4), done.
> remote: Total 10 (delta 0), reused 0 (delta 0), pack-reused 0
> Unpacking objects: 100% (10/10), done.
> From https://github.com/asottile-archive/git-windows-branch-test
> * [new branch] master -> origin/master
> error: cannot lock ref 'refs/remotes
1 - 100 of 3514 matches
Mail list logo
