Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

On 11/05/2017 07:17 AM, Junio C Hamano wrote: > Junio C Hamano writes: >> Rafael Ascensão writes: >> ... >>> Because changing the default behavior of that function has >>> implications on multiple commands which I think shouldn't change. But >>> at the

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 11/06/2017 02:23 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> [1] I say "almost entirely" because putting them in one function means >> that only `pattern` needs to be scanned for glob characters. But that is >> an unimportant detail. > > That could

benefits of "/" in branch names other than the obvious?

another picky question ... are there any other benefits of supporting slashes in branch names other than the obvious ones i know about? 1) visually, let's you *imagine* a branch hierarchy, and 2) allows wildcarding on a full "component" basis are there any other benefits of the above? thank

Re: what is the function of .git/branches/?

On Mon, 6 Nov 2017, Junio C Hamano wrote: > "Robert P. J. Day" writes: > > > currently proofing "pro git" book, and an example of a new repo > > doesn't show a .git/branches/ directory, but initializing a new > > repo with current version of 2.13.6 *does* show an

Re: [PATCH 3/3] Documentation: revisions: add note about 3dots usages as continuation indications

Ann T Ropea writes: > Also, fix typo: "three dot" ---> "three-dot" (align with "two-dot"). > > Signed-off-by: Ann T Ropea > --- > Documentation/revisions.txt | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Rafael Ascensão writes: > Would checking the output of ref_exists() make sense here? > By that I mean, only add a trailing '/*' if the ref doesn't exist. I do not think it would hurt, but it is not immediately obvious if the benefit of doing so outweighs the cost of having

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Would checking the output of ref_exists() make sense here? By that I mean, only add a trailing '/*' if the ref doesn't exist. Unless I am missing something obvious this would allow us to keep both shortcuts and exact patterns.

Re: [PATCH 1/3] checkout: describe_detached_head: remove 3dots after committish

Ann T Ropea writes: > This could be confusing not only for novices; in either case, no range > should be insinuated by describe_detached_head. We actually do not insinuate any range in these output. These dots denote "truncated at the end, instead of giving full length."

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 06/11/17 01:23, Junio C Hamano wrote: > Michael Haggerty writes: > >> [1] I say "almost entirely" because putting them in one function means >> that only `pattern` needs to be scanned for glob characters. But that is >> an unimportant detail. > > That could actually be

Re: [PATCH] fix typos in 2.15.0 release notes

Jean Carlo Machado writes: > Signed-off-by: Jean Carlo Machado > --- > Documentation/RelNotes/2.15.0.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) It is pretty much pointless to update release notes after a

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

Kaartic Sivaraam writes: > diff --git a/builtin/branch.c b/builtin/branch.c > index 7018e5d75..c2bbf8c3d 100644 > --- a/builtin/branch.c > +++ b/builtin/branch.c > @@ -458,11 +458,42 @@ static void reject_rebase_or_bisect_branch(const char > *target) >

Re: [RFC PATCH v3 3/4] branch: introduce dont_fail parameter for branchname validation

Kaartic Sivaraam writes: > This parameter allows the branchname validation functions to > optionally return a flag specifying the reason for failure, when > requested. This allows the caller to know why it was about to die. > This allows more useful error messages to

Re: [RFC PATCH v3 2/4] branch: re-order function arguments to group related arguments

Kaartic Sivaraam writes: > From: Kaartic Sivaraam > > The ad-hoc patches to add new arguments to a function when needed > resulted in the related arguments not being close to each other. > This misleads the person reading the code to

Re: what is the function of .git/branches/?

"Robert P. J. Day" writes: > currently proofing "pro git" book, and an example of a new repo > doesn't show a .git/branches/ directory, but initializing a new repo > with current version of 2.13.6 *does* show an initially empty > directory by that name. however, AFAICT,

Re: [PATCH 1/7] files_transaction_prepare(): don't leak flags to packed transaction

Michael Haggerty writes: >> That much I can understand. But it is not explained why (1) we do >> not pass old_oid anymore and (2) we do give HAVE_NEW. >> >> Presumably the justification for (1) is something like "because we >> are not passing HAVE_OLD, we shouldn't have

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

Michael Haggerty writes: > [1] I say "almost entirely" because putting them in one function means > that only `pattern` needs to be scanned for glob characters. But that is > an unimportant detail. That could actually be an important detail, in that even if prefix has

