Hi,
"Boettger, Heiko" writes:
> Hi,
>
> I discovered an interesting problem when using `git checkout` to which
> I couldn't find a good solution. We have an automatic system trying to
> checkout a branch only when it exists. To do so we check whether `git
> rev-parse` finds a commit for given br
Junio C Hamano writes:
> ...
> as I am getting
>
> error: 'ret' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>
> from here.
>
> Giving an otherwise useless initial value to ret would be a
> workaround.
I've added this on top of the topic before merging to keep
Ævar Arnfjörð Bjarmason writes:
> + switch (cmdmode) {
> + case ENV_HELPER_BOOL:
> + tmp_int = strtol(env_default, (char **)&env_default, 10);
> + if (*env_default) {
> + error(_("option `--default' expects a numerical value
> with `--mode-boo
On Thu, Jun 20 2019, Duy Nguyen wrote:
> On Thu, Jun 20, 2019 at 5:49 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>>
>> On Wed, Jun 19 2019, Jeff King wrote:
>>
>> > On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >
>> >> > You could sort of avoid the problem here too wit
On Thu, Jun 20, 2019 at 12:13:15AM +0200, Christian Couder wrote:
> SYNOPSIS
>
> [verse]
> -'git-psuh'
> +'git-psuh ...'
It doesn't require 1 or more args - you can run it with no args. So it
might be better suited to state the args as optional:
'git psuh [arg]...'
>
> stati
Change the GIT_TEST_GETTEXT_POISON variable from being "non-empty?" to
being a more standard boolean variable.
Since it needed to be checked in both C code and shellscript (via test
-n) it was one of the remaining shellscript-like variables. Now that
we have "env--helper" we can change that.
Ther
Change the GIT_TEST_FAIL_PREREQS variable from being "non-empty?" to
being a more standard boolean variable. I recently added the variable
in dfe1a17df9 ("tests: add a special setup where prerequisites fail",
2019-05-13), having to add another "non-empty?" special-case is what
prompted me to write
The test_tristate helper introduced in 83d842dc8c ("tests: turn on
network daemon tests by default", 2014-02-10) can now be better
implemented with "git env--helper" to give the variables in question
the standard boolean behavior.
The reason for the "tristate" was to have all of false/true/auto,
w
We have many GIT_TEST_* variables that accept a because
they're implemented in C, and then some that take because
they're implemented at least partially in shellscript.
Add a helper that wraps git_env_bool() and git_env_ulong() as the
first step in fixing this. This isn't being added as a test-t
Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
object flags used during counting", 2008-07-03) to stop using the
"script" variable also used for lazy prerequisites in
test-lib-functions.sh.
Since this test uses test_i18ncmp and expects to use its own "script"
variable twice it
A previous change to the "GIT_TEST_GETTEXT_POISON" variable left this
paragraph needing to be re-flowed. Let's do that in this separate
change to make it easy to see that there's no change here when viewed
with "--word-diff".
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 8
1 fi
Simplify an overly verbose test added in 9b25a0b52e ("config: add
include directive", 2012-02-06). The "expect" file was never used, and
by using .gitconfig it's not as intuitive to reproduce this manually
with "-d" as some other tests, since HOME needs to be set in the
environment.
Also remove th
Prepare die_bad_number() for a change to specially handle
GIT_TEST_GETTEXT_POISON calling git_env_bool() by making
die_bad_number() not call gettext() early, which would in turn call
git_env_bool().
There's no meaningful change here yet, just a re-arrangement of the
current code to make that subse
This v2 fixes tricky bugs I noticed after sending v1 in calling
gettext so early in the setup, and the t0016 name clash with pu Junio
pointed out.
I didn't change the "env--helper" interface as suggested because I
already had this ready and figured I'd send a v2 for review of the
stuff I have now.
René Scharfe writes:
> How about this?
Sounds sensible.
> -- >8 --
> Subject: [PATCH] config: simplify unit suffix handling
>
> parse_unit_factor() checks if a K, M or G is present after a number and
> multiplies it by 2^10, 2^20 or 2^30, respectively. One of its callers
> checks if the result
On Wed, Jun 19, 2019 at 08:17:29AM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > Maybe there's a case for storing them as a set of patch files that are
> > revision-controlled somewhere within Documentation/? There was some
> > discussion on the IRC a few weeks ago about trying to or
On Thu, Jun 20 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> This changes the remaining special snowflake test modes
>> to and gets rid of test_tristate() in favor of the now
>> standard "boolea" test.
>>
>> I'm replying to my "gc: run more pre-detach operations under lo
Christian Couder writes:
> On Thu, Jun 20, 2019 at 2:39 PM Derrick Stolee wrote:
>>
>> On 6/20/2019 4:50 AM, Jeff King wrote:
>> > On Thu, Jun 20, 2019 at 10:30:26AM +0200, Christian Couder wrote:
>> >
>> >> Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
>> >> if we should fetch ob
Christian Couder writes:
> In a review[1] of my "many promisor remotes" patch series[2] and in
> the following thread, it was suggested that a flag should be passed to
> tell oid_object_info_extended() that it should not fetch objects from
> promisor remotes if they are missing, instead of using
Fix a couple of tests that would potentially fail under
GIT_TEST_FAIL_PREREQS=true.
I missed these when annotating other tests in dfe1a17df9 ("tests: add
a special setup where prerequisites fail", 2019-05-13) because on my
system I can only reproduce this failure when I run the tests as
"root", si
Matheus Tavares writes:
> Daniel Ferreira (1):
> dir-iterator: add tests for dir-iterator API
>
> Matheus Tavares (8):
> clone: better handle symlinked files at .git/objects/
> dir-iterator: use warning_errno when possible
> dir-iterator: refactor state machine model
> dir-iterator: add
Phillip Wood writes:
>> This one, and the in_progress_advice emitted from the patch 1/5, are
>> both bad in that they make calls to advise() without guarding it
>> with an advice.* configuration variable.
>
> I'm not sure we have one for cherry-pick/revert/rebase. At the moment
> they print advic
Ævar Arnfjörð Bjarmason writes:
> This changes the remaining special snowflake test modes
> to and gets rid of test_tristate() in favor of the now
> standard "boolea" test.
Is that "boolean" test?
I had a lot of trouble with the external interface to "env--helper",
but I kind of liked the ch
Ævar Arnfjörð Bjarmason writes:
> Change the GIT_TEST_GETTEXT_POISON variable from being "non-empty?" to
> being a more standard boolean variable.
>
> Since it needed to be checked in both C code and shellscript (via test
> -n) it was one of the remaining shellscript-like variables. Now that
> w
Am 17.06.19 um 00:26 schrieb Junio C Hamano:
> René Scharfe writes:
>
> To fix it, let's just "unroll" the function (i.e. negate the value if it
> is negative).
There's also imaxabs(3).
>
> That may be true, but seeing that some platforms wants to see
> intmax_t defined in the co
Ævar Arnfjörð Bjarmason writes:
> Change test code added in c0234b2ef6 ("stat_tracking_info(): clear
> object flags used during counting", 2008-07-03) to stop using the
> "script" variable also used for lazy prerequisites in
> test-lib-functions.sh.
>
> Since this test uses test_i18ncmp and expe
> On Wed, Jun 19, 2019 at 10:45:17PM -0400, Denton Liu wrote:
>
>> Using the following command on git.git,
>>
>> $ HOME=/dev/null ./git --exec-path=. difftool --no-index color.c color.h
>>
>> I did a quick bisect on the issue and it seems like the cause of this
>> bug is actually 287ab28bfa
Ævar Arnfjörð Bjarmason writes:
> + struct option opts[] = {
> + OPT_CMDMODE(0, "mode-bool", &cmdmode,
> + N_("invoke git_env_bool(...)"), ENV_HELPER_BOOL),
> + OPT_CMDMODE(0, "mode-ulong", &cmdmode,
> + N_("invoke git_e
On 6/19/2019 5:58 AM, Nguyễn Thái Ngọc Duy wrote:
This is probably just my itch. Every time I have to do something with
the index, I need to add a little bit code here, a little bit there to
get a better "view" of the index.
This solves it for me. It allows me to see pretty much everything in
Jeff King writes:
> I think there may be room for both approaches. Yours fixes the repeated
> message in the more general case, but Duy's suggestion is the most
> efficient thing.
Yeah, not just the most efficient, but it is a low-hanging-fruit
that is very obvious.
> I agree that the "thousand
On Thu, Jun 20, 2019 at 10:38:23AM -0700, Jonathan Tan wrote:
> > @@ -154,7 +154,7 @@ static struct island_bitmap
> > *create_or_get_island_marks(struct object *obj)
> > khiter_t pos;
> > int hash_ret;
> >
> > - pos = kh_put_sha1(island_marks, obj->oid.hash, &hash_ret);
> > + pos =
On Thu, Jun 20, 2019 at 10:44:17AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > For use in object_id hash tables, we have oid_hash() and oid_equal().
> > But these are confusingly similar to the existing oideq() and the
> > oidhash() we plan to add to replace sha1hash().
> >
> > The bi
On Thu, Jun 20, 2019 at 09:32:49AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The find_commit_name() function passes an object_id.hash as the key of a
> > hashmap. That ends up in commit_name_neq(), which then feeds it to
> > oideq(). Which means we should actually be the whole "stru
On Thu, Jun 20, 2019 at 03:21:43PM +0100, Ramsay Jones wrote:
>
>
> On 20/06/2019 08:41, Jeff King wrote:
> > There are no callers left of lookup_object() that aren't just passing us
>
> s/lookup_object/create_object/
Heh, thanks. I took a final pass at these commit messages to normalize
them,
Philippe Blain writes:
> 'git submodule update' will fetch new commits from the submodule remote
> if the SHA-1 recorded in the superproject is not found. This was not
> mentioned in the documentation.
>
> Signed-off-by: Philippe Blain
> ---
> Documentation/git-submodule.txt | 3 ++-
> 1 file c
Ævar Arnfjörð Bjarmason writes:
> This changes the remaining special snowflake test modes
> to and gets rid of test_tristate() in favor of the now
> standard "boolea" test.
>
> I'm replying to my "gc: run more pre-detach operations under lock"
> thread because one of the things my WIP patches
On 2019.06.12 15:18, Jeff King wrote:
> On Wed, Jun 12, 2019 at 09:23:41AM -0700, Josh Steadmon wrote:
>
> > The problem with the existing validators is that they expect each file to
> > be a
> > complete JSON entity, whereas the trace output is one object per line. You
> > can
> > of course loo
Jeff King writes:
> For use in object_id hash tables, we have oid_hash() and oid_equal().
> But these are confusingly similar to the existing oideq() and the
> oidhash() we plan to add to replace sha1hash().
>
> The big difference from those functions is that rather than accepting a
> const point
Jeff King writes:
> Our hashmap.h helpfully defines a sha1hash() function. But it cannot
> define a similar oidhash() without including all of cache.h, which
> itself wants to include hashmap.h! Let's break this circular dependency
> by moving the definition to hash.h, along with the remaining RA
> @@ -105,7 +105,7 @@ int in_same_island(const struct object_id *trg_oid, const
> struct object_id *src_
>* If we don't have a bitmap for the target, we can delta it
>* against anything -- it's not an important object
>*/
> - trg_pos = kh_get_sha1(island_marks, trg_oid-
On 2019.06.14 11:59, Jeff Hostetler wrote:
>
>
> On 6/11/2019 7:31 PM, Josh Steadmon wrote:
> > Define a JSON schema[1] that can be used to validate trace2 event
> > objects. This can be used to add regression tests to verify that the
> > event output format does not change unexpectedly.
> >
> >
Here is today's test coverage report.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-20.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-06-20.txt
---
pu 3f0adadc5dcf9bbc8a1f8a8075b3adca93cfa6a8
jch 956887a8ce1b8d4faa043b5780
Signed-off-by: Barret Rhoden
---
t/t8003-blame-corner-cases.sh | 36 +++
1 file changed, 36 insertions(+)
diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
index c92a47b6d5b1..1c5fb1d1f8c9 100755
--- a/t/t8003-blame-corner-cases.sh
+++ b/t
When ignoring commits, the commit that is blamed might not be
responsible for the change, due to the inaccuracy of our heuristic.
Users might want to know when a particular line has a potentially
inaccurate blame.
Furthermore, guess_line_blames() may fail to find any parent commit for
a given line
This commit integrates the fuzzy fingerprint heuristic into
guess_line_blames().
We actually make two passes. The first pass uses the fuzzy algorithm to
find a match within the current diff chunk. If that fails, the second
pass searches the entire parent file for the best match.
For an example
From: Michael Platings
This algorithm will replace the heuristic used to identify lines from
ignored commits with one that finds likely candidate lines in the
parent's version of the file. The actual replacement occurs in an
upcoming commit.
The old heuristic simply assigned lines in the target
Commits that make formatting changes or function renames are often not
interesting when blaming a file. A user may deem such a commit as 'not
interesting' and want to ignore and its changes it when assigning blame.
For example, say a file has the following git history / rev-list:
---O---A---X---
fill_blame_origin() is a convenient place to store data that we will use
throughout the lifetime of a blame_origin. Some heuristics for
ignoring commits during a blame session can make use of this storage.
In particular, we will calculate a fingerprint for each line of a file
for blame_origins inv
init_skiplist() took a file consisting of SHA-1s and comments and added
the objects to an oidset. This functionality is useful for other
commands and will be moved to oidset.c in a future commit.
In preparation for that move, this commit renames it to
oidset_parse_file() to reflect its more gener
This patch set adds the ability to ignore a set of commits and their
changes when blaming. This can be used to ignore a commit deemed 'not
interesting,' such as reformatting.
v8 -> v9
v8: https://public-inbox.org/git/20190610153014.42055-1-b...@google.com
- Fixed tests that had git-blame's output
Signed-off-by: Barret Rhoden
---
fsck.c | 35 ---
oidset.c | 35 +++
oidset.h | 8
3 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/fsck.c b/fsck.c
index a28cba6b05dd..58ff3c4de992 100644
--- a/fsck.c
+++
The same code for splitting a blame_entry at a particular line was used
twice in blame_chunk(), and I'll use the helper again in an upcoming
patch.
Signed-off-by: Barret Rhoden
---
blame.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff
Jeff King writes:
> The find_commit_name() function passes an object_id.hash as the key of a
> hashmap. That ends up in commit_name_neq(), which then feeds it to
> oideq(). Which means we should actually be the whole "struct object_id".
>
> It works anyway because pointers to the two are intercha
On Thu, Jun 20, 2019 at 9:02 PM Derrick Stolee wrote:
>
> On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> > In c45f0f525d (switch: reject if some operation is in progress,
> > 2019-03-29), a check is added to prevent switching when some operation
> > is in progress. The reason is it's often no
On Thu, Jun 20, 2019 at 9:34 PM Derrick Stolee wrote:
>
> On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> > "git restore --source" (without --staged) could create new files
> > (i.e. not present in index) on worktree to match the given source. But
> > the new files are not tracked, so both "gi
On 11/06/2019 11:29, Xeno Amess wrote:
Not all people can afford stable network connection...
I'm now suffered from connection lost and have to restart the clone/push fully.
It's OK when dealing with a project of several MB size, but when I try
to clone a 2GB sized repo I never succeed.
So I wond
On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> "git restore --source" (without --staged) could create new files
> (i.e. not present in index) on worktree to match the given source. But
> the new files are not tracked, so both "git diff" and "git diff
> " ignore new files. "git commit -a" will
Hi,
I discovered an interesting problem when using `git checkout` to which I
couldn't find a good solution. We have an automatic system trying to checkout a
branch only when it exists. To do so we check whether `git rev-parse` finds a
commit for given branch name:
git rev-parse "${BRANCH_NAME}
On 20/06/2019 08:41, Jeff King wrote:
> There are no callers left of lookup_object() that aren't just passing us
s/lookup_object/create_object/
ATB,
Ramsay Jones
On Thu, Jun 20, 2019 at 2:39 PM Derrick Stolee wrote:
>
> On 6/20/2019 4:50 AM, Jeff King wrote:
> > On Thu, Jun 20, 2019 at 10:30:26AM +0200, Christian Couder wrote:
> >
> >> Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
> >> if we should fetch objects from promisor remotes when we
On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> In c45f0f525d (switch: reject if some operation is in progress,
> 2019-03-29), a check is added to prevent switching when some operation
> is in progress. The reason is it's often not safe to do so.
>
> This is true for merge, am, rebase, cherry-
--
Meu querido,
Eu quero financiar um projeto de caridade em seu país para o benefício
dos menos privilegiados, Por favor, confirme seu interesse se você
puder lidar com tal projeto com honestidade. Eu vou te dar mais
detalhes depois de receber sua resposta,
Deus te abençoê,
Saudações,
Sra, Sere
On 6/20/2019 4:58 AM, Jeff King wrote:
> The delta island code always prints "Marked %d islands", even if
> progress has been suppressed with --no-progress or by sending stderr to
> a non-tty.
>
> Let's pass a progress boolean to load_delta_islands(). We already do
> the same thing for the progres
On 6/20/2019 4:50 AM, Jeff King wrote:
> On Thu, Jun 20, 2019 at 10:30:26AM +0200, Christian Couder wrote:
>
>> Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
>> if we should fetch objects from promisor remotes when we
>> haven't found them elsewhere.
>>
>> Now that OBJECT_INFO_NO_FE
Before the previous patch, the server version is printed after all the
"Server supports" lines. The previous one puts the version in the middle
of "Server supports" group.
Instead of moving it to the bottom, I move it to the top. Version may
stand out more at the top as we will have even more debu
When we check if some capability is supported, we do print something in
verbose mode. Some capabilities are not printed though (and it made me
think it's not supported; I was more used to GIT_TRACE_PACKET) so let's
print them all.
It's a bit more code. And one could argue for printing all supporte
This reduces the work on translators since they only have one string to
translate (and I think it's still enough context to translate). It also
makes sure no capability name is translated by accident.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fetch-pack.c | 18 +-
1 file changed, 9
Hi Rohit
On 20/06/2019 11:34, Rohit Ashiwal wrote:
Hi Phillip
On 2019-06-20 10:02 UTC Phillip Wood wrote:
+test_expect_success 'allow skipping stopped cherry-pick because of untracked
file modifications' '
+ pristine_detach initial &&
+ git rm --cached unrelated &&
+ git
I'm trying to run git fetch using --shallow-since with a date range that
results in no commits to be selected.
In this scenario the command hangs indefinitely:
git fetch --shallow-since=2019-05-20 -vv
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
Serve
On Thu, Jun 20, 2019 at 12:49:32AM +0200, Ævar Arnfjörð Bjarmason wrote:
> We do it deterministically, when gc.auto thresholds et al are exceeded
> we kick one off without waiting for other stuff, if we can get the lock.
>
> I don't think this desire to just wait a bit until all the fetches are
>
Hi Phillip
On 2019-06-20 10:02 UTC Phillip Wood wrote:
>
> > +test_expect_success 'allow skipping stopped cherry-pick because of
> > untracked file modifications' '
> > + pristine_detach initial &&
> > + git rm --cached unrelated &&
> > + git commit -m "untrack unrelated" &&
> > + test_m
On Sat, Jun 15, 2019 at 01:19:33AM +0200, Ævar Arnfjörð Bjarmason wrote:
> ...small correction, we currently hard-rely on kwset() for any pattern
> containing a \0 for "git-grep" (these can only by supplied via the -f
> option), this means that any pattern containing a \0
> is implicitly fixed, u
On Thu, Jun 20, 2019 at 5:49 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Jun 19 2019, Jeff King wrote:
>
> > On Wed, Jun 19, 2019 at 08:01:55PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> >> > You could sort of avoid the problem here too with
> >> >
> >> > parallel 'git fetch --no-auto-gc {}'
On Thu, Jun 20, 2019 at 05:11:03PM +0700, Duy Nguyen wrote:
> > Another option would be to just pass "-c gc.auto=0" to the child
> > processes to inhibit auto-gc. But maybe it makes sense to have a nicer
> > interface (after all, somebody else could be doing the same "let's do a
> > bunch of fetch
On Thu, Jun 20, 2019 at 1:59 AM Jeff King wrote:
> I was surprised that we needed a new command-line option here, but I
> guess the sub-fetch processes really have no idea that they're
> subservient to a multi-remote fetch (they do get "--append", but of
> course somebody could specify that indepe
Hi Rohit
On 18/06/2019 18:06, Rohit Ashiwal wrote:
git am or rebase have a --skip flag to skip the current commit if the
user wishes to do so. During a cherry-pick or revert a user could
likewise skip a commit, but needs to use 'git reset' (or in the case
of conflicts 'git reset --merge'), follo
On 20/06/2019 04:40, Junio C Hamano wrote:
Rohit Ashiwal writes:
+give_advice:
+ advise(_("have you committed already?\n"
+"try \"git %s --continue\""),
+action == REPLAY_REVERT ? "revert" : "cherry-pick");
+ return error(_("there is nothing to skip"
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t2070-restore.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t2070-restore.sh b/t/t2070-restore.sh
index 73ea13ede9..2650df1966 100755
--- a/t/t2070-restore.sh
+++ b/t/t2070-restore.sh
@@ -90,9 +90,8 @@ test_expect_success '
"git restore --source" (without --staged) could create new files
(i.e. not present in index) on worktree to match the given source. But
the new files are not tracked, so both "git diff" and "git diff
" ignore new files. "git commit -a" will not recreate a commit
exactly as the given source either.
In c45f0f525d (switch: reject if some operation is in progress,
2019-03-29), a check is added to prevent switching when some operation
is in progress. The reason is it's often not safe to do so.
This is true for merge, am, rebase, cherry-pick and revert, but not so
much for bisect because bisectin
This is small refinements (except 4/4).
2/4 relaxes the 'in-progress' check for bisect because switching while
bisecting is normal _and_ safe. 3/4 makes 'switch -d' completion much
more useful. 4/4 adds the last missing piece in 'git restore', records
new files in worktree as i-t-a.
Still on the
Even though dwim is enabled by default, it will never be done when
--detached is specified. If you force "-d --guess" you will get an error
because --guess then implies -c which cannot be used with -d. So we can
disable dwim in "switch -d". It makes the completion list in this case a
bit shorter.
Hi Junio
On Wed, 19 Jun 2019 20:40:50 -0700 Junio C Hamano wrote:
>
> Two comments.
>
> The places touched by patch 1/5 emitted the error followed by an
> advice message; this new one breaks the pattern by giving the "hint:"
> first and then error. Be consistent by swapping these two (and
> retu
Hi Junio & dscho
On 18/06/2019 04:30, Junio C Hamano wrote:
Phillip Wood writes:
Yes I sent it just before I went offline, but that's a while ago now
Yup. IIRC, you told us not to look at the patch "for now" as you
would be offline, and I was fully expecting that a regular review
exchange
The delta island code always prints "Marked %d islands", even if
progress has been suppressed with --no-progress or by sending stderr to
a non-tty.
Let's pass a progress boolean to load_delta_islands(). We already do
the same thing for the progress meter in resolve_tree_islands().
Signed-off-by:
On Thu, Jun 20, 2019 at 10:30:26AM +0200, Christian Couder wrote:
> Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
> if we should fetch objects from promisor remotes when we
> haven't found them elsewhere.
>
> Now that OBJECT_INFO_NO_FETCH_IF_MISSING exists, let's use
> it instead t
On Thu, Jun 20, 2019 at 10:30:25AM +0200, Christian Couder wrote:
> The fetch_if_missing global variable should be replaced as much
> as possible by passing a flag to oid_object_info_extended().
>
> The existing OBJECT_INFO_FOR_PREFETCH unfortunately conflates
> both a "no fetch if missing" meani
The fetch_if_missing global variable should be replaced as much
as possible by passing a flag to oid_object_info_extended().
The existing OBJECT_INFO_FOR_PREFETCH unfortunately conflates
both a "no fetch if missing" meaning with OBJECT_INFO_QUICK
which is about retrying packed storage.
Let's disa
Currently the OBJECT_INFO_FOR_PREFETCH flag is used to check
if we should fetch objects from promisor remotes when we
haven't found them elsewhere.
Now that OBJECT_INFO_NO_FETCH_IF_MISSING exists, let's use
it instead to be more correct in case this new flag is ever
used without OBJECT_INFO_QUICK.
In a review[1] of my "many promisor remotes" patch series[2] and in
the following thread, it was suggested that a flag should be passed to
tell oid_object_info_extended() that it should not fetch objects from
promisor remotes if they are missing, instead of using the ugly
fetch_if_missing global.
There are no callers left of sha1hash() that do not simply pass the
"hash" member of a "struct object_id". Let's get rid of the outdated
sha1-specific function and provide one that operates on the whole struct
(even though the technique, taking the first few bytes of the hash, will
remain the same)
Our hashmap.h helpfully defines a sha1hash() function. But it cannot
define a similar oidhash() without including all of cache.h, which
itself wants to include hashmap.h! Let's break this circular dependency
by moving the definition to hash.h, along with the remaining RAWSZ
macros, etc. That will p
All of the users of this map have an actual "struct object_id" rather
than a bare sha1. Let's use the more descriptive type (and get one step
closer to dropping khash_sha1 entirely).
Signed-off-by: Jeff King
---
delta-islands.c | 22 +++---
1 file changed, 11 insertions(+), 11 de
All of the callers of khash_sha1 and khash_sha1_pos have been removed,
in favor of using maps that use "struct object_id" as their keys. Let's
drop these now-obsolete types.
Signed-off-by: Jeff King
---
khash.h | 8
1 file changed, 8 deletions(-)
diff --git a/khash.h b/khash.h
index ae
All of the users of our khash_sha1 maps actually have a "struct
object_id". Let's use the more descriptive type.
Signed-off-by: Jeff King
---
pack-bitmap-write.c | 14 +++---
pack-bitmap.c | 8
pack-bitmap.h | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-
khash lets us define a hash as either a map or a set (i.e., with no
"value" type). For the oid maps we define, "oid" is the set and
"oid_map" is the map. As the bug in the previous commit shows, it's easy
to pick the wrong one.
So let's make the names more distinct: "oid_set" and "oid_map".
An al
For use in object_id hash tables, we have oid_hash() and oid_equal().
But these are confusingly similar to the existing oideq() and the
oidhash() we plan to add to replace sha1hash().
The big difference from those functions is that rather than accepting a
const pointer to the "struct object_id", w
There are no callers left of lookup_object() that aren't just passing us
the "hash" member of a "struct object_id". Let's take the whole struct,
which gets us closer to removing all raw sha1 variables. It also
matches the existing conversions of lookup_blob(), etc.
The conversions of callers were
Now that lookup_object() has an object_id, we can consistently pass that
around instead of a raw sha1. We still convert to a hash to pass to
sha1hash(), but the goal is for that to go away shortly.
Signed-off-by: Jeff King
---
object.c | 8
1 file changed, 4 insertions(+), 4 deletions(-
Am 19.06.19 um 20:39 schrieb Jeff King:
> But without that, I have to wonder what problem we are really solving.
You have a point here.
> Now it's baked into the binary. Later it will be baked into the
> distribution, but we still don't want anybody to touch it because their
> changes will be ove
1 - 100 of 109 matches
Mail list logo