Some build machines started consistently failing to fetch updated
source using "repo sync", with error
error: The last gc run reported the following. Please correct the root cause
and remove /build/.repo/projects/tools/git.git/gc.log.
Automatic cleanup will not be performed until the file is
A value of -1 returned from cmd_gc gets propagated to exit(),
resulting in an exit status of 255. Use die instead for a clearer
error message and a controlled exit.
Signed-off-by: Jonathan Nieder
---
As in
https://public-inbox.org/git/20180716225639.gk11...@aiede.svl.corp.google.com/.
The only c
A collection of minor error handling fixes:
- use an error message in lower case, following the usual style
- quote filenames in error messages to make them easier to read and to
decrease translation load by matching other 'stat' error messages
- check for and report errors from 'read', too
- av
Hi,
Jonathan Tan wrote:
> In a087cc9819 ("git-gc --auto: protect ourselves from accumulated
> cruft", 2007-09-17), the user was warned if there were too many
> unreachable loose objects. This made sense at the time, because gc
> couldn't prune them safely. But subsequently, git prune learned the
Hi,
Jeff King wrote:
> On Mon, Jul 16, 2018 at 03:56:39PM -0700, Jonathan Nieder wrote:
>> The calling command in the motivating example is Android's "repo" tool:
>>
>> bare_git.gc('--auto')
>>
>> from https://gerrit-review.googlesource.com/c/git-repo/+/10598/. I
>> think it's reas
> The first step includes using a depth-first-search (DFS) from each from
> commit, sorted by ascending generation number. We do not walk beyond the
> minimum generation number or the minimum commit date. This DFS is likely
> to be faster than the existing reachable() method because we expect
> pre
On Tue, Jul 17, 2018 at 12:03:11AM +, brian m. carlson wrote:
> > +gpg.format::
> > + Specifies which key format to use when signing with `--gpg-sign`.
> > + Default is "openpgp", that is also the only supported value.
>
> I think, as discussed in the other thread, perhaps a different pre
v2:
addressed review comments, renaming the struct, improving the commit message.
v1:
https://public-inbox.org/git/20180712194754.71979-1-sbel...@google.com/
I thought about writing it all in one go, but the series got too large,
so let's chew one bite at a time.
Thanks,
Stefan
Stefan Beller (6)
Separate the command line parsing from the actual execution of the command
within the repository. For now there is not a lot of execution as
most of it is still in git-submodule.sh.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 59 +
1 file ch
This chews off a bit of the shell part of the update command in
git-submodule.sh. When writing the C code, keep in mind that the
submodule--helper part will go away eventually and we want to have
a C function that is able to determine the submodule update strategy,
it as a nicety, make determine_su
The information that is printed for update_submodules in
'submodule--helper update-clone' and consumed by 'git submodule update'
is stored as a string per submodule. This made sense at the time of
48308681b07 (git submodule update: have a dedicated helper for cloning,
2016-02-29), but as we want to
The 'mode' variable is not used in cmd_update for its original purpose,
rename it to 'dummy' as it only serves the purpose to abort quickly
documenting this knowledge.
The variable 'stage' is also not used any more in cmd_update, so remove it.
This went unnoticed as first each function used the c
In a later patch we'll find this method handy.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index fb54936efc7..034ba1bb2e0 100644
-
All other error messages in cmd_update are reporting the submodule based
on its path, so let's do that for invalid update modes, too.
Signed-off-by: Stefan Beller
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5f
The subject should be can_all_from_reach_with_flag (without the "s" at
the end). Likewise in the commit message.
> To make this method testable, add a new can_all_from_reach method that
> does the initial setup and final tear-down. Call the method from
> 'test-tool reach'.
This description leads
On Fri, Jul 13, 2018 at 10:41:23AM +0200, Henning Schild wrote:
> Add "gpg.format" where the user can specify which type of signature to
> use for commits. At the moment only "openpgp" is supported and the value is
> not even used. This commit prepares for a new types of signatures.
>
> Signed-off
On Mon, Jul 16, 2018 at 12:37 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > The information that is printed for update_submodules in
> > 'submodule--helper update-clone' and consumed by 'git submodule update'
> > is stored as a string per submodule. This made sense at the time of
> > 4
Bonjour
Vous aviez besoin de prêts d'argent entre particuliers pour faire face
aux difficultés financières pour enfin sortir de l'impasse que
provoquent les banques, par le rejet de vos dossiers de demande de
crédits ?
Je suis un un citoyen français à la retraite en mesure de vous faire
un prêt de
On Mon, Jul 16, 2018 at 03:56:39PM -0700, Jonathan Nieder wrote:
> The calling command in the motivating example is Android's "repo" tool:
>
> bare_git.gc('--auto')
>
> from https://gerrit-review.googlesource.com/c/git-repo/+/10598/. I
> think it's reasonable that it expects a statu
Jeff King writes:
> On Mon, Jul 16, 2018 at 02:56:34PM -0700, Junio C Hamano wrote:
>
>> >> I'm okay with us forcing "openpgp". That seems sane enough for now, and
>> >> if people scream loudly, we can loosen it.
>> >
>> > Well, I specifically meant "are you sure subsections like this are a
>> >
> @@ -71,6 +78,14 @@ int cmd__reach(int ac, const char **av)
> printf("%s(A,B):%d\n", av[1], in_merge_bases(A, B));
> else if (!strcmp(av[1], "is_descendant_of"))
> printf("%s(A,X):%d\n", av[1], is_descendant_of(A, X));
> + else if (!strcmp(av[1], "get_merge_ba
On Mon, Jul 16, 2018 at 3:55 PM, Jeff King wrote:
> On Mon, Jul 16, 2018 at 03:07:34PM -0700, Elijah Newren wrote:
>
>> > If we were to delete those objects, wouldn't it be exactly the same as
>> > running "git prune"? Or setting your gc.pruneExpire to "now" or even "5
>> > minutes"? Or are you c
This makes the follow up patch easier.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index ce7bedc1b92..d1bae900cdc 100644
--- a/diff.c
+++ b/diff.c
@@ -707,11 +707,15 @@
The new "blocks" mode provides a middle ground between plain and zebra.
It is as intuitive (few colors) as plain, but still has the requirement
for a minimum of lines/characters to count a block as moved.
Suggested-by: Ævar Arnfjörð Bjarmason
(https://public-inbox.org/git/87o9j0uljo@evledraa
This moves the part of code that checks if we're still in a block
into its own function. We'll need a different approach on advancing
the blocks in a later patch, so having it as a separate function will
prove useful.
While at it rename the variable `p` to `prev` to indicate that it refers
to the
The option of --color-moved has proven to be useful as observed on the
mailing list. However when refactoring sometimes the indentation changes,
for example when partitioning a functions into smaller helper functions
the code usually mostly moved around except for a decrease in indentation.
To jus
In the original implementation of the move detection logic the choice for
ignoring white space changes is the same for the move detection as it is
for the regular diff. Some cases came up where different treatment would
have been nice.
Allow the user to specify that white space should be ignored
On Mon, Jul 16, 2018 at 02:37:32PM -0700, Junio C Hamano wrote:
> Eric Sunshine writes:
> > On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
> > wrote:
> >> On Mon, 16 Jul 2018, Johannes Schindelin wrote:
> >> > > - git submodule add --force bogus-url submod &&
> >> > > +
This is a resend of sb/diff-color-move-more
https://public-inbox.org/git/20180629001958.85143-1-sbel...@google.com/
that fixes an errornous squashing within the series; the end result is
the same. range diff is below. (As the latest cooking email said
this series is going to land in next soon, I ho
There is no need to forward-declare these functions, as they are used
after their implementation only.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
xdiff/xdiffi.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 0de1ef
When we initialize the hashmap, we give it a pointer to the
diff_options, which it then passes along to each call of the
hashmap_cmp_fn function. There's no need to pass it a second time as
the "keydata" parameter, and our comparison functions never look at
keydata.
This was a mistake left over fr
These flags were there since the beginning (3443546f6e (Use a *real*
built-in diff generator, 2006-03-24), but were never used. Remove them.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
xdiff/xdiff.h | 8
1 file changed, 8 deletions(-)
diff --git a/xdiff/xdiff.h b/xd
In t4015 we have a pattern of
git diff [] |
grep -v "index" |
test_decode_color >actual &&
to produce output that we want to test against. This pattern was introduced
in 86b452e2769 (diff.c: add dimming to moved line detection, 2017-06-30)
as then the focus on getting the colo
Jonathan Tan writes:
> Introduce a new negotiation algorithm used during fetch that skips
> commits in an effort to find common ancestors faster. The skips grow
> similarly to the Fibonacci sequence as the commit walk proceeds further
> away from the tips. The skips may cause unnecessary commits
> To use the new test-tool, use 'test-tool reach ' and provide
> input to stdin that describes the inputs to the method. Currently, we
> only implement the ref_newer method, which requires two commits. Use
> lines "A:" and "B:" for the two inputs. We will
> expand this input later to accommodate me
Jeff King wrote:
> On Mon, Jul 16, 2018 at 03:03:06PM -0700, Jonathan Nieder wrote:
>> Oh, good point. In non-daemon mode, we don't let "gc --auto" failure
>> cause the invoking command to fail, but in daemon mode we do. That
>> should be a straightforward fix; patch coming in a moment.
>
> OK,
On Mon, Jul 16, 2018 at 03:07:34PM -0700, Elijah Newren wrote:
> > If we were to delete those objects, wouldn't it be exactly the same as
> > running "git prune"? Or setting your gc.pruneExpire to "now" or even "5
> > minutes"? Or are you concerned with taking other objects along for the
> > ride
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The is_descendant_of method previously used in_merge_bases() to check if
> the commit can reach any of the commits in the provided list. This had
> two performance problems:
>
> 1. The performance
On Mon, Jul 16, 2018 at 03:03:06PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I don't think any command should report failure of its _own_ operation
> > if "gc --auto" failed. And grepping around the source code shows that we
> > typically ignore it.
>
> Oh, good point. In non-daemo
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> Note how the time increases between the two cases in the two versions.
> The new code increases relative to the number of commits that need to be
> walked, but not directly relative to the number of 'from' commits.
Cool!
> /* Remember to update object flag allocation in object.h */
> +#define REACHABLE (1u<<15)
> #define PARENT1 (1u<<16)
> #define PARENT2 (1u<<17)
> #define STALE(1u<<18)
Update the object flag allocation in object.h.
> +int reachable(struct comm
On Mon, Jul 16, 2018 at 02:56:34PM -0700, Junio C Hamano wrote:
> >> I'm okay with us forcing "openpgp". That seems sane enough for now, and
> >> if people scream loudly, we can loosen it.
> >
> > Well, I specifically meant "are you sure subsections like this are a
> > good idea". But it seems li
Jules Maselbas writes:
> The variable smtp_encryption must keep it's value between two batches.
> Otherwise the authentication is skipped after the first batch.
>
> Signed-off-by: Jules Maselbas
> ---
> git-send-email.perl | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The ref_newer method is used by 'git push' to check if a force-push is
> required. This method does not use any kind of cutoff when walking, so
> in the case of a force-push will walk all reachable
On Mon, Jul 16, 2018 at 2:21 PM, Jeff King wrote:
> On Mon, Jul 16, 2018 at 02:09:43PM -0700, Elijah Newren wrote:
>> The point of gc is to: expire reflogs, repack referenced objects, and
>> delete loose objects that (1) are no longer referenced and (2) are
>> "old enough".
>>
>> The "old enough"
Jeff King wrote:
> I don't think any command should report failure of its _own_ operation
> if "gc --auto" failed. And grepping around the source code shows that we
> typically ignore it.
Oh, good point. In non-daemon mode, we don't let "gc --auto" failure
cause the invoking command to fail, but
On Mon, Jul 16, 2018 at 5:30 PM Stefan Beller wrote:
> > +test_expect_success 'reduce_heads' '
> > + cat >input <<-\EOF &&
> > + X:commit-1-10
> > + X:commit-2-8
> > + X:commit-3-6
> > + X:commit-4-4
> > + X:commit-1-7
> >
Jeff King writes:
> On Sat, Jul 14, 2018 at 06:13:47PM +, brian m. carlson wrote:
>
>> On Tue, Jul 10, 2018 at 12:56:38PM -0400, Jeff King wrote:
>> > On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
>> >
>> > > Should we allow:
>> > >
>> > > [gpg "OpenPGP"]
>> > > program = w
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The can_all_from_reach_with_flags method is used by ok_to_give_up in
> upload-pack.c to see if we have done enough negotiation during a fetch.
> This method is intentionally created to preserve sta
On Mon, Jul 16, 2018 at 02:40:03PM -0700, Jonathan Nieder wrote:
> > The key thing is that the presence of the warning/log still suppress
> > the actual gc for the gc.logExpiry period.
>
> Ah, now I think I see the source of the misunderstanding.
>
> When I initially read the docs, I also assume
Jeff King wrote:
> On Mon, Jul 16, 2018 at 01:37:53PM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> With the current code, that produces a bunch of annoying warnings for
>>> every commit ("I couldn't gc because the last gc reported a warning").
>>> But after Jonathan's patch, every single
On Mon, Jul 16, 2018 at 01:14:34PM -0700, Junio C Hamano wrote:
> > #define PGP_SIGNATURE "-BEGIN PGP SIGNATURE-"
> > @@ -138,6 +139,12 @@ int git_gpg_config(const char *var, const char *value,
> > void *cb)
> > return 0;
> > }
> >
> > + if (!strcmp(var, "gpg.format")
Eric Sunshine writes:
> On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
> wrote:
>> On Mon, 16 Jul 2018, Johannes Schindelin wrote:
>> > > - git submodule add --force bogus-url submod &&
>> > > + git submodule add --force /bogus-url submod &&
>> >
>> > This breaks on Win
On Sat, Jul 14, 2018 at 06:13:47PM +, brian m. carlson wrote:
> On Tue, Jul 10, 2018 at 12:56:38PM -0400, Jeff King wrote:
> > On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
> >
> > > Should we allow:
> > >
> > > [gpg "OpenPGP"]
> > > program = whatever
> > >
> > > given tha
> +/* Remember to update object flag allocation in object.h */
> +#define PARENT1 (1u<<16)
> +#define PARENT2 (1u<<17)
> +#define STALE(1u<<18)
> +#define RESULT (1u<<19)
Update object.h to point to commit-reach.c instead of commit.c also.
>
On Sat, Jul 14, 2018 at 06:33:12PM +, brian m. carlson wrote:
> > This series is a fine replacement for that earlier work. It's flexible
> > enough to allow what we really wanted out of that series (gpgsm support,
> > or another drop-in tool that uses the same interface). It doesn't lay
> > an
> +test_expect_success 'reduce_heads' '
> + cat >input <<-\EOF &&
> + X:commit-1-10
> + X:commit-2-8
> + X:commit-3-6
> + X:commit-4-4
> + X:commit-1-7
> + X:commit-2-5
> + X:commit-3-3
> +
Elijah Newren wrote:
> I totally agree with your general plan to put unreferenced loose
> objects into a pack. However, I don't think these objects should be
> part of that pack; they should just be deleted instead.
This might be the wrong thread to discuss it, but did you follow the
reference/p
> +test_expect_success 'get_merge_bases_many' '
> + cat >input <<-\EOF &&
> + A:commit-5-7
> + X:commit-4-8
> + X:commit-6-6
> + X:commit-8-3
> + EOF
> + {
> + printf "get_merge_bases_many(A,X):\n" &&
> +
On Mon, Jul 16, 2018 at 02:09:43PM -0700, Elijah Newren wrote:
> >> Um, except it doesn't actually do that. The testcase I provided shows
> >> that it leaves around 1 objects that are totally deletable and
> >> were only previously referenced by reflog entries -- entries that gc
> >> removed
On Mon, Jul 16, 2018 at 01:56:46PM -0700, Jonathan Nieder wrote:
> I don't believe we are very good at transitively propagating freshness
> today, by the way.
Perhaps I don't understand what you mean by transitive here. But we
should be traversing from any fresh object and marking any non-fresh
o
Jeff King writes:
> On Mon, Jul 16, 2018 at 11:14:51AM -0700, Junio C Hamano wrote:
>
>> Porcelain, but I suspect in practice always giving GIT_DIR and
>> GIT_WORK_TREE would work well for many existing hooks.
>
> Yeah, that may be an option. I don't remember if this was discussed in
> this threa
On Mon, Jul 16, 2018 at 1:38 PM, Jeff King wrote:
> On Mon, Jul 16, 2018 at 01:16:45PM -0700, Elijah Newren wrote:
>
>> >> The basic problem here, at least for us, is that gc has enough
>> >> information to know it could expunge some objects, but because of how
>> >> it is structured in terms of s
On Mon, Jul 16, 2018 at 01:37:53PM -0700, Jonathan Nieder wrote:
> >and I think the
> > right solution is to pack the unreachable objects instead of exploding
> > them.
>
> That seems like a huge widening in scope relative to what this
> ori
Jeff King writes:
> I think you missed it. In the paragraph above the one you
> quoted, I said:
>
>The cgit repository, for example, has a file named
>.gitmodules from a pre-submodule attempt at sharing code,
>but does not actually have any gitlinks.
Indeed.
> So I'm curious if you
Michael Haggerty writes:
> The magic 100 blames back to our chief magician, Junio:
>
> 8ac65937d0 Make sure we do not write bogus reflog entries. (2007-01-26)
Yup, guilty as charged.
cf.
"%s %s %s\n" with old and new commit object name and the message
will be "2 * len(hash_in_hex)
Jeff King wrote:
> On Mon, Jul 16, 2018 at 01:21:40PM -0700, Elijah Newren wrote:
>> Jonathan Nieder wrote:
>>> My understanding is that exploding the objects is intentional behavior,
>>> to avoid a race where objects are newly referenced while they are being
>>> pruned.
[...]
>> Ah, that's good t
Olga Telezhnaya writes:
> -static int get_object(struct ref_array_item *ref, const struct object_id
> *oid,
> - int deref, struct object **obj, struct strbuf *err)
> +static int get_object(struct ref_array_item *ref, int deref, struct object
> **obj,
> + stru
Henning Schild writes:
> +gpg..program::
> + Use this to customize the program used for the signing format you
> + chose. (see gpg.program) gpg.openpgp.program is a synonym for the
> + legacy gpg.program.
I _think_ you meant "see gpg.format", but I am not 100% sure.
When X is a syno
On 07/15, Simon Ruderich wrote:
> On Sat, Jul 14, 2018 at 10:44:36PM +0100, Thomas Gummerer wrote:
> > 'git rerere' is considered a plumbing command and as such its output
>
> s/plumbing/porcelain/?
Ah yes indeed. Thanks for catching!
> Regards
> Simon
> --
> + privacy is necessary
> + using g
Henning Schild writes:
> Create a struct that holds the format details for the supported formats.
> At the moment that is still just "openpgp". This commit prepares for the
> introduction of more formats, that might use other programs and match
> other signatures.
>
> Signed-off-by: Henning Schil
Henning Schild writes:
> gnupg does print the keyid followed by a space and the signer comes
> next. The same pattern is also used in gpgsm, but there the key length
> would be 40 instead of 16. Instead of hardcoding the expected length,
> find the first space and calculate it.
> Input that does
On Mon, Jul 16, 2018 at 01:16:45PM -0700, Elijah Newren wrote:
> >> The basic problem here, at least for us, is that gc has enough
> >> information to know it could expunge some objects, but because of how
> >> it is structured in terms of several substeps (reflog expiration,
> >> repack, prune),
Jeff King wrote:
> On Mon, Jul 16, 2018 at 12:54:31PM -0700, Jonathan Nieder wrote:
>> Even restricting attention to the warning, not the exit code, I think
>> you are saying the current behavior is acceptable. I do not believe
>> it is.
>
> I didn't say that at all. The current situation sucks,
On Mon, Jul 16, 2018 at 01:21:40PM -0700, Elijah Newren wrote:
> > My understanding is that exploding the objects is intentional behavior,
> > to avoid a race where objects are newly referenced while they are being
> > pruned.
> >
> > I am not a fan of that behavior. It's still racy. But when we
On Mon, Jul 16, 2018 at 12:54:31PM -0700, Jonathan Nieder wrote:
> Even restricting attention to the warning, not the exit code, I think
> you are saying the current behavior is acceptable. I do not believe
> it is.
I didn't say that at all. The current situation sucks, and I think the
right sol
Hi,
On Mon, Jul 16, 2018 at 12:19 PM, Jonathan Nieder wrote:
> Elijah Newren wrote:
>
>> The basic problem here, at least for us, is that gc has enough
>> information to know it could expunge some objects, but because of how
>> it is structured in terms of several substeps (reflog expiration,
>>
On Mon, Jul 16, 2018 at 12:52 PM, Jeff King wrote:
> On Mon, Jul 16, 2018 at 12:15:05PM -0700, Elijah Newren wrote:
>
>> The basic problem here, at least for us, is that gc has enough
>> information to know it could expunge some objects, but because of how
>> it is structured in terms of several s
Henning Schild writes:
> Test setting gpg.format to both invalid and valid values.
>
> Signed-off-by: Henning Schild
> ---
> t/t7510-signed-commit.sh | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index 6e2015ed9..1b6a1dd9
Henning Schild writes:
> Add "gpg.format" where the user can specify which type of signature to
> use for commits. At the moment only "openpgp" is supported and the value is
> not even used. This commit prepares for a new types of signatures.
>
> Signed-off-by: Henning Schild
> ---
> Documentat
Jeff King wrote:
> On Mon, Jul 16, 2018 at 12:09:49PM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> Er, the action is to run "git prune", like the warning says. :)
>>
>> I don't think we want to recommend that, especially when "git gc --auto"
>> does the right thing automatically.
>
> But
On Mon, Jul 16, 2018 at 12:15:05PM -0700, Elijah Newren wrote:
> The basic problem here, at least for us, is that gc has enough
> information to know it could expunge some objects, but because of how
> it is structured in terms of several substeps (reflog expiration,
> repack, prune), the informat
On Mon, Jul 16, 2018 at 12:09:49PM -0700, Jonathan Nieder wrote:
> >>> So while I completely agree that it's not a great thing to encourage
> >>> users to blindly run "git prune", I think it _is_ actionable.
> >>
> >> To flesh this out a little more: what user action do you suggest? Could
> >> we
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The ok_to_give_up() method uses the commit date as a cutoff to avoid
> walking the entire reachble set of commits. Before moving the
> reachable() method to commit-reach.c, pull out the dependence
Stefan Beller writes:
> The information that is printed for update_submodules in
> 'submodule--helper update-clone' and consumed by 'git submodule update'
> is stored as a string per submodule. This made sense at the time of
> 48308681b07 (git submodule update: have a dedicated helper for cloning
Hi,
Elijah Newren wrote:
> The basic problem here, at least for us, is that gc has enough
> information to know it could expunge some objects, but because of how
> it is structured in terms of several substeps (reflog expiration,
> repack, prune), the information is lost between the steps and it
On Mon, Jul 16, 2018 at 10:27 AM, Jonathan Tan wrote:
> In a087cc9819 ("git-gc --auto: protect ourselves from accumulated
> cruft", 2007-09-17), the user was warned if there were too many
> unreachable loose objects. This made sense at the time, because gc
> couldn't prune them safely. But subse
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
> +
> +int commit_contains(struct ref_filter *filter, struct commit *commit,
> + struct commit_list *list, struct contains_cache *cache)
[...]
> -
> -static int commit_contains(struct ref_filter *filter, st
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> Signed-off-by: Derrick Stolee
Another verbatim move!
(I'll just re-iterate that the --color-moved option is very helpful in
these reviews)
Thanks,
Stefan
> +++ b/commit-reach.h
> @@ -38,4 +38,6
Hi,
Jeff King wrote:
> On Mon, Jul 16, 2018 at 11:22:07AM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> So while I completely agree that it's not a great thing to encourage
>>> users to blindly run "git prune", I think it _is_ actionable.
>>
>> To flesh this out a little more: what user a
On Mon, Jul 16, 2018 at 2:56 PM Jeff King wrote:
> On Mon, Jul 16, 2018 at 02:40:21PM -0400, Eric Sunshine wrote:
> > On Mon, Jul 16, 2018 at 12:18 PM Jeff King wrote:
> > > git-send-email uses the current time minus an offset, and then
> > > monotonically increases for each patch:
> >
> > Junio
On Mon, Jul 16, 2018 at 6:00 AM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> Signed-off-by: Derrick Stolee
This looks good, apart from nits below.
Thanks,
Stefan
> diff --git a/commit-reach.c b/commit-reach.c
> new file mode 100644
> index 0..f2e2f7461
> --- /de
On Mon, Jul 16, 2018 at 02:40:21PM -0400, Eric Sunshine wrote:
> On Mon, Jul 16, 2018 at 12:18 PM Jeff King wrote:
> > On Mon, Jul 16, 2018 at 02:54:38PM +0100, Ramsay Jones wrote:
> > > This is not your problem, but I find these GitGitGadget
> > > submissions somewhat annoying. This series has b
On Mon, Jul 16, 2018 at 11:22:07AM -0700, Jonathan Nieder wrote:
> > I'm not sure if this tells the whole story. You may still run into a
> > case where auto-gc runs over and over during the grace period, because
> > you have a bunch of objects which are not reachable and not yet ready to
> > be e
On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
wrote:
> On Mon, 16 Jul 2018, Johannes Schindelin wrote:
> > > - git submodule add --force bogus-url submod &&
> > > + git submodule add --force /bogus-url submod &&
> >
> > This breaks on Windows because of the absolute Unix
Hi Johannes,
On Mon, 16 Jul 2018 at 18:59:03 +0300, Johannes Schindelin wrote:
Hi Aaron,
On Mon, 16 Jul 2018, Aaron Schrab wrote:
Looking into that a bit further, it does seem like my explanation above
was incorrect. Here's another attempt to explain why setting
core.commentChar=auto isn't a
On 7/16/2018 2:44 PM, Eric Sunshine wrote:
On Mon, Jul 16, 2018 at 1:27 PM Stefan Beller wrote:
Another pain point of the Gadget is that CC's in the cover letter
do not work as I would imagine. The line
CC: sbel...@google.com
did not put that email into the cc field.
gitgitgadget recognizes
On Mon, Jul 16, 2018 at 1:27 PM Stefan Beller wrote:
> Another pain point of the Gadget is that CC's in the cover letter
> do not work as I would imagine. The line
>
> CC: sbel...@google.com
>
> did not put that email into the cc field.
gitgitgadget recognizes case-sensitive "Cc:" only[1].
[1]:
Introduce a new negotiation algorithm used during fetch that skips
commits in an effort to find common ancestors faster. The skips grow
similarly to the Fibonacci sequence as the commit walk proceeds further
away from the tips. The skips may cause unnecessary commits to be
included in the packfile,
On Mon, Jul 16, 2018 at 12:18 PM Jeff King wrote:
> On Mon, Jul 16, 2018 at 02:54:38PM +0100, Ramsay Jones wrote:
> > This is not your problem, but I find these GitGitGadget
> > submissions somewhat annoying. This series has been spewed
> > all over my in-box in, what I assume, is commit date orde
1 - 100 of 144 matches
Mail list logo