Re: [PATCH] config: document blame configuration

Stefan Beller writes: > The options are currently only referenced by the git-blame man page, > also explain them in git-config, which is the canonical page to > contain all config options. > > Signed-off-by: Stefan Beller > --- Excellent. Will queue.

Re: [PATCH v2 0/2] Re: reduce_heads: fix memory leaks

Martin Ågren writes: > Since v1 [1], I've added a preparatory patch to UNLEAK some variables. > That sets the stage slightly better for patch 2. > > Junio, you placed v1 on maint. Because UNLEAK is not in maint, this is > based on master and maint misses out on this v2.

Re: [PATCH v2 1/2] builtin/merge-base: UNLEAK commit lists

Martin Ågren writes: > In several functions, we iterate through a commit list by assigning > `result = result->next`. As a consequence, we lose the original pointer > and eventually leak the list. > > These are immediate helpers to `cmd_merge_base()` which is just about

Re: [PATCH 4/7] remote-mediawiki: skip virtual namespaces

Antoine Beaupré writes: > On 2017-11-02 10:24:40, Junio C Hamano wrote: >> Antoine Beaupré writes: >> >>> It might still worth fixing this, but I'm not sure what the process is >>> here - in the latest "what's cooking" Junio said this patchset would be

[PATCH v2 5/8] t0021/rot13-filter: add packet_initialize()

Let's refactor the code to initialize communication into its own packet_initialize() function, so that we can reuse this functionality in following patches. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 26 -- 1 file changed, 16

[PATCH v2 6/8] t0021/rot13-filter: refactor checking final lf

As checking for a lf character at the end of a buffer will be useful in another function, let's refactor this functionality into a small remove_final_lf_or_die() helper function. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 14 +++--- 1 file

[PATCH v2 3/8] t0021/rot13-filter: improve 'if .. elsif .. else' style

Before further refactoring the "t0021/rot13-filter.pl" script, let's modernize the style of its 'if .. elsif .. else' clauses to improve its readability by making it more similar to our other perl scripts. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 39

[PATCH v2 7/8] t0021/rot13-filter: add capability functions

These function help read and write capabilities. To make them more generic and make it easy to reuse them, the following changes are made: - we don't require capabilities to come in a fixed order, - we allow duplicates, - we check that the remote supports the capabilities we advertise, - we

[PATCH v2 4/8] t0021/rot13-filter: improve error message

If there is no new line at the end of something it receives, the packet_txt_read() function die()s, but it's difficult to debug without much context. Let's give a bit more information when that happens. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 3

[PATCH v2 1/8] t0021/rot13-filter: fix list comparison

Since edcc8581 ("convert: add filter..process option", 2016-10-16) when t0021/rot13-filter.pl was created, list comparison in this perl script have been quite broken. packet_txt_read() returns a 2-element list, and the right hand side of "eq" also has a list with (two, elements), but "eq" takes

[PATCH v2 2/8] t0021/rot13-filter: refactor packet reading functions

To make it possible in a following commit to move packet reading and writing functions into a Packet.pm module, let's refactor these functions, so they don't handle printing debug output and exiting. While at it let's create packet_required_key_val_read() to still handle erroring out in a common

[PATCH v2 8/8] Add Git/Packet.pm from parts of t0021/rot13-filter.pl

And while at it let's simplify t0021/rot13-filter.pl by using Git/Packet.pm. This will make it possible to reuse packet related functions in other test scripts. Signed-off-by: Christian Couder --- perl/Git/Packet.pm | 168

[PATCH v2 0/8] Create Git/Packet.pm

Goal Packet related functions in Perl can be useful to write new filters or to debug or test existing filters. They might also in the future be used by other software using the same packet line protocol. So instead of having them in t0021/rot13-filter.pl, let's extract them into a new

[PATCH v2 2/2] reduce_heads: fix memory leaks

We currently have seven callers of `reduce_heads(foo)`. Six of them do not use the original list `foo` again, and actually, all six of those end up leaking it. Introduce and use `reduce_heads_replace()` as a leak-free version of `foo = reduce_heads(foo)` to fix several of these. Fix the remaining

[PATCH v2 1/2] builtin/merge-base: UNLEAK commit lists

In several functions, we iterate through a commit list by assigning `result = result->next`. As a consequence, we lose the original pointer and eventually leak the list. These are immediate helpers to `cmd_merge_base()` which is just about to return, so we can use UNLEAK. For example, we could

