William Hubbs writes:
> I attempted to save your patches to apply them, but didn't have any luck
I'll push a topic branch (not merged to any of the integration
branches) ab/author-committer-ident-config later today at the
https://github.com/gitster/git repository.
> Also, according to Junio's r
This fixes the misleading message from "git checkout -m". I also
rephrased the original messages a bit so that when
tg/checkout-no-overlay is merged, fixing counting file deletion is one
line change.
Nguyễn Thái Ngọc Duy (2):
checkout: update count-checkouts messages
checkout: count and print
Commit 0f086e6dca [1] counts the number of files updated by "git
checkout -- " command and prints it. Later on 536ec1839d [2]
adds the ability to remove files in "git checkout -- ". This is
still an update on worktree and should be reported to the user.
To prepare for such an update since that com
Since 0f086e6dca (checkout: print something when checking out paths -
2018-11-13), this command reports how many paths have been updated
from what source (either from a tree, or from the index). I forget
that there's a third source: when -m is used, the merge conflict is
re-created (granted, also f
On Tue, Feb 05, 2019 at 06:15:58PM -0600, William Hubbs wrote:
> On Tue, Feb 05, 2019 at 06:04:13PM -0600, William Hubbs wrote:
> > On Tue, Feb 05, 2019 at 10:14:37PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > >
> > > On Tue, Feb 05 2019, Junio C Hamano wrote:
> > >
> > > > Ævar Arnfjörð Bjarmason
These tests are also marked with a NEEDSWORK comment.
Signed-off-by: Jonathan Tan
---
t/t5515-fetch-merge-logic.sh | 4
t/t5539-fetch-http-shallow.sh | 5 -
t/t5541-http-push-smart.sh| 14 --
t/t5551-http-fetch-smart.sh | 34 ++
4 fil
Protocol v2 filters the ref advertisement, but protocol v0 does not. A
test in t5552 uses the ref advertisement, so fix it to use protocol v0.
Signed-off-by: Jonathan Tan
---
t/t5552-skipping-fetch-negotiator.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/t/t5552-skip
Signed-off-by: Jonathan Tan
---
t/t5700-protocol-v1.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/t5700-protocol-v1.sh b/t/t5700-protocol-v1.sh
index 2e56c79233..9857bd0ecb 100755
--- a/t/t5700-protocol-v1.sh
+++ b/t/t5700-protocol-v1.sh
@@ -4,6 +4,9 @@ test_description='test git wi
In order to extract the wants from a trace, a loop in t5503 currently
breaks if "" is found. This works for protocol v0 and v1, but not
v2. Instead, teach t5503 to look specifically for the "want" string,
which is compatible with all protocols.
Signed-off-by: Jonathan Tan
---
t/t5503-tagfoll
Some tests check that fetching an unreachable object fails, but protocol
v2 allows such fetches. Unset GIT_TEST_PROTOCOL_VERSION so that these
tests are always run using protocol v0.
Signed-off-by: Jonathan Tan
---
t/t5500-fetch-pack.sh | 4 +++-
t/t5516-fetch-push.sh | 22 +
In post_rpc(), remote-curl calls credential_fill() if HTTP_REAUTH is
returned, but this is not true in proxy_request(). Do this in
proxy_request() too.
When t5551 is run using GIT_TEST_PROTOCOL_VERSION=2, one of the tests
that used to fail now pass.
Signed-off-by: Jonathan Tan
---
remote-curl.c
Define a GIT_TEST_PROTOCOL_VERSION environment variable meant to be used
from tests. When set, this ensures protocol.version is at least the
given value, allowing the entire test suite to be run as if this
configuration is in place for all repositories.
As of this patch, all tests pass whether GIT
Protocol v2 supports sending non-HEAD symrefs, but this is not true of
protocol v0. Some tests expect protocol v0 behavior, so fix them to use
protocol v0.
Signed-off-by: Jonathan Tan
---
t/t5512-ls-remote.sh | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a
This is on the latest master (8feddda32c ("Fifth batch for 2.21",
2019-02-05)) + js/protocol-advertise-multi.
This is a resend of [1], which was built on the result of merging many
branches. Now that most of the branches have been merged to master, I
have rebased it on master. The only branch that
On Tue, Feb 05, 2019 at 06:04:13PM -0600, William Hubbs wrote:
> On Tue, Feb 05, 2019 at 10:14:37PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >
> > On Tue, Feb 05 2019, Junio C Hamano wrote:
> >
> > > Ævar Arnfjörð Bjarmason writes:
> > >
> > >> +static int set_ident_internal(const char *var, con
On Tue, Feb 05, 2019 at 10:14:37PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Feb 05 2019, Junio C Hamano wrote:
>
> > Ævar Arnfjörð Bjarmason writes:
> >
> >> +static int set_ident_internal(const char *var, const char *value,
> >> + struct strbuf *sb, const int flag
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
A handful more topics have been me
Jeff King writes:
> After making initial contact with an http server, we have to decide if
> the server supports smart-http, and if so, which version. Our rules are
> a bit inconsistent:
> ...
>
> - we now predicate the smart/dumb decision entirely on the presence of
>the correct content-typ
On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer wrote:
>
> [Dropped Stefan from the Cc list, as his email bounces]
>
> On 02/04, Thomas Gummerer wrote:
> The idea is to add an option to 'git stash push', so it can stash
> merge conflicts, and restore them with 'git stash pop'. The various
> stag
[Dropped Stefan from the Cc list, as his email bounces]
On 02/04, Thomas Gummerer wrote:
> On 02/04, Christian Couder wrote:
> > It would be nice to have a few more project ideas.
> > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible
> > projects:
>
> Thanks for putting this t
On Tue, Feb 05 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> +static int set_ident_internal(const char *var, const char *value,
>> +struct strbuf *sb, const int flag)
>> +{
>> +if (!value)
>> +return config_error_nonbool(var);
>> +
On 02/04, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > There was also some discussion around the naming of the option, but I
> > don't have a strong opinion on that, so I'm happy with keeping the
> > --[no-]overlay option. I just wanted to bring it up again here in
> > case someone had
Elijah Newren writes:
>> > Further, in patch format, this changes the from/to headers so that
>> > instead of just having one "from" header, we get one for each parent.
>> > For example, instead of having
>> >
>> > --- a/phooey.c
>> > +++ b/phooey.c
>> >
>> > we would see
>> >
>> > --- a/fo
Am 05.02.19 um 12:06 schrieb Johannes Schindelin:
> The real examples are much more mundane, and very different from what you
> suspected, e.g. inserting the tag header before the tag message in
> `create_tag()` in `builtin/tag.c`. Basically, it is building up a strbuf
> for the sake of calling `st
Ævar Arnfjörð Bjarmason writes:
> +static int set_ident_internal(const char *var, const char *value,
> + struct strbuf *sb, const int flag)
> +{
> + if (!value)
> + return config_error_nonbool(var);
> + strbuf_reset(sb);
> + strbuf_addstr(sb, value
On 2/4/2019 2:44 PM, Ramsay Jones wrote:
On 30/01/2019 12:29, Jeff Hostetler wrote:
On 1/26/2019 4:07 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Jeff,
If you need to re-roll your 'jh/trace2' branch, could you please
squash this into the relevant patches (sorry, I didn
I had some feedback on v2 that wasn't addressed. See
https://public-inbox.org/git/875zuc49uj@evledraar.gmail.com/ &
https://public-inbox.org/git/871s4w4khs@evledraar.gmail.com/
This fixes that, except I couldn't with limited time reproduce the bug
I was talking about in the latter E-Mail i
There were no explicit tests for the interaction between setting GIT_*
in the environment, and the user.{name,email} config variables. These
tests are basic, but we're about to learn
{author,committer}.{name,email} in addition to user.{name,email}, so
they'll soon become more useful.
Signed-off-by
From: William Hubbs
The author.email, author.name, committer.email and committer.name
settings are analogous to the GIT_AUTHOR_* and GIT_COMMITTER_*
environment variables, but for the git config system. This allows them
to be set separately for each repository.
Git supports setting different aut
Thanks. Overall, one major point: I think that the declaration of
supported versions need to be transport-scoped (search this email for
"transport-scoped" for context). And one medium point: it might be
better for protocol.version to be the preferred and maximum version, not
only the preferred vers
Johannes Schindelin writes:
> In particular, the tests t2024 and t5552 are broken for
> ma/doc-diff-usage-fix on Windows. The reason seems to be that those are
> already broken for the base commit that Junio picked:
> jk/diff-rendered-docs (actually, not the tip of it, but the commit fixed
> by M
Ramsay Jones writes:
> Changes in v2:
>
> - Add a new patch #1, which removes an obsolete use of SPARSE_FLAGS
> - Actually initialise the new SP_EXTRA_FLAGS variable
> - Reword the commit message (now #2) to, hopefully, clarify the
> usage of SPARSE_FLAGS and SP_EXTRA_FLAGS
Thanks. Ap
Elijah Newren writes:
> I don't want to get rid of them; the initial reviews of my original
> patch thought the format was ambiguous and would mishandle files with
> tabs in them. But yeah, I can definitely add a few testcases without
> FUNNYNAMES. Sorry for the headache; I'll fix this up.
Tha
Johannes Schindelin writes:
>> +objects.
>> +If you need the `author` or `committer` to be different, the
>> +`author.name`, `author.email`, `committer.name` or
>> +`committer.email` variables can be set.
>> +Also, all of these can be overridden by the `GIT_AUTHOR_NAME`,
>> +
Johannes Schindelin writes:
> Or that they are read with a fine toothed comb, but that the focus lies
> more on style and maintainability than correctness. We talked about this
> in the past.
Perhaps we can do better the next time, then. I find unreadable
code is impossible to reason about its
Johannes Schindelin writes:
> On Mon, 4 Feb 2019, SZEDER Gábor wrote:
>
>> Under Dscho's bugreport it looks like they already merged a one-liner
>> fix, but how long will it take to tickle down to Travis CI, I have no
>> idea.
>
> Since the fix affected a Homebrew package, it was not so much abou
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When contributing the patch series, the cover letter tried to convey
> clearly that the patch introducing the shortcut -y was included only to
> show that it is possible, with a slight bias against it.
>
> During the
> On Mon, Feb 4, 2019 at 7:06 AM brian m. carlson
> wrote:
> >
> > When we write an alternate shallow file in update_shallow, we write it
> > into the lock file. The string stored in alternate_shallow_file is
> > copied from the lock file path, but it is freed the moment that the lock
> > file is
Hi Dscho,
On Tue, Feb 5, 2019 at 1:48 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Mon, 4 Feb 2019, Elijah Newren wrote:
>
> > The combined diff format for merges will only list one filename, even if
> > rename or copy detection is active. For example, with raw format one
> > might see:
>
On Mon, Feb 4, 2019 at 1:20 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> There is one place that says combined-all-paths, and everywhere else
> it says combined-all-names. The former is probably techincally more
> correct, I think ;-)
Looks like I had a mixture of my original name (co
On Tue, Feb 05 2019, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Feb 05 2019, Dani Koretsky wrote:
>
>> I have 2 tags such as release-17.6.230 and release-17.6.220:
>> If I'm changing commits, all works as expected.
>>
>> If however both are pointing to the same commit, the output is as follows:
>>
On Tue, Feb 05 2019, Dani Koretsky wrote:
> I have 2 tags such as release-17.6.230 and release-17.6.220:
> If I'm changing commits, all works as expected.
>
> If however both are pointing to the same commit, the output is as follows:
>
> git checkout release-17.6.220
> git status
> HEAD detached
On February 5, 2019 4:20, Dani Koretsky wrote:
> I have 2 tags such as release-17.6.230 and release-17.6.220:
> If I'm changing commits, all works as expected.
>
> If however both are pointing to the same commit, the output is as follows:
>
> git checkout release-17.6.220
> git status
> HEAD deta
From: Johannes Schindelin
When contributing the patch series, the cover letter tried to convey
clearly that the patch introducing the shortcut -y was included only to
show that it is possible, with a slight bias against it.
During the review, there were a couple reviewers who agreed with this
se
I totally missed that this patch, despite my pledge to not include it, made
it into master. Sorry about that.
Johannes Schindelin (1):
Revert "rebase: introduce a shortcut for --reschedule-failed-exec"
Documentation/git-rebase.txt | 6 --
builtin/rebase.c | 21
Hi Gábor,
On Mon, 4 Feb 2019, SZEDER Gábor wrote:
> Under Dscho's bugreport it looks like they already merged a one-liner
> fix, but how long will it take to tickle down to Travis CI, I have no
> idea.
Since the fix affected a Homebrew package, it was not so much about
trickling down to Travis,
Hi Gábor,
On Mon, 4 Feb 2019, SZEDER Gábor wrote:
> On Mon, Feb 04, 2019 at 10:49:05AM +0100, Johannes Schindelin wrote:
>
> > So our best bet at not getting overwhelmed with failed builds ...
>
> Oh, in my long-time for-fun semi-automated CI experiment [1] all
> integration branches and cookin
Hi Ramsay,
On Tue, 5 Feb 2019, Ramsay Jones wrote:
>
> An upcoming commit will change the semantics of the SPARSE_FLAGS
> variable from an internal to a user only customisation variable.
> The MinGW configuration section contains an obsolete setting for
> this variable which was used (some years
Hi Junio,
On Mon, 4 Feb 2019, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > strbuf_vinsertf inserts a formatted string in the middle of an existing
> > strbuf value. It makes room in the strbuf by moving existing string to
> > the back, then formats the string to insert directly into the
Hi Hannes,
On Mon, 4 Feb 2019, Johannes Sixt wrote:
> Am 04.02.19 um 11:38 schrieb Johannes Schindelin:
> > On Mon, 4 Feb 2019, Johannes Sixt wrote:
> >
> >> Am 03.02.19 um 17:51 schrieb Johannes Sixt:
> >>> strbuf_vinsertf inserts a formatted string in the middle of an existing
> >>> strbuf val
Hi Peff and Martin,
On Tue, 5 Feb 2019, Jeff King wrote:
> On Mon, Feb 04, 2019 at 09:50:37PM +0100, Martin Ågren wrote:
>
> > `usage` tries to call $0, which might very well be "./doc-diff", so if
> > we `cd_to_toplevel` before calling `usage`, we'll end with an error to
> > the effect of "./do
On Mon, 4 Feb 2019 at 23:28, Jeff King wrote:
>
> On Mon, Feb 04, 2019 at 01:45:35PM +, Luke Diamand wrote:
>
> > I tried to do a partial clone, but it gave me a "bad pack header". Is
> > there anything I can do to debug this?
> >
> > I did "git config uploadpack.allowfilter true" in my repo.
Hi Elijah,
On Mon, 4 Feb 2019, Elijah Newren wrote:
> The combined diff format for merges will only list one filename, even if
> rename or copy detection is active. For example, with raw format one
> might see:
>
> ::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c
> ::100755 10
I have 2 tags such as release-17.6.230 and release-17.6.220:
If I'm changing commits, all works as expected.
If however both are pointing to the same commit, the output is as follows:
git checkout release-17.6.220
git status
HEAD detached at release-17.6.220
now if I run:
git checkout release-17
Hi William,
On Mon, 4 Feb 2019, William Hubbs wrote:
> diff --git a/Documentation/config/user.txt b/Documentation/config/user.txt
> index b5b2ba1199..0557cbbceb 100644
> --- a/Documentation/config/user.txt
> +++ b/Documentation/config/user.txt
> @@ -1,12 +1,19 @@
> -user.email::
> - Your emai
55 matches
Mail list logo
