Re: Strange behavior of git rev-list

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

Re: [RFC PATCH 0/2] Add named reference to latest push cert

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 > >

Re: Strange behavior of git rev-list

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

Re: Git in Outreachy round 15?

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

Strange behavior of git rev-list

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

Re: [RFC PATCH 0/2] Add named reference to latest push cert

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 > >

Re: Strange behavior of git rev-list

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

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

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

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

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

Re: [PATCH] name-rev: change ULONG_MAX to TIME_MAX

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

Re: [PATCH] match_name_as_path: Pass WM_CASEFOLD to wildmatch

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"

[PATCH 4/4] t6120: test describe and name-rev with deep repos

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

[PATCH 1/4] t7004: move limited stack prereq to test-lib

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

[PATCH 2/4] t6120: test name-rev --all and --stdin

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

[PATCH 3/4] t6120: clean up state after breaking repo

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

Git diff --no-index and file descriptor inputs

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

[PATCH] commit-tree: don't append a newline with -F

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:

[PATCH 0/4] Test name-rev with small stack

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

Re: "git shortlog -sn --follow -- " counts all commits to entire repo

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. > >

RE: Git diff --no-index and file descriptor inputs

> -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.

[PATCH v3 3/3] merge-recursive: change current file dir string_lists to hashmap

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

[PATCH v3 1/3] merge-recursive: fix memory leak

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 ---

[PATCH v3 2/3] merge-recursive: remove return value from get_files_dirs

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

[PATCH v3 0/3] merge-recursive: replace string_list with hashmap

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

Re: Git diff --no-index and file descriptor inputs

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,

Re: [PATCH 09/10] set_git_dir: handle feeding gitdir to itself

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

[PATCH v2] read-cache: fix index corruption with index v4

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

Re: Strange behavior of git rev-list

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 >

"git shortlog -sn --follow -- " counts all commits to entire repo

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

Re: clone repo & history to disconnected server

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 >

Re: [RFC PATCH 0/2] Add named reference to latest push cert

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

[PATCH] match_name_as_path: Pass WM_CASEFOLD to wildmatch

--- 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

Re: [PATCH 0/4] Test name-rev with small stack

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: Donation

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

clone repo & history to disconnected server

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,

git diff doesn't quite work as documented?

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

Re: [RFC PATCH 0/2] Add named reference to latest push cert

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

[PATCH] usage: conditionally compile unleak_memory() definition

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

Re: [PATCH] refs: make sure we never pass NULL to hashcpy

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. > >> [...] > > >

Re: [PATCH 10/10] add UNLEAK annotation for reducing leak false positives

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". :)

Re: clone repo & history to disconnected server

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

[PATCHv3] builtin/merge: honor commit-msg hook for merges

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

Re: [PATCH 27/34] shortlog: release strbuf after use in insert_one_record()

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

Re: [PATCH] refs: make sure we never pass NULL to hashcpy

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

Re: [PATCHv3] builtin/merge: honor commit-msg hook for merges

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

Re: Branch name support & character

Andrew Ardill writes: > Using git checkout -b 'my' works for me (single quotes around > the branch name). > > Pushing to a local remote also works: git push --set-upstream > ../git-test-2 'my' Thanks for sanity-checking. I was wondering if we have codepaths that botch

Re: git diff doesn't quite work as documented?

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

Re: [PATCH] commit-tree: don't append a newline with -F

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

Re: RFC v3: Another proposed hash function transition plan

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*

Re: Strange behavior of git rev-list

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,

Re: RFC v3: Another proposed hash function transition plan

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

Re: Strange behavior of git rev-list

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 > >

Re: Strange behavior of git rev-list

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

Re: [PATCH] usage: conditionally compile unleak_memory() definition

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

Re: [PATCH 27/34] shortlog: release strbuf after use in insert_one_record()

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

Re: [PATCH 07/10] t1404: demonstrate two problems with reference transactions

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

Re: "git shortlog -sn --follow -- " counts all commits to entire repo

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

Re: [PATCH 27/34] shortlog: release strbuf after use in insert_one_record()

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

Re: Donation

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

Re: [RFC PATCH 0/2] Add named reference to latest push cert

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

How to include references to subfolders

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

Re: [PATCH] refs: make sure we never pass NULL to hashcpy

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

Re: Donation

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