[PATCH v2 0/2] Re: reduce_heads: fix memory leaks

Since v1 [1], I've added a preparatory patch to UNLEAK some variables. That sets the stage slightly better for patch 2. Junio, you placed v1 on maint. Because UNLEAK is not in maint, this is based on master and maint misses out on this v2. If you have any advice for how I should (not) do series

[PATCH v2 4/4] bisect: fix memory leak when returning best element

When `find_bisection()` returns a single list entry, it leaks the other entries. Move the to-be-returned item to the front and free the remainder. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano --- bisect.c | 6 +- 1 file changed, 5

[PATCH v2 3/4] bisect: fix off-by-one error in `best_bisection_sorted()`

After we have sorted the `cnt`-many commits that we have selected, we place them into the commit list. We then set `p->next` to NULL, but as we do so, `p` is already pointing one beyond item number `cnt`. Indeed, we check whether `p` is NULL before dereferencing it. This only matters if there are

[PATCH v2 2/4] bisect: fix memory leak in `find_bisection()`

`find_bisection()` rebuilds the commit list it is given by reversing it and skipping uninteresting commits. The uninteresting list entries are leaked. Free them to fix the leak. Signed-off-by: Martin Ågren --- bisect.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH v2 1/4] bisect: change calling-convention of `find_bisection()`

This function takes a commit list and returns a commit list. The returned list is built by modifying the original list. Thus the caller should not use the original list again (and after the next commit fixes a memory leak, it must not). Change the function signature so that it takes a **list and

[PATCH v2 0/4] bisect: assorted leak-fixes

