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 hints cgit has some
problem (but not exactly what problem). Is that the "cgit
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 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
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 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 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 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 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 8:21 AM Taylor Blau wrote:
>
> On Mon, Jul 16, 2018 at 01:27:52AM +, brian m. carlson wrote:
> > This is the fourteenth series of patches to switch to using struct
> > object_id and the_hash_algo. This series converts several core pieces
> > to use struct object_id,
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
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 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
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
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: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 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
> couldn't prune them safely.
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 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,
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 Sat, Jul 14, 2018 at 11:56:57PM +0200, Johannes Schindelin wrote:
> > > To avoid this problem, let's prune the shallow list in `git repack` when
> > > the `-d` option is passed, unless `-A` is passed, too (which would force
> > > the now-unreachable objects to be turned into loose objects
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
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
>>
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
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
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
> ---
>
> +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 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
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
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 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
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
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 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
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
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
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
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
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: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),
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
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 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
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
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 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 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 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
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 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
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 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
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 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
>>
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 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
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,
> +
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
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 '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
> +
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,
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 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
> 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
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
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 &&
> >> > > +
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,
>>
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 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
> >
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 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:
> 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 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
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
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 *
> +/* 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.
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
> @@ -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 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
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
> >
On Tue, Jul 3, 2018 at 7:26 AM Thomas Rast via GitGitGadget
wrote:
> These are essentially lifted from https://github.com/trast/tbdiff, with
> light touch-ups to account for the command now being an option of `git
> branch`.
The "option of `git branch`" mention is outdated. Perhaps just drop
On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
wrote:
> After using this command extensively for the last two months, this
> developer came to the conclusion that even if the dual color mode still
> leaves a lot of room for confusion what was actually changed, the
On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
wrote:
> At this stage, `git range-diff` can determine corresponding commits
> of two related commit ranges. This makes use of the recently introduced
> implementation of the Hungarian algorithm.
Did you want
On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
wrote:
> This change brings `git range-diff` yet another step closer to
> feature parity with tbdiff: it now shows the oneline, too, and indicates
> with `=` when the commits have identical diffs.
>
> Signed-off-by: Johannes
On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
wrote:
> The bulk of this patch consists of a heavily butchered version of
> tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from
> https://github.com/trast/tbdiff.
>
> Signed-off-by: Johannes Schindelin
> ---
From: Johannes Schindelin
In 60f487ac0ef (Remove common-cmds.h, 2018-05-10), we forgot to adjust
this README when removing the common-cmds.h file.
Signed-off-by: Johannes Schindelin
---
compat/vcbuild/README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-41.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub
In 60f487ac0ef (Remove common-cmds.h, 2018-05-10), we forgot to adjust
this README when removing the common-cmds.h file.
Signed-off-by: Johannes Schindelin
Johannes Schindelin (1):
vcbuild/README: update to accommodate for missing common-cmds.h
compat/vcbuild/README | 4 ++--
1 file
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.
>
>
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
1 - 100 of 139 matches
Mail list logo
