On Thu, Sep 24, 2015 at 11:13:52AM +0200, Johannes Schindelin wrote:
> The behavior of `mark_reachable_objects()` without this patch is that it
> dies if it encounters a broken ref. This is sometimes undesirable, e.g.
> when garbage collecting in a repository with a stale remote HEAD.
>
> So let'
For static linking especially library order while linking is important. For
example libssl contains symbol from libcrypto so the former should be linked
before the latter.
The global link order should be libcurl then libssl then libcrypto then
libintl and finally zlib.
Signed-off-by: Remi Pommare
On Thu, Sep 24, 2015 at 11:13:44AM +0200, Johannes Schindelin wrote:
> It is quite possible for, say, a remote HEAD to become stale, e.g. when
> the default branch was renamed.
>
> We should still be able to pack our objects when such a thing happens;
> simply ignore invalid refs (because they ca
On Thu, Sep 24, 2015 at 12:32:01PM +0200, Patrick Steinhardt wrote:
> The function `install_branch_config`, which is used to set up
> tracking branches, does not verify return codes of
> `git_config_set`. Due to this we may incorrectly print that a
> tracking branch has been set up when in fact we
Replace 'unkown' with 'unknown'.
Signed-off-by: Tobias Klauser
---
connect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/connect.c b/connect.c
index c0144d8..777f31c 100644
--- a/connect.c
+++ b/connect.c
@@ -254,7 +254,7 @@ static const char *prot_name(enum protocol prot
The function `install_branch_config`, which is used to set up
tracking branches, does not verify return codes of
`git_config_set`. Due to this we may incorrectly print that a
tracking branch has been set up when in fact we did not due to an
error.
Fix this by checking the return value of `git_conf
Hi Junio,
On 2015-09-24 00:56, Junio C Hamano wrote:
> * jc/fsck-dropped-errors (2015-09-23) 1 commit
> - fsck: exit with non-zero when problems are found
>
> There were some classes of errors that "git fsck" diagnosed to its
> standard error that did not cause it to exit with non-zero statu
When encountering broken refs, such as a stale remote HEAD (which can
happen if the active branch was renamed in the remote), it is more
helpful to remove those refs than to exit with an error.
This fixes https://github.com/git-for-windows/git/issues/423
Signed-off-by: Johannes Schindelin
---
b
The behavior of `mark_reachable_objects()` without this patch is that it
dies if it encounters a broken ref. This is sometimes undesirable, e.g.
when garbage collecting in a repository with a stale remote HEAD.
So let's introduce an optional parameter to collect such broken refs. The
behavior of t
It is quite possible for, say, a remote HEAD to become stale, e.g. when
the default branch was renamed.
We should still be able to pack our objects when such a thing happens;
simply ignore invalid refs (because they cannot matter for the packing
process anyway).
Signed-off-by: Johannes Schindelin
Signed-off-by: Johannes Schindelin
---
t/t6500-gc.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
index 63194d8..b736774 100755
--- a/t/t6500-gc.sh
+++ b/t/t6500-gc.sh
@@ -30,4 +30,19 @@ test_expect_success 'gc -h with invalid configuration' '
There has been a report in the Git for Windows project that gc fails
sometimes: https://github.com/git-for-windows/git/issues/423
It turns out that there are cases when a remote HEAD can go stale and
it is not the user's fault at all. It can happen, for example, if the
active branch in the remote
On 23 September 2015 at 13:28, Lars Schneider wrote:
>
>> Here's the last bit of the crash dump from git-p4 I get:
>>
>> File "/home/ldiamand/git/git/git-p4", line 2580, in streamP4FilesCbSelf
>>self.streamP4FilesCb(entry)
>> File "/home/ldiamand/git/git/git-p4", line 2497, in streamP4FilesC
101 - 113 of 113 matches
Mail list logo
