Jeff King writes:
> On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:
>
>> If you're not coming, you can probably stop reading this message now.
>> The rest is all logistics.
>
> Here are a few additional last-minute logistics:
>
>> For people who want to try to join remotely, I don't th
Piotr Krukowiecki writes:
> Hi,
>
> I have a repo downloaded on machines which do automatic tests.
> Sometimes I want to make a quick fix there and push back to origin.
> Reading git-commit docs I had impression that I can use "--author=me"
> and it will work. But it requires setting global user
Piotr Krukowiecki writes:
>> On Sat, Apr 6, 2019 at 8:25 PM Jakub Narebski wrote:
>>>
>>> Better though is to focus on what you want, namely to prevent accidental
>>> commits without specified author, instead of how you want to achieve it,
>>> i.e.
Piotr Krukowiecki writes:
> On Mon, Apr 8, 2019 at 1:06 PM Jakub Narebski wrote:
>> Piotr Krukowiecki writes:
>>>> On Sat, Apr 6, 2019 at 8:25 PM Jakub Narebski wrote:
>>>>>
>>>>> Better though is to focus on what you want, namely to preven
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>> On Wed, Apr 17 2019, Giuseppe Crinò wrote:
>>
>>> The feature I'm asking is to add an extra-step during rebasing,
>>> checking whether there's a reference to a commit that's not going to
>>> be included in history and asks the user wheth
Hello,
Giuseppe Crinò writes:
> On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski wrote:
>> Well, what about limiting changes and rewriting only to the commits
>> being rewritten by [interactive] rebase? I mean that we would rewrite
>> "revert 01a9fe8" only if:
"_g e r r y _ _l o w r y _"
writes:
>
>
> QUESTION: if YOU use a Windows GUI for Git, i would appreciate knowing which
> one and why
>
> i have been asked to look at GUI versions of Git for Windows.
>
> https://git-scm.com/download/gui/windows currently
SZEDER Gábor writes:
> On Sat, May 18, 2019 at 01:17:06PM +0900, Mike Hommey wrote:
>> On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
>>> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
[...]
> There
Ævar Arnfjörð Bjarmason writes:
> On Thu, May 16 2019, Eric S. Raymond wrote:
>> Derrick Stolee :
>>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
The deeper problem is that I want something from Git that I cannot
have with 1-second granularity. That is: a unique timestamp on each
c
"Eric S. Raymond" writes:
> Jakub Narebski :
>> As far as I understand it this would slow down receiving new commits
>> tremendously. Currently great care is taken to not have to parse the
>> commit object during fetch or push if it is not necessary (thanks to
Derrick Stolee writes:
> On 5/18/2019 12:17 AM, Mike Hommey wrote:
>> On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
>>> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
All the above is without commit-graph, I presume? If so, then you
should give it a tr
Derrick Stolee writes:
> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>
>> Are there any blockers that prevent the switch to this
>> "generation number v2"?
>>
>> - Is it a problem with insufficient data to choose the correct numbering
>>
Elijah Newren writes:
> On Wed, May 15, 2019 at 8:30 AM Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, May 15 2019, Piotr Krukowiecki wrote:
>>>
>>> I'm migrating two repositories from svn. I already did svn->git
>>> migration (git-svn clone) and now have two git repositories.
>>>
>>> I would like t
Jakub Narebski writes:
> Derrick Stolee writes:
>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>
>>> Are there any blockers that prevent the switch to this
>>> "generation number v2"?
[...]
>> Using the generation nu
"Eric S. Raymond" writes:
> Jakub Narebski :
>>> What "commits that follow it?" By hypothesis, the incoming commit's
>>> timestamp is bumped (if it's bumped) when it's first added to a branch
>>> or branches, before there are foll
Derrick Stolee writes:
> On 5/20/2019 7:27 PM, Jakub Narebski wrote:
>> Jakub Narebski writes:
>>> Derrick Stolee writes:
>>>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>>>
>>>>> Are there any blockers
e...@thyrsus.com (Eric S. Raymond) writes:
> I have been thinking hard about the problems raised during my
> request for unique timestamps. I think I've found a better way
> to bust the box I was trying to break out of. I am therefore
> withdrawing that proposal and replacing it with this one.
>
Derrick Stolee writes:
> On 5/22/2019 2:49 PM, Karl Ostmo wrote:
>> After producing the file ".git/objects/info/commit-graph" with the
>> command "git commit-graph write", is there a way to answer queries
>> like "git merge-base --is-ancestor" without having a .git directory?
>> E.g. is there a l
Derrick Stolee writes:
> On 5/22/2019 2:29 PM, Jakub Narebski wrote:
>> Derrick Stolee writes:
>>> On 5/20/2019 7:27 PM, Jakub Narebski wrote:
>>
>> Restating it yet again:
>>
>>A. corrected_date(C) = max(committer_date(C),
>>
Jeff King writes:
> On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Clarify the hash-object docs to explicitly note that the --literally
>> option guarantees that a loose object will be written, but that a
>> normal -w ("write") invocation doesn't.
>
> I had to double
Josh Steadmon writes:
> On 2019.06.12 15:28, Ævar Arnfjörð Bjarmason wrote:
>> On Wed, Jun 12 2019, Josh Steadmon wrote:
>>
>>> trace_schema_validator can be used to verify that trace2 event output
>>> conforms to the expectations set by the API documentation and codified
>>> in event_schema.jso
Jakub Narebski writes:
> Derrick Stolee writes:
>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>
>>> Are there any blockers that prevent the switch to this
>>> "generation number v2"?
>>>
>>> - Is it a problem with insufficient
Ævar Arnfjörð Bjarmason writes:
[...]
> To clarify (and I should have said) I meant it'll include only packed
> commits in the mode Karl Ostmo invoked it in, as Derrick points out.
>
> But yeah, you can of course give it arbitrary starting points, but
> needing to deal with those sorts of caveats
Bikeshed painting ahead.
Nguyễn Thái Ngọc Duy writes:
[...]
> The problem is we try every possible way to resolve a rev. Let's have
> some annotation to express that we only want to resolve a rev in a
> certain way:
>
> - @{hash} only accepts a full hash or a short hash. If it's a
> short hash,
Duy Nguyen writes:
> On Mon, Jul 1, 2019 at 10:32 PM Derrick Stolee via GitGitGadget
> wrote:
>> @@ -601,3 +602,22 @@ core.abbrev::
>> in your repository, which hopefully is enough for
>> abbreviated object names to stay unique for some time.
>> The minimum length is 4.
>>
Mike Hommey writes:
> On Fri, Jul 05, 2019 at 01:14:13AM -0400, Jeff King wrote:
>> On Thu, Jul 04, 2019 at 10:13:20PM +0900, Mike Hommey wrote:
[...]
>> I think I explained all of the memory-usage questions in my earlier
>> response, but just for reference: if you have access to it, valgrind's
>
Johannes Schindelin writes:
> Team,
>
> I kept talking about this idea of a purely online Git Contributor Summit,
> and it is finally time for action.
>
> The idea: just like the Git Contributor Summits we have on the day before
> GitMerge, but instead of traveling to the same place, we'll use an
Josh Steadmon writes:
> Define a JSON schema[1] that can be used to validate trace2 event
> objects. This can be used to add regression tests to verify that the
> event output format does not change unexpectedly.
>
> Two versions of the schema are provided:
Actually, four versions of the schema
Josh Steadmon writes:
> trace_schema_validator can be used to verify that trace2 event output
> conforms to the expectations set by the API documentation and codified
> in event_schema.json (or strict_schema.json). This allows us to build a
> regression test to verify that trace2 output does not
"Randall S. Becker" writes:
> On July 9, 2019 5:51 PM, Peff wrote:
[...]
>> No, textconv only applies when generating a diff to output, and will never
>> impact what's stored in Git.
>>
>> It sounds like you might want a clean filter instead, to sanitize the file
>> contents as they come into Git
Derrick Stolee writes:
> On 7/1/2019 10:29 AM, Derrick Stolee via GitGitGadget wrote:
>>
>> Here is a second run at this RFC, which aims to create a "meta" config
>> setting that automatically turns on other settings according to a user's
>> willingness to trade new Git behavior or new feature ris
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The rev-list command is critical to Git's functionality. Ensure it
> works in the three commit-graph environments constructed in
> t6600-test-reach.sh. Here are a few important types of rev-list
> operations:
>
> * Basic: git r
"Derrick Stolee via GitGitGadget" writes:
> This patch series performs a decently-sized refactoring of the revision-walk
> machinery. Well, "refactoring" is probably the wrong word, as I don't
> actually remove the old code. Instead, when we see certain options in the
> 'rev_info' struct, we redi
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> When running 'git rev-list --topo-order' and its kin, the topo_order
> setting in struct rev_info implies the limited setting. This means
> that the following things happen during prepare_revision_walk():
>
> * revs->limited im
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> There are a few things that need to move around a little before
> making a big refactoring in the topo-order logic:
>
> 1. We need access to record_author_date() and
>compare_commits_by_author_date() in revision.c. These ar
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The current --topo-order algorithm requires walking all
> reachable commits up front, topo-sorting them, all before
> outputting the first value. This patch introduces a new
> algorithm which uses stored generation numbers to
>
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> As we are working to rewrite some of the revision-walk machinery,
> there could easily be some interesting interactions between the
> options that force topological constraints (--topo-order,
> --date-order, and --author-date-o
Derrick Stolee writes:
> On 10/22/2018 9:37 AM, Jakub Narebski wrote:
>> "Derrick Stolee via GitGitGadget" writes:
[...]
>> Sidenote: the new algorithm looks a bit like Unix pipeline, where each
>> step of pipeline does not output much more than next step
Junio C Hamano writes:
> Derrick Stolee writes:
>
>> time git log --topo-order -10 master >/dev/null
>>
>> time git log --topo-order -10 maint..master >/dev/null
>>
>> I get 0.39s for the first call and 0.01s for the second. (Note: I
>> specified "-10" to ensure we are only writing 10 co
SZEDER Gábor writes:
> On Mon, Oct 22, 2018 at 05:36:33PM +0200, Nguyễn Thái Ngọc Duy wrote:
>>
>> The current gettext() function just replaces all strings with
>> '# GETTEXT POISON #' including format strings and hides the things
>> that we should be allowed to grep (like branch names, or some ot
"brian m. carlson" writes:
> SHA-1 is weak and we need to transition to a new hash function. For
> some time, we have referred to this new function as NewHash. Recently,
> we decided to pick SHA-256 as NewHash.
Even if we have decided to not repeat the reasoning behind the need to
switch away
[I have noticed that in some places I wrote A..B instead of B..A. Sorry
about that]
Derrick Stolee writes:
> We've discussed in several places how to improve upon generation
> numbers. This RFC is a report based on my investigation into a
> few new options, and how they compare for Git's purpo
Stefan Beller writes:
>> Based on the performance results alone, we should remove minimum
>> generation numbers, (epoch, date) pairs, and FELINE index from
>> consideration. There are enough examples of these indexes performing
>> poorly.
>>
>> In contrast, maximum generation numbers and correcte
Derrick Stolee writes:
> Here is a re-formatted version of the tables I introduced earlier.
> The tables were too wide for public-inbox to render correctly (when
> paired with my email client). Hopefully this bulleted-list format
> works better. Thanks, Stefan, for pointing out the rendering
> pr
Jakub Narebski writes:
> Stefan Beller writes:
[...]
>> How would this impact creation of a commit?
>>
>> The current generation numbers can be lazily updated or not
>> updated at all. In my understanding of the maximum generation
>> numbers, a new commit wo
Derrick Stolee writes:
> On 10/29/2018 11:59 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
[...]
>>> * **Compatible?** In our test implementation, we use a previously unused
>>>byte of data in the commit-graph format to indicate which reachability
>>>index version we are using. Exis
Derrick Stolee writes:
> On 10/31/2018 8:54 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Tue, Oct 30 2018, Junio C Hamano wrote:
>>> Derrick Stolee writes:
In contrast, maximum generation numbers and corrected commit
dates both performed quite well. They are frequently the top
two
Derrick Stolee writes:
> On 11/1/2018 8:27 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
>>
>>> Please also let me know about any additional tests that I could
>>> run. Now that I've got a lot of test scripts built up, I can re-run
>>> t
Jakub Narebski writes:
> Jakub Narebski writes:
>> Stefan Beller writes:
> [...]
>>> How would this impact creation of a commit?
>>>
>>> The current generation numbers can be lazily updated or not
>>> updated at all. In my understanding of the ma
Junio C Hamano writes:
> Stefan Xenos writes:
>
>> What is the evolve command?
>> ...
>> - Systems like gerrit would no longer need to rely on "change-id" tags
>> in commit comments to associate commits with the change that they
>> edit, since git itself would have that information.
>> ...
>> Is
"Derrick Stolee via GitGitGadget" writes:
> As I was testing the release candidate, I stumbled across a regression in
> 'git merge-base' as a result of the switch to generation numbers. The commit
> message in [PATCH 1/1] describes the topology involved, but you can test it
> yourself by comparin
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> In 3afc679b "commit: use generations in paint_down_to_common()",
> the queue in paint_down_to_common() was changed to use a priority
> order based on generation number before commit date. This served
> two purposes:
>
> 1. Whe
Derrick Stolee writes:
> On 9/21/2018 1:39 PM, Derrick Stolee via GitGitGadget wrote:
> Hello, Git contributors.
>
> I understand that this commit message and patch are pretty
> daunting. There is a lot to read and digest. I would like to see if
> anyone is willing to put the work in to review t
Derrick Stolee writes:
> While iterating through the commit parents, perform the generation
> number calculation and compare against the value stored in the
> commit-graph.
All right, that's good.
What about commit-graph files that have GENERATION_NUMBER_ZERO for all
its commits (because we ver
Derrick Stolee writes:
Nice and simple. The only possible question may be the ordering of
patches in the series, namely whether this change should be before or
after test checking generation numbers.
> Signed-off-by: Derrick Stolee
> ---
> commit-graph.c | 6 ++
> t/t5318-commit-
Derrick Stolee writes:
> The commit-graph file has an extra chunk to store the parent int-ids for
> parents beyond the first parent for octopus merges. Our test repo has a
> single octopus merge that we can manipulate to demonstrate the 'verify'
> subcommand detects incorrect values in that chunk
Derrick Stolee writes:
> The commit-graph file ends with a SHA1 hash of the previous contents. If
> a commit-graph file has errors but the checksum hash is correct, then we
> know that the problem is a bug in Git and not simply file corruption
> after-the-fact.
>
> Compute the checksum right away
Derrick Stolee writes:
> If core.commitGraph is true, verify the contents of the commit-graph
> during 'git fsck' using the 'git commit-graph verify' subcommand. Run
> this check on all alternates, as well.
All right, so we have one config variable to control the use of
serialized commit-graph f
Derrick Stolee writes:
> When writing commit-graph files, it can be convenient to ask for all
> reachable commits (starting at the ref set) in the resulting file. This
> is particularly helpful when writing to stdin is complicated, such as a
> future integration with 'git gc' which will call
> wr
Derrick Stolee writes:
> The commit-graph file is a very helpful feature for speeding up git
> operations. In order to make it more useful, write the commit-graph file
> by default during standard garbage collection operations.
I think you meant here "make it possible to write the commit-graph f
Derrick Stolee writes:
> The commit-graph feature is now integrated with 'fsck' and 'gc',
> so remove those items from the "Future Work" section of the
> commit-graph design document.
It is always nice to have such commit as a summary what was done in the
series, and to have up to date roadmap.
Derrick Stolee writes:
> On 5/31/2018 10:30 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>>> Shallow clones do not interact well with the commit-graph feature for
>>> several reasons. Instead of doing the hard thing to fix those
>>> interactions, instead prevent reading or writing a com
"brian m. carlson" writes:
> On Sat, May 26, 2018 at 08:46:09PM +0200, Jakub Narebski wrote:
>> One issue: in the future when Git moves to NewHash, it could encounter
>> then both commit-graph files using SHA-1 and using NewHash. What about
>> GRPH_OID_LEN the
Derrick Stolee writes:
> On 5/27/2018 6:55 PM, Jakub Narebski wrote:
>> Derrick Stolee writes:
[...]
>>> +static int verify_commit_graph_error;
>>> +
>>> +static void graph_report(const char *fmt, ...)
>>> +{
>>>
Derrick Stolee writes:
> On 5/28/2018 10:05 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
[...]
>>> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
>>> index 6ca451dfd2..bd64481c7a 100755
>>> --- a/t/t5318-commit-graph.sh
>>>
Derrick Stolee writes:
> On 5/30/2018 6:24 PM, Jakub Narebski wrote:
[...]
>> NOTE: we will be checking Commit Data chunk; I think it would be good
>> idea to verify that size of Commit Data chunk matches (N * (H + 16) bytes)
>> that format gives us, so that we don't a
Derrick Stolee writes:
> The commit-graph file stores a condensed version of the commit history.
> This helps speed up several operations involving commit walks. This
> feature does not work well if those commits "change" using features like
> commit grafts, replace objects, or shallow clones.
I
Derrick Stolee writes:
First, this commit seems to try to do two things at once, and in its
current form it should be split into adding destroy_commit_graph() and
into grafts / replacements check. Those are separate and unconnected
features, and should be in separate patches, in my opinion.
> C
"Derrick Stolee via GitGitGadget" writes:
Sidenote: the GitGitGadget doesn't fold/wrap lines properly in the
cover-letter. Not that it is much of a problem.
> One unresolved issue with the commit-graph feature is that it can
> cause issues when combined with replace objects, commit grafts, or
>
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> 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 dif
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> 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.
All right, looks sensible. Did you s
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> 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 2762ca656..6
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> 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-gr
"Derrick Stolee via GitGitGadget" writes:
[I hope that the rest of replies would make it all right through
GitGitGadget]
> From: Derrick Stolee
>
> Signed-off-by: Derrick Stolee
> ---
> commit-graph.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/commit-graph.c b/commit-graph.c
Derrick Stolee writes:
> This commit is not intended to be merged, but is only to create a test
> environment to see what works with the commit-graph feature and what
> does not. The tests that fail are primarily related to corrupting the
> object store to remove a commit from visibility and test
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> Make close_commit_graph() work for arbitrary repositories.
The first line (above) does not match the rest of the commit message.
> Call close_commit_graph() when about to start a rev-list walk that
> includes shallow commits.
Stefan Beller writes:
>> I wonder though if all those changes to the testsuite shouldn't be
>> merged.
>
> I think Stolee doesn't want this to be merged after rereading
> subject and the commit message.
Yes, I understand that, and for the most part I agree with it. This
commit main purpose is t
Junio C Hamano writes:
> * ds/commit-graph-with-grafts (2018-07-19) 8 commits
> (merged to 'next' on 2018-08-02 at 0ee624e329)
> + commit-graph: close_commit_graph before shallow walk
> + commit-graph: not compatible with uninitialized repo
> + commit-graph: not compatible with grafts
> + c
Derrick Stolee writes:
> On 6/25/2019 3:51 AM, Jakub Narebski wrote:
>> Jakub Narebski writes:
>>> Derrick Stolee writes:
[...]
>>> O.K., so the "generation number v2 (legacy)" would be incremental and
>>> backward-compatibile in use (though not i
Hello,
Johannes Schindelin writes:
> On Fri, 20 Sep 2019, Mike Hommey wrote:
>> 6. Newcomers don't really have any idea /what/ they could contribute.
>> They either have to come with their own itch to scratch, or read the
>> code to figure out if there's something to fix.
>
> I think this is ver
Elijah Newren writes:
> On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee wrote:
[...]
>> II. Approach
>>
>> The action items below match the problems listed above.
>>
>> 1. Improve the documentation for contributing to Git.
>>
>> In preparation for this email, I talked to someone familiar with is
Derrick Stolee writes:
> On 9/25/2019 9:36 AM, Pierre Tardy wrote:
[...]
>> And why restrict on DVCS?
>> Isn't it admitted that the distributed version control is nowadays
>> much better in term of software productivity?
>> Is there some use cases that "traditional" centralized VCS are better
>> o
"brian m. carlson" writes:
> I think GitGitGadget is a useful tool which I haven't really had the
> time to learn how to use. I appreciate that many people prefer a
> patch-based workflow, and that using a patch-based workflow and a
> mailing list provides the project independence and avoids fav
I hope that I am addressing the most recent version of this series.
Derrick Stolee writes:
> As promised [1], this patch contains a way to serialize the commit graph.
> The current implementation defines a new file format to store the graph
> structure (parent relationships) and basic commit met
Derrick Stolee writes:
> +== graph-*.graph files have the following format:
What is this '*' here?
[...]
> + The remaining data in the body is described one chunk at a time, and
> + these chunks may be given in any order. Chunks are required unless
> + otherwise specified.
Does Git need to
Derrick Stolee writes:
> On 3/30/2018 9:25 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
>>
>>> +== graph-*.graph files have the following format:
>> What is this '*' here?
>
> No longer necessary. It used to be a placeholder for a hash value,
Derrick Stolee writes:
> On 3/30/2018 7:10 AM, Jakub Narebski wrote:
>> I hope that I am addressing the most recent version of this series.
>
> Hi Jakub. Thanks for the interest in this patch series.
>
> The most-recent version is v6 [1], but I will re-roll to v7 soon
>
Hello,
Derrick Stolee writes:
> This is the first of several "small" patches that follow the serialized
> Git commit graph patch (ds/commit-graph).
>
> As described in Documentation/technical/commit-graph.txt, the generation
> number of a commit is one more than the maximum generation number amo
Derrick Stolee writes:
> On 4/3/2018 2:03 PM, Brandon Williams wrote:
>> On 04/03, Derrick Stolee wrote:
>>> This is the first of several "small" patches that follow the serialized
>>> Git commit graph patch (ds/commit-graph).
>>>
>>> As described in Documentation/technical/commit-graph.txt, the
Derrick Stolee writes:
[...]
> On the Linux repository, performance tests were run for the following
> command:
>
> git log --graph --oneline -1000
>
> Before: 0.92s
> After: 0.66s
> Rel %: -28.3%
>
> Adding '-- kernel/' to the command requires loading the root tree
> for every c
Brandon Williams writes:
> On 03/26, Jeff Hostetler wrote:
[...]
>> All of these cases could be eliminated if the type/size were available
>> in the OID.
>>
>> Just a thought. While we are converting to a new hash it seems like
>> this would be a good time to at least discuss it.
>
> Echoing wh
Derrick Stolee writes:
> On 4/2/2018 10:46 AM, Jakub Narebski wrote:
>> Derrick Stolee writes:
> [...]
>> I see the FELINE-index as a stronger form of generation numbers (called
>> also level of the vertex / node), in that it allows to negative-cut even
>> more, p
Derrick Stolee writes:
> From: Derrick Stolee
>
> If we want to use a hashfile on the temporary file for a lockfile, then
> we need finalize_hashfile() to fully write the trailing hash but also keep
> the file descriptor open.
>
> Do this by adding a new CSUM_HASH_IN_STREAM flag along with a fun
Derrick Stolee writes:
> diff --git a/Documentation/technical/commit-graph-format.txt
> b/Documentation/technical/commit-graph-format.txt
> new file mode 100644
> index 00..ad6af8105c
> --- /dev/null
> +++ b/Documentation/technical/commit-graph-format.txt
> @@ -0,0 +1,97 @@
> +Git commit
Derrick Stolee writes:
> From: Derrick Stolee
>
> Add Documentation/technical/commit-graph.txt with details of the planned
> commit graph feature, including future plans.
That's in my opinion a very good idea. It would help anyone trying to
add to and extend this feature.
> Signed-off-by: Der
Derrick Stolee writes:
> +# Current graph structure:
> +#
> +# __M3___
> +# / | \
> +# 3 M1 5 M2 7
> +# |/ \|/ \|
> +# 246
> +# |___//
> +# 1
Good, so we are testing EDGE chunk, because the commit graph has octopus
merge in it (with more than two parents).
Do we need to tes
Derrick Stolee writes:
[...]
> EXAMPLES
>
> @@ -45,6 +51,12 @@ EXAMPLES
> $ git commit-graph write
>
>
> +* Read basic information from the commit-graph file.
> ++
> +
> +$ git commit-g
Derrick Stolee writes:
> From: Derrick Stolee
>
> The commit graph feature is controlled by the new core.commitGraph config
> setting. This defaults to 0, so the feature is opt-in.
Nice. That's how bitmaps feature was introduced, I think. I guess that
in the future reading would be opt-out, i
Derrick Stolee writes:
> @@ -96,10 +101,12 @@ static int graph_write(int argc, const char **argv)
>builtin_commit_graph_write_options,
>builtin_commit_graph_write_usage, 0);
>
> + if (opts.stdin_packs && opts.stdin_commits)
> +
Hello,
Konstantin Ryabitsev writes:
> This is an entirely idle pondering kind of question, but I wanted to
> ask. I recently discovered that some edge providers are starting to
> offer systems with GPU cards in them -- primarily for clients that need
> to provide streaming video content, I guess
1 - 100 of 195 matches
Mail list logo
