The reason rerere(), rerere_forget() and rerere_remaining() take a
struct repository instead of struct index_state is not obvious from
the patch:
Deep in update_paths() and find_conflict(), hold_locked_index() and
read_index() are called. These functions assumes the index path at
$GIT_DIR/index
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
combine-diff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/combine-diff.c b/combine-diff.c
index de7695e728..4fa7707b57 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -1054,7 +1054,8 @@ static
diff and textconv code has so widespread use that it's hard to simply
update their api and all call sites at once because it would result in
a big patch. For now reduce the_index references to two places:
diff_setup() and fill_textconv().
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/grep.c | 4 ++--
builtin/log.c | 2 +-
grep.c | 13 -
grep.h | 7 +--
revision.c | 4 ++--
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/builtin/grep.c
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
apply.c| 9 ++---
builtin/checkout.c | 3 ++-
diff.c | 2 +-
ll-merge.c | 17 +
ll-merge.h | 5 -
merge-blobs.c | 3 ++-
merge-recursive.c | 3 ++-
A new variant repo_diff_setup() is added that takes 'struct repository *'
and diff_setup() becomes a thin macro around it that is protected by
NO_THE_REPOSITORY_COMPATIBILITY_MACROS, similar to NO_THE_INDEX_
The plan is these macros will always be defined for all library files
and the macros
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
diff-lib.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 88a98b1c06..c54773fe12 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -70,7 +70,7 @@ static int
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
blame.c| 7 ---
builtin/cat-file.c | 6 --
builtin/log.c | 3 ++-
combine-diff.c | 27 ---
diff.c | 17 +
diff.h | 9 +++--
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/merge.c | 8 +---
builtin/pull.c | 7 +--
cache.h | 6 --
merge.c | 20 +++-
sequencer.c | 6 +++---
5 files changed, 28 insertions(+), 19 deletions(-)
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/log.c | 2 +-
patch-ids.c | 4 ++--
patch-ids.h | 3 ++-
revision.c| 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 4b602236d6..978fe7c10f 100644
---
This function calls do_diff_cache() which eventually needs to set this
"istate" to unpack_options->src_index [1]. This is an unfortunate fact
that unpack_trees() _will_ update [2] src_index so we can't really pass a
const index_state there. Just remove 'const'.
[1] Right now diff_cache() in
The new "repo" field in archive_args has been added since b612ee202a
(archive.c: avoid access to the_index - 2018-08-13). Use it instead of
hard coding the_repository.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
archive.c | 2 +-
1 file changed, 1 insertion(+), 1
v5 only has commit message update in one patch. range-diff below.
Also, from "What's cooking" today
On Fri, Sep 21, 2018 at 7:22 AM Junio C Hamano wrote:
> * nd/the-index (2018-09-17) 23 commits
> ...
>
> Will merge to 'next'.
>
> As expected, this has close to irritating amount of textual
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/merge-tree.c | 2 +-
merge-blobs.c| 15 +++
merge-blobs.h| 7 +--
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
read-cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 6f772b2885..563500fe98 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -823,7 +823,7 @@ struct cache_entry
The current naming convention for 'struct repository *' is 'r' for
temporary variables or arguments. I did not notice this. Since we're
updating blame.c again in the next patch, let's fix this.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
blame.c | 36
Derrick Stolee writes:
> On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Sep 21 2018, Derrick Stolee wrote:
>>
>>>
>>> This error was reported by Peff [1] and fixed in [2], but as stated
>>> [3] I was waiting for more review before sending a v3. I'll send that
>>> v3 shortly,
On 9/18/2018 2:05 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Sep 18 2018, Derrick Stolee via GitGitGadget wrote:
Thanks. Good to see the commit graph used for more stuff.
On the Linux repository, I got the following performance results when
comparing to the previous version with or without a
On 9/21/2018 11:15 AM, Derrick Stolee via GitGitGadget wrote:
For example, I ran this against the 'next' branch (22e244b)
versus 'master' (150f307) and got the following output:
fsck.c
fb8952077df (René Scharfe 2018-09-03 14:49:26 + 212)
die_errno("Could not read
From: Derrick Stolee
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has
an
We have coverage targets in our Makefile for using gcov to display line
coverage based on our test suite. The way I like to do it is to run:
make coverage-test
make coverage-report
This leaves the repo in a state where every X.c file that was covered has an
X.c.gcov file containing the coverage
From: Derrick Stolee
The can_all_from_reach_with_flag() method uses 'assign_flag' as a
value we can use to mark objects temporarily during our commit walk.
The intent is that these flags are removed from all objects before
returning. However, this is not the case.
The 'from' array could also
As Peff reported [1], the refactored can_all_from_reach_with_flags() method
does not properly peel tags. Since the helper method can_all_from_reach()
and code in t/helper/test-reach.c all peel tags before getting to this
method, it is not super-simple to create a test that demonstrates this.
I
From: Derrick Stolee
The can_all_from_reach_with_flag() algorithm was refactored in 4fbcca4e
"commit-reach: make can_all_from_reach... linear" but incorrectly
assumed that all objects provided were commits. During a fetch
negotiation, ok_to_give_up() in upload-pack.c may provide unpeeled tags
to
On 9/21/2018 10:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Derrick Stolee wrote:
This error was reported by Peff [1] and fixed in [2], but as stated
[3] I was waiting for more review before sending a v3. I'll send that
v3 shortly, responding to the feedback so far.
-Stolee
On Fri, Sep 21 2018, Derrick Stolee wrote:
> On 9/21/2018 10:30 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Sep 21 2018, Junio C Hamano wrote:
>>
>>> * ds/reachable (2018-08-28) 19 commits
>>>(merged to 'next' on 2018-08-28 at b1634b371d)
>>> + commit-reach: correct accidental #include
On 9/21/2018 10:30 AM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Sep 21 2018, Junio C Hamano wrote:
* ds/reachable (2018-08-28) 19 commits
(merged to 'next' on 2018-08-28 at b1634b371d)
+ commit-reach: correct accidental #include of C file
(merged to 'next' on 2018-08-22 at 17f3275afb)
On Fri, Sep 21 2018, Junio C Hamano wrote:
> * ds/reachable (2018-08-28) 19 commits
> (merged to 'next' on 2018-08-28 at b1634b371d)
> + commit-reach: correct accidental #include of C file
> (merged to 'next' on 2018-08-22 at 17f3275afb)
> + commit-reach: use can_all_from_reach
> +
On Fri, Sep 21, 2018 at 03:19:20AM -0400, Eric Sunshine wrote:
> On Thu, Sep 20, 2018 at 2:04 PM Taylor Blau wrote:
> > The recently-introduced "core.alternateRefsCommand" allows callers to
> > specify with high flexibility the tips that they wish to advertise from
> > alternates. This
Hello!
Git default progress indicator for clone is very unattractive, IMO. It does its
job in providing all the operation details very well, but I bet most of users
strongly dream about a gauge box!
Have a look at my gauge box constructed as git-stderr pipe script:
On 17.09.18 17:37, Junio C Hamano wrote:
Tim Schumacher writes:
On 08.09.18 15:28, Duy Nguyen wrote:
On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
+ /*
+* It could be an alias -- this works around the insanity
* of overriding "git
Hi,
If you wouldn't mind, please confirm if you received previous email
correspondence as I have been trying to reach you regarding the above
subject.
Sincerely,
Jamila
Hi,
Coming back to you with some updates.
I understand finally interest of difference between 'from' and 'at'.
The point is: is it a bug if the 'git status' provide the origin/HEAD instead
of HEAD SHA1?
If you want a test case with screenshots, let me know.
Regards,
Laurent
On Thu, Sep 20, 2018 at 2:04 PM Taylor Blau wrote:
> The recently-introduced "core.alternateRefsCommand" allows callers to
> specify with high flexibility the tips that they wish to advertise from
> alternates. This flexibility comes at the cost of some inconvenience
> when the caller only wishes
101 - 134 of 134 matches
Mail list logo
