WORK AND LIVE IN TORONTO CANADA.

-- Hello, WORK AND LIVE IN TORONTO CANADA. The management of LNG Toronto, Canada is recruiting staffs across the globe. This offer is opened to skilled and unskilled workers. Interested candidates are to send CV / resume to Email: humanresource...@job4u.com Regards, Announcer.

Re: [RFC] cover-at-tip

Junio C Hamano writes: > Nicolas Morey-Chaisemartin writes: > >> I agree this is a "am" job. Was just wondering if reusing some of >> the code from apply (and move it so it makes more sense) wouldnd't >> make more sense than rewriting a patch

Re: [PATCH v1 5/8] sequencer: don't die in print_commit_summary()

On 10/11/17 18:05, Junio C Hamano wrote: > Phillip Wood writes: > >> On 07/11/17 15:13, Junio C Hamano wrote: >> ... >>> Another possibility perhaps is that the function is safe to reuse >>> already even without this patch, of course ;-). >>> >> Hmm, maybe it is.

Re: [PATCH v2 3/9] Add a function to update HEAD after creating a commit

On 10/11/17 18:36, Junio C Hamano wrote: > Phillip Wood writes: > >> From: Phillip Wood >> >> Add update_head() based on the code that updates HEAD after committing >> in builtin/commit.c that can be called by 'git commit' and other >>

Re: [PATCH v2 0/9] sequencer: dont't fork git commit

On 10/11/17 19:21, Junio C Hamano wrote: > Phillip Wood writes: > >> Here's the summary from the previous version >> These patches teach the sequencer to create commits without forking >> git commit when the commit message does not need to be edited. This >> speeds up

Re: [PATCH] doc: Remove explanation of "--" from several man pages

On Mon, 13 Nov 2017, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > > There is no value in individual man pages explaining the purpose > > of the "--" separator. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > unless every man

Re: [RFC] cover-at-tip

Nicolas Morey-Chaisemartin writes: > I agree this is a "am" job. Was just wondering if reusing some of > the code from apply (and move it so it makes more sense) wouldnd't > make more sense than rewriting a patch detection function. Yes, I understood that and have

Re: [RFC] cover-at-tip

Le 13/11/2017 à 11:30, Junio C Hamano a écrit : > Junio C Hamano writes: > >> Nicolas Morey-Chaisemartin writes: >> >>> I agree this is a "am" job. Was just wondering if reusing some of >>> the code from apply (and move it so it makes more sense)

RE: cherry-pick very slow on big repository

Kevin Willford: Since this is happening during a merge, you might need to use merge.renameLimit or the merge strategy option of -Xno-renames. Although the code does fallback to use the diff.renameLimit but there is still a lot that is done before even checking the rename limit so I would

"man git-clean" doesn't clarify the *default* behaviour of "git clean"

