ot; &&
>> >> + ln "$bindir/$p" "$execdir/$p" 2>/dev/null ||
>> >> + cp "$bindir/$p" "$execdir/$p" || exit; }
>> >> + done;
>> >> +} &&
>> >> +for p in $list_bindir_git_dashed; do
>> >> + $RM
n
>> "git var" above. Why does this test suspect that somebody in the
>> future may break the expectation that after running 'git add' and/or
>> 'git stash', our committer identity may have been changed, and how
>> would such a breakage happen?
> In previous re
Jeff King writes:
> If you are arguing that even in a repo we should reject "authorname"
> early (just as we would outside of a repo), I could buy that.
Yup, that (and replace 'authorname' with anything that won't work
with missing objects) for consistency was what I meant.
Johannes Schindelin writes:
> Meaning: essentially, `rebase.useBuiltin` was defaulting to `false`, and
> if a user installed Git for Windows with the experimental built-in rebase,
> it was set to `true` in the system config.
Oh, that changes the picture entirely. If that was what was shipped
Hi Junio,
On Fri, 16 Nov 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > The rebase.useBuiltin variable introduced in 55071ea248 ("rebase:
> > start implementing it as a builtin", 2018-08-07) was turned on by
> > default in 5541bd5b8f ("rebase: default to using the builtin
On Fri, Nov 16, 2018 at 02:09:07PM +0900, Junio C Hamano wrote:
> >> I see problems in both directions:
> >>
> >> - sorting by "objectname" works now, but it's marked with SOURCE_OBJ,
> >>and would be forbidden with your patch. I'm actually not sure if
> >>SOURCE_OBJ is accurate; we
On Thu, Nov 15, 2018 at 11:59:45PM -0800, Elijah Newren wrote:
> This is a series of small fixes and features for fast-export and
> fast-import, mostly on the fast-export side.
>
> Changes since v2 (full range-diff below):
> * Dropped the final patch; going to try to use Peff's suggestion of
>
hanged environment variables or configuration since we ran
"git var" above. Why does this test suspect that somebody in the
future may break the expectation that after running 'git add' and/or
'git stash', our committer identity may have been changed, and how
would such a breakage happen?
In
Junio C Hamano writes:
> Slavica Djukic writes:
>
>> +test_expect_failure 'stash works when user.name and user.email are not set'
>> '
>> +git reset &&
>> +git var GIT_COMMITTER_IDENT >expected &&
> ...
> Anyway, we grab the committer ident we use by default during the
> test with this
Junio C Hamano writes:
> Now we start using use-config-only, so unsetting environment
> variables will cause trouble when Git insists on having an
> explicitly configured identities. Makes sense.
>
>> +(
>> +sane_unset GIT_AUTHOR_NAME &&
>> +sane_unset
Slavica Djukic writes:
> +test_expect_failure 'stash works when user.name and user.email are not set' '
> + git reset &&
> + git var GIT_COMMITTER_IDENT >expected &&
All the other existing test pieces in this file calls the expected
result "expect"; is there a reason why this patch
Slavica Djukic writes:
> git-stash.sh | 17 +
> t/t3903-stash.sh | 2 +-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/git-stash.sh b/git-stash.sh
> index 94793c1a9..789ce2f41 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -55,6 +55,20 @@
Jeff King writes:
> On Thu, Nov 15, 2018 at 04:38:44AM -0500, Jeff King wrote:
>
>> Is SOURCE_NONE a complete match for what we want?
>>
>> I see problems in both directions:
>>
>> - sorting by "objectname" works now, but it's marked with SOURCE_OBJ,
>>and would be forbidden with your
On Thu, Nov 15, 2018 at 11:07 PM Junio C Hamano wrote:
> yanke131...@gmail.com writes:
> > * add macOS gettext explanation to get the i18n locale translation take
> > effect in macOS, as the most polular way of gettext
> > install in macOS, the gettext is not linked by default, this commit
Jeff King writes:
> On Wed, Nov 14, 2018 at 11:46:17AM +0100, SZEDER Gábor wrote:
>
>> This patch series should have been marked as v6, but I chose to reset
>> the counter, because:
>>
>> - v5 was sent out way over a year ago [1], and surely everybody has
>> forgotten about it since then
Konstantin Ryabitsev writes:
> On Thu, Nov 15, 2018 at 07:54:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> > I think that if we use the "principle of least surprise," insteadOf
>> > rules shouldn't be applied for git-request-pull URLs.
>>
>> I haven't used request-pull so I don't have much of
yanke131...@gmail.com writes:
> Subject: Re: [[PATCH v2] ] INSTALL: add macOS gettext and sdk header
> explanation to INSTALL
The above should look more like
Subject: [PATCH v2] INSTALL: add macOS ...
> From: out0fmemory
This line is to give information that records who
tation of
> + linkgit:git-rebase[1]. Is `true` by default, which means use
> + the built-in rewrite of it in C.
> ++
> +The C rewrite is first included with Git version 2.20. This option
> +serves an an escape hatch to re-enable the legacy version in case any
> +bugs are
Denton Liu writes:
>> If the current invocation of "git commit" added a scissors line in
>> the buffer to be edited already, and we are adding another one in
>> this function, is it possible that the real problem that somebody
>> else has called wt_status_add_cut_line() before this function is
Josh Steadmon writes:
>> What I was alludding to was a lot simpler, though. An advert string
>> "version=0:version=1" from a client that prefers version 0 won't be
>> !strcmp("version=0", advert) but seeing many strcmp() in the patch
>> made me wonder.
>
> Ah I see. The strcmp()s against
On 2018-11-15, Stefan Beller wrote:
> On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote:
>> Well, currently the submodule config can be disabled in diff_flags by
>> setting override_submodule_config=1. However, I'm thinking it may be
>> simpler to selectively *enable* the submodule config in
On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote:
>
> On 2018-11-15, Stefan Beller wrote:
> > On Wed, Nov 14, 2018 at 10:05 PM Michael Forney
> > wrote:
> >> Looking at ff6f1f564c, I don't really see anything that might be
> >> related to git-add, git-reset, or git-diff, so I'm guessing
> Please have a look at the last 4 patches specifically as they were new in
> the last iteration (but did not receive any comment), as they demonstrate
> and fix a problem that is only exposed when using GIT_TEST_COMMIT_GRAPH=1
> for the test suite.
Thanks. I only reviewed patches 18 and 20-23,
On 2018-11-15, Michael Forney wrote:
> Here is a work-in-progress diff that seems to have the correct
> behavior in all cases I tried.
I was hoping that gmail wouldn't mess with the whitespace, but apparently
it has, sorry about that. Let me try again.
---
builtin/add.c | 1 -
diff-lib.c|
On 2018.11.14 02:00, Jeff King wrote:
> On Tue, Nov 13, 2018 at 07:49:15PM -0500, Jeff King wrote:
>
> > Yes, the packet_read_line_buf() interface will both advance the buf
> > pointer and decrement the length. So if we want to "peek", we have to
> > do so with a copy (there's a peek function if
On 2018-11-15, Stefan Beller wrote:
> On Wed, Nov 14, 2018 at 10:05 PM Michael Forney
> wrote:
>> Looking at ff6f1f564c, I don't really see anything that might be
>> related to git-add, git-reset, or git-diff, so I'm guessing that this
>> only worked before because the submodule config wasn't
On Thu, Nov 15, 2018 at 11:54 AM Jonathan Tan wrote:
>
> > +/*
> > + * Initialize 'out' based on the provided submodule path.
> > + *
> > + * Unlike repo_submodule_init, this tolerates submodules not present
> > + * in .gitmodules. This function exists only to preserve historical
> > behavior,
>
On Wed, Nov 14, 2018 at 10:05 PM Michael Forney wrote:
>
> +bmwill
>
> On 2018-11-14, Michael Forney wrote:
> > On 2018-10-25, Stefan Beller wrote:
> >> I guess reverting that commit is not a good idea now, as
> >> I would expect something to break.
> >>
> >> Maybe looking through the series
Hi Peff,
On Thu, 15 Nov 2018, Jeff King wrote:
> On Thu, Nov 15, 2018 at 05:32:15PM +0100, Johannes Schindelin wrote:
>
> > I cannot claim that I wrapped my head around your explanation or your
> > diff (I am busy trying to prepare Git for Windows' `master` for
> > rebasing to v2.20.0-rc0), but
> +/*
> + * Initialize 'out' based on the provided submodule path.
> + *
> + * Unlike repo_submodule_init, this tolerates submodules not present
> + * in .gitmodules. This function exists only to preserve historical behavior,
> + *
> + * Returns 0 on success, -1 when the submodule is not present.
> I have a git repository which contains a number of submodules that
> refer to external repositories. Some of these repositories need to
> patched in some way, so patches are stored alongside the submodules,
> and are applied when building. This mostly works fine, but causes
> submodules to show
On Thu, Nov 15, 2018 at 07:54:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I think that if we use the "principle of least surprise," insteadOf
> > rules shouldn't be applied for git-request-pull URLs.
>
> I haven't used request-pull so I don't have much of an opinion on this,
> but do you think
On Thu, Nov 15 2018, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Looks like setting url.insteadOf rules alters the output of
> git-request-pull. I'm not sure that's the intended use of insteadOf,
> which is supposed to replace URLs for local use, not to expose them
> publicly (but I may be
Am 15.11.18 um 12:22 schrieb Johannes Schindelin via GitGitGadget:
From: Johannes Schindelin
The MSDN documentation has been superseded by Microsoft Docs (which is
backed by a repository on GitHub containing many, many files in Markdown
format).
Signed-off-by: Johannes Schindelin
---
On Thu, Nov 15, 2018 at 1:59 PM Johannes Schindelin
wrote:
> So yes, we are trying to unlink the `.lock` file, and as far as I can tell
> that
> `unlink()` call comes from the tempfile cleanup asked for by Martin. However,
> as
> we still have a handle open to that file, that call fails.
>
> I
On Thu, Nov 15, 2018 at 05:32:15PM +0100, Johannes Schindelin wrote:
> I cannot claim that I wrapped my head around your explanation or your diff (I
> am
> busy trying to prepare Git for Windows' `master` for rebasing to v2.20.0-rc0),
> but it does fix the problem. Thank you so much!
>
> The
Hi Peff,
On Thu, 15 Nov 2018, Jeff King wrote:
> On Thu, Nov 15, 2018 at 01:57:45PM +0100, Johannes Schindelin wrote:
>
> > > I looked at the test to see if it would pass, but it is not even
> > > checking anything about lockfiles! It just checks that we exit 1 by
> > > returning up the
Hi Peff,
On Thu, 15 Nov 2018, Jeff King wrote:
> On Thu, Nov 15, 2018 at 09:40:38AM +0100, Johannes Schindelin wrote:
>
> > From @chucklu:
> >
> > > my user case is like this :
> > >
> > > When I want to cherr-pick commits from A to G (ABCDEFG), image C and E
> > > are merge commits. Then I
On Thu, Nov 15 2018, sxe...@google.com wrote:
> +Detailed design
> +===
> +Obsolescence information is stored as a graph of meta-commits. A meta-commit
> is
> +a specially-formatted merge commit that describes how one commit was created
> +from others.
> +
> +Meta-commits look like
On Thu, Nov 15, 2018 at 09:48:54AM -0500, Jeff King wrote:
> I don't think "48h" does what you expect either:
>
> $ t/helper/test-date approxidate now
> now -> 2018-11-15 14:43:32 +
>
> $ t/helper/test-date approxidate 48h
> 48h -> 2018-11-15 14:43:34 +
>
> $
On Thu, Nov 15, 2018 at 02:45:28PM +0100, Andreas Krey wrote:
> I've now located why our backup repo shrinks every month:
>
> git gc --prune=2d
>
> doesn't do what I expected, and differs a lot from --prune=48h.
Yeah, it understands "2 days", but not "d" as a unit.
I don't think "48h" does
On Wed, Oct 17, 2018 at 07:39:21AM -0700, Tejun Heo wrote:
> A while ago, I proposed changes to name-rev and describe so that they
> can identify the commits cherry-picked from the one which is being
> shown.
>
>
>
On Thu, Nov 15, 2018 at 01:57:45PM +0100, Johannes Schindelin wrote:
> > I looked at the test to see if it would pass, but it is not even
> > checking anything about lockfiles! It just checks that we exit 1 by
> > returning up the callstack instead of calling die(). And of course it
> > would not
Hi Peff,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Wed, Nov 14, 2018 at 02:08:48PM -0800, Stefan Beller wrote:
>
> > On Wed, Nov 14, 2018 at 1:43 PM Martin Ågren wrote:
> > >
> > > On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
> > > wrote:
> > > > However, the `.lock` file was
Hi Stefan,
On Wed, 14 Nov 2018, sxe...@google.com wrote:
> From: Stefan Xenos
>
> This document describes what an obsolescence graph for
> git would look like, the behavior of the evolve command,
> and the changes planned for other commands.
Thanks, this is a good discussion starter.
>
On Thu, Nov 15, 2018 at 01:29:58PM +0100, Johannes Schindelin wrote:
> > Do we actually care where the templates are? I thought the point was to
> > override for the built Git to use the built templates instead of the
> > installed one. For an installed Git, shouldn't we not be overriding the
> >
Hi Slavica,
this looks very good to me. Just one grammar thing:
On Wed, 14 Nov 2018, Slavica Djukic wrote:
> Add test to document that stash fails if user.name and user.email
> are not configured.
> In the later commit, test will be updated to expect success.
In a later commit [...]
Hi Junio,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Wed, Nov 14, 2018 at 02:16:37PM +0100, Johannes Schindelin wrote:
>
> > > Makes perfect sense. Shouldn't we be asking where the template
> > > directory of the installed version is and using it instead of the
> > > freshly built one, no?
> >
patibilities
> if rebase-merge:
> if incompatible_opts
> show_error_about_merge_and_am_incompatibilities
>
> which was a triply nested if, and the first (git_am_opt) and third
> (incompatible_opts) were slightly redundant; the latter being a subset
> of the former.
Ah, th
On Wed, Nov 14, 2018 at 11:46:17AM +0100, SZEDER Gábor wrote:
> This patch series should have been marked as v6, but I chose to reset
> the counter, because:
>
> - v5 was sent out way over a year ago [1], and surely everybody has
> forgotten about it since then anyway. But more
On Wed, Nov 14, 2018 at 11:46:20AM +0100, SZEDER Gábor wrote:
> Due to limitations in the current implementation, some configuration
> variables specified via 'git clone -c var=val' (or 'git -c var=val
> clone') are ignored during the initial fetch and checkout.
>
> Let the users know which
On Wed, Nov 14, 2018 at 11:46:19AM +0100, SZEDER Gábor wrote:
> The initial fetch during a clone doesn't transfer refs matching
> additional fetch refspecs given on the command line as configuration
> variables, e.g. '-c remote.origin.fetch='. This contradicts
> the documentation stating that
On Wed, Nov 14, 2018 at 11:46:18AM +0100, SZEDER Gábor wrote:
> cmd_clone() declares two strbufs 'key' and 'value' on the same line,
> suggesting that they are used to contruct a config variable's name and
> value. However, this is not the case: 'key' is used to construct the
> names of multiple
Thanks for review, I will summit a new patch soon to improve this.
Jonathan Nieder 于2018年11月15日周四 上午11:05写道：
>
> Hi!
>
> yanke131...@gmail.com wrote:
>
> > From: out0fmemory
> >
> > ---
> > INSTALL | 7 +++
> > 1 file changed, 7 insertions(+)
>
> Thanks for writing. A few bits of
On Thu, Nov 15, 2018 at 04:38:44AM -0500, Jeff King wrote:
> Is SOURCE_NONE a complete match for what we want?
>
> I see problems in both directions:
>
> - sorting by "objectname" works now, but it's marked with SOURCE_OBJ,
>and would be forbidden with your patch. I'm actually not sure if
On Thu, Nov 15, 2018 at 09:40:38AM +0100, Johannes Schindelin wrote:
> From @chucklu:
>
> > my user case is like this :
> >
> > When I want to cherr-pick commits from A to G (ABCDEFG), image C and E
> > are merge commits. Then I will get lots of popup like:
> >
> >The previous cherry-pick
On Wed, Nov 14, 2018 at 01:27:25PM +0100, SZEDER Gábor wrote:
> The command 'git ls-remote --sort=authordate ' segfaults when
> run outside of a repository, ever since the introduction of its
> '--sort' option in 1fb20dfd8e (ls-remote: create '--sort' option,
> 2018-04-09).
>
> While in general
Hi,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Agreed. I'm happy to see the test for-loop gone as I noted in
> > https://public-inbox.org/git/87d0rm7zeo@evledraar.gmail.com/ but as
> > noted in that v3 feedback the whole "why would anyone want this?"
+bmwill
On 2018-11-14, Michael Forney wrote:
> On 2018-10-25, Stefan Beller wrote:
>> I guess reverting that commit is not a good idea now, as
>> I would expect something to break.
>>
>> Maybe looking through the series 614ea03a71
>> (Merge branch 'bw/submodule-config-cleanup', 2017-08-26)
>>
On 2018-10-25, Stefan Beller wrote:
> On Thu, Oct 25, 2018 at 11:03 AM Michael Forney
> wrote:
>>
>> On 2018-03-16, Michael Forney wrote:
>> > Hi,
>> >
>> > In the past few months have noticed some confusing behavior with
>> > ignored submodules. I finally got around to bisecting this to commit
On Wed, Nov 14, 2018 at 02:08:48PM -0800, Stefan Beller wrote:
> On Wed, Nov 14, 2018 at 1:43 PM Martin Ågren wrote:
> >
> > On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
> > wrote:
> > > However, the `.lock` file was still open and on Windows that means
> > > that it could not be
Hi!
yanke131...@gmail.com wrote:
> From: out0fmemory
>
> ---
> INSTALL | 7 +++
> 1 file changed, 7 insertions(+)
Thanks for writing. A few bits of administrivia, from
https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html:
Can we forge your sign-off? See the section
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 1. Using multiple versions of Git on a single machine. For example,
>> some IDEs bundle a particular version of Git, which can be a
>> different version from the system copy, or on a Mac, /usr/bin/git
>> quickly goes out of sync
Hi,
Ben Peart wrote:
> There is no way to get multi-threaded reads and NOT get the scary message
> with older versions of git. Multi-threaded reads require the IEOT extension
> to be written into the index and the existence of the IEOT extension in the
> index will always generate the scary
On Wed, Nov 14, 2018 at 11:28 AM SZEDER Gábor wrote:
>
> On Tue, Nov 13, 2018 at 04:25:57PM -0800, Elijah Newren wrote:
> > diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> > index 2fef00436b..3cc98c31ad 100644
> > --- a/builtin/fast-export.c
> > +++ b/builtin/fast-export.c
> > @@
On Wed, Nov 14, 2018 at 11:17 AM SZEDER Gábor wrote:
> On Tue, Nov 13, 2018 at 04:25:53PM -0800, Elijah Newren wrote:
> > diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> > index af724e9937..b984a44224 100644
> > --- a/builtin/fast-export.c
> > +++ b/builtin/fast-export.c
> > @@
Hi Phillip,
On Mon, Nov 12, 2018 at 10:21 AM Phillip Wood wrote:
> >> -Flags only understood by the am backend:
> >> +The following options:
> >>
> >> * --committer-date-is-author-date
> >> * --ignore-date
> >> @@ -520,15 +512,12 @@ Flags only understood by the am backend:
> >> *
ctive:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
show_error_about_merge_and_am_incompatibilities
Before then having this patch coalesce that down to:
if incomptable_opts:
if interactive:
show_error_about_incompatible_options
Since it tripped up both you and Phill
On Wed, Nov 14, 2018 at 1:43 PM Martin Ågren wrote:
>
> On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
> wrote:
> > However, the `.lock` file was still open and on Windows that means
> > that it could not be deleted properly. This patch fixes that issue.
>
> Hmmm, doesn't the tempfile
On Wed, 14 Nov 2018 at 16:26, Gaël Lhez via GitGitGadget
wrote:
> However, the `.lock` file was still open and on Windows that means
> that it could not be deleted properly. This patch fixes that issue.
Hmmm, doesn't the tempfile machinery remove the lock file when we die?
> ref_count =
On Wed, Nov 14, 2018 at 05:59:02AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> This did happen at some stage, and was fixed relatively quickly. Make
> sure that we detect very quickly, too, should that happen again.
>
> Signed-off-by: Johannes Schindelin
On Wed, Nov 14, 2018 at 02:16:37PM +0100, Johannes Schindelin wrote:
> > Makes perfect sense. Shouldn't we be asking where the template
> > directory of the installed version is and using it instead of the
> > freshly built one, no?
>
> It would make sense, but we don't know how to get that
Hi Phillip,
On Wed, 14 Nov 2018, Phillip Wood wrote:
> Thanks for doing this, I think this patch is good.
Thanks!
> I've not checked the first patch as I think it is the same as before
> judging from the covering letter.
Indeed, that's what the range-diff said. Sorry for not stating this
On 2018.11.14 11:38, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > On 2018.11.13 13:01, Junio C Hamano wrote:
> >> I am wondering if the code added by this patch outside this
> >> function, with if (strcmp(client_ad.buf, "version=0") sprinkled all
> >> over the place, works sensibly when
On 2018.11.14 19:22, Junio C Hamano wrote:
> Josh Steadmon writes:
>
> > Fix several bugs identified in v3, clarify commit message, and clean up
> > extern keyword in protocol.h.
>
> It is good to descirbe the change relative to v3 here, which would
> help those who are interested and reviewed
On Tue, Nov 13, 2018 at 04:25:57PM -0800, Elijah Newren wrote:
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 2fef00436b..3cc98c31ad 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -37,6 +37,7 @@ static int fake_missing_tagger;
> static int
On Tue, Nov 13, 2018 at 04:25:53PM -0800, Elijah Newren wrote:
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index af724e9937..b984a44224 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -774,9 +774,12 @@ static void handle_tag(const char *name, struct tag
750 loose objects0.59(0.92+0.05)
> 2.72(2.92+0.17) +361.0% 0.58(0.90+0.04) -1.7%
> 0008.8: index-pack with 256*1000 loose objects 0.59(0.90+0.06)
> 3.50(3.67+0.21) +493.2% 0.57(0.90+0.04) -3.4%
>
> All of which is to say that I think it definitely makes sense to re-
On 11/13/2018 10:24 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
We cannot change the past, but for index extensions of the future,
there is a straightforward improvement: silence that message except
when tracing. This way, the message is still available when
debugging, but in
On 11/13/2018 4:08 PM, Jonathan Nieder wrote:
Hi again,
Ben Peart wrote:
On 11/13/2018 1:18 PM, Jonathan Nieder wrote:
Ben Peart wrote:
Why introduce a new setting to disable writing the IEOT extension instead of
just using the existing index.threads setting? If index.threads=1 then
On Wed, Nov 14, 2018 at 05:06:32PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > If commit.cleanup = scissors is specified, don't produce a scissors line
> > if one already exists in the commit message.
>
> It is good that you won't have two such lines in the end result, but
> is this
Hi Johannes
Thanks for doing this, I think this patch is good. I've not checked the
first patch as I think it is the same as before judging from the
covering letter.
Best Wishes
Phillip
On 14/11/2018 16:25, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
It is a
Hi Ævar,
On Tue, 13 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Trivial updates since v4 addressing the feedback on that
> iteration. Hopefully this is the last one, range-diff with the last
> version:
This range-diff looks good to me.
Thanks,
Dscho
>
> 1: 5399e57513 = 1: f225173f43
On Wed, Nov 14, 2018 at 11:12 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > One of the problems with "git checkout" is that it does so many
> > different things and could confuse people specially when we fail to
> > handle ambiguation correctly.
>
> You would have realized
Hi Stefan,
On Tue, 13 Nov 2018, Stefan Beller wrote:
> On Tue, Nov 13, 2018 at 12:33 PM Gaël Lhez wrote:
> >
> > Hello,
> >
> > I don't know why I receive these message (and especially now given the time
> > at which I pushed this) but I suppose someone (Johannes Schindelin ?)
> > probably
Johannes Schindelin writes:
> It would make sense, but we don't know how to get that information, do we?
> ...
> And changing the code *now* to let us query Git where it thinks its
> templates should be won't work, as this patch is about using the installed
> Git (at whatever pre-compiled
Johannes Schindelin writes:
>> The latter half of this change is a good one. Given what the
>> proposed log message of this patch says
>>
>> Note also: the many, many calls to `git this` and `git that` are
>> unaffected, as the regular PATH search will find the `.exe` files on
>>
Hi Peff,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Tue, Nov 13, 2018 at 04:38:24AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > Phillip Wood reported a problem where the built-in rebase did not understand
> > options like -C1, i.e. it did not expect the option argument.
> >
> >
Hi Phillip,
On Tue, 13 Nov 2018, Phillip Wood wrote:
> On 13/11/2018 19:21, Johannes Schindelin wrote:
> > Hi Phillip,
> >
> > On Tue, 13 Nov 2018, Phillip Wood wrote:
> >
> > > Thanks for looking at this. Unfortunately using OPT_PASSTHRU_ARGV seems to
> > > break the error reporting
> > >
> >
ithub.com/git-for-windows/git/pull/1800
> >and from my cursory reading it is part of
> >2.19.windows, which has a large user base.
> >
> >> (and would re-enable rebase.useBuiltin=true in
> >> master right after 2.20 is out the door).
> >
> &
Hi,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Agreed. I'm happy to see the test for-loop gone as I noted in
> > https://public-inbox.org/git/87d0rm7zeo@evledraar.gmail.com/ but as
> > noted in that v3 feedback the whole "why would anyone want this?"
On Wed, Nov 14 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
>> to running with rebase.useBuiltin=false. This is needed to spot that
>> we're not introducing any
Hi Ævar,
On Wed, 14 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
> Add a GIT_TEST_REBASE_USE_BUILTIN=false test mode which is equivalent
> to running with rebase.useBuiltin=false. This is needed to spot that
> we're not introducing any regressions in the legacy rebase version
> while we're carrying
git-rebase[1]. Is `true` by default, which means use
> + the built-in rewrite of it in C.
> ++
> +The C rewrite is first included with Git version 2.20. This option
> +serves an an escape hatch to re-enable the legacy version in case any
> +bugs are found in the rewrite.
Hi Peff,
On Wed, 14 Nov 2018, Jeff King wrote:
> On Mon, Nov 12, 2018 at 05:48:37AM -0800, Johannes Schindelin via
> GitGitGadget wrote:
>
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 832ede5099..1ea20dc2dc 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -51,7 +51,7
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/Makefile b/Makefile
> > index bbfbb4292d..5df0118ce9 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2590,6 +2590,7 @@ GIT-BUILD-OPTIONS: FORCE
> > @echo
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > We really only need the test helpers in that case, but that is not what
> > we test for. So let's skip the test for now when we know that we want to
Hi Junio,
On Wed, 14 Nov 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > It really makes very, very little sense to use a different git
> > executable than the one the caller indicated via setting the environment
> >
On Wed, Nov 14, 2018 at 12:31:22PM +, Luke Diamand wrote:
> On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
> >
> > On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
> >
> > > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > > >
> > > > Git Merge 2019 is happening on February
On Mon, Nov 12, 2018 at 05:48:37AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 832ede5099..1ea20dc2dc 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -51,7 +51,7 @@ export LSAN_OPTIONS
>
>
901 - 1000 of 100366 matches
Mail list logo
