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 same time, would be nice to have the logic t
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 actually be an important detai
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
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 initially empty
> > directory b
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 a/Documentation/revisions.txt b/Documentation/revision
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 to make an
extra call
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.
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."
Another place these "m
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 an important detail, in
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 release
is made, as the fixed version will not be seen as many peop
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)
> free_worktrees(worktrees);
> }
>
>
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 be given to the user when
> t
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 believe that there isn't
> much relation between those argumen
"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, branches are still track
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 been passing old_oid a
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 wildcard, we'd still append
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. Thanks.
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. If you have any advice
> f
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 to
> return, so we can use
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
>>> merged in "next". Should I reroll the p
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 insertions(+), 10 deletions
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 changed, 11 insertions(+), 3
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 +
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 don
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 ++-
1 file changed, 2 inser
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
Git/Pac
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
th
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 c
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
perl/Makefile
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(&foo)` as a leak-free version of
`foo = reduce_heads(foo)` to fix several of these. Fix the remain
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 `UN
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 wi
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 insertions(+), 1 deletion(-)
diff --git a/bise
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
`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 deletion(-)
diff --git a/bisect
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 h
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.
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.
> >>
> >> Sig
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 +++
>> hex.c |
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 61277469c874..d1b1264271
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
fol
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.
Signe
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
hav
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 th
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 i
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 don't handle
>> printing debug output and exiting.
>
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 through
`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 exis
`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 lo
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
---
Documentatio
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 usef
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 should be pager.
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 N
`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
`ref_transaction_add_upd
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
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 +-
builtin/clone.c| 4 +
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
index 62a7621025..7c1e
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 changed, 26 insertions(+),
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 fil
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, whi
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 logica
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
--- a/refs/files-backend.c
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 b/refs/packed-backend.c
index 7
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 o
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. how
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 what's
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 reproduce this with a minimal example, but it happe
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 oids.
>
>> @@ -478,22 +46
68 matches
Mail list logo
