Make it possible to implement bisecting only on first parents or on
merge commits by passing flags to find_bisection(), instead of just
a 'find_all' boolean.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Use unsigned type and cache flag value
bisect.c
Make it possible to implement bisecting only on first parents or on
merge commits by passing flags to find_bisection(), instead of just
a 'find_all' boolean.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Updating commit message
bisect.c
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Updates according to Christian Couder's code review
bisect.c | 20
bisect.h | 6 --
builtin/rev-list.c | 6 +++---
3 files changed, 19 insertions(+), 13 deletions(-)
---
Notes:
Preperatory patch to enable either Tiago Botelho's or my patch, to do
bisection on first parents / merge commits
bisect.c | 21 -
bisect.h | 5 +++--
builtin/rev-list.c | 6 +++---
3 files changed, 18 insertions(+), 14 deletions(-)
diff
I think it looks similar. But if I'm reading that thread correctly
then there was never a patch created, right?
On Thu, Apr 12, 2018 at 1:33 AM, Stefan Beller <sbel...@google.com> wrote:
> On Wed, Apr 11, 2018 at 3:55 PM, Harald Nordgren
> <haraldnordg...@gmail.com>
When ran with '--merges-only', git bisect will only look at merge commits --
commits with 2 or more parents or the initial commit.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Proof of concept of a feature that I have wanted in Git for a while. In my
daily w
There have been no new comments for the last few days. I know Jeff
King will be away for the next two weeks, but should we still move
forward with this? The initial reactions to the idea seemed positive.
Best regards
Harald
On Mon, Apr 9, 2018 at 3:42 AM, Harald Nordgren
<haraldno
On Mon, Apr 9, 2018 at 2:56 AM, Junio C Hamano wrote:
>
> With the update since v12, I think "because `ls-remote` deals only
> with remotes," can be dropped entirely, and still convey what needs
> to be told: "Be aware some keys that needs access to objects that
> are not here
don't want to set initially.
Instead, let's be explicit that it takes only the minimum
required to create the ref, and that callers should then
fill in the rest themselves.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Changes according to Junio Hamano's code
post-sha1 world.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deleti
linear complexity (as opposed to growing by one,
which is potentially quadratic, though in-place realloc
growth often makes this faster in practice).
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
ref-filter.c | 16 +---
On Mon, Apr 9, 2018 at 12:16 AM, Junio C Hamano wrote:
>
> I can connect "because it deals only with remotes" and "access to
> the object may fail", but I wonder if we can clarify the former a
> bit better to make it easier to understand for those who are not yet
> familiar
don't want to set initially.
Instead, let's be explicit that it takes only the minimum
required to create the ref, and that callers should then
fill in the rest themselves.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Changes according to Junio Hamano's code
linear complexity (as opposed to growing by one,
which is potentially quadratic, though in-place realloc
growth often makes this faster in practice).
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
ref-filter.c | 16 +---
post-sha1 world.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deleti
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Changes according to Eric Sunshine's code
don't want to set initially.
Instead, let's be explicit that it takes only the minimum
required to create the ref, and that callers should then
fill in the rest themselves.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
linear complexity (as opposed to growing by one,
which is potentially quadratic, though in-place realloc
growth often makes this faster in practice).
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
ref-filter.c | 16 +---
Thanks for your very thorough review Eric! I think I address all the
points, but if I missed something please let me know.
On Sun, Apr 8, 2018 at 3:06 AM, Eric Sunshine wrote:
>
> You incorrectly dropped Peff's sign-off[1] when re-sending the patches
> he authored in
post-sha1 world.
Signed-off-by: Jeff King <p...@peff.net>
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deleti
From: Jeff King
We have a helper function to allocate ref_array_item
structs, but it only takes a subset of the possible fields
in the struct as initializers. We could have it accept an
argument for _every_ field, but that becomes a pain for the
fields which some callers don't
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Rebasing my patch on Jeff King's refa
From: Jeff King
In preparation for callers constructing their own ref_array
structs, let's move our own internal push operation into its
own function.
While we're at it, we can replace REALLOC_ARRAY() with
ALLOC_GROW(), which should give the growth operation
amortized linear
From: Jeff King
Internally we store a "struct object_id", and all of our
callers have one to pass us. But we insist that they peel it
to its bare-sha1 hash, which we then hashcpy() into place.
Let's pass it around as an object_id, which future-proofs us
for a post-sha1 world.
---
Looks good to me.
Reviewed-by: Harald Nordgren <haraldnordg...@gmail.com>
On Fri, Apr 6, 2018 at 9:27 PM, Derrick Stolee <sto...@gmail.com> wrote:
> On 4/6/2018 2:59 PM, Jeff King wrote:
>>
>> In preparation for callers constructing their own ref_array
>> str
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Use 'ref_array_item_push' to fix 'REALLOC
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Create 'ref_array_push' function in ref-
AD` would do, maybe you could
explain a bit more?
On Thu, Apr 5, 2018 at 1:01 AM, Harald Nordgren
<haraldnordg...@gmail.com> wrote:
> Create a '--sort' option for ls-remote, based on the one from
> for-each-ref. This e.g. allows ref names to be sorted by version
> semantics, so th
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Partial fixes from Jeff King's co
...@sigill.intra.peff.net/T/#m6d3ce17f0f6dabeddaf03336c92512b7c413422b
On Wed, Apr 4, 2018 at 7:18 PM, Harald Nordgren
<haraldnordg...@gmail.com> wrote:
> I updated the code to use 'ALLOC_GROW'. I makes sense, I now I realize
> why array.alloc is there ;)
>
> Jeff, you are right that 'gi
:11 PM, Harald Nordgren
<haraldnordg...@gmail.com> wrote:
> Create a '--sort' option for ls-remote, based on the one from
> for-each-ref. This e.g. allows ref names to be sorted by version
> semantics, so that v1.2 is sorted before v1.10.
>
> Signed-off-by: Harald Nordgren <
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Started using 'ALLOC_GROW'
Documentati
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Notes:
Moving 'int i' declaration outside of 'for
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Documentation/git-ls-remote.txt | 12 +++-
b
still make sense though.
I will post replies to the original email chain after this message.
On Mon, Apr 2, 2018 at 10:12 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Harald Nordgren <haraldnordg...@gmail.com> writes:
>
>> Subject: Re: [PATCH] ls-remote: create '--sort' o
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Documentation/git-ls-remote.txt | 12 +++-
b
/tags/go1.2.1
...
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Documentation/git-ls-remote.txt | 12 +++-
builtin/ls-remote.c | 27 +--
t/t5512-ls-remote.sh| 41 -
3
Thanks for all the discussion!
I think I figured out a way to reuse more ref-filter.c machinery. I
will submit another patchset shortly.
On Mon, Apr 2, 2018 at 8:32 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> This is a sensible thing to
Both points make sense and it sounds like a very pragmatic approach.
I'll look into it!
On Mon, Apr 2, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> wrote:
>
> On Mon, Apr 02 2018, Harald Nordgren wrote:
>
>> In regards the the print statement, it was only
the
refs.
Which seems necessary in order to hook in to the sorting flow used in
other subcommands. That, or reimplement `cmp_ref_sorting`. But maybe
I'm missing something?
On Mon, Apr 2, 2018 at 8:37 AM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> wrote:
>
> On Mon, Apr 02 2018, Har
Updating tests and documentation
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
Documentation/git-ls-remote.txt | 5 +
t/t5512-ls-remote.sh| 19 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-ls-remote
9c9802fad57c1bcb72ea98c5c55ea2652efc5772refs/tags/go1.2.1
...
Signed-off-by: Harald Nordgren <haraldnordg...@gmail.com>
---
builtin/ls-remote.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/builtin/ls-remote.c b/buil
44 matches
Mail list logo