This fixes a couple of leaks around `find_bisection(). The first patch is new since v1 [1] to make the calling-convention of `find_bisection()` less prone to misuse. Patch 2 is similar to v1, the only difference is that the "while at it" has moved into patch 1. Patches 3 and 4 are identical to v1.

Re: [PATCH 1/3] notes: move hex_to_bytes() to hex.c and export it

On Sun, Nov 05, 2017 at 05:47:47PM +0100, René Scharfe wrote: > Am 05.11.2017 um 03:56 schrieb Kevin Daudt: > > On Tue, Oct 31, 2017 at 02:46:49PM +0100, René Scharfe wrote: > >> Make the function for converting pairs of hexadecimal digits to binary > >> available to other call sites. > >> > >>

Re: [PATCH 1/3] notes: move hex_to_bytes() to hex.c and export it

Am 05.11.2017 um 03:56 schrieb Kevin Daudt: > On Tue, Oct 31, 2017 at 02:46:49PM +0100, René Scharfe wrote: >> Make the function for converting pairs of hexadecimal digits to binary >> available to other call sites. >> >> Signed-off-by: Rene Scharfe >> --- >> cache.h | 7 +++

[PATCH 3/3] Documentation: revisions: add note about 3dots usages as continuation indications

Also, fix typo: "three dot" ---> "three-dot" (align with "two-dot"). Signed-off-by: Ann T Ropea --- Documentation/revisions.txt | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index

[PATCH 1/3] checkout: describe_detached_head: remove 3dots after committish

When a committish, C, is immediately followed by 3dots (...) which are, in turn, not followed by another committish, we are usually asking for the revision range C...HEAD, which is known as the symmetric difference of C and HEAD. When describe_detached_head is invoked, it prints the committish

[PATCH 2/3] Documentation: user-manual: limit potentially confusing usage of 3dots (and 2dots)

Using them as continuation indications for abbreviated SHA-1 values bears the risk that they are mistaken for the dotted range operators. Commands which expect a single commit will fail when given a range of commits. Also, add a note that sometimes, 3dots are just continuation indications.

Hi Dear

My name is Charles Feeney, a philanthropist and the founder of The Atlantic Philanthropies, one of the largest private foundations in the world. Dear I believe strongly in giving while living. I had one idea that never Changed in my mind ― that you should use your wealth to help people and I have

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 11/04/2017 01:41 AM, Rafael Ascensão wrote: > `for_each_glob_ref_in` has some code built into it that converts > partial refs like 'heads/master' to their full qualified form > 'refs/heads/master'. It also assume a trailing '/*' if no glob > characters are present in the pattern. > > Extract

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 11/04/2017 11:45 PM, Kevin Daudt wrote: > On Sat, Nov 04, 2017 at 11:27:39AM +0900, Junio C Hamano wrote: >> I however notice that addition of /* to the tail is trying to be >> careful by using strbuf_complete('/'), but prefixing with "refs/" >> does not and we would end up with a double-slash

Re: [PATCH 1/6] t0021/rot13-filter: refactor packet reading functions

On Sun, Oct 22, 2017 at 2:58 AM, Junio C Hamano wrote: > Christian Couder writes: > >> To make it possible in a following commit to move packet >> reading and writing functions into a Packet.pm module, >> let's refactor these functions, so they

Re: Git Open Source Weekend London 11th/12th November

On Wed, Nov 01, 2017 at 04:36:24PM +, Thomas Gummerer wrote: > Hi, > > Bloomberg is hosting an Open Source Weekend in London on the 11th > & 12th November 2017 to contribute to the Git project. We have > also confirmed that Peff will be amongst the mentors on hand to > guide attendees

[PATCH 2/4] pager: refactor `pager_command_config()`

`pager_command_config()` checks for the config `pager.`. In the next commit, we will want to also look for some strings on the form `pager..foo`. Refactor the code to verify upfront that the string starts with "pager." and then check that the remainder is the empty string. This makes it easy to

[PATCH 3/4] pager: introduce `pager.*.command` and `.enable`

`pager.foo` conflates two concepts: how and whether `git foo` should page. In particular, it can not be used to change *how* to page without possibly also affecting *whether*. Teach Git about two new config items, `pager.foo.command` and `pager.foo.enable`. Make this interact sanely with the

[PATCH 4/4] pager: make `pager.foo.command` imply `.enable=true`

If `pager.foo.command` gets configured and there is no configuration (yet) saying whether we should page, act as if `pager.foo.enable=true`. This means that a lone `pager.foo` can always be written as a lone `pager.foo.command` or `pager.foo.enable`. Signed-off-by: Martin Ågren

[PATCH 1/4] t7006: document that `pager.foo` can be partially preserved

Assuming a blank slate, consider the following configuration: [pager] foo = some-command foo = false Now `git -c pager.foo=true foo` will page using `some-command`. This might have been intended, or is perhaps just a side-effect of the implementation. In any case, it could be

[PATCH/DONOTAPPLY 0/4] first steps towards pager.foo.{command,enable}

I'm not posting this for inclusion (yet), but because I read this: On 4 November 2017 at 10:28, Jeff King wrote: > - the pager. config is mis-designed, because our config keys >cannot represent all possible command names (e.g., case folding and >illegal characters). This

Your long awaited part payment of $2.5.000.00Usd

Attention: Beneficiary, Your long awaited part payment of $2.5.000.00Usd (TWO MILLION FIVE Hundred Thousand United State Dollars) is ready for immediate release to you, and it was electronically credited into an ATM Visa Card for easy delivery. Your new Payment Reference No.- 6363836, Password

[PATCH v2 2/9] prune_ref(): call `ref_transaction_add_update()` directly

`prune_ref()` needs to use the `REF_ISPRUNING` flag, but we want to make that flag private to the files backend. So instead of calling `ref_transaction_delete()`, which is a public function and therefore shouldn't allow the `REF_ISPRUNING` flag, change `prune_ref()` to call

[PATCH v2 4/9] ref_transaction_add_update(): remove a check

We want to make `REF_ISPRUNING` internal to the files backend. For this to be possible, `ref_transaction_add_update()` mustn't know about it. So move the check that `REF_ISPRUNING` is only used with `REF_NODEREF` from this function to `files_transaction_prepare()`. Signed-off-by: Michael Haggerty

[PATCH v2 6/9] refs: rename constant `REF_NODEREF` to `REF_NO_DEREF`

Even after working with this code for years, I still see this constant name as "ref node ref". Rename it to make it's meaning clearer. Signed-off-by: Michael Haggerty --- builtin/am.c | 2 +- builtin/branch.c | 2 +- builtin/checkout.c | 2 +-

[PATCH v2 3/9] ref_transaction_update(): die on disallowed flags

Callers shouldn't be passing disallowed flags into `ref_transaction_update()`. So instead of masking them off, treat it as a bug if any are set. Signed-off-by: Michael Haggerty --- refs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs.c b/refs.c

[PATCH v2 9/9] refs: update some more docs to use "oid" rather than "sha1"

Signed-off-by: Michael Haggerty --- refs.c| 2 +- refs.h| 8 refs/files-backend.c | 19 +-- refs/packed-backend.c | 2 +- refs/ref-cache.c | 4 ++-- refs/refs-internal.h | 18 +- 6 files

[PATCH v2 5/9] refs: tidy up and adjust visibility of the `ref_update` flags

The constants used for `ref_update::flags` were rather disorganized: * The definitions in `refs.h` were not close to the functions that used them. * Maybe constants were defined in `refs-internal.h`, making them visible to the whole refs module, when in fact they only made sense for the

[PATCH v2 0/9] Tidy up the constants related to ref_update::flags

This is a reroll of a patch series that tidies up some stuff around the ref_update::flags constants. Thanks to Junio and Martin for their comments about v1 [1]. Relative to v1, this version: * In patch 5, cleans up the touched comments to refer to OIDs rather than SHA-1s. * Adds a patch 8,

[PATCH v2 1/9] files_transaction_prepare(): don't leak flags to packed transaction

The files backend uses `ref_update::flags` for several internal flags. But those flags have no meaning to the packed backend. So when adding updates for the packed-refs transaction, only use flags that make sense to the packed backend. `REF_NODEREF` is part of the public interface, and it's

[PATCH v2 7/9] refs: rename constant `REF_ISPRUNING` to `REF_IS_PRUNING`

Underscores are cheap, and help readability. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 71e088e811..bb10b715a8 100644 ---

[PATCH v2 8/9] write_packed_entry(): take `object_id` arguments

Change `write_packed_entry()` to take `struct object_id *` rather than `unsigned char *` arguments. Signed-off-by: Michael Haggerty --- refs/packed-backend.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/refs/packed-backend.c

Re: git grep -P fatal: pcre_exec failed with error code -8

Hello, thanks for your answer. I understand that the PCRE's stack can get exhausted for some files, but in such cases, git grep shall proceed with the other files, and print at the end/stderr for which files the pattern was not applied. Such behaviour would be more usefull than the current

Re: what is the function of .git/branches/?

On Sun, Nov 05, 2017 at 11:24:00AM +0200, Robert P. J. Day wrote: > currently proofing "pro git" book, and an example of a new repo > doesn't show a .git/branches/ directory, but initializing a new repo > with current version of 2.13.6 *does* show an initially empty > directory by that name.

what is the function of .git/branches/?

currently proofing "pro git" book, and an example of a new repo doesn't show a .git/branches/ directory, but initializing a new repo with current version of 2.13.6 *does* show an initially empty directory by that name. however, AFAICT, branches are still tracked under .git/refs/heads/, so

Re: Regression[2.14.3->2.15]: Interactive rebase fails if submodule is modified

On Sat, Nov 4, 2017 at 8:04 PM, Orgad Shaneh wrote: > On Fri, Nov 3, 2017 at 6:20 PM, Johannes Schindelin > wrote: >> Hi Orgad, >> >> On Fri, 3 Nov 2017, Johannes Schindelin wrote: >> >>> On Thu, 2 Nov 2017, Orgad Shaneh wrote: >>> >>> > I can't

Re: [PATCH 5/7] refs: tidy up and adjust visibility of the `ref_update` flags

On 11/01/2017 09:18 AM, Martin Ågren wrote: > On 28 October 2017 at 11:49, Michael Haggerty wrote: >> The constants used for `ref_update::flags` were rather disorganized: > >> * The documentation wasn't very consistent and partly still referred >> to sha1s rather than

Re: [PATCH 1/7] files_transaction_prepare(): don't leak flags to packed transaction

On 10/30/2017 05:44 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> The files backend uses `ref_update::flags` for several internal flags. >> But those flags have no meaning to the packed backend. So when adding >> updates for the packed-refs transaction, only use

Re: [PATCH 6/7] builtin/describe.c: describe a blob

"Philip Oakley" writes: > Is this not also an alternative case, relative to the user, for the > scenario where the user has an oid/sha1 value but does not know what > it is, and would like to find its source and type relative to the > `describe` command. I am not sure what

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Junio C Hamano writes: > Rafael Ascensão writes: > ... >> Because changing the default behavior of that function has >> implications on multiple commands which I think shouldn't change. But >> at the same time, would be nice to have the logic that deals