(against my better judgment at this point, i'm going to suggest a slight reworking of "man git-clean" to make the OPTIONS more comprehensible.) while the man page for "git clean" explains how options like -d and -e and -x and -X, etc etc, alter the default behaviour of "git clean", that man

Re: [PATCH v2] gpg-interface: strip CR chars for Windows gpg2

On Sun, Nov 12, 2017 at 9:08 PM, Junio C Hamano wrote: > Eric Sunshine writes: >>> + size_t i, j; >>> + for (i = j = bottom; i < buffer->len; i++) >>> + if (!(i < buffer->len - 1 && >>> +

Re: cherry-pick very slow on big repository

Elijah Newren: I would be very interested to hear how my rename detection performance patches work for you; this kind of usecase was the exact one it was designed to help the most. See https://public-inbox.org/git/20171110222156.23221-1-new...@gmail.com/ I'd be happy to try them out. Is

Re: [PATCH] doc: Remove explanation of "--" from several man pages

"Robert P. J. Day" writes: >> > diff --git a/Documentation/git-check-attr.txt >> > b/Documentation/git-check-attr.txt >> > index aa3b2bf2f..0ae2523e0 100644 >> > --- a/Documentation/git-check-attr.txt >> > +++ b/Documentation/git-check-attr.txt >> > @@ -36,10 +36,6 @@

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote: > On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote: > > On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote: > > > From: Kaartic Sivaraam > > > > > > When trying to rename an

Re: [PATCH v2 2/9] commit: move empty message checks to libgit

On 10/11/17 18:51, Ramsay Jones wrote: > > > On 10/11/17 11:09, Phillip Wood wrote: >> From: Phillip Wood >> >> Move the functions that check for empty messages from bulitin/commit.c >> to sequencer.c so they can be shared with other commands. The >> functions are

Re: [PATCH] doc: Remove explanation of "--" from several man pages

On Mon, 13 Nov 2017, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > >> > diff --git a/Documentation/git-check-attr.txt > >> > b/Documentation/git-check-attr.txt > >> > index aa3b2bf2f..0ae2523e0 100644 > >> > --- a/Documentation/git-check-attr.txt > >> > +++

Re: [PATCH 09/30] directory rename detection: testcases checking which side did the rename

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 283 > > 1 file changed, 283 insertions(+) > > diff --git

Re: [PATCH 04/30] directory rename detection: basic testcases

On Mon, Nov 13, 2017 at 2:04 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > (minor thought:) > After rereading the docs above this is clear; I wonder if instead of A, B, C > a notation of Base, ours, theirs would be

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

Ben Peart writes: > The proposed format for extensions (ie having both a header and a > footer with name and size) in the current patch already enables having > multiple extensions that can be parsed forward or backward. Any > extensions that would want to be parse-able in

Re: [PATCH 03/30] merge-recursive: Add explanation for src_entry and dst_entry

Elijah Newren writes: > If I have to walk through the debugger and inspect the values found in > here in order to figure out their meaning, despite having known these > things inside and out some years back, then they probably need a comment > for the casual reader to explain

Re: man page for "git-worktree" is a bit confusing WRT "prune"

[+cc:Duy] On Mon, Nov 13, 2017 at 4:06 PM, Robert P. J. Day wrote: > On Mon, 13 Nov 2017, Eric Sunshine wrote: >> On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day >> wrote: >> > finally, the prune "--expire" option is truly confusing: >> > >> >

Re: [PATCH 07/30] directory rename detection: partially renamed directory testcase/discussion

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 100 > > 1 file changed, 100 insertions(+) > > diff --git

Re: [PATCH v2 0/9] sequencer: dont't fork git commit

Phillip Wood writes: > Are you happy with the '--signoff' is handled (I didn't modify my > changes in the last iteration as you were still thinking about it)? I am not, but I am not unhappy, either. As I understand from your responses, it seems that the existing code

Re: [PATCH 04/30] directory rename detection: basic testcases

On Mon, Nov 13, 2017 at 5:21 PM, Stefan Beller wrote: > On Mon, Nov 13, 2017 at 4:57 PM, Elijah Newren wrote: > (slightly dreaming:) > I wonder if we could teach our test suite to accept multiple test_done > or restart_tests or such to resurrect the clean

Re: [PATCH v2 3/6] diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value

Ann T Ropea writes: > Neither Git nor the user are in need of this (visual) aid anymore, but > we must offer a transition period. > > Also, fix a typo: "abbbreviated" ---> "abbreviated". > > Signed-off-by: Ann T Ropea > --- > v2: rename patch series & focus

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Todd Zullinger writes: >> I wonder if this line in 3320 is doing what it meant to do: >> >>test_must_fail git notes merge z 2>&1 >out &&test_i18ngrep >> "Automatic notes merge failed" out &&grep -v "A notes merge into >> refs/notes/x is already in-progress in" out > >

What's cooking in git.git (Nov 2017, #04; Tue, 14)

What's cooking in git.git (Nov 2017, #04; Tue, 14) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear

Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue

On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote: > I wanted to debug a very similar issue today just after reviewing this > series, see > https://public-inbox.org/git/743acc29-85bb-3773-b6a0-68d4a0b8f...@ispras.ru/ Oh, bleh. That's not a D/F conflict at all, it's the

Re: [PATCH 04/30] directory rename detection: basic testcases

Stefan Beller writes: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> Signed-off-by: Elijah Newren >> ... >> +# B >> +# o >> +# / \ >> +# A o ? >> +# \ / >> +# o >> +# C >> + ... >> +# Testcase

[PATCH V2] config: add --expiry-date

From: Haaris Description: This patch adds a new option to the config command. Uses flag --expiry-date as a data-type to covert date-strings to timestamps when reading from config files (GET). This flag is ignored on write (SET) because the date-string is stored in config

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Junio C Hamano wrote: **Blush**. I should have caught this during the review. Thanks. I've written that code myself in the past and I am sure I will do it again. :) I wonder if this line in 3320 is doing what it meant to do: test_must_fail git notes merge z 2>&1 >out &&

Re: [PATCH v2 6/6] Testing: provide tests requiring them with ellipses after SHA-1 values

Ann T Ropea writes: > Where needed, we arrange for invocations of Git as if > >"-c core.printsha1ellipsis=true" > > had been specified on the command-line. This furnishes ellipses in the > output which then matches what is expected. > > Signed-off-by: Ann T Ropea

Re: [PATCH 05/30] directory rename detection: directory splitting testcases

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 125 > > 1 file changed, 125 insertions(+) > > diff --git

Re: [PATCH] Fix NO_LIBPCRE1_JIT to fully disable JIT

Charles Bailey writes: >> > But that we should take it anyway regardless of that since it'll *also* >> > work on Linux with your patch, and this logic makes some sense whereas >> > the other one clearly didn't and just worked by pure accident of some >> > toolchain

Re: [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 137 > > 1 file changed, 137 insertions(+) > > diff --git

Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

Elijah Newren writes: > 2) Instead of counting pairs of source/dest files compared, just > count number of dest paths completed. (Thus, we wouldn't need a value > big enough to hold rename_dst_nr * rename_src_nr, just big enough to > hold rename_dst_nr). This sounds like

Re: [PATCH 08/30] directory rename detection: files/directories in the way of some renames

On Mon, Nov 13, 2017 at 4:15 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> +# Testcase 5c, Transitive rename would cause >> rename/rename/rename/add/add/add >> +# (Directory rename detection would result in

Re: [PATCH 09/30] directory rename detection: testcases checking which side did the rename

On Mon, Nov 13, 2017 at 4:25 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> +# Testcase 6b, Same rename done on both sides >> +# (Related to testcases 6c and 8e) >> +# Commit A: z/{b,c} >> +# Commit B: y/{b,c} >>

Re: [PATCH 06/30] directory rename detection: testcases to avoid taking detection too far

On Mon, Nov 13, 2017 at 3:25 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> +# Testcase 3a, Avoid implicit rename if involved as source on other side >> +# (Related to testcases 1c and 1f) >> +# Commit A: z/{b,c,d}

Re: [PATCH 10/30] directory rename detection: more involved edge/corner testcases

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > +# In my opinion, testcases that are difficult to understand from this > +# section is due to difficulty in the testcase rather than the directory > +# renaming (similar to how t6042 and t6036 have difficult resolutions

Re: [PATCH] link_alt_odb_entries: make empty input a noop

Joey Hess writes: > Jeff King wrote: >> This should make Joey's immediate pain go away, though only by papering >> it over. I tend to agree that we shouldn't be looking at $PWD at all >> here. > > I've confirmed that Jeff's patch fixes the case I was having trouble with.

Re: [PATCH 19/30] merge-recursive: Split out code for determining diff_filepairs

Elijah Newren writes: > Create a new function, get_diffpairs() to compute the diff_filepairs > between two trees. While these are currently only used in > get_renames(), I want them to be available to some new functions. No > actual logic changes yet. OK. This refactors

Re: [PATCH 21/30] merge-recursive: Add get_directory_renames()

Elijah Newren writes: > + entry = dir_rename_find_entry(dir_renames, old_dir); > + if (!entry) { > + entry = xcalloc(1, sizeof(struct dir_rename_entry)); > + hashmap_entry_init(entry, strhash(old_dir)); Please

Re: What's cooking in git.git (Nov 2017, #04; Tue, 14)

* jc/branch-name-sanity (2017-10-14) 3 commits - branch: forbid refs/heads/HEAD - branch: split validate_new_branchname() into two - branch: streamline "attr_only" handling in validate_new_branchname() "git branch" and "git checkout -b" are now forbidden from creating a branch whose name is

Re: [RFC 2/3] am: semi working --cover-at-tip

Nicolas Morey-Chaisemartin writes: > if (!git_config_get_bool("commit.gpgsign", )) > state->sign_commit = gpgsign ? "" : NULL; > + > } Please give at least a cursory proof-reading before sending things out. > @@ -1106,14 +1131,6 @@ static void

Re: [RFC 3/3] log: add an option to generate cover letter from a branch tip

Nicolas Morey-Chaisemartin writes: > - const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n"; > - const char *msg; > + const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n\n"; H. > @@ -1021,17 +1021,21 @@ static void

Re: no mountable file systems

On Mon, Nov 13, 2017 at 10:35 PM, Louis Gruand wrote: > Dear team, when i download Git on Mac it says “no mountable file systems” and > doesnt open after. how can i solve this? When googling "Mac no mountable file systems", it looks like this error is not specific

Re: [PATCH 16/30] merge-recursive: Introduce new functions to handle rename logic

Junio C Hamano writes: > Elijah Newren writes: > >> +struct rename_info { >> +struct string_list *head_renames; >> +struct string_list *merge_renames; >> +}; > > This type is added in order to allow the caller and the helper to > communicate the

Re: What's cooking in git.git (Nov 2017, #04; Tue, 14)

Kaartic Sivaraam writes: >> * jc/branch-name-sanity (2017-10-14) 3 commits >> - branch: forbid refs/heads/HEAD >> - branch: split validate_new_branchname() into two >> - branch: streamline "attr_only" handling in validate_new_branchname() >> >> "git branch" and

Re: [PATCH V2] config: add --expiry-date

h...@unimetic.com writes: > From: Haaris > > Description: > This patch adds a new option to the config command. > > Uses flag --expiry-date as a data-type to covert date-strings to > timestamps when reading from config files (GET). > This flag is ignored on write (SET) because

Re: [PATCH 17/30] merge-recursive: Fix leaks of allocated renames and diff_filepairs

Elijah Newren writes: > get_renames() has always zero'ed out diff_queued_diff.nr while only > manually free'ing diff_filepairs that did not correspond to renames. > Further, it allocated struct renames that were tucked away in the > return string_list. Make sure all of these

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Junio C Hamano wrote: The message goes to the standard output stream since it was introduced in 809f38c8 ("git notes merge: Manual conflict resolution, part 1/2", 2010-11-09) and 6abb3655 ("git notes merge: Manual conflict resolution, part 2/2", 2010-11-09). I do think it makes more sense to

Re: [RFC 1/3] mailinfo: extract patch series id

Nicolas Morey-Chaisemartin writes: > Extract the patch ID and series length from the [PATCH N/M] > prefix in the mail header > > Signed-off-by: Nicolas Morey-Chaisemartin > --- > mailinfo.c | 35 +++ >

Re: Recovering from gc errors

On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote: > Various incantations of "git show ... 9c355a7726e31" only fail with the same > error, so I can't determine much about the problematic commit. Luckily I'm > not particularly concerned with losing objects, as I push any important >

Re: [PATCH 15/30] merge-recursive: Move the get_renames() function

Elijah Newren writes: > I want to re-use some other functions in the file without moving those other > functions or dealing with a handful of annoying split function declarations > and definitions. > > Signed-off-by: Elijah Newren > --- It took me a while to

Re: [PATCH 16/30] merge-recursive: Introduce new functions to handle rename logic

Elijah Newren writes: > +struct rename_info { > + struct string_list *head_renames; > + struct string_list *merge_renames; > +}; This type is added in order to allow the caller and the helper to communicate the findings in a single logical structure, instead of having

Re: [PATCH V2] config: add --expiry-date

On Tue, Nov 14, 2017 at 3:04 AM, wrote: > From: Haaris > > Description: > This patch adds a new option to the config command. > > Uses flag --expiry-date as a data-type to covert date-strings to > timestamps when reading from config files (GET). > This flag

Re: [RFC PATCH v3 4/4] builtin/branch: give more useful error messages when renaming

On Monday 13 November 2017 05:00 PM, Kevin Daudt wrote: On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote: That was a little attribution I wanted make to the strbuf API as this was the first time I leveraged it to this extent and I was surprised by the way it made string

Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue

On Mon, Nov 13, 2017 at 3:39 PM, Elijah Newren wrote: > On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote: >> I wanted to debug a very similar issue today just after reviewing this >> series, see >>

Re: [PATCH 08/30] directory rename detection: files/directories in the way of some renames

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > Signed-off-by: Elijah Newren > --- > t/t6043-merge-rename-directories.sh | 303 > > 1 file changed, 303 insertions(+) > > diff --git

Re: [PATCH 04/30] directory rename detection: basic testcases

On Mon, Nov 13, 2017 at 4:57 PM, Elijah Newren wrote: > On Mon, Nov 13, 2017 at 2:04 PM, Stefan Beller wrote: >> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> (minor thought:) >> After rereading the docs above this is clear; I

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Todd Zullinger writes: > In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a > call to gpgconf was added to kill the gpg-agent. The intention was to > ignore all output from the call, but the order of the redirection needs > to be switched to ensure that both

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Santiago Torres wrote: Quick followup. The version that triggers this is at least 2.1.21[1]. I recall there was some wiggle room on minor versions before it. Thanks for digging that up! I had 2.1.13 at hand in a fedora-25 chroot which I used to build git recently, but I've not been able to

man page for "git-worktree" is a bit confusing WRT "prune"

once more, into the man pages ... "git worktree" seems like a fairly simple command, but there is some confusion about the function of $ git worktree prune the normal meaning of "prune" (certainly with git commands) is to actually delete some content, and the initial impression of this

Re: [PATCH 00/30] Add directory rename detection to git

From: "Elijah Newren" : Friday, November 10, 2017 11:26 PM On Fri, Nov 10, 2017 at 2:27 PM, Philip Oakley wrote: From: "Elijah Newren" In this patchset, I introduce directory rename detection to merge-recursive, predominantly so

[PATCH 1/2] Documentation/config: add sendemail.tocmd to list preceding "See git-send-email(1)"

Signed-off-by: Rasmus Villemoes --- Documentation/config.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 671fcbaa0..d88fc9f63 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -3000,6

[PATCH 2/2] completion: add git config sendemail.tocmd

Signed-off-by: Rasmus Villemoes --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index fdd984d34..10607cdf2 100644 ---

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

On 11/9/2017 11:46 PM, Junio C Hamano wrote: Ben Peart writes: To make this work for V4 indexes, when writing the index, it periodically "resets" the prefix-compression by encoding the current entry as if the path name for the previous entry is completely different

Re: man page for "git-worktree" is a bit confusing WRT "prune"

On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day wrote: > once more, into the man pages ... "git worktree" seems like a fairly > simple command, but there is some confusion about the function of > > $ git worktree prune > > the normal meaning of "prune" (certainly with

Re: [PATCH] link_alt_odb_entries: make empty input a noop

Jeff King wrote: > This should make Joey's immediate pain go away, though only by papering > it over. I tend to agree that we shouldn't be looking at $PWD at all > here. I've confirmed that Jeff's patch fixes the case I was having trouble with. -- see shy jo signature.asc Description: PGP

[PATCH V2] config: add --expiry-date

Description: This patch adds a new option to the config command. Enables flag --expiry-date as a data-type to covert date-strings to timestamps when reading from config files (GET). This flag is ignored on write (SET) because the date-string is stored in config without performing any

Re: cherry-pick very slow on big repository

On Mon, Nov 13, 2017 at 3:22 AM, Peter Krefting wrote: > Elijah Newren: > >> I would be very interested to hear how my rename detection performance >> patches work for you; this kind of usecase was the exact one it was designed >> to help the most. See >>

Re: [PATCH 02/30] merge-recursive: Fix logic ordering issue

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > merge_trees() did a variety of work, including: > * Calling get_unmerged() to get unmerged entries > * Calling record_df_conflict_files() with all unmerged entries to > do some work to ensure we could handle D/F

Re: [PATCH/RFC] Replace Free Software Foundation address in license notices

Junio C Hamano wrote: This change probably makes sense. From here on after applying the patch, we won't have to worry about updating these every time they move---not that they have moved often, though ;-) Indeed. It's thankfully a rare move. I imagine that's why it's somewhat common to

Re: [RFC 0/3] Add support for --cover-at-tip

Le 13/11/2017 à 20:40, Jonathan Tan a écrit : > On Mon, 13 Nov 2017 18:13:27 +0100 > Nicolas Morey-Chaisemartin wrote: > >> v2: >> - Enhance mailinfo to parse patch series id from subject >> - Detect cover using mailinfo parsed ids in git am > I noticed that this was

Re: [PATCH 3/4] progress: Fix progress meters when dealing with lots of work

Thanks for the reviews and suggestions! On Sun, Nov 12, 2017 at 9:24 PM, Junio C Hamano wrote: > Elijah Newren writes: > >> Subject: Re: [PATCH 3/4] progress: Fix progress meters when dealing with >> lots of work > > Style: s/Fix/fix/; I also messed this

[PATCH v2 1/4] sequencer: warn when internal merge may be suboptimal due to renameLimit

When many files were renamed, the recursive merge strategy stopped detecting renames and left many paths with delete/modify conflicts, without any warning about what was going on or providing any hints about how to tell Git to spend more cycles to detect renames. Signed-off-by: Elijah Newren

Re: [PATCH v3 4/4] Switch empty tree and blob lookups to use hash abstraction

On Sun, Nov 12, 2017 at 1:28 PM, brian m. carlson wrote: > Switch the uses of empty_tree_oid and empty_blob_oid to use the > current_hash abstraction that represents the current hash algorithm in > use. > > Signed-off-by: brian m. carlson

Bug in "revision.c: --all adds HEAD from all worktrees" ?

Hi! I think there may be a regression caused by this change which means that "git fetch origin" doesn't work: commit d0c39a49ccb5dfe7feba4325c3374d99ab123c59 (refs/bisect/bad) Author: Nguyễn Thái Ngọc Duy Date: Wed Aug 23 19:36:59 2017 +0700 revision.c: --all adds HEAD

Re:

To subscribe to the git mailing list, send the email to majord...@vger.kernel.org, not the mailing list itself. On Sat, Nov 11, 2017 at 6:21 PM, wrote: > subscribe git

Re: [PATCH 01/30] Tighten and correct a few testcases for merging and cherry-picking

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > t3501 had a testcase originally added ... goes and looks ... "in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26)" would have helped me here in the commit message. > to ensure cherry-pick

Re: [RFC 0/3] Add support for --cover-at-tip

On Mon, 13 Nov 2017 18:13:27 +0100 Nicolas Morey-Chaisemartin wrote: > v2: > - Enhance mailinfo to parse patch series id from subject > - Detect cover using mailinfo parsed ids in git am I noticed that this was done in the patch set by searching for "PATCH" - that is

[PATCH v2 3/4] Remove silent clamp of renameLimit

In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), the renameLimit was clamped to 32767. This appears to have been to simply avoid integer overflow in the following computation: num_create * num_src <= rename_limit * rename_limit although it also could be viewed as a

[PATCH v2 0/4] Fix issues with rename detection limits

This patchset fixes some issues around rename detection limits. Changes since the original submission[1]: * Patches 2 and 3 are swapped in order so as to not temporarily introduce any bugs (even if only cosmetic) * Commit message fixups * Using uint64_t instead of double for holding

[PATCH v2 2/4] progress: fix progress meters when dealing with lots of work

The possibility of setting merge.renameLimit beyond 2^16 raises the possibility that the values passed to progress can exceed 2^32. Use uint64_t, because it "ought to be enough for anybody". :-) Signed-off-by: Elijah Newren --- This does imply 64-bit math for all progress

Re: more pedantry ... what means a file "known to Git"?

From: "Robert P. J. Day" apologies for more excruciating nitpickery, but i ask since it seems that phrase means slightly different things depending on where you read it. first, i assume that there are only two categories: 1) files known to Git 2) files unknown to

[no subject]

sup Git http://bit.ly/2zz7jZe Yours Truly Cwestin

[RFC 1/3] mailinfo: extract patch series id

Extract the patch ID and series length from the [PATCH N/M] prefix in the mail header Signed-off-by: Nicolas Morey-Chaisemartin --- mailinfo.c | 35 +++ mailinfo.h | 2 ++ 2 files changed, 37 insertions(+) diff --git

[RFC 2/3] am: semi working --cover-at-tip

Issue with empty patch detection Signed-off-by: Nicolas Morey-Chaisemartin --- builtin/am.c | 143 --- 1 file changed, 126 insertions(+), 17 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index

[RFC 0/3] Add support for --cover-at-tip

v2: - Enhance mailinfo to parse patch series id from subject - Detect cover using mailinfo parsed ids in git am - Support multiple patch series in a single run TODO: - Add doc/comments - Add tests - Add a new "seperator" at the end of a cover letter. Right now I added a triple dash to all cover

[RFC 3/3] log: add an option to generate cover letter from a branch tip

TODO: figure out defaults, add a config option, move tip detection to specific function Signed-off-by: Nicolas Morey-Chaisemartin --- Documentation/git-format-patch.txt | 4 builtin/log.c | 44 +- 2

Re: [PATCH 2/2] fsmonitor: Store fsmonitor bitmap before splitting index

On 11/9/2017 2:58 PM, Alex Vandiver wrote: ba1b9caca6 resolved the problem of the fsmonitor data being applied to the non-base index when reading; however, a similar problem exists when writing the index. Specifically, writing of the fsmonitor extension happens only after the work to split

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Hi Santiago, Santiago Torres wrote: Thanks for catching the redirection issue! I agree that the other fixes feel like overkill. Are you certain that switching to gpgconf --reload will have the same effect as --kill? (I know that this is the case for scdaemon only). I am not at all certain

Re: [PATCH 03/30] merge-recursive: Add explanation for src_entry and dst_entry

On Mon, Nov 13, 2017 at 1:06 PM, Stefan Beller wrote: > On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: >> + /* >> +* Because I keep forgetting every few years what src_entry and >> +* dst_entry are and have to walk through a

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

> Were the ENOENT errors you encountered in running the tests multiple times > easy to reproduce? If you had the right gpg2, it should be easy to repro with just re-running. > If so, I can certainly try to reproduce them and then > run the tests with --reload in place of --kill to gpgconf.

Re: [PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

Quick followup. The version that triggers this is at least 2.1.21[1]. I recall there was some wiggle room on minor versions before it. Thanks! -Santiago. [1] https://dev.gnupg.org/T3218 On Mon, Nov 13, 2017 at 06:02:02PM -0500, Santiago Torres wrote: > > > Were the ENOENT errors you

Re: [PATCH 03/30] merge-recursive: Add explanation for src_entry and dst_entry

On Mon, Nov 13, 2017 at 2:57 PM, Elijah Newren wrote: > > Perhaps: > > If 'before' is renamed to 'after' then src_entry will contain > the versions of 'before' from the merge_base, HEAD, and MERGE in > stages 1, 2, and 3; and dst_entry will contain the respective versions

Re: [PATCH v2 2/4] progress: fix progress meters when dealing with lots of work

On Mon, 13 Nov 2017 12:15:58 -0800 Elijah Newren wrote: > The possibility of setting merge.renameLimit beyond 2^16 raises the > possibility that the values passed to progress can exceed 2^32. > Use uint64_t, because it "ought to be enough for anybody". :-) > > Signed-off-by:

Re: man page for "git-worktree" is a bit confusing WRT "prune"

On Mon, 13 Nov 2017, Eric Sunshine wrote: > On Mon, Nov 13, 2017 at 9:48 AM, Robert P. J. Day > wrote: ... snip ... > > finally, the prune "--expire" option is truly confusing: > > > > --expire > > With prune, only expire unused working trees older than .

[PATCH] t/lib-gpg: fix gpgconf stderr redirect to /dev/null

In 29ff1f8f74 (t: lib-gpg: flush gpg agent on startup, 2017-07-20), a call to gpgconf was added to kill the gpg-agent. The intention was to ignore all output from the call, but the order of the redirection needs to be switched to ensure that both stdout and stderr are redirected to /dev/null.

  1   2   >