On Fri, Jul 20, 2018 at 7:28 AM Jeff King wrote:
>
> On Thu, Jul 19, 2018 at 04:11:01PM -0700, Elijah Newren wrote:
>
> > Looking at the output from Peff's instrumentation elsewhere in this
> > thread, I see a lot of lines like
> >mismatched get: 32889efd307c7be376da9e3d45a78305f14ba73a = (,
On Fri, Jul 20, 2018 at 01:28:29AM -0400, Jeff King wrote:
> @@ -162,8 +166,10 @@ struct object_entry *packlist_alloc(struct packing_data
> *pdata,
>
> if (!pdata->in_pack_by_idx)
> REALLOC_ARRAY(pdata->in_pack, pdata->nr_alloc);
> +
On Thu, Jul 19, 2018 at 04:11:01PM -0700, Elijah Newren wrote:
> Looking at the output from Peff's instrumentation elsewhere in this
> thread, I see a lot of lines like
>mismatched get: 32889efd307c7be376da9e3d45a78305f14ba73a = (, 28)
> Does that mean it was reading the array when it wasn't
On Thu, Jul 19, 2018 at 3:26 PM, SZEDER Gábor wrote:
> But how do some of these messages end up on the test script's stderr,
> why don't we get them from all five tests, and why do they come from
> different file/line locations?
Thanks for the detailed explanation.
Signed-off-by: Eric Rannaud
Hi Everyone,
I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
the following when building from sources. This appears to be a new
issue. It was not present in 2.17.1.
gmake: *** No rule to make target `git-daemon'. Stop.
gmake: *** Waiting for unfinished jobs
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Contrast this with memcpy(). This is on Microsoft's SDL banned list[1],
> but I think it's silly for it to be. I would never add it to this list.
I forgot my footnote, which was going to be:
I'm bringing up that list not because I
On Thu, Jul 19, 2018 at 03:46:08PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > For enforcement, we can rely on the compiler and just
> > introduce code which breaks compilation when it sees these
> > functions. This has a few advantages:
> >
> > 1. We know it's run as part of a
On Thu, Jul 19, 2018 at 05:59:47PM -0400, Eric Sunshine wrote:
> > The one I brainstormed (but forgot to mention) is that it might be
> > possible for a platform to have strcpy as a macro already? In which case
> > we'd need to #undef it or risk a compilation error (even if the macro
> > isn't
On Thu, Jul 19, 2018 at 02:47:35PM -0700, Stefan Beller wrote:
> > But that may be overly paranoid. Once upon a time there was some rules
> > lawyering around CodingGuidelines, but I think that was successfully
> > shut down and hasn't reared its head for several years.
>
> Heh; My preference
On July 19, 2018 6:46 PM, Junio wrote:
> Jeff King writes:
>
> > For enforcement, we can rely on the compiler and just introduce code
> > which breaks compilation when it sees these functions. This has a few
> > advantages:
> >
> > 1. We know it's run as part of a build cycle, so it's
> >
On Thu, Jul 19, 2018 at 11:24 AM, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 07:31:35PM +0200, Duy Nguyen wrote:
>> On Thu, Jul 19, 2018 at 01:23:58PM -0400, Jeff King wrote:
>> > On Thu, Jul 19, 2018 at 09:42:00AM -0700, Elijah Newren wrote:
>> >
>> > > Thanks for the quick turnaround.
Jeff King writes:
> For enforcement, we can rely on the compiler and just
> introduce code which breaks compilation when it sees these
> functions. This has a few advantages:
>
> 1. We know it's run as part of a build cycle, so it's
> hard to ignore. Whereas an external linter is an extra
On Thu, Jul 19, 2018 at 3:38 PM Junio C Hamano wrote:
> > If the given object refers to a blob, it will be described as
> > :,
> > such that the blob can be found at in the , which itself
> > describes the first commit in which this blob occurs in a reverse
> > revision walk from HEAD.
>
> You
Stefan Beller writes:
> On Thu, Jul 19, 2018 at 2:02 PM Lars Schneider
> wrote:
>>
>> Hi,
>>
>> I have a blob hash and I would like to know what commit referenced
>> this blob first in a given Git repo.
>
> git describe
>
> If the given object refers to a blob, it will be described as
> :,
>
SZEDER Gábor writes:
>> Forgetting the code in git-sh-setup, are we?
>>
>> git_dir_init() rather specifically set GIT_DIR to the absolute path, and
>> since that variable is already exported, the `exec` commands launched via
>> `git-rebase--interactive` all saw it.
>>
>> That is the reason why
Henning Schild writes:
> Looking at "what is cooking" i assume i should not add/fold this to/in
> the serien anymore. So it comes as a separate patch on top.
Thanks. I only said:
I think this round is mostly ready, except for a minor nit in the
last step. I do not mind merging this
The five new tests added to 't9300-fast-import.sh' in 30e215a65c
(fast-import: checkpoint: dump branches/tags/marks even if
object_count==0, 2017-09-28), all with the prefix "V:" in their test
description, run 'git fast-import' in the background and then 'kill'
it as part of a 'test_when_finished'
On Wed, Jul 18, 2018 at 02:18:44PM +0200, Johannes Schindelin wrote:
> On Sat, 14 Jul 2018, brian m. carlson wrote:
> > I will say that at cPanel, we have a configuration where end users can
> > end up inside a mount namespace without /proc (depending on the
> > preferences of the administrator).
When running the same reproduction script as the previous patch,
it turns out the stack is too small, which can be easily avoided.
Signed-off-by: Stefan Beller
---
xdiff/xhistogram.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/xdiff/xhistogram.c
> On Mon, 16 Jul 2018, 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 fixed
>
On Thu, Jul 19, 2018 at 5:27 PM Jeff King wrote:
> On Thu, Jul 19, 2018 at 05:11:15PM -0400, Eric Sunshine wrote:
> > On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> > > + * This header lists functions that have been banned from our code base,
> > > + * because they're too easy to misuse (and
[please reply inline rather than top-posting]
On Thu, Jul 19, 2018 at 5:11 PM Evgeny Cherpak wrote:
> It seems this code placed at the end of the file, after getcommits() does the
> trick:
>
> if {[tk windowingsystem] eq "aqua"} {
> set openscript [format {
> open -a
On Thu, Jul 19, 2018 at 02:19:34PM -0700, Stefan Beller wrote:
> > I have a blob hash and I would like to know what commit referenced
> > this blob first in a given Git repo.
>
> git describe
>
> If the given object refers to a blob, it will be described as
> :,
> such that the blob can be
On Thu, Jul 19, 2018 at 2:32 PM Jeff King wrote:
>
> On Thu, Jul 19, 2018 at 02:15:54PM -0700, Stefan Beller wrote:
>
> > > Documentation/CodingGuidelines | 3 +++
> >
> > I'd prefer to not add more text to our documentation
> > (It is already long and in case you run into this problem
> > the
> On Jul 19, 2018, at 11:19 PM, Stefan Beller wrote:
>
> On Thu, Jul 19, 2018 at 2:02 PM Lars Schneider
> wrote:
>>
>> Hi,
>>
>> I have a blob hash and I would like to know what commit referenced
>> this blob first in a given Git repo.
>
> git describe
>
> If the given object refers to
On Thu, Jul 19, 2018 at 11:12:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Jul 19 2018, Jeff King wrote:
>
> > Since this use of strncpy was verified by manual inspection
> > and since it doesn't trigger the automated ban-list, we're
> > better off leaving it to keep our divergence
On Thu, Jul 19, 2018 at 02:15:54PM -0700, Stefan Beller wrote:
> > Documentation/CodingGuidelines | 3 +++
>
> I'd prefer to not add more text to our documentation
> (It is already long and in case you run into this problem
> the error message is clear enough IMHO)
I'm fine with that too. I
On Thu, Jul 19, 2018 at 05:11:15PM -0400, Eric Sunshine wrote:
> On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> > [...]
> > Let's start by banning strcpy() and sprintf(). It's not
> > impossible to use these correctly, but it's easy to do so
> > incorrectly, and there's always a better
On Thu, Jul 19, 2018 at 2:02 PM Lars Schneider wrote:
>
> Hi,
>
> I have a blob hash and I would like to know what commit referenced
> this blob first in a given Git repo.
git describe
If the given object refers to a blob, it will be described as
:,
such that the blob can be found at in the ,
On Thu, Jul 19, 2018 at 1:39 PM Jeff King wrote:
>
> There are a few standard C functions (like strcpy) which are
> easy to misuse. We generally discourage these in reviews,
> but we haven't put advice in CodingGuidelines, nor provided
> any automated enforcement. The latter is especially
>
On Thu, Jul 19 2018, Jeff King wrote:
> Since this use of strncpy was verified by manual inspection
> and since it doesn't trigger the automated ban-list, we're
> better off leaving it to keep our divergence from glibc
> minimal.
FWIW it's s/glibc/gawk/. It's originally from glibc, but gawk
It seems this code placed at the end of the file, after getcommits() does the
trick:
if {[tk windowingsystem] eq "aqua"} {
set openscript [format {
open -a \"$(ps -p %d -o comm=)\"
} [pid] ]
exec osascript -e [format {
do shell script "%s"
On Thu, Jul 19, 2018 at 4:39 PM Jeff King wrote:
> [...]
> Let's start by banning strcpy() and sprintf(). It's not
> impossible to use these correctly, but it's easy to do so
> incorrectly, and there's always a better option.
> [...]
> Signed-off-by: Jeff King
> ---
> diff --git a/banned.h
my name is Mrs. patience benkirane I am a canadian, a Senior NATO
Officer and also a conventional Military Officer deployed by the UN to
Syria , and I have been here in Syria for 5years and i am a single
mother i have one child he is disturbed me to resign from Military
work , I got your contact
Hi,
I have a blob hash and I would like to know what commit referenced
this blob first in a given Git repo.
I could iterate through all commits sorted by date (or generation
number) and then recursively search in the referenced trees until
I find my blob. I wonder, is this the most efficient
Johannes Schindelin writes:
> On Tue, 17 Jul 2018, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I'm OK with having a partial fix, or one that fixes immediate pain
>> > without doing a big cleanup, as long as it doesn't make anything _worse_
>> > in a user-visible way. And that's really
The strncpy() function is less horrible than strcpy(). But
it's still pretty easy to misuse because of its funny
termination semantics. And we already have a ready-made
alternative in strlcpy. So let's ban it, to make sure uses
don't creep in.
Note that there is one instance of strncpy in
There are a few standard C functions (like strcpy) which are
easy to misuse. We generally discourage these in reviews,
but we haven't put advice in CodingGuidelines, nor provided
any automated enforcement. The latter is especially
important because it's more consistent, and it can often
save a
This is a patch series to address the discussion in the thread at:
https://public-inbox.org/git/20180713204350.ga16...@sigill.intra.peff.net/
Basically, the question was: can we declare strcpy banned and have a
linter save us the trouble of finding it in review. The answer is yes,
the compiler
Hello Dear,
We are global financial provider, led by a dynamic Investment team. We are
providing corporate and Personal Loan at 3% Interest Rate
for a duration of 2 to 20 Years.
We also pay 1% commission to brokers/person, who introduce project owners
for finance or other opportunities.
Contact
Hi Junio,
On Mon, 16 Jul 2018, 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 fixed
> >
Duy Nguyen writes:
> It turns out gettext is smart! I got this in git.pot
>
> msgid "timestamp too large for this system: %"
OK.
Junio C Hamano writes:
> Imagine that you create a delta and set its size (which happens to
> fit in the entry) and then create another whose size does not fit in
> the entry. How does oe_delta_size() know not to look at
> pack->delta_size[] and instead look at e->delta_size_ when it wants
> to
Duy Nguyen writes:
> @@ -330,20 +330,27 @@ static inline void oe_set_size(struct packing_data
> *pack,
> static inline unsigned long oe_delta_size(struct packing_data *pack,
> const struct object_entry *e)
> {
> - if (e->delta_size_valid)
> + if
On Thu, Jul 19, 2018 at 08:24:42PM +0200, Duy Nguyen wrote:
> > > Looking at that output, my _guess_ is that we somehow end up with a
> > > bogus delta_size value and write out a truncated entry. But I couldn't
> > > reproduce the issue with smaller test cases.
> >
> > Could it be a race
How are you doing today?
We have not heard from you yet. Are you still interested in our photo
retouching services?
We mainly do:
e-commerce products photo retouching
jewelry photos retouching
model beauty/skin retouching
wedding photo editing
also photo cutting out, clipping path
You may
On Thu, Jul 19, 2018 at 2:48 PM Evgeny Cherpak wrote:
> You have probably heard this by now already, but gitk doesn’t work on macOS
> 10.14 - because it uses Apple Events,
> And apps on 10.14 require user to give them permissions to control other apps
> with Apple Events.
This hasn't been
Ben Peart writes:
> +/*
> + * struct mpmcq_entry is an opaque structure representing an entry in the
> + * queue.
> + */
> +struct mpmcq_entry {
> + struct mpmcq_entry *next;
> +};
> +
> +/*
> + * struct mpmcq is the concurrent queue structure. Members should not be
> + * modified directly.
Stefan Beller writes:
> v6:
> * fixed issues hinted at by Andrei, thanks! (range-diff below)
> * incorporates the new config option, sent separately previously.
Let's declare victory and move to incremental by merging to 'next',
if nobody spots anything more serious than just a missing SP
Wow, thanks.
For me it was enough to configure just one rewrite, because my public github
account is associated with my default key. Note that I added the missing slash
and the username:
git config --global \
url.git@gh-org:theorganization/.insteadOf \
By passing the 'xpp' and 'env' argument directly to the function
'fall_back_to_classic_diff', we eliminate an occurrence of the 'index'
in histogram_diff, which will prove useful in a bit.
While at it, move it up in the file. This will make the diff of
one of the next patches more legible.
Currently if you run
seq 1 10 >one
seq 1 4 10 >two
git diff --no-index --histogram one two
you might run into memory issues. After applying the last patch of this series
you only have to wait a bit (as it doesn't fix run time complexity), but
computes the result with less
This will be useful in the next patch as we'll introduce multiple
callers.
Signed-off-by: Stefan Beller
---
xdiff/xhistogram.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/xdiff/xhistogram.c b/xdiff/xhistogram.c
index 6e20f75fe85..5098b6c5021 100644
---
This fixes a memory issue when recursing a lot, which can be reproduced as
seq 1 10 >one
seq 1 4 10 >two
git diff --no-index --histogram one two
Before this patch, histogram_diff would call itself recursively before
calling free_index, which would mean a lot of memory is
Nguyễn Thái Ngọc Duy writes:
> if (flags & CONNECT_VERBOSE) {
> - fprintf_ln(stderr, "done.");
> - fprintf(stderr, "Connecting to %s (port %s) ... ", host, port);
> + /* TRANSLATORS: this is the end of "Looking up %s ... " */
> +
On Thu, Jul 19, 2018 at 8:26 PM Junio C Hamano wrote:
> > @@ -601,7 +601,7 @@ static void dos_time(timestamp_t *timestamp, int
> > *dos_date, int *dos_time)
> > struct tm *t;
> >
> > if (date_overflows(*timestamp))
> > - die("timestamp too large for this system:
Hi
You have probably heard this by now already, but gitk doesn’t work on macOS
10.14 - because it uses Apple Events,
And apps on 10.14 require user to give them permissions to control other apps
with Apple Events.
Here is what I get when I try running it on my machine with beta 4 installed:
Nguyễn Thái Ngọc Duy writes:
> @@ -149,7 +149,7 @@ static void *get_delta(struct object_entry *entry)
> delta_buf = diff_delta(base_buf, base_size,
> buf, size, _size, 0);
> if (!delta_buf || delta_size != DELTA_SIZE(entry))
> - die("delta
Junio C Hamano writes:
>> @@ -622,7 +626,7 @@ int cmd_config(int argc, const char **argv, const char
>> *prefix)
>> * location; error out even if XDG_CONFIG_HOME
>> * is set and points at a sane location.
>> */
>> -
Nguyễn Thái Ngọc Duy writes:
> - return error("path too long (%d chars, SHA1: %s): %s",
> + return error(_("path too long (%d chars, SHA1: %s): %s"),
> - return error("unsupported file mode: 0%o (SHA1: %s)", mode,
> + return error(_("unsupported
On Thu, Jul 19, 2018 at 07:31:35PM +0200, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 01:23:58PM -0400, Jeff King wrote:
> > On Thu, Jul 19, 2018 at 09:42:00AM -0700, Elijah Newren wrote:
> >
> > > Thanks for the quick turnaround. Unfortunately, I have some bad news.
> > > With this patch, I get
Nguyễn Thái Ngọc Duy writes:
> @@ -256,7 +256,7 @@ static int write_tar_entry(struct archiver_args *args,
> *header.typeflag = TYPEFLAG_REG;
> mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
> } else {
> - return error("unsupported file
Nguyễn Thái Ngọc Duy writes:
> static void check_argc(int argc, int min, int max) {
> if (argc >= min && argc <= max)
> return;
> - error("wrong number of arguments");
> + if (min == max)
> + error("wrong number of arguments, should be %d", min);
> +
On Thu, Jul 19, 2018 at 10:32 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > "git format-patch HEAD^ --color" produces red/green output
> > (like git log would), so I do not see why --color-moved should impact
> > format-patch differently. (i.e. if the user requests format-patch with
>
Hi,
On Tue, 17 Jul 2018, Duy Nguyen wrote:
> On Tue, Jul 17, 2018 at 6:39 PM Duy Nguyen wrote:
> >
> > On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > From: Johannes Schindelin
> > >
> > > While it is true that we never add unreachable commits into
Hi Peff,
On Tue, 17 Jul 2018, Jeff King wrote:
> On Tue, Jul 17, 2018 at 03:15:31PM -0400, Jeff King wrote:
>
> > > - Also trigger `prune_shallow()` when
> > > `--unpack-unreachable=` was passed to `git repack`.
> > > - No need to trigger `prune_shallow()` when `git repack` was called with
>
Good day,
I have a business proposal which I would like to discuss with you
confidentially.
I assisted a certain (Libyan) General by name (Mohammed Hadiya Al-Feitouri) to
secure certain amount of his funds here in the UK, the general who was later
involved in
the Libyan Crisis which claimed
Stefan Beller writes:
> "git format-patch HEAD^ --color" produces red/green output
> (like git log would), so I do not see why --color-moved should impact
> format-patch differently. (i.e. if the user requests format-patch with
> color-moved we can do it, otherwise, when colors are off, we do
On Thu, Jul 19, 2018 at 01:23:58PM -0400, Jeff King wrote:
> On Thu, Jul 19, 2018 at 09:42:00AM -0700, Elijah Newren wrote:
>
> > Thanks for the quick turnaround. Unfortunately, I have some bad news.
> > With this patch, I get the following:
> >
> > $ /usr/bin/time -f 'MaxRSS:%M Time:%e' git gc
On Thu, Jul 19, 2018 at 9:29 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano wrote:
> >>
> >> Stefan Beller writes:
> >>
> >> > diff --git a/Documentation/diff-options.txt
> >> > b/Documentation/diff-options.txt
> >> > index
On Thu, Jul 19, 2018 at 09:42:00AM -0700, Elijah Newren wrote:
> Thanks for the quick turnaround. Unfortunately, I have some bad news.
> With this patch, I get the following:
>
> $ /usr/bin/time -f 'MaxRSS:%M Time:%e' git gc --aggressive
> Enumerating objects: 4460703, done.
> Counting objects:
Translate 108 new messages came from git.pot update in 9b7388a85 (l10n:
git.pot: v2.18.0 round 1 (108 new, 14 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 373 +--
1 file changed, 194 insertions(+), 179 deletions(-)
diff --git
On Wed, Jul 18, 2018 at 3:03 PM, Junio C Hamano wrote:
> * en/rebase-i-microfixes (2018-06-27) 3 commits
> (merged to 'next' on 2018-07-11 at d913ca0f77)
> + git-rebase--merge: modernize "git-$cmd" to "git $cmd"
> + Fix use of strategy options with interactive rebases
> + t3418: add
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> I would like to ask you to reinstate the post-rewrite hook, as it still
>> improves the situation over the current one.
>
> Without post-rewrite I seem to be getting correct amlog entries for
> commits created by "git rebase"; do our
On Thu, Jul 19, 2018 at 05:16:42PM +0200, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 07:57:37AM +0200, Duy Nguyen wrote:
> > I thought 2M was generous but I was obviously wrong. I'd like to see
> > the biggest delta size in this pack and whether it's still reasonable
> > to increase
On Thu, Jul 19, 2018 at 02:50:16PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I thought of writing a wrapper script to deduce the key from the arguments:
> >
> > g...@github.com git-upload-pack '/theorganization/privaterepo.git'
> >
> > Is this the only option?
>
> Yes, I had a similar
Hi Junio,
On Tue, 17 Jul 2018, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm OK with having a partial fix, or one that fixes immediate pain
> > without doing a big cleanup, as long as it doesn't make anything _worse_
> > in a user-visible way. And that's really my question: is pruning
On Thu, Jul 19, 2018 at 03:24:54PM +0300, Basin Ilya wrote:
> I have two github accounts, one is for my organization and I want git
> to automatically choose the correct ssh `IdentityFile` based on the
> clone URL:
>
> g...@github.com:other/publicrepo.git
>~/.ssh/id_rsa
>
On Thu, Jul 19, 2018 at 8:16 AM, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 07:57:37AM +0200, Duy Nguyen wrote:
>> I thought 2M was generous but I was obviously wrong. I'd like to see
>> the biggest delta size in this pack and whether it's still reasonable
>> to increase OE_DELTA_SIZE_BITS. But
Hi Stolee,
On Wed, 18 Jul 2018, Derrick Stolee wrote:
> On 7/18/2018 1:01 PM, Junio C Hamano wrote:
> > No, fixing a tool that throws such a harder-to-read patch series in
> > reader's mailbox is *not* something I'd spend my primary focus on,
> > especially when many contributors are perfectly
Eric Sunshine writes:
> I guess the two fixup!'s were meant to be squashed (and it's probably
> too late to do so now?).
I guess so. That is what we get from trying to be nice to reduce
the number of iterations and cheating by short-circuitting the
process X-<.
Hi Peff,
On Wed, 18 Jul 2018, Jeff King wrote:
> On Wed, Jul 18, 2018 at 02:23:11PM +0200, Johannes Schindelin wrote:
>
> > > Yeah, they're out of order in mutt's threaded display. And the
> > > back-dating means there's a much higher chance of them getting blocked
> > > as spam (e.g., some of
Stefan Beller writes:
>> It seems to pass its own self-tests standalone, but seems to break
>> horribly when merged to 'pu'.
>
> It actually breaks combined with sb/submodule-core-worktree :-(
> as that introduces another user of $name in git-submodule.sh
> which we eliminate in this series.
Hi Junio,
On Wed, 18 Jul 2018, Junio C Hamano wrote:
> That won't stop those who want to improve the tool. But I'd wish
> those who want to make Git better spend their time on making Git,
> over making GitGitGadget, better.
And I'd wish that you would not make this task harder by refusing to
Stefan Beller writes:
> On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > diff --git a/Documentation/diff-options.txt
>> > b/Documentation/diff-options.txt
>> > index 143acd9417e..8da7fed4e22 100644
>> > --- a/Documentation/diff-options.txt
>> > +++
On Thu, Jul 19, 2018 at 5:27 PM Elijah Newren wrote:
>
> On Wed, Jul 18, 2018 at 10:41 PM, Duy Nguyen wrote:
> > On Thu, Jul 19, 2018 at 12:51 AM Elijah Newren wrote:
> >>
> >> I had a user report some poor behavior of 'git gc --aggressive' on a
> >> certain repo (which I sadly cannot share).
On Wed, Jul 18, 2018 at 10:41 PM, Duy Nguyen wrote:
> On Thu, Jul 19, 2018 at 12:51 AM Elijah Newren wrote:
>>
>> I had a user report some poor behavior of 'git gc --aggressive' on a
>> certain repo (which I sadly cannot share). Turns out that on this
>> repo, this operation takes about 60%
On Thu, Jul 19, 2018 at 07:57:37AM +0200, Duy Nguyen wrote:
> I thought 2M was generous but I was obviously wrong. I'd like to see
> the biggest delta size in this pack and whether it's still reasonable
> to increase OE_DELTA_SIZE_BITS. But if it's very close to 4GB limit
> then we could just
On Thu, Jul 19, 2018 at 02:14:09PM +0200, Henning Schild wrote:
> Unsetting the varibale for good can have unwanted effects for new
s/varibale/variable
> tests added in the future It also meant we needed to hardcode the
s/future/&.
> value for "user.signingkey".
> Move the unset into a
On 07/19/2018 06:52 PM, Sitaram Chamarty wrote:
> On Thu, Jul 19, 2018 at 03:24:54PM +0300, Basin Ilya wrote:
>> Hi.
>>
>> I have two github accounts, one is for my organization and I want git to
>> automatically choose the correct ssh `IdentityFile` based on the clone URL:
>>
>>
On Thu, Jul 19, 2018 at 03:24:54PM +0300, Basin Ilya wrote:
> Hi.
>
> I have two github accounts, one is for my organization and I want git to
> automatically choose the correct ssh `IdentityFile` based on the clone URL:
>
> g...@github.com:other/publicrepo.git
>~/.ssh/id_rsa
>
On Thu, Jul 19 2018, Basin Ilya wrote:
> Hi.
>
> I have two github accounts, one is for my organization and I want git to
> automatically choose the correct ssh `IdentityFile` based on the clone URL:
>
> g...@github.com:other/publicrepo.git
>~/.ssh/id_rsa
>
Hi.
I have two github accounts, one is for my organization and I want git to
automatically choose the correct ssh `IdentityFile` based on the clone URL:
g...@github.com:other/publicrepo.git
~/.ssh/id_rsa
g...@github.com:theorganization/privaterepo.git
Looking at "what is cooking" i assume i should not add/fold this to/in
the serien anymore. So it comes as a separate patch on top.
Henning
Am Thu, 19 Jul 2018 14:14:09 +0200
schrieb Henning Schild :
> Unsetting the varibale for good can have unwanted effects for new
> tests added in the future
Unsetting the varibale for good can have unwanted effects for new
tests added in the future It also meant we needed to hardcode the
value for "user.signingkey".
Move the unset into a subshell, get rid of the hardcoded
"commit...@example.com", and switch the GPG variant to using test_config
just
>>> Sebastian Staudt schrieb am 19.07.2018 um 09:55 in
Nachricht
:
> Hello Ulrich,
>
> if you want to ignore a file in the root of the repository (and only
> there) this is the correct syntax:
>
> /foo
Hi!
Thanks, you are perfectly right: It works, and actually, when read carefully
Thanks for the review.
On Tue, Jul 17, 2018 at 10:33 AM Junio C Hamano wrote:
>
> Samuel Lijin writes:
>
> > diff --git a/wt-status.c b/wt-status.c
> > index 75d389944..4ba657978 100644
> > --- a/wt-status.c
> > +++ b/wt-status.c
> > @@ -718,6 +718,39 @@ static void
On Thu, Jul 19 2018, Timothy Rice wrote:
>> How did you come up with this "./" syntax?
>
> It is a Unix thing: "./" or just "." refers to the current directory.
>
> When calling scripts or programs in the current directory from a Unix
> command line, it is required to refer to them as, say,
On Thu, Jul 19, 2018 at 07:06:57PM +1000, Timothy Rice wrote:
[...]
> Most people do put "." in their PATH for convenience
[...]
IMO this is a gross overstatement: personally, I know of no person using
a Unix-like operation system who does this.
Hi Junio
On 18/07/18 18:17, Junio C Hamano wrote:
> Phillip Wood writes:
>
>>> (I think we had code to do so in "git am"
>>> that was rewritten in C first).
>>
>> The code in builtin/am.c doesn't try to write valid posix shell (if
>> one assumes it is the only consumer of the author script then
1 - 100 of 105 matches
Mail list logo
