Jeff King writes:
> Yes, I think we could just call this "list_move_to_front()" or
> something. The fact that it's operating on a list called
> "packed_git_mru" is probably sufficient to make it clear that the
> purpose is managing recentness.
I earlier said I wasn't sure, but I
On Fri, Sep 29, 2017 at 11:38:27PM +0300, Оля Тележная wrote:
> > About minor issues ( "tmp" vs "p2", variable scope, space indentation)
> > - fully agree, I will fix it.
> > ...
> > So finally I think that I need to fix that minor issues and that's
> > all.
>
> I forgot about leak. I also need
On Fri, Sep 29, 2017 at 07:08:28PM +0300, Оля Тележная wrote:
> Many thanks to all of you, I am interested in every opinion. Sorry
> that I wasn't in the discussion, unfortunately I got sick, that's why
> I skipped all the process.
No problem. It's often reasonable to let review comments come in
On Fri, Sep 29, 2017 at 11:43:57PM +0200, Johannes Schindelin wrote:
> On Thu, 28 Sep 2017, Jeff King wrote:
>
> > If you're planning on using an oidset to mark every object in a
> > 100-million-object monorepo, we'd probably care more. But I'd venture to
> > say that any scheme which involves
Hi,
On Fri, 15 Sep 2017, Wesley Smith wrote:
> Thanks for your response. I'm glad to see that you've been able to
> understand the problem. I'm working with the Windows git team to properly
> return EACCESS when "rename" fails due to access permissions, but it also
> sounds like there will
Hi Philip,
On Fri, 15 Sep 2017, Philip Oakley wrote:
> From: "Johannes Schindelin"
>
> > In light of such experiences, I have to admit that the notion that the
> > rename detection can always be improved in hindsight puts quite a bit of
> > insult to injury for those
This is similar to using the hashmap in hashmap.c, but with an
easier-to-use API. In particular, custom entry comparisons no longer
need to be written, and lookups can be done without constructing a
temporary entry structure.
This is implemented as a thin wrapper over the hashmap API. In
Stephan Beyer wrote:
> On 09/29/2017 08:40 PM, Jonathan Nieder wrote:
>> Going forward, is there an easy way to preview the effect of this kind
>> of change (e.g., to run "make style" on the entire codebase so as to be
>> able to compare the result with two different versions of
>>
Hi,
On 09/29/2017 08:40 PM, Jonathan Nieder wrote:
> Going forward, is there an easy way to preview the effect of this kind
> of change (e.g., to run "make style" on the entire codebase so as to be
> able to compare the result with two different versions of
> .clang-format)?
I just ran
Hi Joan,
On Fri, 29 Sep 2017, Joan Daemen wrote:
> if ever there was a SHA-2 competition, it must have been held inside NSA:-)
Oops. My bad, I indeed got confused about that, as you suggest below (I
actually thought of the AES competition, but that was obviously not about
SHA-2). Sorry.
> But
Hi Peff,
On Thu, 28 Sep 2017, Jeff King wrote:
> If you're planning on using an oidset to mark every object in a
> 100-million-object monorepo, we'd probably care more. But I'd venture to
> say that any scheme which involves generating that hash table on the fly
> is doing it wrong. At at that
On 09/27, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> + # Client requested to use protocol v1
> >> + grep "version=1" log &&
> >> + # Server responded using protocol v1
> >> + grep "clone< version 1" log
> >
> > This looked a bit strange to check "clone< version
On 09/27, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> +enum protocol_version determine_protocol_version_server(void)
> >> +{
> >> + const char *git_protocol = getenv(GIT_PROTOCOL_ENVIRONMENT);
> >> + enum protocol_version version = protocol_v0;
> >> +
> >> + if
Hey Stephan,
On Sat, Sep 30, 2017 at 12:24 AM, Stephan Beyer wrote:
>
> Hi Pranit,
>
> On 09/29/2017 08:49 AM, Pranit Bauva wrote:
> > It has been a long time since this series appeared on the mailing list.
> > The previous version v15[1] is now split into many parts and I am
>
Hi Jonathan,
On Fri, 29 Sep 2017, Jonathan Tan wrote:
> Jeff Hostetler has sent out some object-filtering patches [1] that is a
> superset of the object-filtering functionality that I have (in the
> pack-objects patches). I have gone for the minimal approach here, but if
> his patches are
> About minor issues ( "tmp" vs "p2", variable scope, space indentation)
> - fully agree, I will fix it.
> ...
> So finally I think that I need to fix that minor issues and that's
> all.
I forgot about leak. I also need to add checking in mru_clear. That's
not beautiful solution but it works
On Wed, 27 Sep 2017 18:46:30 +0200
Christian Couder wrote:
> I am ok to split the patch series, but I am not sure that 01/40 to
> 09/40 is the right range for the first patch series.
> I would say that 01/40 to 07/40 is better as it can be seen as a
> separate
Well something like this is not paying _Paul_ enough for what he gave to The
People, so I do not think there is worth trying.
> On 28 Sep 2017, at 06:37, Junio C Hamano wrote:
>
> Max Kirillov writes:
>
>> Tilda-based path may confise some users. First,
On Tue, 26 Sep 2017 17:26:33 +0200
Michael Haggerty wrote:
> Maybe naming has been discussed at length before, and I am jumping into
> a long-settled topic. And admittedly this is bikeshedding.
>
> But I find these names obscure, even as a developer. And terms like this
>
Currently, in pack_objects, add_object_entry() distinguishes between 2
types of non-preferred-base objects:
(1) objects that should not be in "to_pack" because an option like
--local or --honor-pack-keep is set
(2) objects that should be in "to_pack"
A subsequent commit will teach
Teach fsck to not treat missing promisor objects indirectly pointed to
by refs as an error when extensions.partialclone is set.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c | 11 +++
t/t0410-partial-clone.sh | 23 +++
2 files
Introduce fetch-object, providing the ability to fetch one object from a
promisor remote.
This uses fetch-pack. To do this, the transport mechanism has been
updated with 2 flags, "from-promisor" to indicate that the resulting
pack comes from a promisor remote (and thus should be annotated as such
When running checkout, first prefetch all blobs that are to be updated
but are missing. This means that only one pack is downloaded during such
operations, instead of one per missing blob.
This operates only on the blob level - if a repository has a missing
tree, they are still fetched one at a
Teach fetch-pack and upload-pack to support excluding large blobs
through a blob-max-bytes parameter.
Signed-off-by: Jonathan Tan
---
Documentation/technical/pack-protocol.txt | 9
Documentation/technical/protocol-capabilities.txt | 7 ++
In fetch-pack, the global variable save_commit_buffer is set to 0, but
not restored to its original value after use.
In particular, if show_log() (in log-tree.c) is invoked after
fetch_pack() in the same process, show_log() will return before printing
out the commit message (because the
Teach clone to support excluding large blobs through a blob-max-bytes
parameter.
Signed-off-by: Jonathan Tan
---
builtin/clone.c | 23 +--
t/t5601-clone.sh | 49 +
2 files changed, 70 insertions(+), 2
As part of an effort to improve Git support for very large repositories
in which clients typically have only a subset of all version-controlled
blobs, teach pack-objects to support --blob-max-bytes, packing only
blobs not exceeding that size unless the blob corresponds to a file
whose name starts
Teach sha1_file to fetch objects from the remote configured in
extensions.partialClone whenever an object is requested but missing.
The fetching of objects can be suppressed through a global variable.
This is used by fsck and index-pack.
However, by default, such fetching is not suppressed. This
Teach gc to stop traversal at promisor objects, and to leave promisor
packfiles alone. This has the effect of only repacking non-promisor
packfiles, and preserves the distinction between promisor packfiles and
non-promisor packfiles.
Signed-off-by: Jonathan Tan
---
Teach fetch to support excluding large blobs through a blob-max-bytes
parameter. This is only allowed for the remote configured in
extensions.partialclone.
Signed-off-by: Jonathan Tan
---
builtin/fetch.c | 22 --
connected.c | 1 +
Teach fsck to not treat missing promisor objects provided on the CLI as
an error when extensions.partialclone is set.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c | 2 ++
t/t0410-partial-clone.sh | 13 +
2 files changed, 15 insertions(+)
diff
Teach clone to configure blobmaxbytes in any repos that it generates
when the --blob-max-bytes parameter is set. Also teach fetch to use this
parameter.
Signed-off-by: Jonathan Tan
---
builtin/clone.c | 1 +
builtin/fetch.c | 4
remote.c
In a subsequent commit, index-pack will be taught to write ".promisor"
files which are similar to the ".keep" files it knows how to write.
Refactor the writing of ".keep" files, so that the implementation of
writing ".promisor" files becomes easier.
Signed-off-by: Jonathan Tan
Teach rev-list to support termination of an object traversal at any
object from a promisor remote (whether one that the local repo also has,
or one that the local repo knows about because it has another promisor
object that references it).
This will be used subsequently in gc and in the
Teach fsck to not treat refs referring to missing promisor objects as an
error when extensions.partialclone is set.
For the purposes of warning about no default refs, such refs are still
treated as legitimate refs.
Signed-off-by: Jonathan Tan
---
builtin/fsck.c
Separate out the calculation of remotes to be fetched from and the
actual fetching. This will allow us to include an additional step before
the actual fetching in a subsequent commit.
Signed-off-by: Jonathan Tan
---
builtin/fetch.c | 14 --
1 file changed,
Currently, Git does not support repos with very large numbers of objects
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every
These patches are also available online:
https://github.com/jonathantanmy/git/commits/partialclone3
(I've announced it in another e-mail, but am now sending the patches to the
mailing list too.)
Here's an update of my work so far. Notable features:
- These 18 patches allow a user to clone with
On 09/29, Jonathan Nieder wrote:
> Hi Dscho,
>
> Johannes Schindelin wrote:
>
> > Signed-off-by: Johannes Schindelin
> > ---
> > .clang-format | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> Well executed and well explained. Thank you.
>
On Thu, 28 Sep 2017 10:33:39 -0400
Jeff Hostetler wrote:
> Maybe. What I have here now is the result of adding these arguments to
> rev-list and pack-objects (in the current patch series), and also to
> fetch-pack, fetch, clone, upload-pack, index-pack, and the transport
On Fri, Sep 29, 2017 at 12:04:56PM -0700, Jonathan Tan wrote:
> > So depending how you count it, we're wasting between 28% (sha1 and no
> > extra hash) and 16% (sha256 plus reusing hashmap). That's not great, but
> > it's probably not breaking the bank.
>
> Hmm...how did you get the 16% figure?
On Thu, 28 Sep 2017 16:05:57 -0400
Jeff King wrote:
> When I saw that you were implementing "oidset" in terms of "oidmap", I
> was all ready to be crabby about this extra memory. But then I saw that
> the implementation tries hard not to waste any memory. :)
>
> All of which is
Hi Pranit,
On 09/29/2017 08:49 AM, Pranit Bauva wrote:
> It has been a long time since this series appeared on the mailing list.
> The previous version v15[1] is now split into many parts and I am
> sending the first part right now, will focus on getting this merged and
> then send out the next
Hi Dscho,
Johannes Schindelin wrote:
> Signed-off-by: Johannes Schindelin
> ---
> .clang-format | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Well executed and well explained. Thank you.
Reviewed-by: Jonathan Nieder
On Wed, Sep 27 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> I do think however that we also need to update the docs, the relevant
>> origin/master...gitster/sd/branch-copy diff is currently:
>>
>> +The `-c` and `-C` options have the exact same
We really, really, really want to limit the columns to 80 per line: One
of the few consistent style comments on the Git mailing list is that the
lines should not have more than 80 columns/line (even if 79 columns/line
would make more sense, given that the code is frequently viewed as diff,
and
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> This document describes what a transition to a new hash function for
>> Git would look like. Add it to Documentation/technical/ as the plan
>> of record so that future changes can be recorded as patches.
>>
>> Also-by:
On Fri, Sep 29, 2017 at 6:08 AM, Derrick Stolee wrote:
> Hi Junio,
>
> On 9/29/2017 12:34 AM, Junio C Hamano wrote:
>>
>> * ds/find-unique-abbrev-optim (2017-09-19) 4 commits
>> - SQUASH???
>> - sha1_name: parse less while finding common prefix
>> - sha1_name: unroll len
from the man page:
"If the --include-untracked option is used, all untracked files are
also stashed and then cleaned up with git clean, leaving the working
directory in a very clean state. If the --all option is used instead
^^^
Hi everyone,
Many thanks to all of you, I am interested in every opinion. Sorry
that I wasn't in the discussion, unfortunately I got sick, that's why
I skipped all the process.
I want to reply to the main moments and also ask some questions.
>> Simplify mru.c, mru.h and related code by reusing
Hello,
Really excited to release version 2.3.0 of Tig which brings several
improvements to the rendering performance, new features like search/prompt
history persistence, and important fixes to the graph rendering and emoji
display. I'd like thank all contributors and Roland Walker and Sven
Dear Johannes,
if ever there was a SHA-2 competition, it must have been held inside
NSA:-) But maybe you are confusing with the SHA-3 competition. In any
case, when considering SHA-2 vs SHA-3 for usage in git, you may have a
look at arguments we give in the following blogpost:
Dear Friend,
Good day to you.
With due respect, i apologize you for this sudden message, it was due to the
urgency of this transaction made me to seek for your immediate assistance. I
hope that you will not expose or betray this trust.
I am Mr.Kevin Achimota, a banker with position of the
Hello ,
I am specifically contacting you in respect of a business proposal that I
have for you as you appear very relevant in the proposal.
Please kindly reply back to me for further details.
Waiting to hear from you.
Regards,
Mr.Adams Salem
Hi Gilles,
On Tue, 19 Sep 2017, Gilles Van Assche wrote:
> On 19/09/17 00:16, Johannes Schindelin wrote:
> >>> SHA-256 got much more cryptanalysis than SHA3-256 […].
> >>
> >> I do not think this is true.
> >
> > Please read what I said again: SHA-256 got much more cryptanalysis
> > than
Hi Junio,
On 9/29/2017 12:34 AM, Junio C Hamano wrote:
* ds/find-unique-abbrev-optim (2017-09-19) 4 commits
- SQUASH???
- sha1_name: parse less while finding common prefix
- sha1_name: unroll len loop in find_unique_abbrev_r()
- sha1_name: create perf test for find_unique_abbrev()
Hi Nicolas,
On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote:
> Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
> >
> > C'mon, don't *try* to misunderstand me.
> >
> > Of course there need to be updates as to the state of patch series.
> >
> > It's just that mails only go *so* far when
> -Original Message-
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Thursday, September 28, 2017 10:21 PM
> To: Ben Peart
> Cc: david.tur...@twosigma.com; ava...@gmail.com;
> christian.cou...@gmail.com; git@vger.kernel.org;
> johannes.schinde...@gmx.de;
Hi all,
Thanks for the fast feedback, I'll answer everyone in a single email
if you don't mind.
On Fri, Sep 29, 2017 at 5:48 AM, Jonathan Nieder wrote:
snip
> I wonder if we can make this so intuitive that it doesn't need
> mentioning in CodingGuidelines. What if the test
Hi Jonathan,
On Tue, 19 Sep 2017, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>
> > To relate that, you are using a plain text format that is not well
> > defined and not structured, and certainly not machine-readable, for
> > information that is crucial for project management.
> >
> >
On Fri, Sep 29, 2017 at 9:23 AM, Jeff King wrote:
> On Fri, Sep 29, 2017 at 09:18:11AM +0200, Christian Couder wrote:
>
>> As we use the "prepare_packed_git_run_once" static, this function will
>> only be called only once when packed_git_mru has not yet been
>> initialized, so
Hi Junio,
On Sat, 16 Sep 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Fri, 15 Sep 2017, Junio C Hamano wrote:
> >
> >> --
> >> [Cooking]
> >>
> >> [...]
> >>
> >> *
A donation of 1 million British Pounds to you in good faith
This aims to make git-submodule 'status' a built-in. Hence, the function
cmd_status() is ported from shell to C. This is done by introducing
four functions: module_status(), submodule_status_cb(),
submodule_status() and print_status().
The function module_status() acts as the front-end of the
Introduce function for_each_listed_submodule() and replace a loop
in module_init() with a call to it.
The new function will also be used in other parts of the
system in later patches.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
Introduce function get_submodule_displaypath() to replace the code
occurring in submodule_init() for generating displaypath of the
submodule with a call to it.
This new function will also be used in other parts of the system
in later patches.
Mentored-by: Christian Couder
changes in v6:
* The function get_submodule_displaypath() was modified for the case
when get_super_prefix() returns a non-null value. The condition to check
if the super-prefix ends with a '/' is removed. To accomodate this change
appropriate value of super_prefix is passed instead in the
Eric Rannaud writes:
> On Thu, Sep 28, 2017 at 8:51 PM, Junio C Hamano wrote:
>> I think that your patch the last round that feeds fd#8 in the
>> foreground (i.e. fully trusting that the caller is sensibly giving
>> input that produces no output) is
On 29/09/2017 00:47, Junio C Hamano wrote:
> [jch: a patch that hopefully is applicable is attached at the end;
> I'd appreciate input from Paolo, the contributor of the original
> upstream]
I wasn't involved in upstream commit d42461c3, but Linux is also always
overwriting the revents output
Junio C Hamano writes:
> Or perhaps we could. There is nothing that says a signed tag
> created in the SHA-1 world must have the PGP/SHA-1 signature in the
> NewHash payload---it could be split off of the object data and
> stored in a local metadata cache, to be used only
On Fri, Sep 29, 2017 at 09:18:11AM +0200, Christian Couder wrote:
> On Fri, Sep 29, 2017 at 12:42 AM, Jeff King wrote:
> > On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote:
> >
> >> diff --git a/packfile.c b/packfile.c
> >> index f69a5c8d607af..ae3b0b2e9c09a 100644
On Fri, Sep 29, 2017 at 12:42 AM, Jeff King wrote:
> On Thu, Sep 28, 2017 at 08:38:39AM +, Olga Telezhnaya wrote:
>
>> diff --git a/packfile.c b/packfile.c
>> index f69a5c8d607af..ae3b0b2e9c09a 100644
>> --- a/packfile.c
>> +++ b/packfile.c
>> @@ -876,6 +876,7 @@ void
Add test to explicitly check that 'git bisect reset' is working as
expected. This is already covered implicitly by the test suite.
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
Reimplement the `write_terms` shell function in C and add a `write-terms`
subcommand to `git bisect--helper` to call it from git-bisect.sh . Also
remove the subcommand `--check-term-format` as it can now be called from
inside the function write_terms() C implementation.
Also `|| exit` is added
Reimplement `bisect_clean_state` shell function in C and add a
`bisect-clean-state` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-clean-state` subcommand is a measure to port shell
function to C so as to use the existing test suite. As more functions
are
Reimplement `is_expected_rev` & `check_expected_revs` shell function in
C and add a `--check-expected-revs` subcommand to `git bisect--helper` to
call it from git-bisect.sh .
Using `--check-expected-revs` subcommand is a temporary measure to port
shell functions to C so as to use the existing
`--next-all` is meant to be used as a subcommand to support multiple
"operation mode" though the current implementation does not contain any
other subcommand along side with `--next-all` but further commits will
include some more subcommands.
Helped-by: Johannes Schindelin
Reimplement the `check_term_format` shell function in C and add
a `--check-term-format` subcommand to `git bisect--helper` to call it
from git-bisect.sh
Using `--check-term-format` subcommand is a temporary measure to port
shell function to C so as to use the existing test suite. As more
On Fri, 2017-09-29 at 13:34 +0900, Junio C Hamano wrote:
>
> * ic/fix-filter-branch-to-handle-tag-without-tagger (2017-09-22) 4
> commits
> (merged to 'next' on 2017-09-25 at c7550033df)
> + filter-branch: use hash-object instead of mktag
> + filter-branch: stash away ref map in a branch
> +
Jonathan Nieder writes:
> This document describes what a transition to a new hash function for
> Git would look like. Add it to Documentation/technical/ as the plan
> of record so that future changes can be recorded as patches.
>
> Also-by: Brandon Williams
80 matches
Mail list logo