Re: Fetch-hooks

On 02/10/2018 02:08 AM, Junio C Hamano wrote: > Leo Gaspard writes: > >> On 02/10/2018 01:13 AM, Jeff King wrote: >>> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: So the changes that are required are: * Adding a notification-only post-fetch hook > >

Re: [PATCH v1] worktree: set worktree environment in post-checkout hook

> On 10 Feb 2018, at 02:01, lars.schnei...@autodesk.com wrote: > > From: Lars Schneider > > In ade546be47 (worktree: invoke post-checkout hook (unless > --no-checkout), 2017-12-07) we taught Git to run the post-checkout hook > in worktrees. Unfortunately, the

Re: Fetch-hooks

Leo Gaspard writes: > On 02/10/2018 01:13 AM, Jeff King wrote: >> On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: >>> So the changes that are required are: >>> * Adding a notification-only post-fetch hook Maybe I missed a very early part of the discussion, but why

[no subject]

I am contacting you in respect of our late client who deposited fund valued at the sum of $6,200,000.00 in my bank,he died with his family in an auto accident. I have contacted you to stand as his heir and inherit the funds, after the success of this transaction, we should share the total funds

Re: [PATCH v6 0/7] convert: add support for different encodings

> On 09 Feb 2018, at 21:09, Junio C Hamano wrote: > > Documentation has core.checkRoundtripEncoding while t0028 and a > comment in convert.c capitalize it differently. I suspect that it > would be more reader-friendly to update the documentation to match. Agreed. I will

[PATCH v1] worktree: set worktree environment in post-checkout hook

From: Lars Schneider In ade546be47 (worktree: invoke post-checkout hook (unless --no-checkout), 2017-12-07) we taught Git to run the post-checkout hook in worktrees. Unfortunately, the environment of the hook was not made aware of the worktree. Consequently, a 'git

Re: Fetch-hooks

On 02/10/2018 01:13 AM, Jeff King wrote: > On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: >> So the changes that are required are: >> * Adding a notification-only post-fetch hook >> * For handling tags, there is a need to have a refmap for tags. Maybe >> adding a

Re: Fetch-hooks

On Sat, Feb 10, 2018 at 12:49:31AM +0100, Leo Gaspard wrote: > > I tend to agree with the direction of thinking you outlined: you're > > generally better off completing the fetch to a local namespace that > > tracks the other side completely, and then manipulating the local refs > > as you see

Re: Fetch-hooks

On 02/09/2018 11:30 PM, Jeff King wrote: > On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote: >> One thing that's not discussed yet, and I know just enough about for it >> to tingle my spidey sense, but not enough to say for sure (CC'd Jeff & >> Brandon who know more) is that

[RFC PATCH 2/3] t1450-fsck: Add tests for HEAD of other worktrees

Signed-off-by: Elijah Newren --- t/t1450-fsck.sh | 27 +++ 1 file changed, 27 insertions(+) diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh index cb4b66e29d..fa94c59458 100755 --- a/t/t1450-fsck.sh +++ b/t/t1450-fsck.sh @@ -102,6 +102,33 @@

Re: [PATCH 046/194] object-store: move replace_objects back to object-store

