On Sun, Sep 10, 2017 at 2:30 PM, Lars Schneider
wrote:
>
>> On 03 Aug 2017, at 10:18, Christian Couder
>> wrote:
>>
>> ...
>>
>> * The "helpers" (registered commands)
>>
>> Each helper manages access to one external ODB.
>>
>> There are 2 different modes for helper:
>>
>> - Helpers configured u
On Sun, Sep 10, 2017 at 2:12 PM, Lars Schneider
wrote:
>
>> On 03 Aug 2017, at 10:18, Christian Couder
>> wrote:
>>
>> To properly test passing objects from Git to an external odb
>> we need an odb-helper script that supports a 'put'
>> capability/instruction.
>>
>> For now we will support only
On Sun, Sep 10, 2017 at 2:12 PM, Lars Schneider
wrote:
>
>> On 03 Aug 2017, at 10:18, Christian Couder
>> wrote:
>>
>> +static void parse_capabilities(char *cap_buf,
>> +unsigned int *supported_capabilities,
>> +const char *process_name)
>>
Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05:
> It's not good to use the phrase 'do not touch' to convey the information
> that the cut-line should not be modified or removed as it could possibly
> be mis-interpreted by a person who doesn't know that the word 'touch' has
> the meaning of '
Please I like you to keep this proposal as a top secret and delete it if you
are not interested and get back to
me if you are interested for details as regards to the transfer of $24,500,000
to you. This money initially
belongs to a Libyan client who died in the libya crisis and had no next
On Thu, Aug 3, 2017 at 10:07 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> +OLDIFS="$IFS"
>> +IFS='&'
>> +set -- $QUERY_STRING
>> +IFS="$OLDIFS"
>> +
>> +while test $# -gt 0
>> +do
>> +key=${1%=*}
>> +val=${1#*=}
>
> When you see that ${V%X*} and ${V#*X} appear in a pair for t
Set curl as the runtime default when it is available.
When linked against older curl versions (< 7_34_0) or without curl,
use the legacy imap implementation.
The goal is to validate feature parity between the legacy and
the curl implementation, deprecate the legacy implementation
later on and in t
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index b5e332420a..1b8fbbd545 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -926,6 +926,25 @@ static int auth
Up to this point, the curl mode only supported getting the username
and password from the gitconfig file while the legacy mode could also
fetch them using the credential API.
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 18 --
1 file changed, 16 insertions(+), 2 de
curl_append_msgs_to_imap always returned 0, whether curl failed or not.
Return a proper status so git imap-send will exit with an error code
if something wrong happened.
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Changes since v3:
- Fix return code in patch #1
- Reword patch#4
Nicolas Morey-Chaisemartin (4):
imap-send: return with error if curl failed
imap-send: add wrapper to get server credentials if needed
imap_send: setup_curl: retreive credentials if not set in config file
imap-send: use curl
Ekelhart Jakob venit, vidit, dixit 13.09.2017 17:07:
> Dear Git,
>
> git merge-base --fork-point "master" not working if master is already newer
> then my current branch.
> Very oddly it seems to work whenever you had the expected commit checked out
> previously - what made it very tricky to det
Jonathan Nieder venit, vidit, dixit 13.09.2017 21:20:
> Ramsay Jones wrote:
>
>> On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
>> the desired effect of limiting the resources of new processes, at least
>> for the stack and file descriptors. However, it always returns succ
On Thu, Aug 3, 2017 at 11:40 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> This implements the 'get_direct' capability/instruction that makes
>> it possible for external odb helper scripts to pass blobs to Git
>> by directly writing them as loose objects files.
>
> I am not sure if th
On Thu, Aug 3, 2017 at 9:50 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Add support for a 'put_raw_obj' capability/instruction to send new
>> objects to an external odb. Objects will be sent as they are (in
>> their 'raw' format). They will not be converted to Git objects.
>>
>> For
On Thu, Aug 3, 2017 at 9:52 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> The mechanism to decide which blobs should be sent to which
>> external object database will be very simple for now.
>> If the external odb helper support any "put_*" instruction
>> all the new blobs will be sen
just noticed in "man git-tag":
1) "-a" explicitly claims to create an unsigned tag
2) both "-s" and "-u" both claim to create signed tags
should that mean that it should be an error to try to use "-a" in
combination with either of "-u" or "-s"? the synopsis does suggest
that you can use
On Thu, Aug 3, 2017 at 9:34 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> diff --git a/external-odb.h b/external-odb.h
>> new file mode 100644
>> index 00..9989490c9e
>> --- /dev/null
>> +++ b/external-odb.h
>> @@ -0,0 +1,8 @@
>> +#ifndef EXTERNAL_ODB_H
>> +#define EXTERNAL_OD
[is this the right place to ask questions about git usage? or is
there a different forum where one can submit possibly embarrassingly
silly questions?]
i've been perusing "git filter-branch", and i'm curious if i have
the right idea about how to very selectively get rid of some useless
histor
On Thu, Sep 14, 2017 at 06:08:10AM -0400, Robert P. J. Day wrote:
> just noticed in "man git-tag":
>
> 1) "-a" explicitly claims to create an unsigned tag
> 2) both "-s" and "-u" both claim to create signed tags
>
> should that mean that it should be an error to try to use "-a" in
> comb
On Thu, Sep 14, 2017 at 07:32:11AM -0400, Robert P. J. Day wrote:
> [is this the right place to ask questions about git usage? or is
> there a different forum where one can submit possibly embarrassingly
> silly questions?]
No, this is the right place for embarrassing questions. :)
> say, ea
Hi Jonathan,
On Wed, 13 Sep 2017, Jonathan Nieder wrote:
> As a side note, I am probably misreading, but I found this set of
> paragraphs a bit condescending. It sounds to me like you are saying
> "You are making the wrong choice of hash function and everything else
> you are describing is irrel
On Tue, Sep 12, 2017 at 10:30:27AM -0700, Jonathan Nieder wrote:
> From: Stefan Beller
>
> The check_has_commit helper uses resolves a submodule entry to a
> commit, when validating its existence. As a side effect this means
> tolerates a submodule entry pointing to a tag, which is not a valid
>
Hi Ramsay,
On Wed, 13 Sep 2017, Ramsay Jones wrote:
> So, I finally got around to testing ulimit with open files and
> found that it does not limit them on cygwin (it actually fails
> on the hard limit of 3200).
Thank you!
> Having seen Johannes email earlier, I took a chance and added MinGW to
Congratulation you have won 85,000,000.00GBP For Claim
email:i...@winningsclaimsoffice.com
4f21454b55 ("merge-base: handle --fork-point without reflog",
2016-10-12) fixed the case without reflog, but only partially:
The original code checks whether the merge base candidates are from the
list that we started with, which was the list of reflog entries before
4f21454b55 and the list of refl
4f21454b55 ("merge-base: handle --fork-point without reflog",
2016-10-12) introduced a fix for merge-base --fork-point without reflog
and a test. While that test is fine, it did not update expected nor actual
output and tested that of the previous test instead.
Fix the test to test the merge-base
In fork-point mode, merge-base adds the commit at refname to a list of
candidates to walk from only when the reflog is empty. Therefore, it
fails to find merge bases that are descendants of the most recent reflog
entry.
Add the commit at the tip unconditionally so that a merge base on the
history
merge-base --fork-point does not quite work as advertised when the
reflog is empty or partial. This series brings it in line with the
documentation and, hopefully, with the original intent.
Michael J Gruber (3):
t6010: test actual test output
merge-base: return fork-point outside reflog
merg
Hi Michael,
On Thu, 14 Sep 2017, Michael J Gruber wrote:
> merge-base --fork-point does not quite work as advertised when the
> reflog is empty or partial. This series brings it in line with the
> documentation and, hopefully, with the original intent.
Thank you so much for working on this. I re
On Thursday 14 September 2017 01:06 PM, Michael J Gruber wrote:
Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05:
void wt_status_add_cut_line(FILE *fp)
{
- const char *explanation = _("Do not touch the line above.\nEverything below
will be removed.");
+ const char *explanat
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Wednesday, September 13, 2017 4:18 PM
>
> Jacob Keller writes:
>
> > By definition if you do a sparse checkout, you're telling git "I only
> > care about the files in this sparse checkout, and do not concern me
> > with anything else"...
On Thu, Sep 14, 2017 at 03:15:18PM +0200, Michael J Gruber wrote:
> 4f21454b55 ("merge-base: handle --fork-point without reflog",
> 2016-10-12) introduced a fix for merge-base --fork-point without reflog
> and a test. While that test is fine, it did not update expected nor actual
> output and test
On Thu, Sep 14, 2017 at 03:15:20PM +0200, Michael J Gruber wrote:
> In fork-point mode, merge-base adds the commit at refname to a list of
> candidates to walk from only when the reflog is empty. Therefore, it
> fails to find merge bases that are descendants of the most recent reflog
> entry.
>
>
On Thu, Sep 14, 2017 at 03:15:17PM +0200, Michael J Gruber wrote:
> merge-base --fork-point does not quite work as advertised when the
> reflog is empty or partial. This series brings it in line with the
> documentation and, hopefully, with the original intent.
>
> Michael J Gruber (3):
> t6010
On Thu, Sep 14, 2017 at 07:47:51PM +0530, Kaartic Sivaraam wrote:
> > > - const char *explanation = _("Do not touch the line above.\nEverything
> > > below will be removed.");
> > > + const char *explanation = _("Do not modify or remove the line
> > > above.\nEverything below will be removed.");
test-lib determines whether a file-system supports FIFOs and needs to do
special casing for CYGWIN and MINGW. This separates those system
specific settings from those at more central place.
Set mkfifo() to false in the central system specific place so that the
same test works everywhere.
Signed-
ulimit succeeds (by return value) but does not limit on some systems.
Set ulimit() to false on these systems so that we do not rely on its
output nor effect. As an intended side-effect, ulimit based
prerequisites are set correctly (to "not-have") on these systems.
Reported-by: Ramsay Jones
Repor
Hi Junio,
On Thu, 14 Sep 2017, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > In other words, a long lifetime for the hash absolutely is a design
> > goal. Coping well with an unexpectedly short lifetime for the hash is
> > also a design goal.
> >
> > If the hash function lasts 10 years
So I often will have a submodule that points to one of my own forks,
because I will have work done on a feature branch that hasn't been
merged upstream yet. Assuming this merge takes a long time to get
approved, I will occasionally rebase my topic branch to keep things up
to date and clean.
Howeve
On 14 September 2017 at 17:23, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Thu, 14 Sep 2017, Junio C Hamano wrote:
>
>> Jonathan Nieder writes:
>>
>> > In other words, a long lifetime for the hash absolutely is a design
>> > goal. Coping well with an unexpectedly short lifetime for the hash is
Le 14/09/2017 à 17:39, Robert Dailey a écrit :
> So I often will have a submodule that points to one of my own forks,
> because I will have work done on a feature branch that hasn't been
> merged upstream yet. Assuming this merge takes a long time to get
> approved, I will occasionally rebase my
On 09/13/2017 07:15 PM, Michael Haggerty wrote:
> [...]
> * `mmap()` the whole file rather than `read()`ing it.
> [...]
Apparently this doesn't work on Windows, because the `snapshot` is
keeping the `packed-refs` file open too long, so the new file can't be
renamed on top of it.
I didn't realize t
On 09/14, Johannes Schindelin wrote:
> Hi Jonathan,
>
> On Wed, 13 Sep 2017, Jonathan Nieder wrote:
>
> > As a side note, I am probably misreading, but I found this set of
> > paragraphs a bit condescending. It sounds to me like you are saying
> > "You are making the wrong choice of hash functio
"git commit-tree -F ", unlike "cat | git
commit-tree" (i.e. feeding the same contents from the standard
input), added a missing final newline when the input ended in an
incomplete line.
Correct this inconsistency by leaving the incomplete line as-is,
as erring on the side of not touching the inpu
On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
the desired effect of limiting the resources of new processes, at least
for the stack and file descriptors. However, it always returns success
and leads to several test prerequisites being erroneously set to true.
Add a check
On 14/09/17 15:52, Michael J Gruber wrote:
> ulimit succeeds (by return value) but does not limit on some systems.
>
> Set ulimit() to false on these systems so that we do not rely on its
> output nor effect. As an intended side-effect, ulimit based
> prerequisites are set correctly (to "not-hav
On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin
wrote:
> Without changing your workflow too much,
If you mean to imply that you have other recommendations if I'm
willing to change my workflow, then please by all means share them.
I'm very interested. I'm not too hooked on my workflow
On Thu, 14 Sep 2017 10:39:35 +0200
Christian Couder wrote:
> From the following email:
>
> https://public-inbox.org/git/20170804145113.5ceaf...@twelve2.svl.corp.google.com/
>
> it looks like his work is fundamentally about changing the rules of
> connectivity checks. Objects are split between "
Ramsay Jones wrote:
> On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
> the desired effect of limiting the resources of new processes, at least
> for the stack and file descriptors. However, it always returns success
> and leads to several test prerequisites being erroneous
Hi Jonathan,
On Wed, 13 Sep 2017, Jonathan Nieder wrote:
> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html,
I had read this short after it was published, and had missed the updates.
One link in particular caught my eye:
https://eprint.iacr.org/2012/476
Essentially, the auth
Hi,
Johannes Schindelin wrote:
> On Wed, 13 Sep 2017, Jonathan Nieder wrote:
>> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html,
>
> I had read this short after it was published, and had missed the updates.
> One link in particular caught my eye:
>
> https://eprint.iacr.org/2012
Hi Linus,
On Wed, 13 Sep 2017, Linus Torvalds wrote:
> On Wed, Sep 13, 2017 at 6:43 AM, demerphq wrote:
> >
> > SHA3 however uses a completely different design where it mixes a 1088
> > bit block into a 1600 bit state, for a leverage of 2:3, and the excess
> > is *preserved between each block*.
Johannes Schindelin wrote:
> On Wed, 13 Sep 2017, Jonathan Nieder wrote:
>> As a side note, I am probably misreading, but I found this set of
>> paragraphs a bit condescending. It sounds to me like you are saying
>> "You are making the wrong choice of hash function and everything else
>> you are
Hi Michael,
On Wed, 13 Sep 2017, Michael Haggerty wrote:
> * `mmap()` the whole file rather than `read()`ing it.
On Windows, a memory-mapped file cannot be renamed. As a consequence, the
following tests fail on `pu`:
t1400-update-ref.sh
t1404-update-ref-errors.sh
t1405-main-ref-store.sh
t1408-p
Hi,
On Thu, 14 Sep 2017, demerphq wrote:
> On 14 September 2017 at 17:23, Johannes Schindelin
> wrote:
> >
> > SHA-256 has been hammered on a lot more than SHA3-256.
>
> Last year that was even more true of SHA1 than it is true of SHA-256
> today.
I hope you are not deliberately trying to anno
The commands should be self explanatory. 0.2.0~20 is the first commit
where the reconstructed repository diverges, that commit had a
simultaneous copy and edit of one file. It seems that copy/rename
detection, enabled with -M -C is confused by this. I reproduced it
with git 2.14 next @ 8fa685d.
gi
Hi Jonathan,
On Thu, 14 Sep 2017, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Wed, 13 Sep 2017, Jonathan Nieder wrote:
>
> >> [3] https://www.imperialviolet.org/2017/05/31/skipsha3.html,
> >
> > I had read this short after it was published, and had missed the updates.
> > One link
Hello,
"git diff -name-status" is useful to list the files one has changed
but it does not list file that one has deleted with "git rm". It would be
really handy if it did. I am using git 2.9.3 on Ubuntu Linux 16.10.
Yours Sincerely,
Gene Thomas.
Hi Michael,
On Thu, 14 Sep 2017, Michael Haggerty wrote:
> On 09/13/2017 07:15 PM, Michael Haggerty wrote:
> > [...]
> > * `mmap()` the whole file rather than `read()`ing it.
> > [...]
>
> Apparently this doesn't work on Windows, because the `snapshot` is
> keeping the `packed-refs` file open too
Hi Michael,
On Thu, 14 Sep 2017, Michael J Gruber wrote:
> test-lib determines whether a file-system supports FIFOs and needs to do
> special casing for CYGWIN and MINGW. This separates those system
> specific settings from those at more central place.
>
> Set mkfifo() to false in the central s
From: "Johannes Schindelin"
Hi Philip,
On Mon, 11 Sep 2017, Philip Oakley wrote:
From: "Pavel Kretov"
> Hi all,
>
> Excuse me if the topic I'm going to raise here has been already
> discussed
> on the mailing list, forums, or IRC, but I couldn't find anything
> related.
>
>
> The problem:
On Thu, Sep 14, 2017 at 12:31:38AM +0100, Ramsay Jones wrote:
> > Hmm, about three or four years ago, I spent two or three evenings
> > getting git to compile -Wextra clean. I remember the signed/unsigned
> > issue was the cause of a large portion of the warnings issued by
> > the compiler. I was
On Wed, Sep 13, 2017 at 02:09:27PM -0700, Jonathan Nieder wrote:
> > We ask to write 41 bytes and make sure that the return value
> > is at least 41. This is the same "dangerous" pattern that
> > was fixed in the prior commit (wherein a negative return
> > value is promoted to unsigned), though it
On Wed, Sep 13, 2017 at 02:14:30PM -0700, Jonathan Nieder wrote:
> >I really wish every "write_in_full()" user would just
> >check against "<0" now, but this fixes the nasty and
> >stupid ones.
>
> Ok, you convinced me.
>
> Should we add a comment to cache.h as well encou
On Wed, Sep 13, 2017 at 02:20:35PM -0700, Jonathan Nieder wrote:
> > --- a/notes-merge.c
> > +++ b/notes-merge.c
> > @@ -302,7 +302,7 @@ static void write_buf_to_worktree(const struct
> > object_id *obj,
> > fd = xopen(path, O_WRONLY | O_EXCL | O_CREAT, 0666);
> >
> > while (size > 0) {
On Wed, Sep 13, 2017 at 02:25:28PM -0700, Jonathan Nieder wrote:
> > Let's flip them to follow the usual write() conventions and
> > update all callers. As these are local to config.c, it's
> > unlikely that we'd have new callers in any topics in flight
> > (which would be silently broken by our c
Dearest,
I am Mrs. Asana Hajraf and I am married to Mr. Hassan Hajraf from kuwait for 19
years without a child and my husband died in 2014. I am contacting you to let
you know my desire to donate the sum of $4.5 million to charities in your
country which I inherited from my late husband. Due to
On Tue, 2017-09-12 at 13:24 -0500, Joseph Dunne wrote:
> Sorry I don't understand your question. The commit-msg hook runs
> properly in all cases except when I perform a merge with the --no-ff
> option enabled.
>
It's working just as the documentation says it does (emphasis mine),
This hoo
On Thu, 2017-09-14 at 09:36 +0200, Michael J Gruber wrote:
>
> Also, given all the translations that we have, it seems somewhat strange
> to try and foresee and workaround possible misunderstandings of commonly
> used English phrases.
In case you're trying to say that "Translators have successful
Jeff King writes:
> # >8
> # Do not modify or remove the line above.
> # Everything below will be ignored.
>
> (I might say "everything below it" to be more precise).
>
> I dunno. We are deep in bikeshed territory here, and I admit I don't
>
Jonathan Nieder writes:
> This is a continuation of the series at [1]. That was part 1 ---
> you can think of this as part 0, since it contains the simplest and
> least controversial part of the series --- each patch in this series
> is a bugfix in its own right.
>
> Patch 1 should be familiar i
Michael J Gruber writes:
> In fact, per documentation "--fork-point" looks at the reflog in
> addition to doing the usual walk from the tip. The original design
> description in d96855ff51 ("merge-base: teach "--fork-point" mode",
> 2013-10-23) describes this as computing from a virtual merge-bas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi there,
While bumping Git's version for our Linux distribution to 2.14.1, I've
run in to a new test failure in t6500-gc.sh. This is the output of
the failing test with debug=t verbose=t:
expecting success:
# make sure we run a backgroun
Gene Thomas writes:
> Hello,
> "git diff -name-status" is useful to list the files one
> has changed but it does not list file that one has
> deleted with "git rm". It would be really handy if it
> did. I am using git 2.9.3 on Ubuntu Linux 16.10.
With or w
On 09/14/2017 10:23 PM, Johannes Schindelin wrote:
> On Wed, 13 Sep 2017, Michael Haggerty wrote:
>
>> * `mmap()` the whole file rather than `read()`ing it.
>
> On Windows, a memory-mapped file cannot be renamed. As a consequence, the
> following tests fail on `pu`:
>
> [...]
Thanks for your qu
Nicolas Morey-Chaisemartin writes:
> + if (cred.username)
> + if (res == CURLE_OK)
> + credential_approve(&cred);
> +#if LIBCURL_VERSION_NUM >= 0x070d01
> + else if (res == CURLE_LOGIN_DENIED)
A slight tangent. This is in line with the way in whic
Nicolas Morey-Chaisemartin writes:
>
> + if (cred.username)
> + if (res == CURLE_OK)
> + credential_approve(&cred);
> +#if LIBCURL_VERSION_NUM >= 0x070d01
> + else if (res == CURLE_LOGIN_DENIED)
> +#else
> + else
> +#endif
> +
It's not good to use the phrase 'do not touch' to convey the information
that the cut-line should not be modified or removed as it could possibly
be mis-interpreted by a person who doesn't know that the word 'touch' has
the meaning of 'tamper with'. Further, it could make translations a little
diff
Kevin Willford writes:
> 1. Does this statement, "I only care about the files in this
> sparse checkout, and do not concern me with anything else", mean
> that git should not change files outside the sparse-checkout whether
> that be in the working directory or in the index? Or does that only
>
Junio,
Thanks for your reply. So git is essentially doing a "git commit"
when I "git rm".
Gene.
-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Friday, 15 September 2017 2:58 PM
To: Gene Thomas
Cc: git@vger.kernel.org
Subject: Re: git diff --name-st
Gene Thomas writes:
> Junio,
>Thanks for your reply. So git is essentially doing a
>"git commit" when I "git rm".
No. You'd probably need to read a bit more on Git; unlike other
systems like CVS and SVN, where you only have two states
(i.e. committed contents vs files on
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.
We are at week #6 of this cycle.
Bonjour
Vous aviez besoin de prêts d'argent entre particuliers pour faire face
aux difficultés financières pour enfin sortir de l'impasse que
provoquent les banques, par le rejet de vos dossiers de demande de
crédits ? Je suis un citoyen français en mesure de vous faire un
prêt de 5000 euros à 500
Using git 2.14.1 for Windows
I'm seeing an issue with the follow sequence of commands:
git init D:\XXX\workspace
git fetch --no-tags --progress https://XXX/_git/PAPI
+refs/heads/*:refs/remotes/origin/* --depth=20
git fetch --no-tags --progress https://XXX/_git/PAPI
+refs/heads/*:refs/remotes/o
Wesley Smith writes:
> 1) This bug is triggered because "git fetch" is causing a pack
> file to be written when that same pack file already exists. It
> seems like this is harmless and shouldn't cause a problem. Is
> that correct?
The final name of the packfile is derived from the entire conte
On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi there,
>
> While bumping Git's version for our Linux distribution to 2.14.1, I've
> run in to a new test failure in t6500-gc.sh. This is the output of
> the failing test with deb
87 matches
Mail list logo
