On Fri, Mar 1, 2019 at 5:20 AM Christian Couder
wrote:
>
> Hi Matheus,
>
> On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
> wrote:
> >
> > I've been in the mailing list for a couple weeks now, mainly working
> > on my gsoc micro-project[1] and in other patches that derived from it.
>
On 22-Feb-19 11:11 PM, Junio C Hamano wrote:
"Slavica Djukic via GitGitGadget" writes:
+static int parse_color_slot(const char *slot)
+{
+ if (!strcasecmp(slot, "prompt"))
+ return COLOR_PROMPT;
+ if (!strcasecmp(slot, "header"))
+ return COLOR_HEADER;
On 22-Feb-19 10:46 PM, Junio C Hamano wrote:
"Slavica Djukic via GitGitGadget" writes:
+#define HEADER_INDENT " "
+
enum collection_phase {
WORKTREE,
INDEX
@@ -27,6 +29,61 @@ struct collection_status {
struct hashmap file_map;
};
+struct list_and_choose_op
Hey!
I'm a little confused as you never provide a clear indication to
where shall I proceed? :-
On Fri, 01 Mar 2019 11:51:46 +0900 Junio C Hamano wrote:
>
> Simple things do not need that many letters to tell ;-) The
> suggestion of 72 is about the maximum.
>
Totally agree on this!
>
> I th
Hi Phillip,
On Thu, 28 Feb 2019, Phillip Wood wrote:
> On 28/02/2019 15:27, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > In the case that the rebase boils down to a fast-forward, the built-in
> > rebase reset the working tree twice: once to start the rebase
Oh yes... I did. Sigh
Regardless,
wouldn’t be nice to have a confirmation in cases like this? considering git
isn’t only used by experts. It would’ve helped me A LOT, that’s for sure… and
I’m 100% sure I won’t be that last person in the history of git that would
suffer this.
Thank you for you
On Fri, Mar 01, 2019 at 07:56:00AM +0100, Johannes Sixt wrote:
> Am 28.02.19 um 22:43 schrieb Manuel Guilamo:
> > I accidentally executed git reset —hard in a project that doesn’t
> > have any commits yet. git erased everything, everything I’ve worked
> > the past week, I believe this is not a des
On Thu, Feb 28 2019, Matheus Tavares Bernardino wrote:
> Hi, Ævar
>
> I'm finishing the required changes in this series to send a v4, but
> when submitting to travis ci, I got some errors on the
> t5604-clone-reference test:
> https://travis-ci.org/MatheusBernardino/git/builds/57587
I don't
Duy Nguyen writes:
> On Thu, Feb 28, 2019 at 08:54:23AM +0300, Sergey Organov wrote:
>> Hello,
>>
>> How do I configure git to handle tags from remotes in a manner similar
>> to branches?
>>
>> Specifically, I want tag 'tag_name' from remote 'origin' to have local
>> name 'origin/tag_name', not
Hi Dscho
On 01/03/2019 13:19, Johannes Schindelin wrote:
Hi Phillip,
On Thu, 28 Feb 2019, Phillip Wood wrote:
On 28/02/2019 15:27, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
In the case that the rebase boils down to a fast-forward, the built-in
rebase reset the w
Hi Peff,
On Fri, 8 Feb 2019, Jeff King wrote:
> On Fri, Feb 08, 2019 at 10:28:12AM +0100, Johannes Schindelin wrote:
>
> > On Fri, 8 Feb 2019, Johannes Schindelin wrote:
> >
> > > I just had a look at the patch you provided below (for some reason, my
> > > previous search on public-inbox only t
Hi Chris,
On Thu, 28 Feb 2019, Christian Couder wrote:
> On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
> wrote:
> >
> > I'm also interested in the 'convert script to builtin' task, and I was
> > wondering if 'git-bisect' would be a good candidate for that.
>
> There is an ongoing
Rather than parse options manually, which is both difficult to
read and error prone, parse options supplied to commit-tree
using the parse-options api.
It was discovered that the --no-gpg-sign option was documented
but not implemented in commit 70ddbd7767 (commit-tree: add missing
--gpg-sign flag,
The completion.commands config var must be set in either the system-wide
or global config file. The completion script does not read a local
repository config.
Signed-off-by: Todd Zullinger
---
Documentation/config/completion.txt | 3 ++-
Documentation/git.txt | 3 ++-
2 files chan
6532f3740b ("completion: allow to customize the completable command
list", 2018-05-20) added the completion.commands config variable.
Multiple commands may be added or removed, separated by a space.
Demonstrate the failure of multiple removals.
Signed-off-by: Todd Zullinger
---
t/t9902-completi
Jeff King wrote:
> I can reproduce your problem, though the test you included passes for me
> even with the current tip of master.
Oh, hrm. I think the issue is that completion.commands needs to be
set in the global (or system-wide) config, via test_config_global
rather than the local repo config
From: Jeff King
6532f3740b ("completion: allow to customize the completable
command list", 2018-05-20) added the completion.commands config
variable.
The documentation states multiple commands may be added,
separated by spaces. Adding multiple commands to remove fails,
only removing the last co
A ref may not be the descendant of all of the commits mentionned in
stdin. In this case, we want to avoid naming its parents.
To do this, find_commits_in_strbuf() is created. It returns a raw list
of all the commits that have been found in the input buffer. ishex() is
converted to an inlined fu
name_rev() is a recursive function. For each commit, it allocates the
name of its parents, and call itself. A parent may not use a name for
multiple reasons, but in any case, the name will not be released. On a
repository with a lot of branches, tags, remotes, and commits, it can
use more than 2
To avoid naming some commits, name_rev() will need to check if a commit
is part of a commit list.
Signed-off-by: Alban Gruin
---
commit.c | 12
commit.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/commit.c b/commit.c
index a5333c7ac6..fcb3e9245f 100644
--- a/commit.c
+++
Until now, name_rev() named every commit it found, even it the name
would ultimately be unused.
This makes name_rev() take a commit_list and check if the commit it wants
to name is part of the list. If it is, the commit is named, and
name_rev() signals to its caller that the name should not be fr
rafasc reported on IRC that on a repository with a lot of branches,
tags, remotes, and commits, name-rev --stdin could use a massive amount
of memory (more than 2GB of RAM) to complete.
This patch series tries to improve name-rev’s memory usage.
There is some improvement that could be done, such
On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin wrote:
> There a condition that will always be false here when name_rev() calls
> itself for the first parent, but it will become useful when name_rev()
> will stop to name commits that are not mentionned in the stdin buffer.
s/mentionned/mentioned/
>
On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin wrote:
> Until now, name_rev() named every commit it found, even it the name
s/even it/even if/
> would ultimately be unused.
> [...]
> Signed-off-by: Alban Gruin
> ---
> diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> @@ -107,12 +107,18 @@ sta
On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin wrote:
> A ref may not be the descendant of all of the commits mentionned in
> stdin. In this case, we want to avoid naming its parents.
s/mentionned/mentioned/
>
> To do this, find_commits_in_strbuf() is created. It returns a raw list
> of all the c
On Fri, Mar 01, 2019 at 12:34:43PM -0500, Todd Zullinger wrote:
> The commit message could probably be worded better, particularly since it's
> forged in your name.
What you have is OK, but I'd have probably written it like this:
-- >8 --
Subject: [PATCH] completion: fix multiple command removal
Hi Eric,
Le 01/03/2019 à 19:05, Eric Sunshine a écrit :
> On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin wrote:
> -%<-
> Minor: It would probably be more efficient to check if the count is 0
> first, and only search the list if not.
>
> By the way, how big is 'commits' likely to get? Will the linea
On Fri, Mar 1, 2019 at 12:35 PM Todd Zullinger wrote:
> 6532f3740b ("completion: allow to customize the completable command
> list", 2018-05-20) added the completion.commands config variable.
> Multiple commands may be added or removed, separated by a space.
>
> Demonstrate the failure of multiple
On Fri, Mar 01, 2019 at 12:34:40PM -0500, Todd Zullinger wrote:
> Jeff King wrote:
> > I can reproduce your problem, though the test you included passes for me
> > even with the current tip of master.
>
> Oh, hrm. I think the issue is that completion.commands needs to be
> set in the global (or
On Fri, Mar 01, 2019 at 07:22:47PM +0100, Alban Gruin wrote:
> Le 01/03/2019 à 19:05, Eric Sunshine a écrit :
> > On Fri, Mar 1, 2019 at 12:50 PM Alban Gruin wrote:
> > -%<-
> > Minor: It would probably be more efficient to check if the count is 0
> > first, and only search the list if not.
> >
On Fri, Mar 01, 2019 at 06:50:20PM +0100, Alban Gruin wrote:
> rafasc reported on IRC that on a repository with a lot of branches,
> tags, remotes, and commits, name-rev --stdin could use a massive amount
> of memory (more than 2GB of RAM) to complete.
>
> This patch series tries to improve name-
On Fri, Mar 01, 2019 at 06:50:21PM +0100, Alban Gruin wrote:
> name_rev() is a recursive function. For each commit, it allocates the
> name of its parents, and call itself. A parent may not use a name for
> multiple reasons, but in any case, the name will not be released. On a
> repository with
On Fri, Mar 01, 2019 at 04:02:22PM +0100, Johannes Schindelin wrote:
> > I think that patch does the write_or_die conversion to handle EPIPE, but
> > it would still need to turn off SIGPIPE for the whole process.
> >
> > So you'd also need to stick a:
> >
> > sigchain_push(SIGPIPE, SIG_IGN);
>
On Fri, Mar 01, 2019 at 01:13:04PM -0400, Brandon Richardson wrote:
> +/*
> + * Use this assertion for callbacks that expect to be called with NONEG,
> + * and require an argument be supplied.
> + */
> +#define BUG_ON_OPT_NEG_NOARG(unset, arg) do { \
I think this general concept is fine. It's a v
Hi Jeff,
Le 01/03/2019 à 19:42, Jeff King a écrit :
> On Fri, Mar 01, 2019 at 06:50:20PM +0100, Alban Gruin wrote:
>
>> rafasc reported on IRC that on a repository with a lot of branches,
>> tags, remotes, and commits, name-rev --stdin could use a massive amount
>> of memory (more than 2GB of RAM
On Fri, Mar 01, 2019 at 08:14:26PM +0100, Alban Gruin wrote:
> > diff --git a/builtin/name-rev.c b/builtin/name-rev.c
> > index f1cb45c227..7aaa86f1c0 100644
> > --- a/builtin/name-rev.c
> > +++ b/builtin/name-rev.c
> > @@ -431,6 +431,8 @@ int cmd_name_rev(int argc, const char **argv, const
> > c
From: Johannes Schindelin
In d85b0dff72 (Makefile: use `find` to determine static header
dependencies, 2014-08-25), we switched from a static list of header
files to a dynamically-generated one, asking `find` to enumerate them.
Back in those days, we did not use `$(LIB_H)` by default, and many a
I noticed this quite a bit of time ago, but did not get a chance to look
into it in detail: all of a sudden, make started really slowly over here.
The culprit turned out to be a find call, which was in the Makefile for
ages, so I was puzzled why it only caused problems recently.
After some diggin
On Fri, Mar 01, 2019 at 01:22:52PM -0500, Eric Sunshine wrote:
> On Fri, Mar 1, 2019 at 12:35 PM Todd Zullinger wrote:
> > 6532f3740b ("completion: allow to customize the completable command
> > list", 2018-05-20) added the completion.commands config variable.
> > Multiple commands may be added or
On Fri, Mar 1, 2019 at 2:10 PM Jeff King wrote:
> On Fri, Mar 01, 2019 at 01:13:04PM -0400, Brandon Richardson wrote:
> > + if((!unset) && (!arg)) \
> > + BUG("option callback does not expect negation and requires an
> > argument"); \
Peff didn't highlight this, but compare your
On Fri, Mar 01, 2019 at 11:57:46AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> In d85b0dff72 (Makefile: use `find` to determine static header
> dependencies, 2014-08-25), we switched from a static list of header
> files to a dynamically-generated one, asking `find` to enumerate them.
>
On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
> > However, as of ebb7baf02f (Makefile: add a hdr-check target,
> > 2018-09-19), $(LIB_H) is part of a global rule and therefore must be
> > expanded. Meaning: this `find` command has to be run upon every
> > `make` invocation. In the pre
SZEDER Gábor wrote:
> On Fri, Mar 01, 2019 at 01:22:52PM -0500, Eric Sunshine wrote:
>> On Fri, Mar 1, 2019 at 12:35 PM Todd Zullinger wrote:
>>> 6532f3740b ("completion: allow to customize the completable command
>>> list", 2018-05-20) added the completion.commands config variable.
>>> Multiple c
On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
> The one thing we do lose, though, is make's parallelization. It would
> probably be possible to actually shove this into a sub-make which
> defined the hdr-check rules, but I don't know how complicated that would
> become.
This seems to
Jeff King wrote:
> On Fri, Mar 01, 2019 at 12:34:40PM -0500, Todd Zullinger wrote:
>
>> Jeff King wrote:
>>> I can reproduce your problem, though the test you included passes for me
>>> even with the current tip of master.
>>
>> Oh, hrm. I think the issue is that completion.commands needs to be
On Fri, Mar 01, 2019 at 05:15:51PM -0500, Todd Zullinger wrote:
> Hmm. The comments in list_cmds_by_config() made me wonder
> if not using a local repo config was intentional:
>
> /*
> * There's no actual repository setup at this point (and even
> * if there is, we don'
Invocations of 'git config ' print a trailing newline after
writing the value assigned to the given configuration variable.
This has an unexpected interaction with 63e2a0f8e9 (builtin/config:
introduce `color` type specifier, 2018-04-09), which causes a newline to
be printed after a color's ANSI e
On Sat, Mar 2, 2019 at 6:08 AM Jeff King wrote:
>
> On Fri, Mar 01, 2019 at 05:15:51PM -0500, Todd Zullinger wrote:
>
> > Hmm. The comments in list_cmds_by_config() made me wonder
> > if not using a local repo config was intentional:
> >
> > /*
> > * There's no actual repository
Todd Zullinger writes:
> Hmm. The comments in list_cmds_by_config() made me wonder
> if not using a local repo config was intentional:
>
> /*
> * There's no actual repository setup at this point (and even
> * if there is, we don't really care; only global config
>
Hi,
Junio C Hamano wrote:
> Todd Zullinger writes:
>
>> Hmm. The comments in list_cmds_by_config() made me wonder
>> if not using a local repo config was intentional:
>>
>> /*
>> * There's no actual repository setup at this point (and even
>> * if there is, we don't re
On Fri, Mar 1, 2019 at 2:09 PM Jeff King wrote:
> I think you want an "OR". Or even separate conditions, since really this
> is just implying OPT_NEG(). In fact, you could implement and explain it
> like this:
>
> diff --git a/parse-options.h b/parse-options.h
> index 14fe32428e..d46f89305c 100644
Hi Eric,
On Fri, Mar 1, 2019 at 3:53 PM Eric Sunshine wrote:
> Note, in particular how Peff used !(arg) rather than (!arg) in your
> patch. This distinction is subtle but important enough to warrant
> being called out. The reason that Peff did it this way (the _correct_
> way) is that, as a macro
On Fri, Mar 01, 2019 at 09:40:12PM -0500, Todd Zullinger wrote:
> Hi,
>
> Junio C Hamano wrote:
> > Todd Zullinger writes:
> >
> >> Hmm. The comments in list_cmds_by_config() made me wonder
> >> if not using a local repo config was intentional:
> >>
> >> /*
> >> * There's no ac
On Fri, Mar 01, 2019 at 06:43:26PM +0530, Rohit Ashiwal wrote:
> >
> > Simple things do not need that many letters to tell ;-) The
> > suggestion of 72 is about the maximum.
> >
>
> Totally agree on this!
>
I was bikeshedding the patch and mentioned that the commit message body
is usually wrapp
54 matches
Mail list logo