Stefan Beller writes: > @@ -32,7 +31,15 @@ struct object_store { >* Objects that should be substituted by other objects >* (see git-replace(1)). >*/ > - struct replace_objects replacements; > + struct replace_objects { > + /* > +

[RFC PATCH 0/3] Make fsck check other worktree HEADs

This patchset adds checking of other worktree HEADs to fsck. The reason I've marked this RFC is that I'm worried my incidental reliance on "worktrees/$WORKTREE/HEAD" resolving as a ref (in patch 3) might raise some flags for others. In particular, in [1] Peff said that this refname resolves

[RFC PATCH 1/3] fsck: Move fsck_head_link() to get_default_heads() to avoid some globals

This will make it easier to check the HEAD of other worktrees from fsck. Signed-off-by: Elijah Newren --- builtin/fsck.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/builtin/fsck.c b/builtin/fsck.c index

[RFC PATCH 3/3] fsck: Check HEAD of other worktrees as well

This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will currently resolve as a ref, which may not be true in the future with different ref backends. I don't think it locks us in to supporting resolving other worktree HEADs with this syntax, as I view the user-visible error message

Re: [PATCH 042/194] object-store: move alternates API to new alternates.h

"brian m. carlson" writes: >> +#include "strbuf.h" >> +#include "sha1-array.h" >> + >> +struct alternates { >> +struct alternate_object_database *list; >> +struct alternate_object_database **tail; >> +}; >> +#define ALTERNATES_INIT { NULL, NULL } > > I was

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >>> Will queue with the above typofix, together with the other one. I >>> am not sure if we want to say "Before 2.17", though. >> >> I'm just keeping in mind the user who later on upgrades git

Re: Fetch-hooks

On Fri, Feb 09 2018, Leo Gaspard jotted: > On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also > have some intermediate step between these two, where e.g. your refspec for "origin" is "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: >> Will queue with the above typofix, together with the other one. I >> am not sure if we want to say "Before 2.17", though. > > I'm just keeping in mind the user who later on upgrades git from say > 2.14 to 2.18 or something, and is able to

Re: Fetch-hooks

Jeff King writes: > The negotiation for future fetches uses the existing refs as the > starting point. And if we don't know that we have the objects because > there are no refs pointing at them, they're going to get transferred > again. That's extra load no the server, and extra

Re: "git bisect run make" adequate to locate first unbuildable commit?

From: "Robert P. J. Day" On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote: (apologies for using the fancy letters after the name ID...) From: "Robert P. J. Day" > > writing a short tutorial on "git bisect" and, all the details of > special

Re: [PATCH 2/2] fetch: add tweak-fetch hook

Leo Gaspard writes: > +tweak-fetch > +~~~ > + > +This hook is invoked by 'git fetch' (commonly called by 'git pull'), after > refs > +have been fetched from the remote repository. It is not executed, if nothing > was > +fetched. Need to tighten explanation of "nothing

Re: [PATCH 1/2] fetch: preparations for tweak-fetch hook

Leo Gaspard writes: > From: Léo Gaspard > > No behavior changes yet, only some groundwork for the next change. > > The refs_result structure combines a status code with a ref map, which > can be NULL even on success. Sorry, but I have absolutely no idea what

Re: Fetch-hooks

On Fri, Feb 09, 2018 at 11:04:17PM +0100, Ævar Arnfjörð Bjarmason wrote: > One thing that's not discussed yet, and I know just enough about for it > to tingle my spidey sense, but not enough to say for sure (CC'd Jeff & > Brandon who know more) is that this feature once shipped might cause >

Re: Fetch-hooks

On 02/09/2018 11:04 PM, Ævar Arnfjörð Bjarmason wrote:>>> You could also have some intermediate step between these two, where >>> e.g. your refspec for "origin" is >>> "+refs/heads/*:refs/remotes/origin-untrusted/*" instead of the default >>> "+refs/heads/*:refs/remotes/origin/*", you fetch all

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> +Before 2.17, the untracked cache had a bug where replacing a directory >> +with a symlink to another directory could cause it to incorrectly show >> +files tracked by git as untracked. See

Re: [PATCH 0/2] update-index doc: note new caveats in 2.17

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> When users upgrade to 2.17 they're going to have git yelling at them >> (as my users did) on existing checkouts, with no indication whatsoever >> that it's due to the UC or how to fix it. > >

Re: [PATCH 003/194] object-store: move packed_git and packed_git_mru to object store

Stefan Beller writes: > Patch generated by > > 2. Applying the semantic patch contrib/coccinelle/packed_git.cocci > to adjust callers. About this part... > diff --git a/contrib/coccinelle/packed_git.cocci > b/contrib/coccinelle/packed_git.cocci > new file mode 100644

Re: Fetch-hooks

On Thu, Feb 08 2018, Leo Gaspard jotted: > On 02/08/2018 10:06 PM, Ævar Arnfjörð Bjarmason wrote:>> Hmm, OK, so I > guess I'll try to update the patch when I get some time to >>> delve into git's internals, as my use case (forbidding some fetches) >>> couldn't afaik be covered by a wrapper hook.

Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: > +Before 2.17, the untracked cache had a bug where replacing a directory > +with a symlink to another directory could cause it to incorrectly show > +files tracked by git as untracked. See the "status: add a failing test > +showing a

[PATCH 1/2] fetch: preparations for tweak-fetch hook

From: Léo Gaspard No behavior changes yet, only some groundwork for the next change. The refs_result structure combines a status code with a ref map, which can be NULL even on success. This will be needed when there's a tweak-fetch hook, because it can filter out all refs,

[PATCH 2/2] fetch: add tweak-fetch hook

From: Léo Gaspard The tweak-fetch hook is fed lines on stdin for all refs that were fetched, and outputs on stdout possibly modified lines. Its output is then parsed and used when `git fetch` updates the remote tracking refs, records the entries in FETCH_HEAD, and produces its

Re: [PATCH 0/2] update-index doc: note new caveats in 2.17

Ævar Arnfjörð Bjarmason writes: > When users upgrade to 2.17 they're going to have git yelling at them > (as my users did) on existing checkouts, with no indication whatsoever > that it's due to the UC or how to fix it. Wait. Are you saying that the new warning is "warning"

[PATCH 0/2] fetch: add tweak-fetch hook

On 02/09/2018 09:20 PM, Joey Hess wrote:> Yes; my patches are under the same GPL-2 as the rest of git. Thanks! So here comes my patch series, heavily based on yours. There are some things to bear in mind while reviewing it: * This is my first real attempt at contributing to git, which means I

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

On Fri, Feb 9, 2018 at 3:27 PM, Jeff King wrote: > On Fri, Feb 09, 2018 at 09:05:00PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >> + key=$(echo $1 | sed -e 's/^remote\.origin/fetch/') >> > >> > Faster (thus more Windows-friendly) assuming that $1 always starts >> >

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

Junio C Hamano writes: > Ævar Arnfjörð Bjarmason writes: > + key=$(echo $1 | sed -e 's/^remote\.origin/fetch/') >>> >>> Faster (thus more Windows-friendly) assuming that $1 always starts >>> with "remote.origin": >>> >>>

Re: [PATCH v2 00/17] document & test fetch pruning & add fetch.pruneTags

On Thu, Feb 08 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> On Thu, Feb 08 2018, Ævar Arnfjörð Bjarmason jotted: >> >>> As noted in my 87h8quytmq@evledraar.gmail.com there was a bug I >>> noticed in v3 where it would segfault on some git-fetch

[PATCH 1/2] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's not obvious how to fix

[PATCH 0/2] update-index doc: note new caveats in 2.17

On Fri, Feb 09 2018, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: >> I think you / Nguyễn may not have seen my >> <87d11omi2o@evledraar.gmail.com> >> (https://public-inbox.org/git/87d11omi2o@evledraar.gmail.com/) >> >> As noted there I think it's best to

[PATCH 2/2] update-index doc: note the caveat with "could not open..."

Note the caveat where 2.17 is stricter about index validation potentially causing "could not open directory" warnings when git is upgraded. See the preceding "dir.c: stop ignoring opendir() error in open_cached_dir()" change. This caused some mayhem when I upgraded git to a version with this

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

Ævar Arnfjörð Bjarmason writes: >>> + key=$(echo $1 | sed -e 's/^remote\.origin/fetch/') >> >> Faster (thus more Windows-friendly) assuming that $1 always starts >> with "remote.origin": >> >> key=fetch${u#remote.origin} > > Tests fail with this and I'm not

Re: "git bisect run make" adequate to locate first unbuildable commit?

From: "Robert P. J. Day" writing a short tutorial on "git bisect" and, all the details of special exit code 125 aside, if one wanted to locate the first unbuildable commit, would it be sufficient to just run? $ git bisect run make as i read it, make returns either

Re: "git bisect run make" adequate to locate first unbuildable commit?

On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote: > From: "Robert P. J. Day" > > > > writing a short tutorial on "git bisect" and, all the details of > > special exit code 125 aside, if one wanted to locate the first > > unbuildable commit, would it be sufficient to just

[PATCH v5 17/17] fetch: make the --prune-tags work with

Make the new --prune-tags option work properly when git-fetch is invoked with a parameter instead of a parameter. This change is split off from the introduction of --prune-tags due to the relative complexity of munging the incoming argv, which is easier to review as a separate change.

[PATCH v5 16/17] fetch: add a --prune-tags option and fetch.pruneTags config

Add a --prune-tags option to git-fetch, along with fetch.pruneTags config option and a -P shorthand (-p is --prune). This allows for doing any of: git fetch -p -P git fetch --prune --prune-tags git fetch -p -P origin git fetch --prune --prune-tags origin Or simply: git

[PATCH v5 15/17] fetch tests: add scaffolding for the new fetch.pruneTags

The fetch.pruneTags configuration doesn't exist yet, but will be added in a subsequent commit. Since testing for it requires adding new parameters to the test_configured_prune function it's easier to review this patch first to assert that no functional changes are introduced yet. Signed-off-by:

[PATCH v5 07/17] fetch tests: add a tag to be deleted to the pruning tests

Add a tag to be deleted to the fetch --prune tests. The tag is always kept for now, which is the expected behavior, but now I can add a test for tag pruning in a later commit. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 93

[PATCH v5 06/17] fetch tests: re-arrange arguments for future readability

Re-arrange the arguments to the test_configured_prune() function used in this test to pass the arguments to --fetch last. A subsequent change will test for more elaborate fetch arguments, including long refspecs. It'll be more readable to be able to wrap those on a new line of their own.

[PATCH v5 14/17] git-fetch & config doc: link to the new PRUNING section

Amend the documentation for fetch.prune, fetch..prune and --prune to link to the recently added PRUNING section. I'd have liked to link directly to it with "<>" from fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt also includes it, but doesn't include that option). However

[PATCH v5 12/17] git fetch doc: add a new section to explain the ins & outs of pruning

Add a new section to canonically explain how remote reference pruning works, and how users should be careful about using it in conjunction with tag refspecs in particular. A subsequent commit will update the git-remote documentation to refer to this section, and details the motivation for writing

[PATCH v5 11/17] fetch tests: fetch as well as fetch []

When a remote URL is supplied on the command-line the internals of the fetch are different, in particular the code in get_ref_map(). An earlier version of the subsequent fetch.pruneTags patch hid a segfault because the difference wasn't tested for. Now all the tests are run as both of the

[PATCH v5 13/17] git remote doc: correct dangerous lies about what prune does

The "git remote prune " command uses the same machinery as "git fetch --prune", and shares all the same caveats, but its documentation has suggested that it'll just "delete stale remote-tracking branches under ". This isn't true, and hasn't been true since at least v1.8.5.6 (the oldest version I

[PATCH v5 05/17] fetch tests: refactor in preparation for testing tag pruning

In a subsequent commit this function will learn to test for tag pruning, prepare for that by making space for more variables, and making it clear that "expected" here refers to branches. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 9 ++--- 1 file changed,

[PATCH v5 01/17] fetch: don't redundantly NULL something calloc() gave us

Stop redundantly NULL-ing the last element of the refs structure, which was retrieved via calloc(), and is thus guaranteed to be pre-NULL'd. This code dates back to b888d61c83 ("Make fetch a builtin", 2007-09-10), where wasn't any reason to do this back then either, it's just boilerplate left

[PATCH v5 03/17] fetch: stop accessing "remote" variable indirectly

Access the "remote" variable passed to the fetch_one() directly rather than through the gtransport wrapper struct constructed in this function for other purposes. This makes the code more readable, as it's now obvious that the remote struct doesn't somehow get munged by the prepare_transport()

[PATCH v5 04/17] remote: add a macro for "refs/tags/*:refs/tags/*"

Add a macro with the refspec string "refs/tags/*:refs/tags/*". There's been a pre-defined struct version of this since e0aaa29ff3 ("Have a constant extern refspec for "--tags"", 2008-04-17), but nothing that could be passed to e.g. add_fetch_refspec(). This will be used in subsequent commits to

[PATCH v5 10/17] fetch tests: expand case/esac for later change

Expand a compact case/esac statement for a later change that'll add more logic to the body of the "*" case. This is a whitespace-only change. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH v5 02/17] fetch: trivially refactor assignment to ref_nr

Trivially refactor an assignment to make a subsequent patch smaller. The "ref_nr" variable is initialized to 0 earlier, just as "j" is, and "j" is only incremented in that loop, so this change isn't a logic error. This change simplifies a subsequent change, which will split the incrementing of

[PATCH v5 09/17] fetch tests: double quote a variable for interpolation

If the $cmdline variable contains arguments with spaces they won't be interpolated correctly, since the body of the test is single quoted, and because test-lib.sh does its own eval(). This will be used in a subsequent commit to pass arguments that need to be quoted to git-fetch, i.e. a file://

[PATCH v5 00/17] document & test fetch pruning & add fetch.pruneTags

Here's a v5 (correct subject line this time!). Many thanks to Eric for a thorough review. I'll spare you the per-patch changelog. These are all minor commit message / doc / comment wording changes, with the exception of making a bit of the test code better, and adding a \n for grep portability.

[PATCH v5 08/17] fetch tests: test --prune and refspec interaction

Add a test for the interaction between explicitly provided refspecs and fetch.prune. There's no point in adding this boilerplate to every combination of unset/false/true, it's instructive and sufficient to show that no matter if the variable is unset, false or true the refspec on the command-line

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

On Fri, Feb 09, 2018 at 09:05:00PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh > >> @@ -548,18 +548,52 @@ set_config_tristate () { > >> *) > >> git config "$1" "$2" > >> + key=$(echo $1 | sed -e

Re: Fetch-hooks

Leo Gaspard wrote: > I just wanted to check, you did not put the Signed-off-by line in > patches in https://marc.info/?l=git=132491485901482=2 > > Could you confirm that the patches you sent are “covered under an > appropriate open source license and I have the right under that license > to

Re: [PATCH v6 0/7] convert: add support for different encodings

Documentation has core.checkRoundtripEncoding while t0028 and a comment in convert.c capitalize it differently. I suspect that it would be more reader-friendly to update the documentation to match.

Re: [PATCH v2 11/17] fetch tests: fetch as well as fetch []

On Fri, Feb 09 2018, Eric Sunshine jotted: > On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason > wrote: >> When a remote URL is supplied on the command-line the internals of the >> fetch are different, in particular the code in get_ref_map(). An >> earlier version of

Re: [PATCH v6 4/7] utf8: add function to detect a missing UTF-16/32 BOM

> On 09 Feb 2018, at 20:28, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> From: Lars Schneider >> >> If the endianness is not defined in the encoding name, then let's >> ... >> [3] https://encoding.spec.whatwg.org/#utf-16le >>

Re: totally confused as to what "git bisect skip" is supposed to do

On Fri, 9 Feb 2018, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > > i'm confused ... why, after skipping a good chunk in the > > interval [v4.13,v4.14], do i still have exactly 7300 revisions to > > bisect? what am i so hopelessly misunderstanding here? > > Are

Re: [PATCH 2/2] packfile: refactor hash search with fanout table

On Fri, 9 Feb 2018 19:03:48 +0100 René Scharfe wrote: > Going from unsigned to signed int means the patch breaks support for > more than 2G pack entries, which was put with 326bf39677 (Use uint32_t > for all packed object counts.) in 2007. Ah, good catch. I'll wait to see if there

Re: totally confused as to what "git bisect skip" is supposed to do

"Robert P. J. Day" writes: > i'm confused ... why, after skipping a good chunk in the interval > [v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what > am i so hopelessly misunderstanding here? Are you really "skipping" a chunk in the interval? I

totally confused as to what "git bisect skip" is supposed to do

all right, i'm sure i'm just being an idiot, but i always thought i knew what "git bisect skip" did and, now that i'm trying to put together a simple example, i'm utterly confused so here's a stripped down example. with linus kernel source code, start bisecting [v4.13,v4.14]: $ git bisect

Re: [PATCH] CodingGuidelines: mention "static" and "extern"

On Fri, Feb 09, 2018 at 11:07:38AM -0800, Jonathan Tan wrote: > On Thu, 8 Feb 2018 18:14:06 -0500 > Eric Sunshine wrote: > > > On Thu, Feb 8, 2018 at 4:38 PM, Jeff King wrote: > > > Subject: [PATCH] CodingGuidelines: mention "static" and "extern" > > >

Re: [PATCH 1/1] Mark messages for translations

On Fri, Feb 09, 2018 at 11:15:06AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > >> - if ! grep "Invalid gitfile format" .err > >> + if ! test_i18ngrep "invalid gitfile format" .err > > > > Shouldn't this rather be like so instead? > > > > if test_i18ngrep !

Re: [PATCH v6 4/7] utf8: add function to detect a missing UTF-16/32 BOM

lars.schnei...@autodesk.com writes: > From: Lars Schneider > > If the endianness is not defined in the encoding name, then let's > ... > [3] https://encoding.spec.whatwg.org/#utf-16le > > Signed-off-by: Lars Schneider > > utf > --- Huh? >

Re: [PATCH 1/1] Mark messages for translations

Junio C Hamano writes: >> -if ! grep "Invalid gitfile format" .err >> +if ! test_i18ngrep "invalid gitfile format" .err > > Shouldn't this rather be like so instead? > > if test_i18ngrep ! "invalid gitfile format" .err > > Ditto for the other negated use of

Re: Fetch-hooks

On 02/08/2018 06:02 PM, Leo Gaspard wrote: > On 02/08/2018 04:30 PM, Joey Hess wrote: >> [...] > > Hmm, OK, so I guess I'll try to update the patch when I get some time to > delve into git's internals, as my use case (forbidding some fetches) > couldn't afaik be covered by a wrapper hook. Joey,

Re: [PATCH] CodingGuidelines: mention "static" and "extern"

On Thu, 8 Feb 2018 18:14:06 -0500 Eric Sunshine wrote: > On Thu, Feb 8, 2018 at 4:38 PM, Jeff King wrote: > > Subject: [PATCH] CodingGuidelines: mention "static" and "extern" > > [...] > > > > Signed-off-by: Jeff King > > --- > > diff

Re: [PATCH v2 01/17] fetch: don't redundantly NULL something calloc() gave us

On Fri, Feb 09 2018, Eric Sunshine jotted: > On Thu, Feb 8, 2018 at 11:19 AM, Ævar Arnfjörð Bjarmason > wrote: >> Stop redundantly NULL-ing the last element of the refs structure, >> which was retrieved via calloc(), and is thus guaranteed to be >> pre-NULL'd. >> [...] >>

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

On Fri, Feb 09, 2018 at 01:57:10PM -0500, Jeff King wrote: > Here's what it looks like as a patch. > > -- >8 -- > Subject: [PATCH] t: send verbose test-helper output to fd 4 That applies on 'master'. If we go this route, we'd want this on sg/test-i18ngrep, which is in 'next' right now: -- >8

Re: [PATCH v3 04/42] git-completion.bash: introduce __gitcomp_builtin

Nguyễn Thái Ngọc Duy writes: > +# This function is equivalent to > +# > +#__gitcomp "$(git xxx --git-completion-helper) ..." > +# > +# except that the output is cached. Accept 1-3 arguments: > +# 1: the git command to execute, this is also the cache key > +# 2: extra

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

On Fri, Feb 09, 2018 at 10:36:19AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > 2. The "-x" problems aren't specific to test_must_fail at all. They're > > a general issue with shell functions. > > > > I'm not entirely happy with saying "if you want to use -x,

Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)

Ævar Arnfjörð Bjarmason writes: > On Thu, Feb 01 2018, Junio C. Hamano jotted: > >> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits >> - dir.c: stop ignoring opendir() error in open_cached_dir() >> - update-index doc: note a fixed bug in the untracked cache >> -

Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)

On Thu, Feb 01 2018, Junio C. Hamano jotted: > * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits > - dir.c: stop ignoring opendir() error in open_cached_dir() > - update-index doc: note a fixed bug in the untracked cache > - dir.c: fix missing dir invalidation in untracked code >

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

Jeff King writes: > 2. The "-x" problems aren't specific to test_must_fail at all. They're > a general issue with shell functions. > > I'm not entirely happy with saying "if you want to use -x, please use > bash". But given that it actually solves the problems everywhere

Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)

On Fri, Feb 09 2018, Johannes Schindelin jotted: > Hi, > > On Thu, 1 Feb 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Feb 01 2018, Junio C. Hamano jotted: >> >> > * ab/wildmatch-tests (2018-01-30) 10 commits >> > - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS >> > - test-lib: add an

Re: [PATCH 3/3] t1404: use 'test_must_fail stderr='

SZEDER Gábor writes: > On Fri, Feb 9, 2018 at 4:16 AM, Eric Sunshine wrote: >> On Thu, Feb 8, 2018 at 9:42 PM, SZEDER Gábor wrote: >>> Instead of 'test_must_fail git cmd... 2>output.err', which redirects >>> the standard

Re: [PATCH 1/1] Mark messages for translations

Alexander Shopov writes: > Small changes in messages to fit the style and typography of rest > Reuse already translated messages if possible > Do not translate messages aimed at developers of git > Fix unit tests depending on the original string > Use `test_i18ngrep` for

Re: [PATCH 2/2] packfile: refactor hash search with fanout table

Am 02.02.2018 um 23:36 schrieb Jonathan Tan: > Subsequent patches will introduce file formats that make use of a fanout > array and a sorted table containing hashes, just like packfiles. > Refactor the hash search in packfile.c into its own function, so that > those patches can make use of it as

Re: [PATCH] rebase -p: fix incorrect commit message when calling `git merge`.

Hi, On Thu, 8 Feb 2018, gregory.herr...@oracle.com wrote: > From: Gregory Herrero > > Since commit dd6fb0053 ("rebase -p: fix quoting when calling `git > merge`"), commit message of the merge commit being rebased is passed to > the merge command using a subshell

Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)

Hi, On Thu, 1 Feb 2018, Ævar Arnfjörð Bjarmason wrote: > On Thu, Feb 01 2018, Junio C. Hamano jotted: > > > * ab/wildmatch-tests (2018-01-30) 10 commits > > - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS > > - test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite > > - wildmatch test:

Dear friend,

Dear friend, I Mr. Baari Abdul, Head of Operation at Bank of Africa. I want invite into a business overture which involves an amount of $ 22.3 million. At your acceptance, this amount will be transferred to your name as a foreign partner. I need your help to get this fund to be

should "git bisect skip" not visually reduce number of revisions left?

perhaps i'm misreading something, but i'm trying to put together a hands-on example on how to use "git bisect" with feature branches as explained here: https://blog.smart.ly/2015/02/03/git-bisect-debugging-with-feature-branches/ and i'm using the linux kernel source as the content, so i

[BUG] Integer overflow when supplying large context value to diff --unified

Hello, Git versions tested: 2.13.6, 2.1.4 When passing-in a large context value for the --unified option for git-diff, Git will produce an invalid-looking range information for hunks. For example, if running 'git diff --unified=10 HEAD^', the output will include (this is just a run against my

Re: [PATCH 2/3] t: teach 'test_must_fail' to save the command's stderr to a file

On Fri, Feb 09, 2018 at 03:42:34AM +0100, SZEDER Gábor wrote: > To check that a git command fails and to inspect its error message we > usually execute a command like this throughout our test suite: > > test_must_fail git command --option 2>output.err > > Note that this command doesn't limit

Re: [PATCH v3 42/42] git-completion.bash: add GIT_COMPLETION_OPTIONS=all config

On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy jotted: > By default, some option names (mostly --force, scripting related or for > internal use) are not completable for various reasons. When > GIT_COMPLETION_OPTIONS is set to all, all options (except hidden ones) > are completable. > > Signed-off-by:

Re: [PATCH v3 14/14] commit-graph: build graph from starting commits

On 2/9/2018 8:02 AM, SZEDER Gábor wrote: On Thu, Feb 8, 2018 at 9:37 PM, Derrick Stolee wrote: Teach git-commit-graph to read commits from stdin when the --stdin-commits flag is specified. Commits reachable from these commits are added to the graph. This is a much faster way

Re: categorization, documentation and packaging of "git core" commands

On Wed, 7 Feb 2018, Todd Zullinger wrote: > Robert P. J. Day wrote: > > not to belabour this (and i'm sure it's *way* too late for that), > > but fedora has the following packaging scheme. first, there's a > > bunch of stuff in "git-core", which has no dependencies on any > > other git-related

Re: "git bisect run make" adequate to locate first unbuildable commit?

On Fri, Feb 9, 2018 at 2:20 PM, Robert P. J. Day wrote: > > writing a short tutorial on "git bisect" and, all the details of > special exit code 125 aside, if one wanted to locate the first > unbuildable commit, would it be sufficient to just run? > > $ git bisect run

[PATCH v6 6/7] convert: add tracing for 'working-tree-encoding' attribute

From: Lars Schneider Add the GIT_TRACE_WORKING_TREE_ENCODING environment variable to enable tracing for content that is reencoded with the 'working-tree-encoding' attribute. This is useful to debug encoding issues. Signed-off-by: Lars Schneider

[PATCH v6 1/7] strbuf: remove unnecessary NUL assignment in xstrdup_tolower()

From: Lars Schneider Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we allocate the buffer for the lower case string with xmallocz(). This already ensures a NUL at the end of the allocated buffer. Remove the unnecessary assignment. Signed-off-by:

[PATCH v6 2/7] strbuf: add xstrdup_toupper()

From: Lars Schneider Create a copy of an existing string and make all characters upper case. Similar xstrdup_tolower(). This function is used in a subsequent commit. Signed-off-by: Lars Schneider --- strbuf.c | 12 strbuf.h |

[PATCH v6 0/7] convert: add support for different encodings

From: Lars Schneider Hi, Patches 1-4, 6 are preparation and helper functions. Patch 5,7 are the actual change. This series depends on Torsten's 8462ff43e4 (convert_to_git(): safe_crlf/checksafe becomes int conv_flags, 2018-01-13) which is already in next. Changes

  1   2   >