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
> 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
>
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
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
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
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
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
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
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
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.
>
>
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
> >
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
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
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],
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
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
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 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
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
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
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
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 &&
> >> > > +
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
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
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
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
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
> >
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
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
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
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
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
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
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,
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 =
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
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
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,
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
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
> +/* 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
> >
> +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
> +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
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
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
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
>
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 *
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
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,
> +
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
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
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
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
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
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
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
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
> ---
>
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
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
> >>
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
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
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,
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
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
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
> ---
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
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
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
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
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
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
On Mon, Jul 16, 2018 at 11:14:51AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > None of which is too surprising. The root of the bug is in the
> > conversion to rebase--helper, I think, when presumably we started
> > setting GIT_DIR at all (but I didn't dig further). Then 09d7b6c6fa
On Mon, Jul 16, 2018 at 11:04:04AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >site's support). And the broken .gitmodules may be too
> >far back in history for rewriting to be feasible (again,
> >this is an issue for cgit).
>
> "again" but this is the first mention that
Hi,
Jeff King wrote:
> On Mon, Jul 16, 2018 at 10:27:17AM -0700, 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
>>
Jeff King writes:
> None of which is too surprising. The root of the bug is in the
> conversion to rebase--helper, I think, when presumably we started
> setting GIT_DIR at all (but I didn't dig further). Then 09d7b6c6fa fixed
> _one_ fallout of that, which was relative paths, but didn't help the
1 - 100 of 139 matches
Mail list logo
