On Tue, Aug 29, 2017 at 10:20:25AM +0200, Michael Haggerty wrote:
> The old code incremented the packed ref cache reference count when
> acquiring the packed-refs lock, and decremented the count when
> releasing the lock. This is unnecessary because a locked packed-refs
> file cannot be changed, s
Jeff King writes:
> IOW, something like the patch below, which pushes the re-parsing out to
> the stdin code-path, and lets the internal traversal format directly
> into the final buffer. It seems to be about 3% faster than the existing
> code, and fixes the leak (by dropping that variable entire
Jeff King writes:
> That's definitely the intent, but I think --follow is just buggy here.
> We don't seem to trigger a diff, which is where "git log" does the
> follow check (because of the way it's bolted onto the diff, and not the
> actual pathspec-pruning mechanism).
Yeah, at the same time,
On Tue, Sep 05, 2017 at 09:01:50AM -0400, Jeff King wrote:
> Most of this is actual leak fixes. The interesting part, I think, is the
> UNLEAK annotation in patch 10.
>
> [01/10]: test-lib: --valgrind should not override --verbose-log
> [02/10]: test-lib: set LSAN_OPTIONS to abort by default
On Thu, Sep 07, 2017 at 12:30:01PM -0700, Stefan Beller wrote:
> > "--follow" switch is not listed on
> > https://git-scm.com/docs/git-shortlog so maybe it's not supported. In
> > this case I would expect error message.
> >
> > Tried the following versions:
> > "git version 2.14.1.windows.1" on Wi
Michael Haggerty writes:
> + git for-each-ref $prefix >actual &&
> + grep "Unable to create $Q.*packed-refs.lock$Q: File exists" err &&
I added a squash for doing s/grep/test_i18n&/ here; are there other
issues in the series, or is the series more or less ready to be
polished in 'next'?
On Thu, Sep 07, 2017 at 11:56:48PM -0400, Jeff King wrote:
> > True; I do not think string_list API does. But for this particular
> > application, I suspect that we can by looking at the util field of
> > the item returned. A newly created one has NULL, but we always make
> > it non-NULL before
On Fri, Sep 08, 2017 at 09:33:38AM +0900, Junio C Hamano wrote:
> >> An alterative, as this is the only place we add to log->list, could
> >> be to make log->list take ownership of the string by not adding a
> >> _release() here but instead _detach(), I guess.
> >
> > I agree that would be better,
On Fri, Sep 08, 2017 at 12:37:28PM +0900, Junio C Hamano wrote:
> > I'm still moderately against storing generation numbers inside the
> > objects. They're redundant with the existing parent pointers, which
> > means it's an opportunity for the two sets of data to disagree. And as
> > we've seen,
On Thu, Sep 07, 2017 at 05:08:23PM +0100, Ramsay Jones wrote:
> Hi Jeff,
>
> If you need to re-roll your 'jk/leak-checkers' branch, could you
> please squash this into the relevant patch (commit c57586d954,
> "add UNLEAK annotation for reducing leak false positives", 05-09-2017).
>
> This was no
Jeff King writes:
> On Thu, Sep 07, 2017 at 12:24:02PM -0700, Stefan Beller wrote:
>
>> > We've discussed storing true generation numbers in the past, which would
>> > make this optimization more robust, as well as allow us to speed up many
>> > other traversals (e.g., the "tag --contains"). It's
On Fri, Sep 08, 2017 at 11:40:21AM +0900, Junio C Hamano wrote:
> Our "git fsck" already treats certain brokenness (like a tree whose
> entry has mode that is 0-padded to the left) as broken but still
> tolerate them. I am not sure if it is sufficient to diagnose and
> declare broken and invalid
On Thu, Sep 07, 2017 at 12:24:02PM -0700, Stefan Beller wrote:
> > We've discussed storing true generation numbers in the past, which would
> > make this optimization more robust, as well as allow us to speed up many
> > other traversals (e.g., the "tag --contains"). It's something I'd like
> > to
Junio C Hamano writes:
> One thing I still do not know how I feel about after re-reading the
> thread, and I didn't find the above doc, is Linus's suggestion to
> use the objects themselves as NewHash-to-SHA-1 mapper [*1*].
> ...
> [Reference]
>
> *1*
I think this falls into the same category
Ross Kabus writes:
> This change makes it such that commit-tree -F never appends a newline
> character to the supplied commit message (either from file or stdin).
>
> Previously, commit-tree -F would always append a newline character to
> the text brought in from file or stdin.
This is not corre
Olaf Klischat writes:
> `git diff --help' says:
>
> git diff [--options] [--] [...]
>This form is to view the changes you have in your
>working tree relative to the named .
That help text is poorly phrased.
When "git diff" talks about files in your working tree, it al
Andrew Ardill writes:
> Using git checkout -b 'my&branch' works for me (single quotes around
> the branch name).
>
> Pushing to a local remote also works: git push --set-upstream
> ../git-test-2 'my&branch'
Thanks for sanity-checking. I was wondering if we have codepaths
that botch quoting (we
Stefan Beller writes:
> The --no-verify option however is not remembered across invocations
> of git-merge. Originally the author assumed an alternative in which the
> 'git merge --continue' command accepts the --no-verify flag, but that
> opens up the discussion which flags are allows to th
Michael Haggerty writes:
> I did just realize one thing: `ref_transaction_update()` takes `flags`
> as an argument and alters it using
>
>> flags |= (new_sha1 ? REF_HAVE_NEW : 0) | (old_sha1 ? REF_HAVE_OLD :
>> 0);
>
> Perhaps gcc is *more* intelligent than we give it credit for, and is
Jeff King writes:
> On Thu, Sep 07, 2017 at 04:51:12AM +0900, Junio C Hamano wrote:
>
>> > diff --git a/builtin/shortlog.c b/builtin/shortlog.c
>> > index 43c4799ea9..48af16c681 100644
>> > --- a/builtin/shortlog.c
>> > +++ b/builtin/shortlog.c
>> > @@ -50,66 +50,67 @@ static int compare_by_list(
Similar to 65969d43d1 (merge: honor prepare-commit-msg hook, 2011-02-14)
merge should also honor the commit-msg hook: When a merge is stopped due
to conflicts or --no-commit, the subsequent commit calls the commit-msg
hook. However, it is not called after a clean merge. Fix this
inconsistency by i
OK apologies for not reading the docs thoroughly enough, and thank
you!! This looks to be exactly what I need.
On Thu, Sep 7, 2017 at 1:35 PM, Stefan Beller wrote:
> On Thu, Sep 7, 2017 at 9:50 AM, Kermit Short wrote:
>> Greetings!
>> I have to set up a workflow where I'll be developing and tes
On Thu, Sep 7, 2017 at 2:17 AM, Jeff King wrote:
>> After having a sneak peak at the implementation
>> it is O(1) in runtime for each added element, and the
>> space complexity is O(well).
>
> I'm not sure if your "well" is "this does well" or "well, it could be
> quite a lot". :)
Both actually.
On 09/07, Michael Haggerty wrote:
> On Wed, Sep 6, 2017 at 3:26 AM, Junio C Hamano wrote:
> > Thomas Gummerer writes:
> >
> >> gcc on arch linux (version 7.1.1) warns that a NULL argument is passed
> >> as the second parameter of memcpy.
> >> [...]
> >
> > It is hugely annoying to see a halfway-i
> -Original Message-
> From: Martin Ågren
> Sent: Thursday, September 7, 2017 1:48 PM
>
> On 7 September 2017 at 18:00, Jason Pyeron wrote:
> >
> > I was hoping to leverage --word-diff-regex, but the
> --no-index option
> > does not seem to work with <(...) notation.
> >
> > I am I doin
On Thu, Sep 7, 2017 at 9:50 AM, Kermit Short wrote:
> Greetings!
> I have to set up a workflow where I'll be developing and testing on
> one network, and then deploying to production on a disconnected
> network. I'd like to be able to have the full commit history for all
> branches, tags, etc. on
On Thu, Sep 7, 2017 at 11:13 AM, Валентин wrote:
> Hi,
>
> I'll be short as shortlog :)
>
> "git shortlog -sn -- "
> counts all commits to the specified path, as expected.
>
> "git shortlog -sn --follow -- "
> counts all commits to the entire repo, which looks like a bug.
>
> "--follow" switch is
On Thu, Sep 7, 2017 at 3:11 AM, Jeff King wrote:
> On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote:
>
>> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic?
>
> I don't think there's a way to turn it off for `rev-list`. Merge-base
> computations are more c
ce012deb98 ("read-cache: avoid allocating every ondisk entry when
writing", 2017-08-21) changed the way cache entries are written to the
index file. While previously it wrote the name to an struct that was
allocated using xcalloc(), it now uses ce_write() directly. Previously
ce_namelen - common
On 09/05, Jeff King wrote:
> Ideally we'd free the existing gitdir field before assigning
> the new one, to avoid a memory leak. But we can't do so
> safely because some callers do the equivalent of:
>
> set_git_dir(get_git_dir());
>
> We can detect that case as a noop, but there are even more
Hi,
I'll be short as shortlog :)
"git shortlog -sn -- "
counts all commits to the specified path, as expected.
"git shortlog -sn --follow -- "
counts all commits to the entire repo, which looks like a bug.
"--follow" switch is not listed on
https://git-scm.com/docs/git-shortlog so maybe it's no
On 7 September 2017 at 18:00, Jason Pyeron wrote:
>
> I was hoping to leverage --word-diff-regex, but the --no-index option does
> not seem to work with <(...) notation.
>
> I am I doing something wrong or is this a bug?
There were some patches floating around half a year ago, I don't know
what h
On Thu, Sep 7, 2017 at 2:11 AM, Shikher Verma wrote:
> On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:
>> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
>> > Currently, git only stores push certificates if there is a receive hook
>> > present. This may violate the principle o
On Thu, Sep 7, 2017 at 12:08 AM, Shikher Verma wrote:
> Hey everyone,
>
> I felt like I should introduce myself since this is my first patch on
> the git mailing list (or any mailing list actually) :D
Welcome to the list. :)
> I am Shikher[1], currently in my 4th year undergrad at IIT Kanpur.
>
Greetings!
I have to set up a workflow where I'll be developing and testing on
one network, and then deploying to production on a disconnected
network. I'd like to be able to have the full commit history for all
branches, tags, etc. on the disconnected side, in case I need to
perform a roll-back, c
oklischat@oklischat:/tmp$ mkdir gittest
oklischat@oklischat:/tmp$ cd gittest/
oklischat@oklischat:/tmp/gittest$ git init
Initialized empty Git repository in /private/tmp/gittest/.git/
oklischat@oklischat:/tmp/gittest$ echo foo > foo.txt
oklischat@oklischat:/tmp/gittest$ git add foo.txt
oklischat@ok
The code was using two string_lists, one for the directories and
one for the files. The code never checks the lists independently
so we should be able to only use one list. The string_list also
is a O(log n) for lookup and insertion. Switching this to use a
hashmap will give O(1) which will save
The return value of the get_files_dirs call is never being used.
Looking at the history of the file and it was originally only
being used for debug output statements. Also when
read_tree_recursive return value is non zero it is changed to
zero. This leads me to believe that it doesn't matter if
r
Code was using two string_lists, one for the directories and
one for the files. The code never checks the lists independently
so we should be able to only use one list. The string_list also
is a O(log n) for lookup and insertion. Switching this to use a
hashmap will give O(1) which will save som
In merge_trees if process_renames or process_entry returns less
than zero, the method will just return and not free re_merge,
re_head, or entries.
This change cleans up the allocated variables before returning
to the caller.
Signed-off-by: Kevin Willford
---
merge-recursive.c | 12 +---
Signed-off-by: Ramsay Jones
---
Hi Jeff,
If you need to re-roll your 'jk/leak-checkers' branch, could you
please squash this into the relevant patch (commit c57586d954,
"add UNLEAK annotation for reducing leak false positives", 05-09-2017).
This was noticed by sparse, since it is not declared
I was hoping to leverage --word-diff-regex, but the --no-index option does
not seem to work with <(...) notation.
I am I doing something wrong or is this a bug?
-Jason (reply to list please)
root@blackfat /projects
$ git diff --no-index -- <(xmllint --format
HRUniversalServices/pairs/src/esb/ws
Greetings To You,
My Name is Mavis wanczyk , the winner of the Power ball jackpot of $ $758.7
million in the AUGUST 24, 2017, My jackpot was a gift from God to me hence my
Entire family/foundation has AGREED to do this. My foundation is donating
$500,000.00USD to you. please contac maviswanczy
On Thu, Sep 07, 2017 at 04:02:19PM +0200, Michael J Gruber wrote:
> name-rev segfaults for me in emacs.git with the typical 8102 stack size.
> The reason is the recursive walk that name-rev uses.
>
> This series adds a test to mark this as known failure, after some
> clean-ups.
These all look re
On Thu, Sep 07, 2017 at 04:51:36PM +0300, Aleksandr Makarov wrote:
> ---
Your commit message leaves me with a lot of questions. Let me see if I
can answer them. :)
Can this code path be triggered? We need to set filter->ignore_case,
but also filter->match_as_patch. So "git branch --ignore-case"
This change makes it such that commit-tree -F never appends a newline
character to the supplied commit message (either from file or stdin).
Previously, commit-tree -F would always append a newline character to
the text brought in from file or stdin. This has caused confusion in a
number of ways:
name-rev segfaults for me in emacs.git with the typical 8102 stack size.
The reason is the recursive walk that name-rev uses.
This series adds a test to mark this as known failure, after some
clean-ups.
Michael J Gruber (4):
t7004: move limited stack prereq to test-lib
t6120: test name-rev --
The lazy prerequisite ULIMIT_STACK_SIZE is used only in t7004 so far.
Move it to test-lib.sh so that it can be used in other tests (which it will
be in a follow-up commit).
Signed-off-by: Michael J Gruber
---
t/t7004-tag.sh | 6 --
t/test-lib.sh | 6 ++
2 files changed, 6 insertions(+
name-rev is used in a few tests, but tested only in t6120 along with
describe so far.
Add tests for name-rev with --all and --stdin.
Signed-off-by: Michael J Gruber
---
t/t6120-describe.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/t/t6120-describe.sh b/t/t61
Depending on the implementation of walks, limitted stack size may lead
to problems (for recursion).
Test name-rev and describe with deep repos and limitted stack size and
mark the former with known failure.
We add these tests (which add gazillions of commits) last so as to keep
the runtime of oth
t6120 breaks the repo state intentionally in the last tests.
Clean up the breakage afterwards (and before adding more tests).
Signed-off-by: Michael J Gruber
---
t/t6120-describe.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 7c5728ebd5..1
---
ref-filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ref-filter.c b/ref-filter.c
index bc591f4..3746628 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1663,7 +1663,7 @@ static int match_name_as_path(const struct ref_filter
*filter, const char *refna
Jeff King venit, vidit, dixit 06.09.2017 15:35:
> On Wed, Sep 06, 2017 at 01:59:31PM +0200, Michael J Gruber wrote:
>
>> BTW, there's more fallout from those name-rev changes: In connection
>> with that other thread about surprising describe results for emacs.git I
>> noticed that I can easily get
On Tue, Sep 05, 2017 at 11:06:34PM +0200, Christian Couder wrote:
> On Sat, Sep 2, 2017 at 12:30 AM, Jeff King wrote:
> >
> > The big questions on whether we can make this happen are:
> >
> > 1. Do we have mentor interest?
> >
> > I'm willing to mentor, but I'd like to hear whether other p
On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote:
> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic?
I don't think there's a way to turn it off for `rev-list`. Merge-base
computations are more careful, so you could determine the correct
endpoints that w
Thanks. Any plans to fix that? Or is there a way to turn off this heuristic?
On 7 September 2017 at 11:47, Jeff King wrote:
> On Thu, Sep 07, 2017 at 11:20:15AM +0200, Paweł Marczewski wrote:
>
>> I have an interesting case. In my repository, there are two commits,
>> 'one' and 'two'. 'one' is re
On Thu, Sep 07, 2017 at 11:20:15AM +0200, Paweł Marczewski wrote:
> I have an interesting case. In my repository, there are two commits,
> 'one' and 'two'. 'one' is reachable from 'two' (as evidenced by 'git
> rev-list two | grep $(giv rev-parse one)'). However, the output of
> 'git rev-list two..
Hi,
I have an interesting case. In my repository, there are two commits,
'one' and 'two'. 'one' is reachable from 'two' (as evidenced by 'git
rev-list two | grep $(giv rev-parse one)'). However, the output of
'git rev-list two..one' is not empty, as is 'git rev-list ^two one'.
Here is the reposito
On Tue, Sep 05, 2017 at 03:05:12PM -0700, Stefan Beller wrote:
> On Tue, Sep 5, 2017 at 6:05 AM, Jeff King wrote:
>
> > int main(void)
>
> nit of the day:
> s/void/int argc, char *argv/ or in case we do not
> want to emphasize the argument list s/void//
> as that adds no uninteresting t
On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:
> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
> > Currently, git only stores push certificates if there is a receive hook
> > present. This may violate the principle of least surprise (e.g., I
> > pushed with --signed, and
On Wed, Sep 06, 2017 at 07:16:00PM +0200, Martin Ågren wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index b3b04f5dd3..de775d906c 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1819,5 +1819,6 @@ int cmd_commit(int argc, const char **argv, const
> > char *pr
On Thu, Sep 07, 2017 at 09:55:25AM +0900, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > On the ref to store the push certs:
> > (a) Currently the ref points at the blob, I wonder if we'd rather want to
> > point at a commit? (Then we can build up a history of
> > push certs, instead
Greetings To You,
My Name is Mavis wanczyk , the winner of the Power ball jackpot of $ $758.7
million in the AUGUST 24, 2017, My jackpot was a gift from God to me hence my
Entire family/foundation has AGREED to do this. My foundation is donating
$500,000.00USD to you. please contac maviswanczy
On Wed, Sep 6, 2017 at 3:26 AM, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
>> gcc on arch linux (version 7.1.1) warns that a NULL argument is passed
>> as the second parameter of memcpy.
>> [...]
>
> It is hugely annoying to see a halfway-intelligent compiler forces
> you to add such point
Hello,
I've been searching what's the best way to include a reference to a
subfolder/subdirectory from a (secondary) remote repo into a subfolder
of my (primary) repo.
Here I found some approaches:
https://stackoverflow.com/a/30386041/509369
Where the first 3 options don't seem to support se
Hey everyone,
I felt like I should introduce myself since this is my first patch on
the git mailing list (or any mailing list actually) :D
I am Shikher[1], currently in my 4th year undergrad at IIT Kanpur.
This summer I was lucky enough to intern at NYU Secure Systems Lab[2]
mentored by Santiago.
66 matches
Mail list logo