Hello all,
Due to the following mathematical proof, stating it is right to be a
normal female or male, we must now all file formal complaints about
products lying, it was not OK to be a normal female or male.
- Die naturalistic-fallacy ist inzwischen als (nature&community)
gelöst, und "we made it
SZEDER Gábor wrote:
> On Thu, Sep 19, 2019 at 11:34:21AM -0300, Joseph Mingrone wrote:
> > Hello,
> >
> > We maintain a .gitauthors file for git-svn. When a new committer is
> > added to our project, a new entry is added to the .gitauthors file,
> > but we sometimes see errors like this:
> >
>
What does the soul do? It just says NO.
On Fri, Sep 20, 2019 at 7:04 AM Klaus Sembritzki wrote:
>
> Our harrassers have no soul, please help.
>
> On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki wrote:
> >
> > I hereby instruct the German military to kill our harrassers.
> >
> > On Thu, Sep 19,
Our harrassers have no soul, please help.
On Thu, Sep 19, 2019 at 10:20 PM Klaus Sembritzki wrote:
>
> I hereby instruct the German military to kill our harrassers.
>
> On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki wrote:
> >
> > Hello all,
> >
> > A game-theoretical insight, as the GIT maili
On Thu, Sep 19, 2019 at 10:17:57PM -0400, Derrick Stolee wrote:
> > I.e., I think we want to grow the community a bit more organically,
> > which should be more sustainable in the long run.>
> > So I think any advertising would be more about making it clear that _if_
> > you have an idea, we're ve
On 9/19/2019 6:16 PM, Jeff King wrote:
> On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
>>
>> 5. Advertise that Git wants new contributors
>>
> This point is the one I'm least on board with. Not because I'm not
> thrilled to have new contributors, but that to some degree I think th
On Thu, Sep 19, 2019 at 11:34:21AM -0300, Joseph Mingrone wrote:
> Hello,
>
> We maintain a .gitauthors file for git-svn. When a new committer is
> added to our project, a new entry is added to the .gitauthors file,
> but we sometimes see errors like this:
>
> % git -C /usr/ports svn rebase
>
Please ignore this patch as well.
On Thu, Sep 19, 2019 at 11:47:12PM +0200, SZEDER Gábor wrote:
> The loop iterating over the parent commits in the name_rev() function
> contains two xstrfmt() calls, and their result is leaked if the parent
> commit is not processed further (because that parent ha
On 2019.09.19 14:23, Jeff Hostetler wrote:
>
>
> On 9/16/2019 2:20 PM, Josh Steadmon wrote:
> > On 2019.09.16 10:11, Jeff Hostetler wrote:
> > >
> > >
> > > On 9/16/2019 8:07 AM, Derrick Stolee wrote:
> > > > On 9/13/2019 8:26 PM, Josh Steadmon wrote:
> > > > > Add a new "overload" event type f
Please ignore this mail.
On Thu, Sep 19, 2019 at 11:47:10PM +0200, SZEDER Gábor wrote:
> The name_rev() function's 'tip_name' parameter is a freshly
> xstrdup()ed string, so when name_rev() invokes:
>
> tip_name = xstrfmt("%s^0", tip_name);
>
> then the original 'tip_name' string is leaked.
>
On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> Feel free to pick apart all of the claims I make below. This is based
> on my own experience and opinions. It should be a good baseline
> for us to all arrive with valuable action items.
First off, thanks for starting this conversa
On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:
> > 4. Add an official Code of Conduct
> >
> > So far, the community has had an unofficial policy of "be nice,
> > as much as possible". We should add a Code of Conduct that is
> > more explicit about the behavior we want to model. This
On Thu, Sep 19, 2019 at 11:37 AM Derrick Stolee wrote:
>
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to make the community
> more welcoming to new contributors of all kinds. Let's discuss some of
> the ideas we
Use strip_suffix() instead of open-coding it, making the code more
idiomatic.
Signed-off-by: SZEDER Gábor
---
builtin/name-rev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index c785fe16ba..d345456656 100644
--- a/builtin/n
In 'builtin/name-rev.c' in the name_rev() function there is a loop
iterating over all parents of the given commit, and the loop body
looks like this:
if (parent_number > 1) {
if (generation > 0)
// do stuff #1
else
// do stuff #2
} else {
// do stuff #3
}
These cond
The 'check_describe' helper function runs 'git describe' outside of
'test_expect_success' blocks, with extra hand-rolled code to record
and examine its exit code.
Update this helper and move the 'git decribe' invocation inside the
'test_expect_success' block.
Signed-off-by: SZEDER Gábor
---
t/t
Following the previous patches in this series we can get the values of
name_rev()'s 'generation' and 'distance' parameters from the 'stuct
rev_name' associated with the commit as well.
Let's simplify the function's signature and remove these two
unnecessary parameters.
Note that at this point we
Signed-off-by: SZEDER Gábor
---
builtin/name-rev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index e406ff8e17..dec2228cc7 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -98,7 +98,7 @@ static void name_rev(struct commit
The 'if (deref) { ... }' condition near the beginning of the recursive
name_rev() function can only ever be true in the first invocation,
because the 'deref' parameter is always 0 in the subsequent recursive
invocations.
Extract this condition from the recursion into name_rev()'s caller and
drop t
The name_rev() function's 'tip_name' parameter is a freshly
xstrdup()ed string, so when name_rev() invokes:
tip_name = xstrfmt("%s^0", tip_name);
then the original 'tip_name' string is leaked.
Make sure that this string is free()d after it has been used as input
for that xstrfmt() call.
This
Earlier patches in this series moved a couple of conditions from the
recursive name_rev() function into its caller name_ref(), for no other
reason than to make eliminating the recursion a bit easier to follow.
Since the previous patch name_rev() is not recursive anymore, so let's
move all those co
In a later patch in this series we'll want to do this in two places.
Signed-off-by: SZEDER Gábor
---
builtin/name-rev.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index dec2228cc7..cb8ac2f
At the beginning of the recursive name_rev() function it creates a new
'struct rev_name' instance for each previously unvisited commit or, if
this visit results in better name for an already visited commit, then
updates the 'struct rev_name' instance attached to to the commit, or
returns early.
Re
The loop iterating over the parent commits in the name_rev() function
contains two xstrfmt() calls, and their result is leaked if the parent
commit is not processed further (because that parent has already been
visited before, and this further visit doesn't result in a better name
for its ancestors
At the beginning of the recursive name_rev() function it parses the
commit it got as parameter, and returns early if the commit is older
than a cutoff limit.
Restructure this so the caller parses the commit and checks its date,
and doesn't invoke name_rev() if the commit to be passed as parameter
The loop iterating over the parent commits in the name_rev() function
contains two xstrfmt() calls, and their result is leaked if the parent
commit is not processed further (because that parent has already been
visited before, and this further visit doesn't result in a better name
for its ancestors
The name_rev() function calls itself recursively for each interesting
parent of the commit it got as parameter, and, consequently, it can
segfault when processing a deep history if it exhausts the available
stack space. E.g. running 'git name-rev --all' and 'git name-rev
HEAD~10' in the gcc, g
Casting a 'struct object' to 'struct commit' is unnecessary there,
because it's already available in the local 'commit' variable.
Signed-off-by: SZEDER Gábor
---
builtin/name-rev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index d
The name_rev() function's 'tip_name' parameter is a freshly
xstrdup()ed string, so when name_rev() invokes:
tip_name = xstrfmt("%s^0", tip_name);
then the original 'tip_name' string is leaked.
Make sure that this string is free()d after it has been used as input
for that xstrfmt() call.
This
'git name-rev' is implemented using a recursive algorithm, and,
consequently, it can segfault in deep histories (e.g. WebKit), and
thanks to a test case demonstrating this limitation every test run
results in a dmesg entry logging the segfaulting git process.
This patch series eliminates the recur
At the top of 't6120-describe.sh' an ASCII graph illustrates the
repository's history used in this test script. This graph is a bit
misleading, because it swapped the second merge commit's first and
second parents.
When describing/naming a commit it does make a difference which parent
is the firs
On 09/18, Junio C Hamano wrote:
> * tg/stash-refresh-index (2019-09-05) 3 commits
> - stash: make sure to write refreshed cache
> - merge: use refresh_and_write_cache
> - factor out refresh_and_write_cache function
>
> "git stash" learned to write refreshed index back to disk.
>
> Needs coor
On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to make the community
> more welcoming to new contributors of all kinds. Let's discuss some of
> the ide
On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
> @@ -848,6 +953,10 @@ static int add_patterns_from_buffer(char *buf, size_t
> size,
> int i, lineno = 1;
> char *entry;
>
> + pl->use_cone_patterns = core_sparse_checkout_cone;
> + hashmap_init(&pl->recursive_hash
Use the macro COPY_ARRAY to copy array elements and MOVE_ARRAY to do the
same for moving them backwards in an array with potential overlap. The
result is shorter and safer, as it infers the element type automatically
and does a (very) basic type compatibility check for its first two
arguments.
Th
Thanks for sending this. I guess I don't know the alphabet very well :)
A different color we could paint the bikeshed would be to write "add a
new line for `psuh` immediately after it" in these places instead. But I
have no preference whatsoever.
- Emily
Reviewed-by: Emily Shaffer
On Thu, Sep
On Thu, Sep 19, 2019 at 10:34:23AM -0700, Denton Liu wrote:
> Aside from getting the first email sent, most of my time learning to
> contribute to Git stemmed from the fact that there's a lot of tribal
> knowledge that's not really written down anywhere. Here are some of the
> smaller things that c
I hereby instruct the German military to kill our harrassers.
On Thu, Sep 19, 2019 at 9:12 PM Klaus Sembritzki wrote:
>
> Hello all,
>
> A game-theoretical insight, as the GIT mailing-list has just been
> hacked: Such a move necessitates everyone to down-value the hackers'
> intellects, if it was
On Thu, Sep 19, 2019 at 12:11:05PM -0700, Denton Liu wrote:
> > > For the record, you could do a
> > >
> > > git cherry-pick -Xsubtree=git-gui 00ddc9d13c 7560f547e6
I forgot one more thing, if you end up doing this, you should probably
sign-off on your cherry-picks by doing `-s`.
Hello all,
A game-theoretical insight, as the GIT mailing-list has just been
hacked: Such a move necessitates everyone to down-value the hackers'
intellects, if it was not a false-flag-operation.
Cheers,
Klaus Sembritzki
On Thu, Sep 19, 2019 at 8:44 PM Klaus Sembritzki wrote:
>
> Hello all,
>
On Fri, Sep 20, 2019 at 12:33:59AM +0530, Pratyush Yadav wrote:
> On 19/09/19 11:47AM, Denton Liu wrote:
> > On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> > > Hi Junio,
> > >
> > > On 18/09/19 10:49AM, Junio C Hamano wrote:
> > > > Pratyush Yadav writes:
> > > > You should be
On 19/09/19 11:47AM, Denton Liu wrote:
> On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> > Hi Junio,
> >
> > On 18/09/19 10:49AM, Junio C Hamano wrote:
> > > Pratyush Yadav writes:
> > > You should be able to merge this (and all other git-gui topics
> > > already in my tree Dent
Using the pull command instead of push is more accurate when giving
instructions on placing the psuh command in alphabetical order.
Signed-off-by: Pedro Sousa
---
Documentation/MyFirstContribution.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/MyFir
On Fri, Sep 20, 2019 at 12:02:58AM +0530, Pratyush Yadav wrote:
> Hi Junio,
>
> On 18/09/19 10:49AM, Junio C Hamano wrote:
> > Pratyush Yadav writes:
> > You should be able to merge this (and all other git-gui topics
> > already in my tree Denton pointed out) to your 'master'. If you
> > then ma
Hello all,
1. Long texts stem from false (You can deduce anything from something
that is wrong).
2. TL;DR is therefore sane.
3. (Inclusion & Diversity) is a tautology, it includes all of it.
Cheers,
Klaus Sembritzki
On Thu, Sep 19, 2019 at 8:35 PM Derrick Stolee wrote:
>
> During the Virtual G
Am 18.09.19 um 23:44 schrieb Kamil Domański:
> On 9/18/19 8:28 AM, Johannes Sixt wrote:
>> Am 18.09.19 um 02:11 schrieb Kamil Domański:
>>> DESCRIPTION
>>> ---
>>> @@ -21,6 +21,11 @@ commit IDs.
>>> OPTIONS
>>> ---
>>> +--count=::
>>> + By default the command shows all re
Hi Junio,
On 18/09/19 10:49AM, Junio C Hamano wrote:
> Pratyush Yadav writes:
> You should be able to merge this (and all other git-gui topics
> already in my tree Denton pointed out) to your 'master'. If you
> then make a trial merge of the result back into my tree with "git
> merge -Xsubtree=g
On 9/16/2019 2:20 PM, Josh Steadmon wrote:
On 2019.09.16 10:11, Jeff Hostetler wrote:
On 9/16/2019 8:07 AM, Derrick Stolee wrote:
On 9/13/2019 8:26 PM, Josh Steadmon wrote:
Add a new "overload" event type for trace2 event destinations. Write
this event into the sentinel file created by th
Travis CI offers shell access to its virtual machine environment
running the build jobs, called "debug mode" [1]. After restarting a
build job in debug mode and logging in, the first thing I usually do
is to install dependencies, i.e. run './ci/install-dependencies.sh'.
This works just fine when I
Hello,
As a relatively new contributor (just less than a year), I guess I'll
share some thoughts:
On Thu, Sep 19, 2019 at 12:30:13PM -0400, Derrick Stolee wrote:
> During the Virtual Git Contributors' Summit, Dscho brought up the topic of
> "Inclusion & Diversity". We discussed ideas for how to m
During the Virtual Git Contributors' Summit, Dscho brought up the topic of
"Inclusion & Diversity". We discussed ideas for how to make the community
more welcoming to new contributors of all kinds. Let's discuss some of
the ideas we talked about, and some that have been growing since.
Feel free to
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
as arguments and writes them to the sparse-checkout file. Then, it
updates the working directory using 'git read-tree -mu HEAD'.
The 'set' subcommand will replace the entire contents of the
sparse-checkout fil
This series makes the sparse-checkout feature more user-friendly. While
there, I also present a way to use a limited set of patterns to gain a
significant performance boost in very large repositories.
Sparse-checkout is only documented as a subsection of the read-tree docs
[1], which makes the fea
From: Derrick Stolee
The sparse-checkout feature can have quadratic performance as
the number of patterns and number of entries in the index grow.
If there are 1,000 patterns and 1,000,000 entries, this time can
be very significant.
Create a new Boolean config option, core.sparseCheckoutCone, to
From: Derrick Stolee
The parent and recursive patterns allowed by the "cone mode"
option in sparse-checkout are restrictive enough that we
can avoid using the regex parsing. Everything is based on
prefix matches, so we can use hashsets to store the prefixes
from the sparse-checkout file. When che
From: Derrick Stolee
The 'git sparse-checkout set' subcommand takes a list of patterns
and places them in the sparse-checkout file. Then, it updates the
working directory to match those patterns. For a large list of
patterns, the command-line call can get very cumbersome.
Add a '--stdin' option
From: Derrick Stolee
To make the cone pattern set easy to use, update the behavior of
'git sparse-checkout [init|set]'.
Add '--cone' flag to 'git sparse-checkout init' to set the config
option 'core.sparseCheckoutCone=true'.
When running 'git sparse-checkout set' in cone mode, a user only
needs
From: Derrick Stolee
The instructions for disabling a sparse-checkout to a full
working directory are complicated and non-intuitive. Add a
subcommand, 'git sparse-checkout disable', to perform those
steps for the user.
Signed-off-by: Derrick Stolee
---
Documentation/git-sparse-checkout.txt | 2
From: Jeff Hostetler
When Git updates the working directory with the sparse-checkout
feature enabled, the unpack_trees() method calls clear_ce_flags()
to update the skip-wortree bits on the cache entries. This
check can be expensive, depending on the patterns used.
Add trace2 regions around the
From: Derrick Stolee
The sparse-checkout feature is mostly hidden to users, as its
only documentation is supplementary information in the docs for
'git read-tree'. In addition, users need to know how to edit the
.git/info/sparse-checkout file with the right patterns, then run
the appropriate 'git
From: Derrick Stolee
The sparse-checkout feature in "cone mode" can use the fact that
the recursive patterns are "connected" to the root via parent
patterns to decide if a directory is entirely contained in the
sparse-checkout or entirely removed.
In these cases, we can skip hashing the paths wi
From: Derrick Stolee
Getting started with a sparse-checkout file can be daunting. Help
users start their sparse enlistment using 'git sparse-checkout init'.
This will set 'core.sparseCheckout=true' in their config, write
an initial set of patterns to the sparse-checkout file, and update
their wor
From: Derrick Stolee
When someone wants to clone a large repository, but plans to work
using a sparse-checkout file, they either need to do a full
checkout first and then reduce the patterns they included, or
clone with --no-checkout, set up their patterns, and then run
a checkout manually. This
Hello,
We maintain a .gitauthors file for git-svn. When a new committer is
added to our project, a new entry is added to the .gitauthors file,
but we sometimes see errors like this:
% git -C /usr/ports svn rebase
M .gitauthors
r512146 = 0c1f924ca984d5beabb909ea53afb856c44b (ref
Here is today's test coverage report.
It's been a while, because I intended to modify the code to add
commit-by-commit grouping of the uncovered lines. However, that is not a simple
change and I haven't gotten around to it. Hopefully I can do it soon, or
someone could contribute one on
https:/
65 matches
Mail list logo
