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

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

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

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

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

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

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

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 v2 6/6] Testing: provide tests requiring them with ellipses after SHA-1 values

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 --- v2: rename patch series & focus on

Re: [PATCH v2 4/6] Documentation: user-manual: limit usage of ellipsis

Confusing the ellipsis with the three-dot operator should be made as difficult as possible. Signed-off-by: Ann T Ropea --- v2: rename patch series & focus on removal of ellipses Documentation/user-manual.txt | 22 +++--- 1 file changed, 11 insertions(+), 11

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

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 on removal of ellipses diff.c | 69

Re: [PATCH v2 2/6] checkout: describe_detached_head: remove ellipsis after committish

We do not want an ellipsis displayed following an (abbreviated) SHA-1 value. The days when this was necessary to indicate the truncation to lower-level Git commands and/or the user are bygone. However, to ease the transition, the ellipsis will still be printed if the user (actively!) sets the

Re: [PATCH v2 5/6] Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line with "two-dot").

Signed-off-by: Ann T Ropea --- v2: rename patch series & focus on removal of ellipses Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 61277469c874..dfcc49c72c0f

Re: [PATCH v2 1/6] config: introduce core.printsha1ellipsis

We use it to ascertain whether or not the user wants an ellipsis printed after an abbreviated SHA-1 value. By de-asserting it in the default, we encourage not printing the ellipsis in such circumstances. Not adding a corresponding cli option is intentional; and we would like to remove the config

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

Thanks for the reviews! On Mon, Nov 13, 2017 at 1:33 PM, Jonathan Tan wrote: > On Mon, 13 Nov 2017 12:15:58 -0800 > Elijah Newren wrote: > >> -static int display(struct progress *progress, unsigned n, const char *done) >> +static int display(struct

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

> Of course, beyond getting stderr to /dev/null, there is the fact that on > versions of gnupg < 2.1, gpgconf --kill is not available. I noticed this with > gnupg-2.0.14 on CentOS 6. It also occurs on CentOS 7, which provides > gnupg-2.0.22. > > I don't know if there's much value in trying to

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

On Mon, Nov 13, 2017 at 2:03 PM, Luke Diamand wrote: > On 13 November 2017 at 19:51, Luke Diamand wrote: >> Hi! >> >> I think there may be a regression caused by this change which means >> that "git fetch origin" doesn't work: >> >> commit

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

On Mon, Nov 13, 2017 at 2:04 PM, Elijah Newren wrote: > Do you feel it's important that I come up with a demonstration case > here? If so, I'll see if I can generate one. I was mostly "just curious" on how you'd construct it theoretically. > it's actually something newly

INFO

I have important transaction for you as next of kin to claim US$8.37m email me at changgordo...@yahoo.com.hk so I can send you more details

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

Thanks for the reviews! On Mon, Nov 13, 2017 at 11:48 AM, Stefan Beller wrote: > 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

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

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

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

On 13 November 2017 at 19:51, Luke Diamand wrote: > 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

[buglet] gitk and git cherry-pick --abort interaction

Apologies in advance for the vagueness of this bug report. I was juggling a few patches around in a git repo (happens to be linux but that's probably not particularly relevant). I'd been reverting, rebasing and cherry-picking on the CLI. Then I found I needed one more commit which I located with

no mountable file systems

Dear team, when i download Git on Mac it says “no mountable file systems” and doesnt open after. how can i solve this? Thank you for your help,

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: > -static int display(struct progress *progress, unsigned n, const char *done) > +static int display(struct progress *progress, uint64_t n, const char *done) > { > const char *eol, *tp; > > @@ -106,7 +106,7 @@

Recovering from gc errors

(I'm using git 2.15.0.) So today "git gc" started complaining: error: Could not read 2bc277bcb7e9cc6ef2ea677dd1c3dcd1f9af0c2b fatal: Failed to traverse parents of commit 9c355a7726e31b3033b8e714cf7edb4f0a41d8d4 error: failed to run repack I suspect I'm a victim of the worktree+submodule bugs

[PATCH] rebase: fix stderr redirect in apply_autostash()

The intention is to ignore all output from the 'git stash apply' call. Adjust the order of the redirection to ensure that both stdout and stderr are redirected to /dev/null. Signed-off-by: Todd Zullinger --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 1/2] merge: close the index lock when not writing the new index

On 11 November 2017 at 00:13, Joel Teichroeb wrote: > If the merge does not have anything to do, it does not unlock the index, > causing any further index operations to fail. Thus, always unlock the index > regardless of outcome. > if (clean < 0) >

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

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 .

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

On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote: > 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 >

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:

[PATCH v2 4/4] sequencer: show rename progress during cherry picks

When trying to cherry-pick a change that has lots of renames, it is somewhat unsettling to wait a really long time without any feedback. Signed-off-by: Elijah Newren --- sequencer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sequencer.c b/sequencer.c index

[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

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

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

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

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:

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

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

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

[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

[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

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

[no subject]

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

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

  1   2   >