Add cc to git@vger.kernel.org and jgit-...@eclipse.org
From: Robin Shen
Sent: Thursday, January 10, 2019 2:37 PM
To: Jonathan Nieder
Cc: git@vger.kernel.org; jgit-...@eclipse.org
Subject: Re: Introducing OneDev - an open source git server w
Am 10.01.19 um 04:28 schrieb Jiang Xin:
SZEDER Gábor 于2019年1月9日周三 下午8:56写道：
Use something like
find .git/objects -type f | grep -v pack >out &&
test_must_be_empty out
instead, so we get an informative error message on failure.
if `grep -v pack` return empty output, it will return erro
On Thu, Jan 10, 2019 at 04:25:51AM +, brian m. carlson wrote:
> Since oidcpy and hashcpy are no longer functionally identical, remove
> the Cocinelle object_id transformations that convert from one into the
> other.
Unfortunately this means we'll no longer automatically find cases where
"foo"
On Thu, Jan 10, 2019 at 04:25:50AM +, brian m. carlson wrote:
> diff --git a/tree-walk.c b/tree-walk.c
> index 1e040fc20e..b6daeab16d 100644
> --- a/tree-walk.c
> +++ b/tree-walk.c
> @@ -48,7 +48,8 @@ static int decode_tree_entry(struct tree_desc *desc, const
> char *buf, unsigned l
> /
On Thu, Jan 10, 2019 at 04:25:49AM +, brian m. carlson wrote:
> When we're splicing trees, we're writing directly from one location into
> a buffer that is exactly the same size as a tree object. If the current
> hash algorithm is SHA-1, we may not have a full 32 (GIT_MAX_RAWSZ) bytes
> availa
On Thu, Jan 10, 2019 at 04:25:46AM +, brian m. carlson wrote:
> There are a small number of places in our codebase where we cast a
> buffer of unsigned char to a struct object_id pointer. When we have
> GIT_MAX_RAWSZ set to 32 (because we have SHA-256), one of these places
> (the buffer for tr
Test new formatting option deltabase.
Signed-off-by: Olga Telezhnaia
---
t/t6300-for-each-ref.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 097fdf21fe196..0ffd63071392e 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each
Test new formatting atom.
Signed-off-by: Olga Telezhnaia
---
t/t6300-for-each-ref.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 97bfbee6e8d69..097fdf21fe196 100755
--- a/t/t6300-for-each-ref.sh
+++ b/t/t6300-for-each-ref.sh
@@ -
Add documentation for formatting options objectsize:disk
and deltabase.
Signed-off-by: Olga Telezhnaia
---
Documentation/git-for-each-ref.txt | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each
Add new formatting option: deltabase.
If the object is stored as a delta on-disk, this expands
to the 40-hex sha1 of the delta base object.
Otherwise, expands to the null sha1 (40 zeroes).
We have same option in cat-file command.
Hopefully, in the end I will remove formatting code from
cat-file and
If we have negative file size, we are doing something wrong.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ref-filter.c b/ref-filter.c
index ecef4b47c751c..57f3789d1040d 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1491,6 +1491,8 @@ sta
Add new formatting option objectsize:disk to know
exact size that object takes up on disk.
Signed-off-by: Olga Telezhnaia
---
ref-filter.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 61d75d5c86c64..ecef4b47c751c 1
пн, 24 дек. 2018 г. в 16:16, Оля Тележная :
>
> пт, 9 нояб. 2018 г. в 10:37, Оля Тележная :
> >
> > Add formatting options %(objectsize:disk) and %(deltabase), as in
> > cat-file command.
> >
> > I can not test %(deltabase) properly (I mean, I want to have test with
> > meaningful deltabase in the
On Wed, Jan 09, 2019 at 02:42:28PM -0800, Stefan Beller wrote:
> On Wed, Jan 9, 2019 at 1:37 PM Stefan Beller wrote:
> >
> > > > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > > > I think I'll postpone the later parts of this series and ask this to
> > > > be sent after sb
Currently, the struct object_id pointer returned from tree_entry_extract
lives directly inside the parsed tree buffer. In a future commit, this
will change so that it instead points to a dedicated struct member.
Since in this code path, we want to modify the buffer directly, compute
the buffer offs
There are some situations in which we want to store an object ID into
struct object_id without the_hash_algo necessarily being set correctly.
One such case is when cloning a repository, where we must read refs from
the remote side without having a repository from which to read the
preferred algorit
There are a small number of places in our codebase where we cast a
buffer of unsigned char to a struct object_id pointer. When we have
GIT_MAX_RAWSZ set to 32 (because we have SHA-256), one of these places
(the buffer for tree objects) can lead to us copying too much data when
using SHA-1 as the ha
When we're splicing trees, we're writing directly from one location into
a buffer that is exactly the same size as a tree object. If the current
hash algorithm is SHA-1, we may not have a full 32 (GIT_MAX_RAWSZ) bytes
available to write, nor would we want to write that many bytes even if
we did. In
When parsing a tree, we read the object ID directly out of the tree
buffer. This is normally fine, but such an object ID cannot be used with
oidcpy, which copies GIT_MAX_RAWSZ bytes, because if we are using SHA-1,
there may not be that many bytes to copy.
Instead, store the object ID in a separate
In a future commit, the pointer returned by tree_entry_extract will
point into the struct tree_desc, causing its lifetime to be bound to
that of the struct tree_desc itself. To ensure this code path keeps
working, copy the object_id into a local variable so that it lives long
enough.
Signed-off-b
SZEDER Gábor 于2019年1月9日周三 下午8:56写道：
>
> On Wed, Jan 02, 2019 at 12:34:54PM +0800, Jiang Xin wrote:
> > From: Jiang Xin
> > +test_description='git redundant test'
>
> s/redundant/pack-redundant/ ?
Yes, will correct it.
> > +
> > +. ./test-lib.sh
> > +
> > +create_commits()
> > +{
> > + set -
On Tue, Jan 08, 2019 at 04:16:41PM +0100, Harald Dunkel wrote:
> Hi folks,
>
> I wonder why git-lfs is needed to efficiently handle large files
> in git. Would it be reasonable to integrate this functionality
> into the native git?
Most of the problems Git has with handling large files aren't rea
On Tuesday, January 8, 2019 11:58:29 PM MST Johannes Sixt wrote:
> But notice that the value of $TODAY_REGEX contains blanks.
>
> In this line
>
> check_human_date "$(($(date +%s)-18000)) +0200" $TODAY_REGEX
>
> the value of $TODAY_REGEX is substituted and then the value is split
> into fields a
On Wed, Jan 09, 2019 at 10:06:08PM +0100, Martin Ågren wrote:
> I found some more time to look into this.
>
> It seems we have a buffer with raw data and we set up a `struct
> object_id *` pointing into it, at a (supposed) OID value. Then
> `update_tree_entry_internal()` verifies that the buffer c
Hi Petko,
Petko Yanev wrote:
> I'm writing to you because git-scm.com is a great project and I want to help
> out.
>
> I'd love to contribute with a donation or in another manner you consider
> acceptable.
>
> In exchange, all I expect is a do-follow backlink to one of our sites.
>
> Do let me kn
On Tue, Jan 8, 2019 at 10:31 AM Junio C Hamano wrote:
>
> Phillip Wood writes:
>
> > I just wanted to check that these patches are on your radar as they
> > haven't made it into pu yet.
>
> Sorry, but they were not on my radar. I was waiting for comments to
> come in on them before doing anythin
On Wed, 9 Jan 2019 at 18:42, Stefan Beller wrote:
>
> On Tue, Jan 8, 2019 at 2:16 PM Tomasz Śniatowski wrote:
> >
> > After upgrading to 2.20.1 I noticed in some submodule+worktree scenarios git
> > will break the submodule configuration. Reproducible with:
> > git init a && (cd a; touch a; g
On Wed, Jan 2, 2019 at 2:14 PM David Turner wrote:
>
> When a submodule is renamed, git log gives incorrect output:
>
> commit 350ebece9bce8d9c495f9a51e6f5529749c5c3cc (HEAD -> master)
> Author:
> David Turner
> Date: Wed Jan 2 17:09:56 2019 -0500
>
> move
>
> diff --git a/.gitmodules b/.gi
On Wed, Jan 9, 2019 at 5:19 PM Kim Gybels wrote:
> According to getenv(3)'s notes:
> [...]
> Since strings returned by getenv() are allowed to change on subsequent
> calls to getenv(), make sure to duplicate when caching external_diff_cmd
> from environment.
> [...]
> Signed-off-by: Kim Gybels
>
The mtime of the files in my working copy change when I amend or
rebase or checkout different branches or in general when I use git
commands. I carefully store the mtime when these files are generated
or overwritten and restore it when it is going to be read. The tool I
use is https://packages.ubun
On Wed, Jan 09, 2019 at 02:27:25PM -0800, Stefan Beller wrote:
> > > I would've thought somebody had done this by now, but I guess
> > > it's dependent on a bunch of things (TLS layer nowadays, maybe
> > > HTTP/2), so git-daemon support alone wouldn't cut it...
> >
> > Polling is not all bad, espec
On Wed, Jan 9, 2019 at 1:37 PM Stefan Beller wrote:
>
> > > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > > I think I'll postpone the later parts of this series and ask this to
> > > be sent after sb/more-repo-in-api matures a bit mroe.
> >
> > There were several conflicts
Hi everyone,
On Tue, 8 Jan 2019 at 00:56, Mazo, Andrey wrote:
>
> > git-p4 can map a "git move" operation to a Perforce "move" operation.
> > But by default this is disabled. You then end up with a P4 commit
> > where the file is deleted, and a fresh file is created with the same
> > contents at
On Fri, Dec 28, 2018 at 8:39 PM Konstantin Ryabitsev
wrote:
>
> On Sat, Dec 29, 2018 at 03:56:21AM +, Eric Wong wrote:
> > Hey all, I just added this to the TODO file for public-inbox[1] but
> > obviously it's intended for git.git (meta@public-inbox cc-ed):
> >
> > > +* Contribute something li
According to getenv(3)'s notes:
The implementation of getenv() is not required to be reentrant. The
string pointed to by the return value of getenv() may be statically
allocated, and can be modified by a subsequent call to getenv(),
putenv(3), setenv(3), or unsetenv(3).
Since str
> > Yikes, the conflicts with sb/more-repo-in-api is quite irritating.
> > I think I'll postpone the later parts of this series and ask this to
> > be sent after sb/more-repo-in-api matures a bit mroe.
>
> There were several conflicts, but it was mostly just tedious textual
> fixups. I pushed the r
On Tue, Jan 8, 2019 at 1:36 PM Junio C Hamano wrote:
>
> Jonathan Tan writes:
>
> >> The in-core repository instances are passed through more codepaths.
> >
> > I think this is ready to be considered for merging to next. This series
> > looks
> > good both to Stolee [1] and to me (I replied to
On Tue, Jan 8, 2019 at 10:26 AM Junio C Hamano wrote:
>
> Barret Rhoden writes:
>
> >> A policy decision like the above two shouldn't be hardcoded in the
> >> feature like this, but should be done as a separate option. By
> >> default, these shouldn't be marked with '*', as the same tools you
>
On Wed, 9 Jan 2019 at 08:37, Martin Ågren wrote:
>
> On Tue, 8 Jan 2019 at 00:34, Junio C Hamano wrote:
> > * bc/sha-256 (2018-11-14) 12 commits
> > - hash: add an SHA-256 implementation using OpenSSL
> > - sha256: add an SHA-256 implementation using libgcrypt
> > - Add a base implementation o
Hi -
On 2019-01-08 at 10:26 Junio C Hamano wrote:
> >> Obviously, an interesting consideration is what happens when a merge
> >> commit is skipped. Is it sufficient to change this description to
> >> "...will get passed to its parentS", or would the code do completely
> >> nonsensical things wit
On Thu, Dec 27, 2018 at 8:26 AM Nguyễn Thái Ngọc Duy wrote:
>
> Bitfield addresses cannot be passed around in a pointer. This makes it
> hard to use parse-options to set/unset them. Turn this struct to
> normal integers. This of course increases the size of this struct
> multiple times, but since
> Unfortunately I'm not sure of an easy fix. We'd have to tell the log
> code "figure out if you're going to show the commit, but don't actually
> show anything", which means respecting the count flag virtually
> everywhere that would produce output.
This is (partially) solved for commit parts alr
From: Elijah Newren
When the explanatory text uses the term "respectively", the order of
flags is important.
Signed-off-by: Elijah Newren
---
Documentation/git-show-ref.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-sh
A trivial documentation fix...and testing out gitgitgadget. :-)
Elijah Newren (1):
git-show-ref.txt: fix order of flags
Documentation/git-show-ref.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: ecbdaf0899161c067986e9d9d564586d4b045d62
Published-As:
https://github.com
On Sat, Jan 05, 2019 at 02:46:37PM -0800, Linus Torvalds wrote:
> "git log" is really the human-facing useful command that long long ago
> used to scripted around "git rev-list".
>
> In fact, if you want to use the old scripting code, you can still
> approximate "git log" with something like
>
>
On 2018.12.18 13:24, Jonathan Tan wrote:
> Commit 685fbd3291 ("fetch-pack: perform a fetch using v2", 2018-03-15)
> attempted to teach Git deepen-relative in protocol v2 (among other
> things), but it didn't work:
>
> (1) fetch-pack.c needs to emit "deepen-relative".
> (2) upload-pack.c needs to
Hi,
On Wed, 9 Jan 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Jan 09 2019, Aleksey Svistunov wrote:
>
> > Hi there.
> >
> > I could be wrong but there is a typo on one of the installation step's
> > text. A word sport instead of support is used.
> >
> > Here is a screenshot in attachments
On Wed, Jan 09, 2019 at 10:55:43AM -0800, Josh Steadmon wrote:
> On 2019.01.09 13:23, SZEDER Gábor wrote:
> > On Mon, Jan 07, 2019 at 04:17:09PM -0800, Josh Steadmon wrote:
> > > diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> > > index 5285e7674d..9efb3e9902 100644
> >
On 2019.01.09 13:23, SZEDER Gábor wrote:
> On Mon, Jan 07, 2019 at 04:17:09PM -0800, Josh Steadmon wrote:
> > diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> > index 5285e7674d..9efb3e9902 100644
> > --- a/list-objects-filter-options.c
> > +++ b/list-objects-filter-opti
Will try to reply in-line, when appropriate.
The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
has the issue.
- Bret
On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
wrote:
>
> Hi Bret,
>
>
> On Thu, 3 Jan 2019, Bret Barkelew wrote:
>
> > They are the exact same path (wi
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
> They are the exact same path (with a different drive letter).
[it's a bit hard to follow the thread if you top-post a reply to an
inline-replied answer, maybe imitate the style of other mails in the
future.]
> Another thing I've been able to
On Wed, Jan 9, 2019 at 10:25 AM Johannes Schindelin
wrote:
>
> Hi Anthony,
>
> On Thu, 3 Jan 2019, Anthony Sottile wrote:
>
> > Minimal reproduction
> >
> > ```
> > git init t
> > git -C t commit --allow-empty -m 'initial commit'
> > touch t/a
> > git -C t add --intent-to-add a
> > git -C t stash
Hi Anthony,
On Thu, 3 Jan 2019, Anthony Sottile wrote:
> Minimal reproduction
>
> ```
> git init t
> git -C t commit --allow-empty -m 'initial commit'
> touch t/a
> git -C t add --intent-to-add a
> git -C t stash
> ```
>
> ```
> + git init t
> Initialized empty Git repository in /private/tmp/t/
> This applies suggestions from Jonathan Tan and Junio. These are mostly
> stylistic and readability changes, although there is also an added test case
> in t/t6112-rev-list-filters-objects.sh which checks for the scenario when
> filtering which would exclude a blob, but the blob is given on the co
On Wed, Jan 9, 2019 at 9:21 AM Stefan Beller wrote:
>
> Sounds reasonable to me to have such functionality,
> as I tend to use
> git log --oneline origin/master..origin/next --no-merges |wc -l
> for such queries, which I always assume to be doing useless
> work as I'd be interested in *only* the
On Tue, Jan 8, 2019 at 2:16 PM Tomasz Śniatowski wrote:
>
> After upgrading to 2.20.1 I noticed in some submodule+worktree scenarios git
> will break the submodule configuration. Reproducible with:
> git init a && (cd a; touch a; git add a; git commit -ma)
> git init b && (cd b; git submod
On Sat, Jan 5, 2019 at 2:47 PM Linus Torvalds
wrote:
>
> This is a ridiculous patch. And I understand entirely if nobody else
> cares, because I don't think anybody else has ever even noticed.
>
> It turns out that I still use "git rev-list" outside of some hard-core
> scripting for one silly reas
On Wed, Jan 09, 2019 at 01:56:28PM +0100, SZEDER Gábor wrote:
> On Wed, Jan 02, 2019 at 12:34:54PM +0800, Jiang Xin wrote:
> > +cat >expected < > +P1:$P1
> > +P4:$P4
> > +P5:$P5
> > +P6:$P6
> > +EOF
Creating the expected results could be moved into the
test_expect_success block as well.
> > +
> >
On Sat, Jan 05, 2019 at 10:44:47PM +0100, Daniel Fanjul wrote:
> I'm on Ubuntu. I do not use LFS. I track mods and saved games of
> Skyrim with git, TESV.exe sorts the saved games only by their mtime. I
> know it is not the most usual use case for git.
>
> I agree with that viewpoint and I like th
On Wed, Jan 09, 2019 at 07:21:17AM -0800, Derrick Stolee via GitGitGadget wrote:
> Introduce a 'repack' subcommand to 'git multi-pack-index' that
> takes a '--batch-size' option. The verb will inspect the
s/verb/subcommand/
> diff --git a/builtin/multi-pack-index.c b/builtin/multi-pack-index.c
>
On Wed, Jan 09, 2019 at 07:21:16AM -0800, Derrick Stolee via GitGitGadget wrote:
> The 'git multi-pack-index expire' command ...
The subject line could use a s/verb/subcommand/.
From: Derrick Stolee
The repack builtin deletes redundant pack-files and their
associated .idx, .promisor, .bitmap, and .keep files. We will want
to re-use this logic in the future for other types of repack, so
pull the logic into 'unlink_pack_path()' in packfile.c.
The 'ignore_keep' parameter i
From: Derrick Stolee
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. However, it is likely that many of these
pack-files are rather small, and could be repacked into a slightly
larger pack-fi
From: Derrick Stolee
In anticipation of the expire subcommand, refactor the way we sort
the packfiles by name. This will greatly simplify our approach to
dropping expired packs from the list.
First, create 'struct pack_info' to replace 'struct pack_pair'.
This struct contains the necessary infor
From: Derrick Stolee
To repack using a multi-pack-index, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, adding the packs to a list if they are smaller than the
given pack-size. Finally, collect the objects from the multi-pack-
index that are
From: Derrick Stolee
Before writing the multi-pack-index, we compute the length of the
pack-index names concatenated together. This forms the data in the
pack name chunk, and we precompute it to compute chunk offsets.
The value is also modified to fit alignment needs.
Previously, this computatio
From: Derrick Stolee
The multi-pack-index tracks objects in a collection of pack-files.
Only one copy of each object is indexed, using the modified time
of the pack-files to determine tie-breakers. It is possible to
have a pack-file with no referenced objects because all objects
have a duplicate
From: Derrick Stolee
During development of the multi-pack-index expire subcommand, a
version went out that improperly computed the pack order if a new
pack was introduced while other packs were being removed. Part of
the subtlety of the bug involved the new pack being placed before
other packs th
The multi-pack-index provides a fast way to find an object among a large
list of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
From: Derrick Stolee
We will add new subcommands to the multi-pack-index, and that will
make the documentation a bit messier. Clean up the 'verb'
descriptions by renaming the concept to 'subcommand' and removing
the reference to the object directory.
Helped-by: Stefan Beller
Helped-by: Szeder G
From: Derrick Stolee
The 'git multi-pack-index expire' command looks at the existing
mult-pack-index, counts the number of objects referenced in each
pack-file, deletes the pack-fils with no referenced objects, and
rewrites the multi-pack-index to no longer reference those packs.
Refactor the wr
On Wed, Jan 9, 2019 at 3:05 PM Johannes Schindelin
wrote:
>
> Having said that, it is an unintended regression in the built-in rebase.
> Markus, could you come up with a minimal test case, preferably in the form
> of a patch to t/t3415-rebase-autosquash.sh?
I don't think I'm familiar enough with
Hi Jake,
On Tue, 8 Jan 2019, Jacob Keller wrote:
> On Tue, Jan 8, 2019 at 12:47 PM Markus Wiederkehr
> wrote:
> >
> > On Tue, Jan 8, 2019 at 6:43 PM Andreas Schwab wrote:
> > >
> > > On Jan 08 2019, Markus Wiederkehr wrote:
> > >
> > > > Would it be possible to retain this information?
> > >
>
On Tue, Jan 8, 2019 at 10:29 PM Andreas Schwab wrote:
>
> On Jan 08 2019, Markus Wiederkehr wrote:
>
> > It is not, depending on what happens in the rebase it could be any
> > entry.
>
> Don't look at the HEAD reflog, use the branch reflog, ie. @{1}.
That's exactly what I was looking for, thanks
On Wed, Jan 02, 2019 at 12:34:54PM +0800, Jiang Xin wrote:
> From: Jiang Xin
>
> Add test cases for git pack-redundant to validate new algorithm for git
> pack-redundant.
>
> Signed-off-by: Jiang Xin
> ---
> t/t5323-pack-redundant.sh | 84
> +++
> 1
On Mon, Jan 07, 2019 at 04:17:09PM -0800, Josh Steadmon wrote:
> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> index 5285e7674d..9efb3e9902 100644
> --- a/list-objects-filter-options.c
> +++ b/list-objects-filter-options.c
> @@ -111,6 +112,21 @@ int opt_parse_list_ob
On Mon, Jan 07, 2019 at 06:47:37PM -0800, Masaya Suzuki wrote:
> HTTP_KEEP_ERROR makes it easy to debug HTTP transport errors. In order
> to make HTTP_KEEP_ERROR enabled for all requests, file handles need to
> be supported.
>
> Signed-off-by: Masaya Suzuki
> ---
> http.c | 9 ++---
> 1 file
On Wed, Jan 09 2019, Ævar Arnfjörð Bjarmason wrote:
> > I think a way to have early exposure of these to a lot more people >
would be to have these on the git-scm.com site. Jeff knows more about >
the build process there. > > I see the general completion of French &
German is at ~10%, but > maybe t
On Tue, Jan 08, 2019 at 02:54:36PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > There is already a kernel of translation in French, from my experiments and
> > a
> > previous effort of German translation[6] was gettextized. If you have such
> > archives for other languages, I'd be happy to integrate
On Mon, Jan 07, 2019 at 03:34:10PM -0800, Junio C Hamano wrote:
> * jk/proto-v2-hidden-refs-fix (2018-12-14) 3 commits
> - upload-pack: support hidden refs with protocol v2
> - parse_hide_refs_config: handle NULL section
> - serve: pass "config context" through to individual commands
>
> The
On Wed, Jan 09 2019, Aleksey Svistunov wrote:
> Hi there.
>
> I could be wrong but there is a typo on one of the installation step's
> text. A word sport instead of support is used.
>
> Here is a screenshot in attachments which shows where exactly the typo is.
It's not a typo, "sport" can be us
Hi there.
I could be wrong but there is a typo on one of the installation step's
text. A word sport instead of support is used.
Here is a screenshot in attachments which shows where exactly the typo is.
Best wishes!
P.s. my personal email (s...@ymail.com) was denied by your post system
with
On Wed, Jan 9, 2019 at 1:40 PM Tomasz Śniatowski wrote:
> > The good news is, I have something that should make it work reliably.
> > But I don't know if it will make it to 2.21 or not.
>
> That's good to hear, is there something I can try out or track?
You can try this
https://gitlab.com/pcloud
Hello,
My name is Petko and I am managing the marketing of few sports betting
and casino review websites.
I'm writing to you because git-scm.com is a great project and I want to
help out.
I'd love to contribute with a donation or in another manner you consider
acceptable.
In exchange, al
84 matches
Mail list logo
