Am 03.10.2018 um 21:40 schrieb Jeff King:
> On Wed, Oct 03, 2018 at 03:16:39PM +0200, René Scharfe wrote:
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index 75047a4b2a..a839315726 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -536,7 +536,7 @@ static int tip_oids_contain(struct oidset
Jeff King wrote:
> On Fri, Aug 17, 2018 at 10:26:05PM -0700, Jonathan Nieder wrote:
>> - testsvn:: is a demo and at a minimum we ought not to install it
>>with "make install"
>>
>> - keeping this in-tree for the benefit of just one user is excessive,
>>so removing it is probably the
On Fri, Aug 17, 2018 at 10:26:05PM -0700, Jonathan Nieder wrote:
> > Of course, I could be completely wrong about people using this. Maybe
> > svn-fe builds are just completely broken on my system, and maybe people
> > really do use testsvn::. But if so, they certainly aren't talking about
> > it
Hi,
Jeff King wrote:
> On Tue, Oct 02, 2018 at 11:43:50AM +0200, Stanisław Drozd wrote:
>> I'm trying to write a fast-import-based git remote helper, but I'm not
>> sure what the output of the `list` command should look like. How can I
>> find an example of the format in action?
>
> There's some
On Tue, Oct 02, 2018 at 07:40:56PM -0400, Jeff King wrote:
> On Mon, Oct 01, 2018 at 07:23:58PM -0700, Taylor Blau wrote:
>
> > +core.alternateRefsCommand::
> > + When advertising tips of available history from an alternate, use the
> > shell to
> > + execute the specified command instead of
On Wed, Oct 03, 2018 at 01:42:39PM +0200, Rasmus Villemoes wrote:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help cmd".
>
> v3: Add some
On Wed, Oct 3, 2018 at 12:52 PM Matthew DeVore wrote:
>
> This is a minor change to the previous rollup. It moves positional
> arguments to the end of git-rev-list invocations. Here is an interdiff
> from v9:
...
There is another problem with this patchset related to dropped exit
codes and
> This seems to break 5520 and 5616 when merged to 'pu'.
>
> It seems that merging master to md/filter-trees and then applying
> this is sufficient to break 5616.
I verified that 5616 is broken on [master + md/filter-trees + my patch],
and after investigation, found a bug in the lazy fetch
A partial clone with missing trees can be obtained using "git clone
--filter=tree:none ". In such a repository, when a tree needs to
be lazily fetched, any tree or blob it directly or indirectly references
is fetched as well, regardless of whether the original command required
those objects, or if
When fetch_pack() is invoked as part of another Git command (due to a
lazy fetch from a partial clone, for example), it uses object flags that
may already be used by the outer Git command.
The commit that introduced the lazy fetch feature (88e2f9ed8e
("introduce fetch-object: fetch one promisor
On Wed, Oct 3, 2018 at 2:34 PM Josh Steadmon wrote:
>
> I believe that git-upload-archive can still speak version 1 without any
> trouble, but it at least doesn't break anything in the test suite to
> limit this to v0 either.
ok, let me just play around with archive to follow along:
Running
On Wed, 3 Oct 2018 at 00:24, Jeff King wrote:
> Yeah, I really like your explanations/diagrams in the comments. It makes
> the logic very clear.
Ok good, I did have the feeling that the logic became actually clearer
to me after I wrestled with the test code, so I think this means I
didn't just
Thanks everyone.
All your answers helped. I found out that the issue was not related to git.
I am using semantic-release to perform a release, apparently
git-credentials is not working with semantic-release.
I did also setup the double authentication and every fix applied on
git-credentials
On 2018.10.02 15:28, Stefan Beller wrote:
> On Tue, Oct 2, 2018 at 3:00 PM Josh Steadmon wrote:
> >
> > For services other than git-receive-pack, clients currently advertise
> > that they support the version set in the protocol.version config,
> > regardless of whether or not there is actually an
I noticed that git-merge-base was unlikely to actually be a git command,
and tried it in my shell. Seeing that it doesn't work, I cleaned up two
places in the docs where it appears.
Signed-off-by: Mihir Mehta
---
Documentation/git-diff.txt | 5 +++--
On Thu, Oct 04, 2018 at 02:34:17AM +0700, Dimitri Kopriwa wrote:
> I have replaced the way I fill the git credentials store, I have verify
> ~/.git-credentials and information are there, the ~/.gitconfig look fine
> too.
>
> I still have 401 error when reading from that file.
>
> This is the
On Wed, Oct 03 2018, Jeff King wrote:
> On Wed, Oct 03, 2018 at 12:08:15PM -0700, Stefan Beller wrote:
>
>> I share these concerns in a slightly more abstract way, as
>> I would bucket the actions into two separate bins:
>>
>> One bin that throws away information.
>> this would include removing
Hi René,
On Wed, 3 Oct 2018, René Scharfe wrote:
> oidset_insert() returns 1 if the object ID is already in the set and
> doesn't add it again, or 0 if it hadn't been present. Make use of that
> fact instead of checking with an extra oidset_contains() call.
>
> Signed-off-by: Rene Scharfe
>
On Wed, Oct 3, 2018 at 12:34 PM Dimitri Kopriwa wrote:
>
> I have replaced the way I fill the git credentials store, I have verify
> ~/.git-credentials and information are there, the ~/.gitconfig look fine
> too.
>
> I still have 401 error when reading from that file.
>
> This is the paste log :
Teach list-objects the "tree:0" filter which allows for filtering
out all tree and blob objects (unless other objects are explicitly
specified by the user). The purpose of this patch is to allow smaller
partial clones.
The name of this filter - tree:0 - does not explicitly specify that
it also
In some cases in this file, BUG makes more sense than die. In such
cases, a we get there from a coding error rather than a user error.
'return' has been removed following some instances of BUG since BUG does
not return.
Signed-off-by: Matthew DeVore
---
list-objects-filter.c | 11 ---
Currently, list-objects.c incorrectly treats all root trees of commits
as USER_GIVEN. Also, it would be easier to mark objects that are
non-user-given instead of user-given, since the places in the code
where we access an object through a reference are more obvious than
the places where we access
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. The --missing=*
and --exclude-promisor-objects flags now work for trees as they already
do for blobs. This is demonstrated in t6112.
Signed-off-by: Matthew DeVore
---
The function gently_parse_list_objects_filter is either called with
errbuf=STRBUF_INIT or errbuf=NULL, but that function calls strbuf_init
when errbuf is not NULL. strbuf_init is only necessary if errbuf
contains garbage, and risks a memory leak if errbuf already has a
non-STRBUF_INIT state. It
If parsing fails when revs->ignore_missing_links and
revs->exclude_promisor_objects are both false, we print the OID anyway
in the die("bad tree object...") call, so any message printed by
parse_tree_gently() is superfluous.
Signed-off-by: Matthew DeVore
---
list-objects.c | 4 +---
1 file
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 158 +++--
1 file changed, 74 insertions(+), 84 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by:
This is a minor change to the previous rollup. It moves positional
arguments to the end of git-rev-list invocations. Here is an interdiff
from v9:
diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh
index 7b6294ca5..53fbf7db8 100755
--- a/t/t5616-partial-clone.sh
+++
From: Johannes Schindelin
Previously, we only ever declared a target Windows version if compiling
with Visual C.
Which meant that we were relying on the MinGW headers to guess which
Windows version we want to target...
Let's be explicit about it, in particular because we actually want to
bump
From: Johannes Schindelin
Windows Vista (and later) actually have a working poll(), but we still
cannot use it because it only works on sockets.
So let's detect when we are targeting Windows Vista and undefine those
constants, and define `pollfd` so that we can declare our own pollfd
struct.
I noticed that a recent GitGitGadget build failed in the Windows phase, with
compat/poll/poll.h problems all over the place.
Turns out that this is caused by the recent upgrade of the mingw-w64 headers
and crt files (7.0.0.5233.e0c09544 -> 7.0.0.5245.edf66197, which I assume
now enforces Vista as
From: Johannes Schindelin
Quite some time ago, a last plea to the XP users out there who want to
see Windows XP support in Git for Windows, asking them to get engaged
and help, vanished into the depths of the universe.
We tried for a long time to play nice with the last remaining XP users
who
On Wed, Oct 03, 2018 at 03:16:39PM +0200, René Scharfe wrote:
> Performance of a command that mainly checks for duplicate objects using
> an oidset, with master and Clang 6.0.1:
>
> $ cmd="./git-cat-file --batch-all-objects --unordered --buffer
> --batch-check='%(objectname)'"
>
> $
I have replaced the way I fill the git credentials store, I have verify
~/.git-credentials and information are there, the ~/.gitconfig look fine
too.
I still have 401 error when reading from that file.
This is the paste log : https://paste.gnome.org/pmntlkdw0
Now that I use git approve, I
On Wed, Oct 03, 2018 at 12:08:15PM -0700, Stefan Beller wrote:
> I share these concerns in a slightly more abstract way, as
> I would bucket the actions into two separate bins:
>
> One bin that throws away information.
> this would include removing expired reflog entries (which
> I do not think
On Wed, Oct 03, 2018 at 02:59:34PM -0400, Derrick Stolee wrote:
> > They don't help yet, and there's no good reason to enable bitmaps for
> > clients. I have a few patches that use bitmaps for things like
> > ahead/behind and --contains checks, but the utility of those may be
> > lessened quite a
>
> But you thought right, I do have an objection against that. 'git gc'
> should, well, collect garbage. Any non-gc stuff is already violating
> separation of concerns.
I share these concerns in a slightly more abstract way, as
I would bucket the actions into two separate bins:
One bin that
On Tue, Aug 14, 2018 at 8:13 AM Jeff Hostetler wrote:
>
> There are a couple of options here:
> [] If really want to omit all trees and blobs (and we DO NOT want
> the oidset of everything omitted), then we might be able to
> shortcut the traversal and speed things up.
>
> {} add a
On 10/3/2018 2:51 PM, Jeff King wrote:
On Wed, Oct 03, 2018 at 08:47:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Wed, Oct 03 2018, Stefan Beller wrote:
So we wouldn't be spending 5 minutes repacking linux.git right after
cloning it, just ~10s generating the commit graph, and the same would
On Wed, Oct 3, 2018 at 1:29 AM Michał Górny wrote:
>
> On Fri, 2018-08-17 at 09:34 +0200, Michał Górny wrote:
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature
On Wed, Oct 03, 2018 at 08:47:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 03 2018, Stefan Beller wrote:
>
> >> So we wouldn't be spending 5 minutes repacking linux.git right after
> >> cloning it, just ~10s generating the commit graph, and the same would
> >> happen if you rm'd
On Wed, Oct 3, 2018 at 5:26 AM Chris Jeschke
wrote:
>
> Hey git-team,
> I am working on a plug-in for a distributed pair programming tool. To
> skip the details: I was thinking about sending parts of the git folder
> as a zip folder with our own Bytestream instead of using the git API.
> Is there
On Wed, Oct 03 2018, Stefan Beller wrote:
>> So we wouldn't be spending 5 minutes repacking linux.git right after
>> cloning it, just ~10s generating the commit graph, and the same would
>> happen if you rm'd .git/objects/info/commit-graph and ran "git commit",
>> which would kick of "gc
On Thu, Oct 04, 2018 at 01:12:11AM +0700, Dimitri Kopriwa wrote:
> Thanks for your reply. I have activated GIT_TRACE_CURL=1 and I can see that
> the request is failing 401.
>
> I can't see which token is used and using what header ?
>
> The log say:
>
> 17:50:26.414654 http.c:657
Thanks for your reply. I have activated GIT_TRACE_CURL=1 and I can see
that the request is failing 401.
I can't see which token is used and using what header ?
The log say:
17:50:26.414654 http.c:657 => Send header: Authorization: Basic
I have retested the token locally and it
On Wed, Oct 3, 2018 at 8:52 AM Jacob Keller wrote:
>
> On Wed, Oct 3, 2018 at 8:05 AM SZEDER Gábor wrote:
> > In fact, it works finer than ever, because running 1.0.0 with this
> > patch on Travis CI notices a possible memmove() -> MOVE_ARRAY()
> > conversion:
> >
> >
> So we wouldn't be spending 5 minutes repacking linux.git right after
> cloning it, just ~10s generating the commit graph, and the same would
> happen if you rm'd .git/objects/info/commit-graph and ran "git commit",
> which would kick of "gc --auto" in the background and do the same thing.
Or
On 10/3/18 11:03 PM, Christian Couder wrote:
(removing git-security from CC)
On Wed, Oct 3, 2018 at 4:09 PM Dimitri Kopriwa wrote:
Git credentials in ~/.git-credentials and ~/.config/git/credentials are
being removed by git upon reading.
https://git-scm.com/docs/git-credential says:
"If
From: Derrick Stolee
The write_commit_graph() method in commit-graph.c leaks some lits
and strings during execution. In addition, a list of strings is
leaked in write_commit_graph_reachable(). Clean these up so our
memory checking is cleaner.
Further, if we use a list of pack-files to find the
From: Derrick Stolee
While writing a commit-graph file, we store the full list of
commits in a flat list. We use this list for sorting and ensuring
we are closed under reachability.
The initial allocation assumed that (at most) one in four objects
is a commit. This is a dramatic over-count for
From: =?UTF-8?q?Martin=20=C3=85gren?=
`graph_verify()`, `graph_read()` and `graph_write()` do the hard work of
`cmd_commit_graph()`. As soon as these return, so does
`cmd_commit_graph()`.
`strbuf_getline()` may allocate memory in the strbuf, yet return EOF.
We need to release the strbuf or
While looking at the commit-graph code, I noticed some memory leaks. These
can be found by running
valgrind --leak-check=full ./git commit-graph write --reachable
The impact of these leaks are small, as we never call write_commit_graph
_reachable in a loop, but it is best to be diligent here.
On Wed, Oct 03, 2018 at 09:06:38PM +0700, Dimitri Kopriwa wrote:
> 18:25:52.940307 git.c:659 trace: exec: git-credential-store
> erase
> 18:25:52.940365 run-command.c:637 trace: run_command:
> git-credential-store erase
> remote: HTTP Basic: Access denied
> fatal:
On Wed, Oct 03, 2018 at 05:19:41PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> >> >> So we should make "git gc --auto" be run on clone,
> >> >> >
> >> >> > There is no garbage after 'git clone'...
> >> >>
> >> >> "git gc" is really "git gc-or-create-indexes" these days.
> >> >
> >> > Because it
On Wed, Oct 3, 2018 at 3:23 PM Ævar Arnfjörð Bjarmason wrote:
>
> Don't have time to patch this now, but thought I'd send a note / RFC
> about this.
>
> Now that we have the commit graph it's nice to be able to set
> e.g. core.commitGraph=true & gc.writeCommitGraph=true in ~/.gitconfig or
>
On Wed, Oct 3, 2018 at 9:26 AM Matthew DeVore wrote:
>
> - git -C pc1 rev-list HEAD --quiet --objects --missing=print >revs &&
> + git -C pc1 rev-list --quiet --objects --missing=print >revs HEAD &&
> awk -f print_1.awk revs |
...
> git -C pc1 blame origin/master --
It is a common mistake to put positional arguments before flags when
invoking git-rev-list. Order the positional arguments last.
This patch skips git-rev-list invocations which include the --not flag,
since the ordering of flags and positional arguments affects the
behavior. This patch also skips
Fix various places where the ordering was obviously wrong, meaning it
was easy to find with grep.
Signed-off-by: Matthew DeVore
---
t/t-basic.sh | 2 +-
t/t0021-conversion.sh | 4 +--
t/t1300-config.sh | 4 +--
'git ... | foo' will mask any errors or crashes in git, so split up such
pipes in this file.
One testcase uses several separate pipe sequences in a row which are
awkward to split up. Wrap the split-up pipe in a function so the
awkwardness is not repeated. Also change that testcase's surrounding
Some pipes in tests lose the exit code of git processes, which can mask
unexpected behavior like crashes. Split these pipes up so that git
commands are only at the end of pipes rather than the beginning or
middle.
The violations fixed in this patch were found in the process of fixing
pipe
The list of Don'ts for test writing has grown large such that it is hard
to see at a glance which section an item is in. In other words, if I
ignore a little bit of surrounding context, the "don'ts" look like
"do's."
To make the list more readable, prefix "Don't" in front of every first
sentence
Add the following guideline to Documentation/CodingGuidelines:
&&, ||, and | should appear at the end of lines, not the
beginning, and the \ line continuation character should be
omitted
And the following to t/README (since it is specific to writing tests):
pipes
Instead of using a line-continuation and pipe on the second line, take
advantage of the shell's implicit line continuation after a pipe
character. So for example, instead of
some long line \
| next line
use
some long line |
next line
And add a blank
Apply suggestions by Szeder and Eric from last version of the patch,
namely:
- Use a sensible example for how one can unknowingly drop a Git exit
code in tests.
- Fixed the message for the second commit.
- Move the test-specific coding guidelines to t/README from
On Wed, 3 Oct 2018 at 18:19, Derrick Stolee wrote:
> I'm fine with squashing it in with both our sign-offs. It is the same
> idea, it just requires a different set of arguments to hit it. I'll
> adjust the commit message as necessary.
> I'll add your PATCH 2/2 to my v2. Thanks!
Cool, thanks a
On 10/3/2018 11:36 AM, Martin Ågren wrote:
Hi Derrick,
These two patches on top of yours make the test suite (i.e., the subset
of it that I run) leak-free with respect to builtin/commit-graph.c and
commit-graph.c.
Thanks!
The first could be squashed into your patch 1/2. It touches the same
(removing git-security from CC)
On Wed, Oct 3, 2018 at 4:09 PM Dimitri Kopriwa wrote:
> Git credentials in ~/.git-credentials and ~/.config/git/credentials are
> being removed by git upon reading.
https://git-scm.com/docs/git-credential says:
"If the action is reject, git-credential will send
On Wed, Oct 3, 2018 at 8:05 AM SZEDER Gábor wrote:
> In fact, it works finer than ever, because running 1.0.0 with this
> patch on Travis CI notices a possible memmove() -> MOVE_ARRAY()
> conversion:
>
> https://travis-ci.org/szeder/git/jobs/436542684#L576
>
> Surprisingly, running 1.0.0
On Wed, Oct 3, 2018 at 3:17 AM SZEDER Gábor wrote:
>
> On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote:
> > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
> >
> > > make coccicheck is used in order to apply coccinelle semantic patches,
> > > and see if any of the
Hi Derrick,
These two patches on top of yours make the test suite (i.e., the subset
of it that I run) leak-free with respect to builtin/commit-graph.c and
commit-graph.c.
The first could be squashed into your patch 1/2. It touches the same
function, but it requires a different usage to trigger,
`graph_verify()`, `graph_read()` and `graph_write()` do the hard work of
`cmd_commit_graph()`. As soon as these return, so does
`cmd_commit_graph()`.
`strbuf_getline()` may allocate memory in the strbuf, yet return EOF.
We need to release the strbuf or UNLEAK it. Go for the latter since we
are
`close_pack(p)` does not free the memory which `p` points to, so follow
up with a call to `free(p)`. All other users of `close_pack()` look ok.
Signed-off-by: Martin Ågren
---
commit-graph.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/commit-graph.c b/commit-graph.c
index
On Wed, Oct 03 2018, SZEDER Gábor wrote:
> On Wed, Oct 03, 2018 at 04:22:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Wed, Oct 03 2018, SZEDER Gábor wrote:
>>
>> > On Wed, Oct 03, 2018 at 04:01:40PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >>
>> >> On Wed, Oct 03 2018, SZEDER Gábor
On Wed, Oct 03, 2018 at 12:16:58PM +0200, SZEDER Gábor wrote:
> On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote:
> > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
> >
> > > make coccicheck is used in order to apply coccinelle semantic patches,
> > > and see if any of the
From: Johannes Schindelin
The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.
Sometimes this functionality would come in handy *without*
cherry-picking a
Stefan asked a while back
[https://public-inbox.org/git/20180118183618.39853-3-sbel...@google.com/]
for a todo command in interactive rebases that would essentially perform the
"stop" part of the edit command, but without the "pick" part: interrupt the
interactive rebase, with exit code 0,
On Wed, Oct 03, 2018 at 04:22:12PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 03 2018, SZEDER Gábor wrote:
>
> > On Wed, Oct 03, 2018 at 04:01:40PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >>
> >> On Wed, Oct 03 2018, SZEDER Gábor wrote:
> >>
> >> > On Wed, Oct 03, 2018 at 03:23:57PM
On Wed, Oct 3, 2018 at 4:01 PM Ævar Arnfjörð Bjarmason wrote:
> >> and change the
> >> need_to_gc() / cmd_gc() behavior so that we detect that the
> >> gc.writeCommitGraph=true setting is on, but we have no commit graph, and
> >> then just generate that without doing a full repack.
> >
> > Or
On Wed, Oct 03 2018, SZEDER Gábor wrote:
> On Wed, Oct 03, 2018 at 04:01:40PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Wed, Oct 03 2018, SZEDER Gábor wrote:
>>
>> > On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >> Don't have time to patch this now, but
On Wed, Oct 03 2018, Derrick Stolee wrote:
> On 10/3/2018 9:36 AM, SZEDER Gábor wrote:
>> On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>> Don't have time to patch this now, but thought I'd send a note / RFC
>>> about this.
>>>
>>> Now that we have the commit graph
On Wed, Oct 03, 2018 at 04:01:40PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 03 2018, SZEDER Gábor wrote:
>
> > On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> Don't have time to patch this now, but thought I'd send a note / RFC
> >> about this.
> >>
>
Dear Git list,
I have tried to used git credentials within Gitlab-CI runners. I have 4
instance of GitLab and discovered a weird bug with Git credentials when
use within a CI process.
Please note before all that the time spend allowed me multiple time to
check that my credentials are valid
On Wed, Oct 03 2018, SZEDER Gábor wrote:
> On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> Don't have time to patch this now, but thought I'd send a note / RFC
>> about this.
>>
>> Now that we have the commit graph it's nice to be able to set
>> e.g.
Thank you so much, I will check this GIT bundle
Since you asked, here are my answers suffixed by MHS >>
Michele
-Original Message-
From: Philip Oakley [mailto:philipoak...@iee.org]
Sent: Wednesday, October 3, 2018 12:00 AM
To: Michele Hallak; git@vger.kernel.org
Subject: Re: git
On 10/3/2018 9:36 AM, SZEDER Gábor wrote:
On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
Don't have time to patch this now, but thought I'd send a note / RFC
about this.
Now that we have the commit graph it's nice to be able to set
e.g. core.commitGraph=true &
On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Don't have time to patch this now, but thought I'd send a note / RFC
> about this.
>
> Now that we have the commit graph it's nice to be able to set
> e.g. core.commitGraph=true & gc.writeCommitGraph=true in ~/.gitconfig
Don't have time to patch this now, but thought I'd send a note / RFC
about this.
Now that we have the commit graph it's nice to be able to set
e.g. core.commitGraph=true & gc.writeCommitGraph=true in ~/.gitconfig or
/etc/gitconfig to apply them to all repos.
But when I clone e.g. linux.git stuff
Reimplement oidset using khash.h in order to reduce its memory footprint
and make it faster.
Performance of a command that mainly checks for duplicate objects using
an oidset, with master and Clang 6.0.1:
$ cmd="./git-cat-file --batch-all-objects --unordered --buffer
Add a function for releasing the khash-internal allocations, but not the
khash structure itself. It can be used with on-stack khash structs.
Signed-off-by: Rene Scharfe
---
1 tab = 4 spaces here.
khash.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/khash.h
Continue the discussion of speeding up oidset started in [1] here in
its own thread.
[1] https://public-inbox.org/git/20180811172350.ga2...@sigill.intra.peff.net/
The first patch does a mild refactoring to support khash structures
on the stack, and the second one converts oidset to khash.
oidset_insert() returns 1 if the object ID is already in the set and
doesn't add it again, or 0 if it hadn't been present. Make use of that
fact instead of checking with an extra oidset_contains() call.
Signed-off-by: Rene Scharfe
---
sequencer.c | 4 +---
1 file changed, 1 insertion(+), 3
Am 17.09.2018 um 17:58 schrieb Jonathan Nieder:
[...]
> Ah, thanks. See git-config(1):
>
> core.bigFileThreshold
> Files larger than this size are stored deflated,
> without attempting delta compression.
>
> Default is 512 MiB on all platforms.
Hey git-team,
I am working on a plug-in for a distributed pair programming tool. To
skip the details: I was thinking about sending parts of the git folder
as a zip folder with our own Bytestream instead of using the git API.
Is there a common sense about what should and what shouldn't be done
when
On 10/2/2018 6:44 PM, Stefan Beller wrote:
My preference is to avoid them in the name of simplicity. If you're
using "make SANITIZE=leak test" to check for leaks, it will skip these
cases. If you're using valgrind, I think these may be reported as
"reachable". But that number already isn't
Most git commands respond to -h anywhere in the command line, or at
least as a first and lone argument, by printing the usage
information. For aliases, we can provide a little more information that
might be useful in interpreting/understanding the following output by
prepending a line telling that
v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
config option, no delay) redirect to the aliased command's help,
preserve pre-existing behaviour of the spelling "git help cmd".
v3: Add some additional comments in patch 1 and avoid triggering leak
checker reports. Use better
As discussed in the thread for v1 of this patch [1] [2], this changes the
rules for "git foo --help" when foo is an alias.
(0) When invoked as "git help foo", we continue to print the "foo is
aliased to bar" message and nothing else.
(1) If foo is an alias for a shell command, print "foo is
This documents the existing behaviour of "git help cmd" when cmd is an
alias, as well as providing a hint to use the "git cmd --help" form to
be taken directly to the man page for the aliased command.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-help.txt | 4
1 file changed, 4
On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote:
> On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
>
> > make coccicheck is used in order to apply coccinelle semantic patches,
> > and see if any of the transformations found within contrib/coccinelle/
> > can be applied to
On Tue, 2 Oct 2018 at 20:04, Phillip Wood wrote:
> const struct emitted_diff_symbol *longer = a->len > b->len ? a : b;
> const struct emitted_diff_symbol *shorter = a->len > b->len ? b : a;
> int d = longer->len - shorter->len;
> + int ret = !strncmp(longer->line +
1 - 100 of 109 matches
Mail list logo
