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
---
Notes:
Use unsigned type and cache flag value
bisect.c | 15 ++-
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
---
Notes:
Updating commit message
bisect.c | 20
Signed-off-by: Harald Nordgren
---
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(-)
diff --git a/bisect.c b/bis
---
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 wrote:
> On Wed, Apr 11, 2018 at 3:55 PM, Harald Nordgren
> wrote:
>> When ran with '--merges-only', git bis
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
---
Notes:
Proof of concept of a feature that I have wanted in Git for a while. In my
daily work my company uses Git
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
wrote:
> From: J
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 won't work".
>
> Ins
o 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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 18 +++---
1 file changed, 11 insertions(+), 7
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
---
Notes:
Changes according to Junio Hamano's code review (2)
Docum
Signed-off-by: Jeff King
Signed-off-by: Harald Nordgren
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index da186691e..4
lexity (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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 16 +---
ref-filter.h | 8
2 files changed, 21 insertions(+), 3
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 with Git.
>
> Keys
o 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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 18 +++---
1 file changed, 11 insertions(+), 7
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
---
Notes:
Changes according to Junio Hamano's code review
Docum
lexity (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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 16 +---
ref-filter.h | 8
2 files changed, 21 insertions(+), 3
Signed-off-by: Jeff King
Signed-off-by: Harald Nordgren
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index da186691e..4
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
---
Notes:
Changes according to Eric Sunshine's code review
Docum
lexity (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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 16 +---
ref-filter.h | 8
2 files changed, 21 insertions(+), 3
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 the series. And, your sign-
Signed-off-by: Jeff King
Signed-off-by: Harald Nordgren
---
builtin/tag.c| 2 +-
builtin/verify-tag.c | 2 +-
ref-filter.c | 10 +-
ref-filter.h | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index da186691e..4
o 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
Signed-off-by: Harald Nordgren
---
ref-filter.c | 18 +++---
1 file changed, 11 insertions(+), 7
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 want to set initial
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
---
Notes:
Rebasing my patch on Jeff King's refatoring patches
Docum
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 complexity (as oppos
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.
---
builtin/tag.c
Looks good to me.
Reviewed-by: Harald Nordgren
On Fri, Apr 6, 2018 at 9:27 PM, Derrick Stolee wrote:
> On 4/6/2018 2:59 PM, Jeff King wrote:
>>
>> In preparation for callers constructing their own ref_array
>> structs, let's move our own internal push operatio
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
---
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
---
Notes:
Create 'ref_array_push' function in ref-filter
e --contains HEAD` would do, maybe you could
explain a bit more?
On Thu, Apr 5, 2018 at 1:01 AM, Harald Nordgren
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.
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
---
Notes:
Partial fixes from Jeff King's comments
Documentation/gi
...@sigill.intra.peff.net/T/#m6d3ce17f0f6dabeddaf03336c92512b7c413422b
On Wed, Apr 4, 2018 at 7:18 PM, Harald Nordgren
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 'git ls-remote --sort=com
On Wed, Apr 4, 2018 at 7:11 PM, Harald Nordgren
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
---
Notes:
Started using 'ALLOC_GROW'
Documentation/gi
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
---
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
---
Documentation/git-ls-remote.txt | 12 +++-
builtin/l
into two
threads. Hopefully the patches 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 wrote:
> Harald Nordgren writes:
>
>> Subject: Re: [PATCH] ls-remote: create '--sort' option
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
---
Documentation/git-ls-remote.txt | 12 +++-
builtin/l
refs/tags/go1.2.1
...
Signed-off-by: Harald Nordgren
---
Documentation/git-ls-remote.txt | 12 +++-
builtin/ls-remote.c | 27 +--
t/t5512-ls-remote.sh| 41 -
3 files changed, 76 insert
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 want, but why not follow the UI we ha
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
wrote:
>
> On Mon, Apr 02 2018, Harald Nordgren wrote:
>
>> In regards the the print statement, it was only moved down according
&g
or storing 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
wrote:
>
> On Mon, Apr 02 2018, Harald Nordgr
Updating tests and documentation
Signed-off-by: Harald Nordgren
---
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.txt b/Documentation/git-ls
5ce0b76refs/tags/go1.2
9c9802fad57c1bcb72ea98c5c55ea2652efc5772refs/tags/go1.2.1
...
Signed-off-by: Harald Nordgren
---
builtin/ls-remote.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/builtin/ls-remote.c b/built
44 matches
Mail list logo
