>>> Jeff King schrieb am 21.08.2018 um 03:07 in Nachricht
<20180821010712.ga32...@sigill.intra.peff.net>:
> On Mon, Aug 20, 2018 at 10:57:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
[...]
> So it really should just be a simple:
>
> progress = start_delayed_progress("Hashing packfile", 0);
>
Jeff Hostetler wrote:
[...]
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -144,8 +144,15 @@ static inline int fcntl(int fd, int cmd, ...)
> errno = EINVAL;
> return -1;
> }
> +
> /* bash cannot reliably detect negative return codes as failure */
> +#if defined(STRUCTURED_LOGGING
g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Teach the Makefile to take STRUCTURED_LOGGING=1 variable to
> compile in/out structured logging feature.
>
> Signed-off-by: Jeff Hostetler
> ---
> Makefile | 8
> structured-logging.c | 9 +
> structured-log
Hi,
Jeff Hostetler wrote:
> Signed-off-by: Jeff Hostetler
> ---
> Documentation/technical/structured-logging.txt | 816
> +
> 1 file changed, 816 insertions(+)
> create mode 100644 Documentation/technical/structured-logging.txt
Can you add this to Documentation/Makefi
On Thu, Aug 16, 2018 at 06:41:38PM -0400, Jeff King wrote:
> - we should avoid anyone who is affiliated with a company that already
>has a member on the committee. So nobody from Google and nobody from
>GitHub. I would extend that to Microsoft, too, given a certain
>impending acquisit
Hi,
Git v2.19.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 382 updated messages need to be translated since last
update:
l10n: git.pot: v2.19.0 round 1 (382 new, 30 removed)
Generate po/git.pot from v2.19.0-rc0 for git v2.19.0 l10n round 1.
On Mon, Aug 20, 2018 at 10:57:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > That seems to apply. BTW: Is there a way go get some repository statistics
> > like a histogram of object sizes (or whatever that might be useful to help
> > making decisions)?
>
> The git-sizer program is really helpful
On Mon, Aug 20, 2018 at 5:27 PM Jonathan Nieder wrote:
>
> Jonathan Nieder wrote:
> > Stefan Beller wrote:
> >> Junio C Hamano wrote:
>
> >>> * "git submodule" did not correctly adjust core.worktree setting that
> >>>indicates whether/where a submodule repository has its associated
> >>>w
> At the risk of going on a tangent, I assumed this was because enums
> are really ints, and the "default" is there in case the enum somehow
> got assigned to an int without a corresponding value. Either because
> of a cast from an int that was out-of-range, or new values that were
> obtained from
> > heh. Thanks for switching the style; I should have emphasized that
> > (after reflection) I found them equally good, I am used to one
> > over the other more.
> It seems marginally better to me. I also noticed a clean-up patch
> going by that aggressively switched to test_must_be_empty wherever
Jonathan Nieder wrote:
> Stefan Beller wrote:
>> Junio C Hamano wrote:
>>> * "git submodule" did not correctly adjust core.worktree setting that
>>>indicates whether/where a submodule repository has its associated
>>>working tree across various state transitions, which has been
>>>cor
(-cc: other lists)
Stefan Beller wrote:
> Junio C Hamano wrote:
>> * "git submodule" did not correctly adjust core.worktree setting that
>>indicates whether/where a submodule repository has its associated
>>working tree across various state transitions, which has been
>>corrected.
>>
On Fri, Aug 17, 2018 at 3:28 PM Stefan Beller wrote:
>
> On Fri, Aug 17, 2018 at 3:20 PM Matthew DeVore wrote:
> >
> > On Fri, Aug 17, 2018 at 2:42 PM Stefan Beller wrote:
> > >
> > > On Wed, Aug 15, 2018 at 4:23 PM Matthew DeVore wrote:
> > > >
> > > > Teach list-objects the "tree:0" filter wh
On Mon, Aug 20, 2018 at 11:38 AM Stefan Beller wrote:
>
> On Mon, Aug 20, 2018 at 6:18 AM Matthew DeVore wrote:
> >
> > There were many instances in this file where it seemed like BUG would be
> > better, so I created a new commit before this one to switch them over. The
> > interdiff is below.
>
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.
An early preview of the upcoming 2
Brandon Williams writes:
> Introduce the config "submodule..gitdirpath" which is used to
> indicate where a submodule's gitdir is located inside of a repository's
> "modules" directory.
>
> Signed-off-by: Brandon Williams
> ---
>
> Maybe something like this on top? Do you think we should disall
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
>
> The new get_all_packs() method exposed the packfiles coverede by
s/coverede/covered/
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
>
> There are many places in the codebase that want to iterate over
> all packfiles known to Git. The purposes are wide-ranging, and
> those that can take advantage of the multi-pack-index already
> do. So, use get_all_packs() instead of get_pa
On Mon, Aug 20, 2018 at 02:03:53PM -0700, Junio C Hamano wrote:
> > So taking all of those options into account, what I ended up
> > with is a separate list of "external bases" that are not
> > part of the main packing list. Each delta entry that points
> > to an external base has a single-bit fla
On Tue, 14 Aug 2018 13:36:17 -0700
Junio C Hamano wrote:
> Antonio Ospite writes:
>
> > /* Equivalent to ACTION_SET in builtin/config.c */
> > - if (argc == 3)
> > + if (argc == 3) {
> > + struct object_id oid;
> > +
> > + /*
> > +* If the .gitmodules fil
Stefan Beller writes:
>> I find the design a bit iffy in that our usual "missing in the
>> working tree? let's use the latest blob" fallback is to take it
>> from the index, not from the HEAD.
>
> I am not sure; why does it feel iffy?
Why doesn't it? There is no justification why it has to
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
>
> When an object fails to decompress from a pack-file, we mark the object
> as 'bad' so we can retry with a different copy of the object (if such a
> copy exists).
>
> Before now, the multi-pack-index did not update the bad objects list for
>
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee wrote:
>
> A pack-file is 'local' if it is stored within the usual object
> directory. If it is stored in an alternate, it is non-local.
>
> Pack-files are stored using a 'pack_local' member in the packed_git
> struct. Add a similar 'local' member to
Jeff King writes:
> And that's exactly what this patch does: when we're
> considering whether to reuse an on-disk delta, if bitmaps
> tell us the other side has the object (and we're making a
> thin-pack), then we reuse it.
That's really the natural extension and logical consequence of the
"reus
Hi list,
I'm a co-author of the git-dit tool [1] discussed in the thread
git-bug: Distributed bug tracker embedded in git
on this mailing list. Partly motivated by Jonathan Nieder's call for
more collaboration, I'd like to request comments on a functionality
which I originally planned on int
On 8/20/2018 3:37 PM, Stefan Beller wrote:
On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
One unresolved issue with the commit-graph feature is that it can cause
issues when combined with replace objects, commit grafts, or shallow
clones. These are not 100% incompatible, as one could be
On Thu, Aug 16, 2018 at 10:37 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > The change a086f921a72 (submodule: decouple url and submodule interest,
> > 2017-03-17) enables us to do more than originally thought.
> > As the url setting was used both to actually set the url where to
> > o
On Sat, Aug 18, 2018 at 9:11 AM Duy Nguyen wrote:
>
> On Tue, Aug 14, 2018 at 12:45 AM Stefan Beller wrote:
> > +static int module_update_module_mode(int argc, const char **argv, const
> > char *prefix)
> > +{
> > + const char *path, *update = NULL;
> > + int just_cloned;
> > +
On 8/19/2018 7:24 AM, Duy Nguyen wrote:
On Fri, Dec 8, 2017 at 5:00 PM Jeff Hostetler wrote:
From: Jeff Hostetler
Teach fetch to support filters. This is only allowed for the remote
configured in extensions.partialcloneremote.
Signed-off-by: Jonathan Tan
---
builtin/fetch.c | 23
On Mon, Aug 20, 2018 at 12:31 PM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On Fri, 17 Aug 2018, Stefan Beller wrote:
>
> > This will prove useful in range-diff in a later patch as we will be able
> > to differentiate between adding a new file (that line is starting with
> > +++ and then the fi
On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
>
> One unresolved issue with the commit-graph feature is that it can cause
> issues when combined with replace objects, commit grafts, or shallow
> clones. These are not 100% incompatible, as one could be reasonably
> successful writing a com
Team,
On Mon, 20 Aug 2018, Phillip Wood wrote:
> On 17/08/2018 23:44, Junio C Hamano wrote:
> > 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
Hi Stefan,
On Fri, 17 Aug 2018, Stefan Beller wrote:
> This will prove useful in range-diff in a later patch as we will be able
> to differentiate between adding a new file (that line is starting with
> +++ and then the file name) and regular new lines.
>
> It could also be useful for experiment
Hi,
Nguyễn Thái Ngọc Duy wrote:
> So many times I have carefully cherry picked changes to the index with
> `git add -p` then accidentally did `git commit -am ` (usually by
> retrieving a command from history and pressing Enter too quickly)
> which destroyed beautiful index.
>
> One way to dea
Am 20.08.2018 um 19:40 schrieb Phillip Wood:
On 20/08/2018 11:22, Konstantin Kharlamov wrote:
It's spectacular, that content of one of inserted conflict markers is
empty, so all you have to do is to remove the markers, and use `git add`
on the file, and then `git rebase --continue`
Its a lot of
On Mon, Aug 20, 2018 at 11:24 AM Derrick Stolee wrote:
> Because of the change of base, it is hard to provide a side-by-side diff
> from v1.
I thought that was the whole point of range-diff. ;-)
I'll take a look.
Thanks,
Stefan
On Mon, Aug 20, 2018 at 6:18 AM Matthew DeVore wrote:
>
> There were many instances in this file where it seemed like BUG would be
> better, so I created a new commit before this one to switch them over. The
> interdiff is below.
>
> BTW, why are there so many instances of "die" without "_"? I exp
Elijah Newren writes:
> == The patch ==
> - Ben's patch only affects the "checkout -b $NEWBRANCH" case. He
> checks for it by looking for any other flag that would be a different
> case, and using the old codepath if he finds any.
> - This means there is a "giant list of checks" for this optimiz
From: Stefan Beller
In 60ce76d3581 (refs: add repository argument to for_each_replace_ref,
2018-04-11) and 0d296c57aec (refs: allow for_each_replace_ref to handle
arbitrary repositories, 2018-04-11), for_each_replace_ref learned how
to iterate over refs by a given arbitrary repository.
New attemp
Call close_commit_graph() when about to start a rev-list walk that
includes shallow commits. This is necessary in code paths that "fake"
shallow commits for the sake of fetch. Specifically, test 351 in
t5500-fetch-pack.sh runs
git fetch --shallow-exclude one origin
with a file-based trans
From: Stefan Beller
Signed-off-by: Stefan Beller
Signed-off-by: Derrick Stolee
---
builtin/replace.c | 8
refs.c| 9 -
refs.h| 2 +-
replace-object.c | 5 +++--
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/builtin/replace.c b/builti
Create new method commit_graph_compatible(r) to check if a given
repository r is compatible with the commit-graph feature. Fill the
method with a check to see if replace-objects exist. Test this
interaction succeeds, including ignoring an existing commit-graph and
failing to write a new commit-grap
As it exists right now, the commit-graph feature may provide
inconsistent results when combined with commit grafts, replace objects,
and shallow clones. Update the design document to discuss why these
interactions are difficult to reconcile and how we will avoid errors by
preventing updates to and
Signed-off-by: Derrick Stolee
---
t/helper/test-repository.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/t/helper/test-repository.c b/t/helper/test-repository.c
index 2762ca6562..6a84a53efb 100644
--- a/t/helper/test-repository.c
+++ b/t/helper/test-repository.c
Signed-off-by: Derrick Stolee
---
commit-graph.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/commit-graph.c b/commit-graph.c
index c4eaedf4e5..cee2caab5c 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -62,6 +62,9 @@ extern int read_replace_refs;
static int commit_graph_compatib
Augment commit_graph_compatible(r) to return false when the given
repository r has commit grafts or is a shallow clone. Test that in these
situations we ignore existing commit-graph files and we do not write new
commit-graph files.
Helped-by: Jakub Narebski
Signed-off-by: Derrick Stolee
---
com
One unresolved issue with the commit-graph feature is that it can cause
issues when combined with replace objects, commit grafts, or shallow
clones. These are not 100% incompatible, as one could be reasonably
successful writing a commit-graph after replacing some objects and not
have issues. The pr
Junio C Hamano wrote:
> * jh/structured-logging (2018-07-25) 25 commits
> - structured-logging: add config data facility
> - structured-logging: t0420 tests for interacitve child_summary
> - structured-logging: t0420 tests for child process detail events
> - structured-logging: add child proce
On Mon, Aug 20, 2018 at 6:40 AM Ben Peart wrote:
> On 8/18/2018 9:44 PM, Elijah Newren wrote:
...
> > == My opinions ==
> > - The performance wins are big enough that I can see why Ben is pushing
> > this.
> > - I totally see Duy's point that more general optimizations would be
> > really nice.
>
On 8/20/2018 1:26 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
Usually, I refrain from merging larger topics in 'next' down to
'master' when we get close to -rc0, but I am wondering if it is
better to merge all of them to 'master', even the ones on the larger
and possibly undercooked side
On Fri, Aug 17, 2018 at 3:44 PM Junio C Hamano wrote:
>
> Usually, I refrain from merging larger topics in 'next' down to
> 'master' when we get close to -rc0, but I am wondering if it is
> better to merge all of them to 'master', even the ones on the larger
> and possibly undercooked side, expect
On Mon, Aug 20, 2018 at 11:41 AM Nguyễn Thái Ngọc Duy wrote:
> One way to deal with this is some form of `git undo` that allows me to
> retrieve the old index. That's not a lot of work by itself. The problem
> is designing that `git undo` interface because there are more undo
> options that this.
On Mon, Aug 20, 2018 at 6:23 AM Phillip Wood wrote:
> On 17/08/2018 23:44, Junio C Hamano wrote:
> > * pw/rebase-i-author-script-fix (2018-08-07) 2 commits
> > - sequencer: fix quoting in write_author_script
> > - sequencer: handle errors from read_author_ident()
> >
> > Undecided.
> > Is it t
On 20/08/2018 11:22, Konstantin Kharlamov wrote:
> So, steps-to-reproduce below rather full of trivia like setting up a
> repo, but the TL;DR is:
>
> Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a
> "hunk" as one commit, and then using `git rebase --continue` so the
> oth
Jonathan Nieder writes:
>> Usually, I refrain from merging larger topics in 'next' down to
>> 'master' when we get close to -rc0, but I am wondering if it is
>> better to merge all of them to 'master', even the ones on the larger
>> and possibly undercooked side, expecting that we collectively sp
The new get_all_packs() method exposed the packfiles coverede by
a multi-pack-index. Before, the 'git cat-file --batch' and
'git count-objects' commands would skip objects in an environment
with a multi-pack-index.
Further, a reachability bitmap would be ignored if its pack-file
was covered by a m
When running 'git pack-objects --local', we want to avoid packing
objects that are in an alternate. Currently, we check for these
objects using the packed_git_mru list, which excludes the pack-files
covered by a multi-pack-index.
Add a new iteration over the multi-pack-indexes to find these
copies
A pack-file is 'local' if it is stored within the usual object
directory. If it is stored in an alternate, it is non-local.
Pack-files are stored using a 'pack_local' member in the packed_git
struct. Add a similar 'local' member to the multi_pack_index struct
and 'local' parameters to the methods
When prepare_packed_git is called with the report_garbage method
initialized, we report unexpected files in the objects directory
as garbage. Stop reporting the multi-pack-index and the pack-files
it covers as garbage.
Signed-off-by: Derrick Stolee
---
packfile.c | 7 ---
1 file changed, 4 i
When an object fails to decompress from a pack-file, we mark the object
as 'bad' so we can retry with a different copy of the object (if such a
copy exists).
Before now, the multi-pack-index did not update the bad objects list for
the pack-files it contains, and we did not check the bad objects li
There are many places in the codebase that want to iterate over
all packfiles known to Git. The purposes are wide-ranging, and
those that can take advantage of the multi-pack-index already
do. So, use get_all_packs() instead of get_packed_git() to be
sure we are iterating over all packfiles.
Signe
The multi-pack-index builtin has a very simple command-line
interface. Instead of simply reporting usage, give the user a
hint to why the arguments failed.
Reported-by: Eric Sunshine
Signed-off-by: Derrick Stolee
---
builtin/multi-pack-index.c | 16
1 file changed, 8 insertions
The logic for constructing the linked list of multi-pack-indexes
in the object store is incorrect. If the local object store has
a multi-pack-index, but an alternate does not, then the list is
dropped.
Add tests that would have revealed this bug.
Signed-off-by: Derrick Stolee
---
midx.c
If a repo contains a multi-pack-index, then the packed_git list
does not contain the packfiles that are covered by the multi-pack-index.
This is important for doing object lookups, abbreviations, and
approximating object count. However, there are many operations that
really want to iterate over all
This series is based on ds/multi-pack-index and
jk/for-each-object-iteration.
The multi-pack-index indexes objects across multiple pack-files. To
speed up object lookups and abbreviations, we do not place the pack-
files covered by the multi-pack-index into the packed_git linked list
or the packed
On Tue, 14 Aug 2018 10:10:58 -0700
Brandon Williams wrote:
> On 08/14, Antonio Ospite wrote:
> > Add a new 'config' subcommand to 'submodule--helper', this extra level
> > of indirection makes it possible to add some flexibility to how the
> > submodules configuration is handled.
> >
> > Signed-
On Tue, 14 Aug 2018 13:16:38 -0700
Junio C Hamano wrote:
> Antonio Ospite writes:
>
[...]
> > test_expect_success 'error message contains blob reference' '
> > + # Remove the error introduced in the previous test.
> > + # It is not needed in the following tests.
> > + test_when_finished
Nguyễn Thái Ngọc Duy writes:
> +commit.preciousDirtyIndex::
> + If some changes are partially staged in the index (i.e.
> + "git commit -a" and "git commit" commit different changes), reject
> + "git commit -a".
Or perhaps better yet, go into yes/no interaction to confirm if you
hav
On 8/16/2018 10:10 AM, Linus Torvalds wrote:
One option that I didn't try to go for - because I just don't know the
less code base well enough - is to basically make the behavior of '-F'
be something like this:
- as long as all the lines are short and well-behaved, and we haven't
seen enough l
So many times I have carefully cherry picked changes to the index with
`git add -p` then accidentally did `git commit -am ` (usually by
retrieving a command from history and pressing Enter too quickly)
which destroyed beautiful index.
One way to deal with this is some form of `git undo` that a
Han-Wen Nienhuys writes:
>> @@ -84,6 +86,9 @@ static void maybe_colorize_sideband(struct strbuf *dest,
>> const char *src, int n)
>> for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> struct keyword_entry *p = keywords + i;
>> int len = strlen(p->keyword);
>>
On 20.08.18 00:10, Eric Sunshine wrote:
> On Sun, Aug 19, 2018 at 5:57 PM brian m. carlson
> wrote:
>> On Sun, Aug 19, 2018 at 04:10:21PM -0400, Eric Sunshine wrote:
>>> On Sun, Aug 19, 2018 at 1:54 PM brian m. carlson
- tr '\015\000abcdef0123456789' QN0 <"$2" >"$exp" &&
Jeff King writes:
>> In the longer term we may want to accept size_t as parameter for
>> clarity (even though we know that a sideband message we are painting
>> typically would fit on a line on a terminal and int is sufficient).
>> Write it down as a NEEDSWORK comment.
>
> This "typically" made m
On 8/18/2018 9:44 PM, Elijah Newren wrote:
On Fri, Aug 17, 2018 at 5:41 AM Ben Peart wrote:
On 8/16/2018 2:37 PM, Duy Nguyen wrote:
On Thu, Aug 16, 2018 at 8:27 PM Ben Peart wrote:
From: Ben Peart
Skip merging the commit, updating the index and working directory if and
only if we are c
There were many instances in this file where it seemed like BUG would be
better, so I created a new commit before this one to switch them over. The
interdiff is below.
BTW, why are there so many instances of "die" without "_"? I expect all
errors that may be caused by a user to be localized.
I'm
On Fri, Aug 17, 2018 at 12:41 AM, Jeff King wrote:
> So here are the nominations I came up with. If you'd like to nominate
> somebody else (or yourself!), please do. If you have opinions, let me
> know (public or private, as you prefer).
>
> - Christian Couder
> - Ævar Arnfjörð Bjarmason
Thank
On 8/18/2018 10:41 AM, Nguyễn Thái Ngọc Duy wrote:
In order to merge one or many trees with the index, unpack-trees code
walks multiple trees in parallel with the index and performs n-way
merge. If we find out at start of a directory that all trees are the
same (by comparing OID) and cache-tre
On Sat, Aug 18, 2018 at 6:16 PM Junio C Hamano wrote:
> > Actually, let's just lose the conditional. strbuf_add() would catch
> > and issue an error message when it notices that we fed negative
> > count anyway ;-).
>
> So I'll have this applied on top of the original topic to prevent a
> buggy v
and, thanks for cleaning up after me :)
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Üdvözlet neked, a nevem Mrs. Charity Edward. egy francia
állampolgárság, özvegy vagyok, jelenleg kórházba került a rákbetegség
miatt. Közben úgy döntöttem, hogy pénzt adok neked mint egy megbízható
személy, aki ezt a pénzt bölcsen fogja felhasználni, 3 800 000 millió
eurót. segíteni a szegényeket é
So, steps-to-reproduce below rather full of trivia like setting up a
repo, but the TL;DR is:
Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a
"hunk" as one commit, and then using `git rebase --continue` so the
other part of hunk would be left in top commit; git raises a co
On 17/08/2018 23:44, Junio C Hamano wrote:
> 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 hol
Hi!
Here are some stats from the repository. First the fast import ones (which had
good performance, but probably all cached, also):
% git fast-import <../git-stream
/usr/lib/git/git-fast-import statistics:
-
Alloc'd objects:
On Mon, Aug 20, 2018 at 10:51 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Aug 20 2018, Christian Couder wrote:
>> Jakub, Markus, Gabriel and me plan to publish this edition on
>> Wednesday August 22nd.
>
> Let's mention that we've picked SHA-256 as NewHash, as a follow-up to
> last month's editi
On Mon, Aug 20 2018, Ulrich Windl wrote:
Jeff King schrieb am 16.08.2018 um 22:55 in Nachricht
> <20180816205556.ga8...@sigill.intra.peff.net>:
>> On Thu, Aug 16, 2018 at 10:35:53PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>>> This is all interesting, but I think unrelated to what Ulrich i
On Mon, Aug 20 2018, Christian Couder wrote:
> Hi,
>
> A draft of a new Git Rev News edition is available here:
>
>
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-42.md
>
> Everyone is welcome to contribute in any section either by editing the
> above page on GitHu
>>> Jeff King schrieb am 16.08.2018 um 22:55 in Nachricht
<20180816205556.ga8...@sigill.intra.peff.net>:
> On Thu, Aug 16, 2018 at 10:35:53PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> This is all interesting, but I think unrelated to what Ulrich is talking
>> about. Quote:
>>
>> Between the
>>> Duy Nguyen schrieb am 16.08.2018 um 17:18 in Nachricht
:
> On Thu, Aug 16, 2018 at 1:10 PM Ulrich Windl
> wrote:
>>
>> Hi!
>>
>> I'd like to point out some minor issue observed while processing some
> 5-object repository with many binary objects, but most are rather small:
>>
>> Between
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-42.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
89 matches
Mail list logo
