[PATCH v4 5/6] midx: honor the MIDX_PROGRESS flag in midx_repack

From: William Baker Update midx_repack to only display progress when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/midx.c b/midx.c index 35bdc5f72c..b5f7f1c54a 100644 --- a/midx.c +++ b/midx.c @@ -1373,6

[PATCH v4 3/6] midx: add progress to expire_midx_packs

From: William Baker Add progress to expire_midx_packs. Progress is displayed when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 12 1 file changed, 12 insertions(+) diff --git a/midx.c b/midx.c index 006f36b570..7157259ca2 100644 --- a/midx.c +++ b

[PATCH v4 2/6] midx: add progress to write_midx_file

From: William Baker Add progress to write_midx_file. Progress is displayed when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/midx.c b/midx.c index f169a681dd..006f36b570

[PATCH v4 4/6] midx: honor the MIDX_PROGRESS flag in verify_midx_file

From: William Baker Update verify_midx_file to only display progress when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/midx.c b/midx.c index 7157259ca2..35bdc5f72c 100644 --- a

[PATCH v4 6/6] multi-pack-index: add [--[no-]progress] option.

From: William Baker Add the --[no-]progress option to git multi-pack-index. Pass the MIDX_PROGRESS flag to the subcommand functions when progress should be displayed by multi-pack-index. The progress feature was added to 'verify' in 144d703 ("multi-pack-index: report progress

[PATCH v4 1/6] midx: add MIDX_PROGRESS flag

From: William Baker Add the MIDX_PROGRESS flag and update the write|verify|expire|repack functions in midx.h to accept a flags parameter. The MIDX_PROGRESS flag indicates whether the caller of the function would like progress information to be displayed. This patch only changes the method

[PATCH v4 0/6] multi-pack-index: add --no-progress

patch. Thanks, William William Baker (6): midx: add MIDX_PROGRESS flag midx: add progress to write_midx_file midx: add progress to expire_midx_packs midx: honor the MIDX_PROGRESS flag in verify_midx_file midx: honor the MIDX_PROGRESS flag in midx_repack multi-pack-index: add [--[no-]p

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

On 10/16/19 12:48 PM, William Baker wrote:>> I do not care too deeply either way, but if you wrote it in one way, >> how about completing the series without changing it in the middle, >> and leave the clean-ups to a follow-up series (if needed)? > > > That plan s

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

ut if you wrote it in one way, > how about completing the series without changing it in the middle, > and leave the clean-ups to a follow-up series (if needed)? That plan sounds good to me. The most recent series (v3) should be ready to go, I don't believe there is any outstanding feedback to address. Thanks, William

[PATCH 1/1] t7519-status-fsmonitor: improve comments

From: William Baker The comments for the staging/unstaging test did not accurately describe the scenario being tested. It is not essential that the test files being staged/unstaged appear at the end of the index. All that is required is that the test files are not flagged with

[PATCH 0/1] t7519-status-fsmonitor: improve comments

This patch series is based on the 'wb/fsmonitor-bitmap-fix' branch and addresses feedback on the new test that was added there. I've updated the comments for the new test to more accurately describe the scenario being tested. Thanks, William William Baker (1): t7519-s

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

flag. - The git codebase uses both #defines and enums for flags. - The debugger always shows the enum value's name if there is a match, if values are OR-ed together there a few possibilities (see discussion above and earlier in the thread). - There are concerns regarding misinterpreting constants that are not a set of bits (e.g. "PROGRESS * 3"). Are there any other details I can provide that would help in reaching a conclusion as to how to proceed? At this time there are no other MIDX_* flags and so there's always the option to revisit the best way to handle multiple MIDX_* flags if/when additional flags are added. Thanks, William

Re: [PATCH v3 1/1] fsmonitor: don't fill bitmap with entries to be removed

On 10/11/19 6:26 PM, Junio C Hamano wrote: > "William Baker via GitGitGadget" writes: > >> +# Test staging/unstaging files that appear at the end of the index. Test >> +# file names begin with 'z' so that they are sorted to the end of the >> index.

[PATCH v3 0/1] fsmonitor: don't fill bitmap with entries to be removed

Dscho. Thanks, William William Baker (1): fsmonitor: don't fill bitmap with entries to be removed fsmonitor.c | 29 - t/t7519-status-fsmonitor.sh | 17 + t/t7519/fsmonitor-env | 24 3 files change

[PATCH v3 1/1] fsmonitor: don't fill bitmap with entries to be removed

From: William Baker While doing some testing with fsmonitor enabled I found that git commands would segfault after staging and unstaging an untracked file. Looking at the crash it appeared that fsmonitor_ewah_callback was attempting to adjust bits beyond the bounds of the index cache. Digging

Re: [PATCH v2 1/1] fsmonitor: don't fill bitmap with entries to be removed

27;t be necessary, and all my comments below about > that not-really-initial commit would be moot, too. > Thanks for this suggestion! I will submit a v3 version of the patch with an update to the test script. - William

[PATCH v2 0/1] fsmonitor: don't fill bitmap with entries to be removed

ment to be more descriptive Thanks, William William Baker (1): fsmonitor: don't fill bitmap with entries to be removed fsmonitor.c | 29 - t/t7519-status-fsmonitor.sh | 13 + t/t7519/fsmonitor-env | 24 +

[PATCH v2 1/1] fsmonitor: don't fill bitmap with entries to be removed

From: William Baker While doing some testing with fsmonitor enabled I found that git commands would segfault after staging and unstaging an untracked file. Looking at the crash it appeared that fsmonitor_ewah_callback was attempting to adjust bits beyond the bounds of the index cache. Digging

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

but I'd still wait for a few > days for people who expressed their Acks but your scan missed, or > those who wanted to give their Acks but forgot to do so, to raise > their hands on this thread. > This looks good to me as well: Acked-by: William Baker Thanks, William

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

flags_both) (lldb) p flags_1 (test_flags) $0 = TEST_FLAG_1 (lldb) p flags_2 (test_flags) $1 = TEST_FLAG_2 (lldb) p flags_both (test_flags) $2 = 3 (lldb) fr v flags_both (test_flags) flags_both = 3 (lldb) fr v --format enum flags_both (test_flags) flags_both = 3 (lldb) version lldb-902.0.79.7 Swift-4.1 Is there something that needs to be adjusted in the config or with --format to display "TEST_FLAG_1 | TEST_FLAG_2" in this example? Thanks, William

Re: [PATCH 1/1] fsmonitor: don't fill bitmap with entries to be removed

oved appear at the end of the index. > > In other words, future developers are warned against adding entries > to and leaving them in the index that sort later than z100 in new > tests they add before this point. Is the above wording clear enough > to tell them that, I wonder? > You're understanding is correct, and I agree this comment could be clearer. I will fix this up in v2. Thanks for the feedback! William

[PATCH 1/1] fsmonitor: don't fill bitmap with entries to be removed

From: William Baker While doing some testing with fsmonitor enabled I found that git commands would segfault after staging and unstaging an untracked file. Looking at the crash it appeared that fsmonitor_ewah_callback was attempting to adjust bits beyond the bounds of the index cache. Digging

[PATCH 0/1] fsmonitor: don't fill bitmap with entries to be removed

some BUG checks that would have helped catch this problem sooner. Special thanks to Dscho for pointing me in the right direction and suggesting a test that can reproduce the issue. Thanks, William William Baker (1): fsmonitor: don't fill bitmap with entries to be removed f

[PATCH v3 2/6] midx: add progress to write_midx_file

From: William Baker Add progress to write_midx_file. Progress is displayed when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/midx.c b/midx.c index b2673f52e8..0808a40dd4

[PATCH v3 5/6] midx: honor the MIDX_PROGRESS flag in midx_repack

From: William Baker Update midx_repack to only display progress when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/midx.c b/midx.c index ced5898bbf..1c5ddeb007 100644 --- a/midx.c +++ b/midx.c @@ -1374,6

[PATCH v3 6/6] multi-pack-index: add [--[no-]progress] option.

From: William Baker Add the --[no-]progress option to git multi-pack-index. Pass the MIDX_PROGRESS flag to the subcommand functions when progress should be displayed by multi-pack-index. The progress feature was added to 'verify' in 144d703 ("multi-pack-index: report progress

[PATCH v3 1/6] midx: add MIDX_PROGRESS flag

From: William Baker Add the MIDX_PROGRESS flag and update the write|verify|expire|repack functions in midx.h to accept a flags parameter. The MIDX_PROGRESS flag indicates whether the caller of the function would like progress information to be displayed. This patch only changes the method

[PATCH v3 4/6] midx: honor the MIDX_PROGRESS flag in verify_midx_file

From: William Baker Update verify_midx_file to only display progress when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/midx.c b/midx.c index f14bebb092..ced5898bbf 100644 --- a

[PATCH v3 3/6] midx: add progress to expire_midx_packs

From: William Baker Add progress to expire_midx_packs. Progress is displayed when the MIDX_PROGRESS flag is set. Signed-off-by: William Baker --- midx.c | 12 1 file changed, 12 insertions(+) diff --git a/midx.c b/midx.c index 0808a40dd4..f14bebb092 100644 --- a/midx.c +++ b

[PATCH v3 0/6] multi-pack-index: add --no-progress

ed Thanks, William William Baker (6): midx: add MIDX_PROGRESS flag midx: add progress to write_midx_file midx: add progress to expire_midx_packs midx: honor the MIDX_PROGRESS flag in verify_midx_file midx: honor the MIDX_PROGRESS flag in midx_repack multi-pack-index: add [--[no-]progre

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

gt; ... that is why compilers give a warning when you write > > switch (var) { > case ...: > ... > } > > and do not have case arms for all the declared enum values without > having the 'default' arm. > Thanks for all of the details and feedback here. I can leave the flag as-is (and not switch to enum). Thanks, William

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

mple. I saw that the code base is currently a mix of #define and enums when it comes to flags (e.g. dir_struct.flags and rebase_options.flags are both enums) and so using one here would not be something new stylistically. Although my debugger might not be the smartest, I haven't noticed any downsides to switching this to an enum. Thanks, William

Re: [PATCH v2 2/6] midx: add progress to write_midx_file Add progress to write_midx_file. Progress is displayed when the MIDX_PROGRESS flag is set.

st be of fixed type, I'd say > just an unsigned would be the most reasonable choice. > I agree that it's best to avoid using a fixed type here unless there's a reason that it must be. Do you think that both 'nr' and 'pack_paths_checked' being about the number of packs is a strong enough reason to use u32 for 'pack_paths_checked'? If not, I will update 'pack_paths_checked' in the next path series to be an unsigned int. Thanks, William

Re: [PATCH v2 1/6] midx: add MIDX_PROGRESS flag

ns when debugging, because > even 'gdb' shows the value using the symbolic names, e.g.: Thanks for this suggestion. I agree on the benefits of using an enum here and will make the switch in my next set of changes. -William

Re: [PATCH v2 2/6] midx: add progress to write_midx_file Add progress to write_midx_file. Progress is displayed when the MIDX_PROGRESS flag is set.

t we would run the (extremely unlikely) risk of having more than 65k packs on a system where unsigned is 16 bits. > FWIW, the function that uses this field is display_progress(), which > takes uint64_t there. Thanks for pointing this out. Given that display_progress() expects a u64 using that type here for 'pack_paths_checked' could help make things more straightforward. -William

Re: [PATCH v2 0/6] multi-pack-index: add --no-progress

e' should fit within the line, so ~50 chars. > > Philip > Thanks for the tip regarding 'git log --oneline'! I missed that I need a second end of line before the body of the commit message and I will be sure to include them in future commits. -William

Re: [PATCH v2 0/6] multi-pack-index: add --no-progress

issing a second line break before the body of the commit. -William

[PATCH v2 3/6] midx: add progress to expire_midx_packs Add progress to expire_midx_packs. Progress is displayed when the MIDX_PROGRESS flag is set.

From: William Baker Signed-off-by: William Baker --- midx.c | 12 1 file changed, 12 insertions(+) diff --git a/midx.c b/midx.c index 54e4e93b2b..3a0e161aea 100644 --- a/midx.c +++ b/midx.c @@ -1206,18 +1206,29 @@ int expire_midx_packs(struct repository *r, const char

[PATCH v2 6/6] multi-pack-index: add [--[no-]progress] option. Add the --[no-]progress option to git multi-pack-index. Pass the MIDX_PROGRESS flag to the subcommand functions when progress should be d

From: William Baker Signed-off-by: William Baker --- Documentation/git-multi-pack-index.txt | 6 ++- builtin/multi-pack-index.c | 18 +-- t/t5319-multi-pack-index.sh| 69 ++ 3 files changed, 87 insertions(+), 6 deletions(-) diff --git a

[PATCH v2 2/6] midx: add progress to write_midx_file Add progress to write_midx_file. Progress is displayed when the MIDX_PROGRESS flag is set.

From: William Baker Signed-off-by: William Baker --- midx.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/midx.c b/midx.c index b2673f52e8..54e4e93b2b 100644 --- a/midx.c +++ b/midx.c @@ -449,6 +449,8 @@ struct pack_list { uint32_t nr

[PATCH v2 4/6] midx: honor the MIDX_PROGRESS flag in verify_midx_file Update verify_midx_file to only display progress when the MIDX_PROGRESS flag is set.

From: William Baker Signed-off-by: William Baker --- midx.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/midx.c b/midx.c index 3a0e161aea..dc7c5f43f8 100644 --- a/midx.c +++ b/midx.c @@ -1098,15 +1098,16 @@ int verify_midx_file(struct repository *r

[PATCH v2 0/6] multi-pack-index: add --no-progress

Hello Git contributors! My name is William Baker and I work at Microsoft. Over the past few years I've worked closely with the Microsoft team contributing to the git ecosystem and I'm excited to start working with the community. Derrick Stolee helped me pick out my first task, and i

[PATCH v2 5/6] midx: honor the MIDX_PROGRESS flag in midx_repack Update midx_repack to only display progress when the MIDX_PROGRESS flag is set.

From: William Baker Signed-off-by: William Baker --- midx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/midx.c b/midx.c index dc7c5f43f8..106ccc4ab2 100644 --- a/midx.c +++ b/midx.c @@ -1374,6 +1374,12 @@ int midx_repack(struct repository *r, const char *object_dir, size_t

[PATCH v2 1/6] midx: add MIDX_PROGRESS flag Add the MIDX_PROGRESS flag and update the write|verify|expire|repack functions in midx.h to accept a flags parameter. The MIDX_PROGRESS flag indicates whet

From: William Baker Signed-off-by: William Baker --- builtin/multi-pack-index.c | 8 builtin/repack.c | 2 +- midx.c | 8 midx.h | 10 ++ 4 files changed, 15 insertions(+), 13 deletions(-) diff --git a/builtin

Re: [PATCH 1/1] multi-pack-index: add --no-progress Add --no-progress option to git multi-pack-index. The progress feature was added in 144d703 ("multi-pack-index: report progress during 'verify'", 20

I wasn't thinking that I would adjust the the subcommand dispatching in multi-pack-index.c in this patch series. By updating all of the subcommands to support [--[no-]progress] I should be able to keep the changes to multi-pack-index.c quite small. If you see any potential issues with this approach please let me know. Thanks, William

Re: [PATCH 1/1] multi-pack-index: add --no-progress Add --no-progress option to git multi-pack-index. The progress feature was added in 144d703 ("multi-pack-index: report progress during 'verify'", 20

structure; > > (3) add a new field "unsigned progress" to the structure, and teach > the command line parser to flip it upon seeing "--[no-]progress". > Thanks for this suggestion I'll use this approach in the next patch. One small point to clarify, in the current struct I'm using an int for "progress" because OPT_BOOL expects an int*. Do you have any concerns with keeping "progress" as an int in the public struct, or would you rather cmd_multi_pack_index parse an int internally and use it to populate the public struct? Thanks! William

[PATCH 0/1] multi-pack-index: add --no-progress

Hello Git contributors! My name is William Baker and I work at Microsoft. Over the past few years I've worked closely with the Microsoft team contributing to the git ecosystem and I'm excited to start working with the community. Derrick Stolee helped me pick out my first task, and i

[PATCH 1/1] multi-pack-index: add --no-progress Add --no-progress option to git multi-pack-index. The progress feature was added in 144d703 ("multi-pack-index: report progress during 'verify'", 2018-0

From: William Baker Signed-off-by: William Baker --- Documentation/git-multi-pack-index.txt | 6 +- builtin/multi-pack-index.c | 14 +--- midx.c | 30 +- midx.h | 6 -- t/t5319

[no subject]

subscribe git

[PATCH] restore: fix typo in docs

Signed-off-by: William Chargin --- Assuming this is a typo, because I can't parse the sentence; if not, perhaps it can be reworded for clarity? Documentation/git-restore.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-restore.txt b/Documentatio

Hello Dear ,

Hello Dear , It took a lot of time to finally find you. I am Susan William from London; I work with Royal Bank of Scotland, This letter is highly privileged and it requires your immediate attention. You are receiving this letter because your family name connected to a deceased client Eng

hello

Mijn naam is Eddy William. Ik ben van beroep advocaat. Ik wil je aanbieden nabestaanden van mijn cliënt. Je ervaart de som van ($ 14,2 miljoen) dollars die mijn cliënt voor zijn overlijden op de bank heeft achtergelaten. Mijn klant is een burger van jouw land die stierf in auto-ongeluk met zijn

hello

Mijn naam is Eddy William. Ik ben van beroep advocaat. Ik wil je aanbieden nabestaanden van mijn cliënt. Je ervaart de som van ($ 14,2 miljoen) dollars die mijn cliënt voor zijn overlijden op de bank heeft achtergelaten. Mijn klant is een burger van jouw land die stierf in auto-ongeluk met zijn

hello

Mijn naam is Eddy William. Ik ben van beroep advocaat. Ik wil je aanbieden nabestaanden van mijn cliënt. Je ervaart de som van ($ 14,2 miljoen) dollars die mijn cliënt voor zijn overlijden op de bank heeft achtergelaten. Mijn klant is een burger van jouw land die stierf in auto-ongeluk met zijn

PRIVEE

Good day , my name is David William , i sent you a mail and there was no response , please confirm that you did get this mail for more details. Regards. David William

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

On Wed, Feb 13, 2019 at 02:37:48PM -0800, Junio C Hamano wrote: > William Hubbs writes: > > > I am writing back onn this thread because I'm not quite sure of the > > status. v5 of the patch seemed ok, but there were some changes discussed > > that would have create

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

ng more or whether I'm waiting for you. ;-) Can you write back and let me know? Thanks, William

Workflow for GitHub branch model interop: advice?

Hi Git folks, I’m looking into automating a Git workflow, and am interested in folks’ feedback about whether my plan is reasonable or insane. The problem that I’m trying to solve is: I use GitHub a lot for work, but often find myself frustrated with GitHub’s “one-branch-per-change” model, as oppo

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

author = git_author_info(IDENT_STRICT); > + if (!author_ident_sufficiently_given()) > + warning("your author ident was auto-detected, etc..."); > + } > strbuf_addf(&buffer, "author %s\n", author); > strbuf_addf(&buffer, "committer %s\n", > git_committer_info(IDENT_STRICT)); > if (!encoding_is_utf8) > > I dunno. It seems pretty low priority, and nobody has even noticed after > all these years. So I'm not sure if it's worth spending too much time on > it. Given this info (which came in while I was writing my last email), I would rather see my v5 patch get in then we fix everything else later. Junio, what do you think? Thanks, William

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

On Wed, Feb 06, 2019 at 10:28:34AM +0100, Ævar Arnfjörð Bjarmason wrote: > > William, is that something you're intererested in carrying forward? I > can also help if you want. Sorry your first contribution to git has > turned into this mess of re-rolls, as often happens we find t

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

On Tue, Feb 05, 2019 at 06:15:58PM -0600, William Hubbs wrote: > On Tue, Feb 05, 2019 at 06:04:13PM -0600, William Hubbs wrote: > > On Tue, Feb 05, 2019 at 10:14:37PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > > > > On Tue, Feb 05 2019, Junio C Hamano wrote: &

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

On Tue, Feb 05, 2019 at 06:04:13PM -0600, William Hubbs wrote: > On Tue, Feb 05, 2019 at 10:14:37PM +0100, Ævar Arnfjörð Bjarmason wrote: > > > > On Tue, Feb 05 2019, Junio C Hamano wrote: > > > > > Ævar Arnfjörð Bjarmason writes: > > > > > >

Re: [PATCH v6 2/2] config: allow giving separate author and committer idents

p(var, "committer.email")) > >> + return set_ident_internal(var, value, &git_committer_email, > >> +IDENT_MAIL_GIVEN); > >> + else if (!strcmp(var, "user.name")) > >> + return set_ident_inte

[PATCH v5 1/1] config: allow giving separate author and committer idents

committer.name settings so this information can be set per repository. Also, it generalizes the fmt_ident function so it can handle author vs committer identification. Signed-off-by: William Hubbs --- Documentation/config/user.txt | 23 ++--- blame.c | 3 +- builtin

[PATCH v5 0/1] config: allow giving separate author and committer

*** BLURB HERE *** This update adds back the reference to the EMAIL environment variable. William Hubbs (1): config: allow giving separate author and committer idents Documentation/config/user.txt | 23 ++--- blame.c | 3 +- builtin/am.c | 1

[PATCH v4 0/1] config: allow giving separate author and committer idents

All, this implements the changes requested in v3 of this patch: - removes an extra comma from the enum - reworks the logic for config handling so that the author and committer variables are handled along with the user variables. Please review. William Hubbs (1): config: allow giving

[PATCH v4 1/1] config: allow giving separate author and committer idents

committer.name settings so this information can be set per repository. Also, it generalizes the fmt_ident function so it can handle author vs committer identification. Signed-off-by: William Hubbs --- Documentation/config/user.txt | 23 ++--- blame.c | 3 +- builtin

[PATCH v3 0/1] config: allow giving different author and committer idents

All, this version of the patch adds more test cases, combines the tests into the main patch, creates the static set_ident function, updates the documentation and fixes some formatting. It also applies against master. Please review. William Hubbs (1): config: allow giving separate author and

[PATCH v3 1/1] config: allow giving separate author and committer idents

committer.name settings so this information can be set per repository. Also, it generalizes the fmt_ident function so it can handle author vs committer identification. Signed-off-by: William Hubbs --- Documentation/config/user.txt | 23 ++--- blame.c | 3 +- builtin

Re: [PATCH v2 1/2] config: allow giving separate author and committer idents

On Fri, Jan 25, 2019 at 11:58:10PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jan 25 2019, William Hubbs wrote: > > > @@ -480,6 +515,46 @@ int git_ident_config(const char *var, const char > > *value, void *data) > > return 0; > >

Re: [PATCH v2 1/2] config: allow giving separate author and committer idents

s the best way to handle formatting issues would be, during your normal review, make a note directly below the affected line about what is wrong with the formatting and I'll fix it during the next pass. Or, another option would be to reply with a diff that I can apply on top of my patch. Thanks, William

Re: [PATCH v2 1/2] config: allow giving separate author and committer idents

On Fri, Jan 25, 2019 at 11:58:10PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jan 25 2019, William Hubbs wrote: > > > diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt > > index b5b2ba1199..18e1ec3c1b 100644 > > --- a/Documentatio

Re: [PATCH v2 2/2] tests: add test for separate author and committer idents

On Sat, Jan 26, 2019 at 12:05:08AM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Jan 25 2019, William Hubbs wrote: ... > > + sane_unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL && > > + sane_unset GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL && > > Fine, but

[PATCH v2 1/2] config: allow giving separate author and committer idents

committer.name settings so this information can be set per repository. Also, it generalizes the fmt_ident function so it can handle author vs committer identification. Signed-off-by: William Hubbs --- Documentation/config/user.txt | 31 +- blame.c | 3

Add author and committer configuration settings

separate author and committer [PATCH v2 2/2] tests: add test for separate author and committer Thanks, William

[PATCH v2 2/2] tests: add test for separate author and committer idents

Signed-off-by: William Hubbs --- t/t7517-per-repo-email.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t7517-per-repo-email.sh b/t/t7517-per-repo-email.sh index 231b8cc19d..06c7c0fb78 100755 --- a/t/t7517-per-repo-email.sh +++ b/t/t7517-per-repo-email.sh @@ -85,4

Attention:

: 05872, Released Code No: 1134; Immediate Telex confirmation No:- 043612; Secret Code No: TBKTA28 Re-Confirm; Regards. Mr Oscar william --

Re: Parsing trailers

> That's what "%(trailers:only)" does (even if the original separator was > something else). It also trims any extra whitespace. Ooh, this is good to know: thanks. (I had found `print_tok_val` in `trailer.c` and assumed that this was the only place with the output logic, but I now see that `format

Re: Parsing trailers

d some free time. :-) Best, WC On Tue, Dec 25, 2018 at 8:33 PM Christian Couder wrote: > > Hi William, > > On Mon, Dec 24, 2018 at 7:52 PM William Chargin wrote: > > > > Hi Christian: thanks for your reply. > > > > > Changing the default separator as sho

Re: Parsing trailers

Hi Christian: thanks for your reply. > Changing the default separator as shown above, should make it easier > to parse the result. But this actually also changes which lines are considered trailers, right? If the commit message ends with Signed-off-by: one Signed-off-by| two and the use

Parsing trailers

I'm interested in parsing the output of `git-interpret-trailers` in a script. I had hoped that the `--parse` option would make this easy, but it seems that the `trailer.separators` configuration option is used to specify both the input format (which separators may indicate a trailer) and the output

[PATCH 1/1] Add author and committer configuration settings

The author.email, author.name, committer.email and committer.name settings are analogous to the GIT_AUTHOR_* and GIT_COMMITTER_* environment variables, but for the git config system. This allows them to be set separately for each repository. Signed-off-by: William Hubbs

[PATCH 0/1] add author and committer configuration settings

reviews, and I would like to publically thank dscho from #git-devel for assisting me in preparing this patch. Also, since I use a screen reader, it would be very helpful if you put your comments in your replies as close to the affected code as possible, preferably directly below it. William Hubbs

Re: enhancement: support for author.email and author.name in "git config"

Hi Jonathan, On Fri, Dec 07, 2018 at 02:44:28PM -0800, Jonathan Nieder wrote: > William Hubbs wrote: > > On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote: > > >> There *is* a way to get what you want that is super easy and will > >> definitely w

Re: enhancement: support for author.email and author.name in "git config"

Hi Johannes, On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote: > Hi William, > >[...] > > There *is* a way to get what you want that is super easy and will > definitely work: if you sit down and do it ;-) > > Please let us know if you need any addit

Re: enhancement: support for author.email and author.name in "git config"

On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote: > Hi William, > > [...] > > This idea was floated a couple of months ago [1]. Junio seemed to find > the request sensible and outlined a design. No patches materialized, as > far as I know, but that could be bec

enhancement: support for author.email and author.name in "git config"

Does anyone have any thoughts on this? I don't think either of us is on the mailing list, so please keep us in CC's when you reply. Thanks, William

Hello Dear

Hello Dear, how are you today,I hope you are doing great. It is my great pleasure to contact you,I want to make a new and special friend,I hope you don't mind. My name is Tracy William from the United States, Am a french and English nationality. I will give you pictures and more de

For your Perusal

your FAMILY. Regards John William

Hello Dear

Hello Dear, how are you today,I hope you are doing great. It is my great pleasure to contact you,I want to make a new and special friend,I hope you don't mind. My name is Tracy William from the United States, Am a french and English nationality. I will give you pictures and more de

[PATCH v4] test_dir_is_empty: fix edge cases with newlines and hyphens

`ls -a` has at most two lines (for `.` and `..`), which should be better behaved, and adds the `--` delimiter before the directory name when invoking `ls`. The newly added unit test fails before this change and passes after it. Signed-off-by: William Chargin --- This patch depends on "t: f

[PATCH v4] test_dir_is_empty: fix edge cases with newlines and hyphens

`ls -a` has at most two lines (for `.` and `..`), which should be better behaved, and adds the `--` delimiter before the directory name when invoking `ls`. The newly added unit test fails before this change and passes after it. Signed-off-by: William Chargin --- This patch depends on "t: f

[PATCH] doc: git-describe

commit cc4bd5268b2dbe90279198acb400a528ee23f5d5 Author: William Pursell Date: Tue Aug 14 06:41:00 2018 -0600 doc: Reference for --dirty/--broken diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index e027fb8c4b..f7d67306c0 100644 --- a/Documentation/git

Re: [PATCH v3] test_dir_is_empty: properly detect files with newline in name

Thanks for the review. > We usually avoid "touch" unless the timestamp of the file is > significant. Makes sense. Will change as you suggest. > This is an abuse of test_must_fail() which is intended strictly for > testing 'git' invocations which might fail for reasons other than the > expected o

[PATCH v3] test_dir_is_empty: properly detect files with newline in name

test fails before this change and passes after it. Signed-off-by: William Chargin --- This patch depends on "t: factor out FUNNYNAMES as shared lazy prereq" (2018-08-06), available from `wc/make-funnynames-shared-lazy-prereq`. The code will work on master, but the test will not run due to

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

> That will recurse any subdirectories, possibly wasting time, but since > the point is that we expect it to be empty, that's probably OK. One caveat involves invocations of `test_must_fail test_dir_is_empty`, wherein we _don't_ actually expect the directory to be empty. It looks like there might

[PATCH] t: factor out FUNNYNAMES as shared lazy prereq

. After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has only one result. Signed-off-by: William Chargin --- Note: I've tested this only on an Ubuntu-like system, where FUNNYNAMES and FUNNIERNAMES are both naturally satisfied. I've verified that the tests corre

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

Hi, > This subject line will appear out of context in "git shortlog" output, > so it's useful to pack in enough information to briefly summarize what > the change does. I'm happy to do so. I think that "simplify" is misleading, because this is a bug fix, not a refactoring. I like your first sugge

[PATCH v2] t/test-lib: make `test_dir_is_empty` more robust

fails before this change and passes after it. Signed-off-by: William Chargin --- I originally wrote this patch for the standalone Sharness library, but that library advises that such patches be sent to the Git mailing list first. t/t-basic.sh| 29 + t

Re: [PATCH 0/1] t/test-lib: make `test_dir_is_empty` more robust

Hi Jonathan, > This information belongs in the commit message Agreed: I included it at the start of the commit message, though I suppose that the wording in the cover letter is clearer, so I've amended the commit to use that wording instead. > Continuing the note about ad

  1   2   >