Hi Junio,
Please pull the following l10n updates for Git 2.23.0.
The following changes since commit 2e27de94d485a6da0c8e264c165e55100f1a13a8:
Git 2.23-rc2 (2019-08-09 10:15:39 -0700)
are available in the Git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.23.0-rnd2
for you to
It is my pleasure to inform you that after our brief meeting this
morning with the Board of Directors WU we have concluded to release
your outstanding payments worth $1.5 Million USD through Western Union
Service.
Therefore be advise to contact the WU office in charge of your
payments with the bel
Not sure if this is the same thing or not but I found this:
https://github.com/tibirna/qgit
It looks to be v2.6. Maybe this might be of use?
Cheers,
Ed Dyer
Associate DevOps Engineer
Alliance Data Retail Services
3075 Loyalty Circle, Columbus OH 43219
Office: 614-944-3923| Mobile: 614-432-3862
Emily Shaffer writes:
> I think comparing this habit to the .gitignore isn't quite fair -
> .gitignore tells me I forgot to add my new command binary to it, when I
> run `git status` to see what I need to add to my commit with new
> command.
That is why I said that we need to actively work on, i
Matheus Tavares Bernardino writes:
>> Thanks. Or we could just go the lazier route. A new stable release
>> would happen within a day or two, and then in a week or so after that,
>> the tip of 'next' gets rewound and rebuilt on top of it. We can
>> discard the older copy and replace with the n
Elijah Newren writes:
> Now, a manual merge of these files gives no conflicts, which surprises me:
>
> $ git merge-file ours base theirs; echo $?
> 0
Indeed that is surprising.
> -- 8< --
> Subject: checkout: remove duplicate code
>
> Both commit a7256debd4b6 ("checkout.txt: note about losi
On Thu, Aug 15, 2019 at 10:01:04PM -0400, Derrick Stolee wrote:
> Here is today's test coverage report.
Are the scripts you use to generate these available somewhere?
I think it's useful to look at uncovered code, but I often struggle to
figure out whether the parts attached to my name are relev
On Fri, Aug 16, 2019 at 02:11:03PM -0400, Jeff King wrote:
> if (opts->ignore_whitespace) {
> struct strbuf buf = STRBUF_INIT;
>
> if (strategy_opts)
> strbuf_addstr(&buf, strategy_opts);
>
> strbuf_add
On Thu, Aug 15, 2019 at 03:03:03PM -0700, Elijah Newren wrote:
> The problematic merge was commit 4a3ed2bec603 ("Merge branch
> 'nd/checkout-m'", 2019-04-25), but redoing that merge produces no merge
> conflicts. This can be seen at the individual file level with the
> following:
> [...]
> I'm no
On Fri, Aug 16, 2019 at 09:41:41AM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > I think comparing this habit to the .gitignore isn't quite fair -
> > .gitignore tells me I forgot to add my new command binary to it, when I
> > run `git status` to see what I need to add to my commit w
Yay! Feel free to tweak and/or butcher the wording, I won't be offended :)
-Original Message-
From: Torsten Bögershausen [mailto:tbo...@web.de]
Sent: Friday, August 16, 2019 12:20 AM
To: Yagnatinsky, Mark
Cc: 'Junio C Hamano' ; 'git@vger.kernel.org'
Subject: Re: suggestion for improve
On Fri, Aug 16, 2019 at 9:51 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Now, a manual merge of these files gives no conflicts, which surprises me:
> >
> > $ git merge-file ours base theirs; echo $?
> > 0
>
> Indeed that is surprising.
>
> > -- 8< --
> > Subject: checkout: remove
Elijah Newren writes:
> There are lots of options that callers can set, yet most have a limited
> range of valid values, some options are meant for output (e.g.
> opt->obuf, which is expected to start empty), and callers are expected
> to not set opt->priv. Add several sanity checks to ensure ca
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 647b1f25c3..bc0da608c4 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -3620,6 +3620,29 @@ static int merge_start(struct merge_options *opt,
> struct tree *head)
> ...
> + assert(opt->buffer_output >= 0 && opt->buffe
Jiang Xin writes:
> Hi Junio,
>
> Please pull the following l10n updates for Git 2.23.0.
>
> The following changes since commit 2e27de94d485a6da0c8e264c165e55100f1a13a8:
>
> Git 2.23-rc2 (2019-08-09 10:15:39 -0700)
>
> are available in the Git repository at:
>
> git://github.com/git-l10n/git-
Hi Emily,
On Thu, 15 Aug 2019, Emily Shaffer wrote:
> On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
> >
> > On Thu, 15 Aug 2019, Derrick Stolee wrote:
> >
> > > On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > > > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > > > new
On Thu, Aug 01, 2019 at 02:35:43AM +0800, 16657101...@163.com wrote:
> > So I actually think the best path forward is just always refreshing when
> > we take the lock, something like:
> >
> > Ultimately the best solution there is to move to a better format (like
> > the reftables proposal).
>
>
The latest feature release Git v2.23.0 is now available at the
usual places. It is comprised of 505 non-merge commits since
v2.22.0, contributed by 77 people, 26 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
Elijah Newren writes:
> We always want our conflict hunks to be labelled so that users can know
> where each came from. The previous commit fixed the one caller in the
> codebase which was not setting opt->ancestor (and thus not providing a
> label for the "merge base" conflict hunk in diff3-sty
On Thu, Aug 15, 2019 at 02:40:50PM -0700, Elijah Newren wrote:
> diff --git a/merge-recursive.c b/merge-recursive.c
> static void merge_finalize(struct merge_options *opt)
> {
> flush_output(opt);
> - if (!opt->call_depth && opt->buffer_output < 2)
> + if (!opt->priv->call_depth &&
Thanks, a bunch Junio! :)
On 14:00 Fri 16 Aug 2019, Junio C Hamano wrote:
The latest feature release Git v2.23.0 is now available at the
usual places. It is comprised of 505 non-merge commits since
v2.22.0, contributed by 77 people, 26 of which are new faces.
The tarballs are found at:
ht
Elijah Newren writes:
> @@ -3507,6 +3507,11 @@ int merge_recursive(struct merge_options *opt,
> struct commit *merged_common_ancestors;
> struct tree *mrtree;
> int clean;
> + int num_merge_bases;
> + struct strbuf merge_base_abbrev = STRBUF_INIT;
> +
> + if (!opt->c
Hello
My name Mrs. Ann Johnson from UK,I am a dying woman who had decided to
donate what I have left to you. I am 59 years old and was diagnosed of ovarian
cancer about 2 years ago immediately after the death of my husband, who had
left me with everything he worked for. I have decided to dona
Elijah Newren writes:
> write_tree_from_memory() appeared to be a merge-recursive special that
> basically duplicated write_index_as_tree(). The two have a different
> signature, but the bigger difference was just that write_index_as_tree()
> would always unconditionally read the index off of di
On Fri, Aug 16, 2019 at 12:52 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > There are lots of options that callers can set, yet most have a limited
> > range of valid values, some options are meant for output (e.g.
> > opt->obuf, which is expected to start empty), and callers are expec
On Fri, Aug 16, 2019 at 12:59 PM Junio C Hamano wrote:
>
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 647b1f25c3..bc0da608c4 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -3620,6 +3620,29 @@ static int merge_start(struct merge_options *opt,
> > struct t
Elijah Newren writes:
> static inline int merge_detect_rename(struct merge_options *opt)
> {
> - return opt->merge_detect_rename >= 0 ? opt->merge_detect_rename :
> - opt->diff_detect_rename >= 0 ? opt->diff_detect_rename : 1;
> + return (opt->detect_renames != -1) ? opt->de
Elijah Newren writes:
> merge_options has several internal fields that should not be set or read
> by external callers. This just complicates the API. Move them into an
> opaque merge_options_internal struct that is defined only in
> merge-recursive.c and keep these out of merge-recursive.h.
>
Hi All,
I do not know whether this would be a good enhancement or micro project for
someone (maybe me) to take on, but I'm wondering whether it might be a good
idea to provide an option to hash-object to select the signature being
computed. The use case begins when someone computes an object signa
On Fri, Aug 16, 2019 at 2:33 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > @@ -3507,6 +3507,11 @@ int merge_recursive(struct merge_options *opt,
> > struct commit *merged_common_ancestors;
> > struct tree *mrtree;
> > int clean;
> > + int num_merge_bases;
> > +
On Fri, Aug 16, 2019 at 3:01 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > write_tree_from_memory() appeared to be a merge-recursive special that
> > basically duplicated write_index_as_tree(). The two have a different
> > signature, but the bigger difference was just that write_index
On Fri, Aug 16, 2019 at 3:14 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > static inline int merge_detect_rename(struct merge_options *opt)
> > {
> > - return opt->merge_detect_rename >= 0 ? opt->merge_detect_rename :
> > - opt->diff_detect_rename >= 0 ? opt->diff_det
On Fri, Aug 16, 2019 at 2:19 PM SZEDER Gábor wrote:
>
> On Thu, Aug 15, 2019 at 02:40:50PM -0700, Elijah Newren wrote:
> > diff --git a/merge-recursive.c b/merge-recursive.c
>
> > static void merge_finalize(struct merge_options *opt)
> > {
> > flush_output(opt);
> > - if (!opt->call_de
The Linux kernel receives many patches to the devicetree files each
release. The hunk header for those patches typically show nothing,
making it difficult to figure out what node is being modified without
applying the patch or opening the file and seeking to the context. Let's
add a builtin 'dts' p
Elijah Newren writes:
> If the only possible values are 0 and 1, I can either add assertions
> to check that at run time, or make the compiler check it for us by
> confining its value to a single bit. A compile-time check seems more
> robust...
Sure, as long as they can catch assignments (e.g.
Elijah Newren writes:
> At the end of this series, the "merge-recursive: add sanity checks for
> relevant merge_options" commit adds some assertions that would fail if
> someone passed such a value, regardless of whether this patch was
> included or not. (Are we worried about people having such
Having read Dscho's response after already writing this reroll, I think
it is a compelling case to rewrite as a C builtin, although I'm worried
a little about the best way to continue to call porcelain commands to
protect against bitrot.
Regardless, I think the proof of concept in patch 2/2 still
Add a new step to the build to generate a whitelist of git-config
variables which are appropriate to include in the output of
git-bugreport. New variables can be added to the whitelist by annotating
their documentation in Documentation/config with the line
"// bugreport-include".
Some configs are
Make it easier for users who encounter a bug to send a report by
collecting some state information, intended to be viewed by humans
familiar with Git.
Teach Git how to prompt the user for a good bug report: reproduction
steps, expected behavior, and actual behavior. Also, teach Git to write
down i
+Frank (me)
On 8/16/19 3:56 PM, Stephen Boyd wrote:
> The Linux kernel receives many patches to the devicetree files each
> release. The hunk header for those patches typically show nothing,
> making it difficult to figure out what node is being modified without
> applying the patch or opening the
On 2019-08-16 at 22:22:17, Randall S. Becker wrote:
> Hi All,
>
> I do not know whether this would be a good enhancement or micro project for
> someone (maybe me) to take on, but I'm wondering whether it might be a good
> idea to provide an option to hash-object to select the signature being
> com
Hello!
I am a representative of the ChaosCC hacker group.
In the period from 23/06/2019 to 11/08/2019 we got access to your account
git@vger.kernel.org by hacking one of the domain.com mail servers.
Your pass for above account on moment of hack was: bread4u2d
You already changed the password?
S
Hello!
I am a representative of the ChaosCC hacker group.
In the period from 23/06/2019 to 11/08/2019 we got access to your account
git@vger.kernel.org by hacking one of the domain.com mail servers.
Your pass for above account on moment of hack was: 28121971
You already changed the password?
S
My Sincere Greetings,
I am Mrs Yvonne D Balakiwal, I decided to donate what I have to you for
investment towards the good work of charity organization, and also to help the
motherless and the less privileged ones and to carry out a charitable works in
your Country and around the World on my Be
44 matches
Mail list logo
