Our filter_refs() function accidentally considers the target of a peeled
tag to be advertised by the server, even though upload-pack on the
server side does not consider it so. This can result in the client
making a bogus fetch to the server, which will end with the server
complaining "not our ref"
We provide a free_refs() function to free a list, but there's no easy
way for a caller to free a single ref. Let's make our singular
free_ref() function public. Since its name is so similar to the
list-freeing free_refs(), and because both of those functions have the
same signature, it might be eas
There's no need for us to write this loop manually when a helper
function can already do it.
Signed-off-by: Jeff King
---
fetch-pack.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index e69993b2eb..a181d3401d 100644
--- a/fetch-pack.c
+++ b/
Since 2d103c31c2 (pack-protocol.txt: accept error packets in any
context, 2018-12-29), the pktline code will detect an ERR packet and die
automatically, saving the caller from dealing with it. But we do so too
early in the function, before we have terminated the buffer with a NUL.
As a result, pas
Commit bdb31eada7 (upload-pack: report "not our ref" to client,
2017-02-23) catches the case where a client asks for an object we don't
have, and issues a message that the client can show to the user (in
addition to dying and writing to stderr).
There's a similar case (with the same message) when
Back in 9f9aa76130 (upload-pack: Improve error message when bad ref
requested, 2010-07-31), we added a test to make sure that we die with a
sensible message when the client asks for an object we don't have.
Much later, in bdb31eada7 (upload-pack: report "not our ref" to client,
2017-02-23), we sta
We annotated our test_must_fail calls in 8bf4becf0c (add "ok=sigpipe" to
test_must_fail and use it to fix flaky tests, 2015-11-27) because the
abrupt hangup of the server meant that we'd sometimes fail on read() and
sometimes get SIGPIPE on write().
But since 143588949c (fetch: ignore SIGPIPE duri
Jeff King writes:
>> +/* writes out the whole block, or dies if fails */
>> +static void write_block_or_die(const char *block) {
>> +if (gzip) {
>> +if (gzwrite(gzip, block, (unsigned) BLOCKSIZE) != BLOCKSIZE)
>> +die(_("gzwrite failed"));
>> +} else {
>> +
This series fixes a few minor bugs around clients trying to fetch
unreachable commits, along with a few associated cleanups.
There's a minor conflict in t5516 when merging with next, since that
adds GIT_TEST_PROTOCOL_VERSION, causing a few textual conflicts. The
resolution should be fairly clear.
Jeff King writes:
> So it sounds like you did that and the result is not _too_ bad. But I'm
> not sure about doing it automatically with sed. For example...
>
>> diff --git a/packfile.h b/packfile.h
>> index d70c6d9afb..dab50405e0 100644
>> --- a/packfile.h
>> +++ b/packfile.h
>> [...]
>> @@ -43,
Emily Shaffer writes:
> I like this suggestion, but don't like the use of "fork" as it
> somewhat conflates
> a GitHub-specific term. I'll take this recommendation but use "create" instead
> of "fork".
The verb "create" is not incorrect per-se. It stops at saying that
the result points at the c
On Fri, Apr 12, 2019 at 03:38:47PM -0700, Josh Steadmon wrote:
> > > Thank you for catching this. I haven't yet figured out the cause. I will
> > > look into this more tomorrow and then send a V4 once I've fixed it.
> >
> > I'm concerned that this is a sign that the approach I suggested does not
Hello everyone.
We are starting knowing and working with Git. We already used some version
control systems for parts of our work and for now we wanna to have one.
So how's the situation.
There is one big company with integration center and a few smaller firms which
send their work there. We are
On Fri, Apr 12, 2019 at 04:04:40PM -0700, Rohit Ashiwal via GitGitGadget wrote:
> From: Rohit Ashiwal
>
> As we already link to the zlib library, we can perform the compression
> without even requiring gzip on the host machine.
Very cool. It's nice to drop a dependency, and this should be a bit
On Fri, Apr 12, 2019 at 04:04:39PM -0700, Rohit Ashiwal via GitGitGadget wrote:
> From: Rohit Ashiwal
>
> MinGit for Windows comes without `gzip` bundled inside, git-archive uses
> `gzip -cn` to compress tar files but for this to work, gzip needs to be
> present on the host system.
>
> In the n
On Fri, Apr 12, 2019 at 04:48:21PM -0700, Denton Liu wrote:
> Junio mentioned that there was a push to drop extern from function
> declarations in headers[1]. I decided to do a mass refactoring so we
> could get rid of everything at once, although I'm not sure if that's
> welcome. But I'll send th
From: Rohit Ashiwal
MinGit for Windows comes without `gzip` bundled inside, git-archive uses
`gzip -cn` to compress tar files but for this to work, gzip needs to be
present on the host system.
In the next commit, we will change the gzip compression so that we no
longer spawn `gzip` but let zlib
From: Rohit Ashiwal
As we already link to the zlib library, we can perform the compression
without even requiring gzip on the host machine.
Signed-off-by: Rohit Ashiwal
Signed-off-by: Johannes Schindelin
---
archive-tar.c | 34 +-
1 file changed, 25 insertions(
When creating .tar.gz archives with git archive, we let gzip handle the
compression part. But that is not even necessary, as we already require zlib
(to compress our loose objects). It is also unfortunate, as it requires gzip
to be in the PATH (which is not the case e.g. with MinGit for Windows, w
On Thu, Apr 11, 2019 at 7:35 PM Junio C Hamano wrote:
>
> "Emily Shaffer via GitGitGadget" writes:
>
> > RFC. I am still working on adding a section on handling refs and objects.
>
> Thanks. Is 'lab' understood widely enough? I _think_ you are
> abbreviating what is known as 'codelab' by your c
On 2019.04.11 00:06, Jeff King wrote:
> On Tue, Apr 09, 2019 at 04:42:55PM -0700, Josh Steadmon wrote:
>
> > > warning: reflog of 'HEAD' references pruned commits
> > > warning: reflog of 'refs/heads/master' references pruned commits
> > > fatal: unable to read 71905dfcd543b7cbb0b4b66fbd2037
On Thu, Apr 11, 2019 at 8:20 PM Junio C Hamano wrote:
>
> "Emily Shaffer via GitGitGadget" writes:
>
> > diff --git a/Documentation/MyFirstContribution
> > b/Documentation/MyFirstContribution
> > new file mode 100644
> > index 00..9b87e424d6
> > --- /dev/null
> > +++ b/Documentation/MyFi
On Tue, Apr 09 2019, Nguyễn Thái Ngọc Duy wrote:
> Here's the replacement patch that keeps "git clean" behavior the same
> as before and only checks 'precious' attribute when --keep-precous is
> specified.
Cool to have the expected interaction with -x. Thanks.
> -'git clean' [-d] [-f] [-i]
On Fri, Apr 12, 2019 at 04:14:32PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> On the git tag -v code, there is a guard to suppress gpg output if a
> pretty format is provided. The rationale for this is that the gpg output
> *and* the pretty formats together may conflict with each
From: Santiago Torres
On the git tag -v code, there is a guard to suppress gpg output if a
pretty format is provided. The rationale for this is that the gpg output
*and* the pretty formats together may conflict with each other. However,
both outputs are directed to different output streams and, a
On Fri, Apr 12, 2019 at 12:51:21PM -0700, Jonathan Tan wrote:
[Reordering the diffs...]
> diff --git a/transport.c b/transport.c
> index e078812897..77446119da 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -252,6 +252,14 @@ static int connect_setup(struct transport *transport,
> int for_pu
Thanks, Junio, for spotting the test_must_fail interaction with
environment variables. I've updated that, and I also noticed that the
first patch's commit message title should say "die" instead of "warn",
so here is another version.
Jonathan Tan (2):
transport: die if server options are unsuppor
Commit 5e3548ef16 ("fetch: send server options when using protocol v2",
2018-04-24) taught "fetch" the ability to send server options when using
protocol v2, but not "clone". This ability is triggered by "-o" or
"--server-option".
Teach "clone" the same ability, except that because "clone" already
Server options were added in commit 5e3548ef16 ("fetch: send server
options when using protocol v2", 2018-04-24), supported only for
protocol version 2. But if the user specifies server options, and the
protocol version being used doesn't support them, the server options are
silently ignored.
Teac
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar e
This patch series fixes two progress display issues by breaking
progress bars longer than the width of the terminal and by properly
cleaning up the previously shown progress bar. Hopefully for good
this time...
This "properly cleaning up" part, i.e. mainly patch 3, was buggy in
previous versions,
The following patches in this series want to handle the progress bar's
title and changing parts (i.e. the counter and the optional percentage
and throughput combined) differently, and need to know the length
of the changing parts of the previously displayed progress bar.
To prepare for those chang
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never b
When the progress bar includes throughput, its length can shorten as
the unit of display changes from KiB to MiB. To cover up remnants of
the previous progress bar when such a change of units happens we
always print three spaces at the end of the progress bar.
Alas, covering only three characters
On Fri, Apr 12, 2019 at 8:00 AM Johannes Schindelin via GitGitGadget
wrote:
> When building with certain build options, some commands are excluded
> from the build. For example, `git-credential-cache` is skipped when
> building with `NO_UNIX_SOCKETS`.
>
> Let's not build or package documentation f
On Fri, Apr 12, 2019 at 05:08:19PM +0700, Nguyễn Thái Ngọc Duy wrote:
> @@ -2096,7 +2096,7 @@ static int absorb_git_dirs(int argc, const char **argv,
> const char *prefix)
> };
>
> const char *const git_submodule_helper_usage[] = {
> - N_("git submodule--helper embed-git-
Hi
On 12/04/2019 00:56, wh wrote:
I'm using git 2.20.1 from Debian. Git is usually careful not to
overwrite untracked files, including ignored files.
Git normally overwrites ignored files, so I think in your example rebase
-i is working as expected, I'm surprised that the am based rebase does
Ron writes:
>> I do not know what "git fetch" uses semicolon for here. Care to
>> elaborate?
>
> Those were all typos, I meant colon, two dots. Sorry.
Do you mean to say that because you can say
$ git fetch origin +master:refs/remotes/origin/master
you expected that you can say this?
Thomas Gummerer writes:
> I'm not sure what the right solution for this is. I think one thing
> I'd like range-diff to do is to add the filename, or some context
> (e.g. is this part of the commit message etc.) to the @@ line (not
> sure what that is called?).
Perhaps the inner diff can be done
Hi,
On Fri, 12 Apr 2019, SZEDER Gábor wrote:
> On Thu, Apr 11, 2019 at 10:58:57PM +0200, SZEDER Gábor wrote:
> > On Thu, Apr 11, 2019 at 10:51:46PM +0200, SZEDER Gábor wrote:
> > > On Wed, Apr 10, 2019 at 10:56:52PM +0200, Johannes Schindelin wrote:
> > > > > ...>}
> > > > >
> > > > >
On 4/11/2019 10:29 PM, Junio C Hamano wrote:
"Jeff Hostetler via GitGitGadget" writes:
[...]
@@ -512,19 +454,28 @@
+ */
+/* clang-format off */
++[TR2_SYSENV_CFG_PARAM] = { "GIT_TR2_CONFIG_PARAMS",
++ "trace
> Junio C Hamano wrote:
> I do not know what "git fetch" uses semicolon for here. Care to
> elaborate?
Those were all typos, I meant colon, two dots. Sorry.
Okay thanks for the reply. I didn't know about git update-index will
try that now.
On Thu, Apr 11, 2019 at 3:57 PM Duy Nguyen wrote:
>
> On Thu, Apr 11, 2019 at 7:49 PM NoName Req wrote:
> >
> > Summary
> >`git -C (folder path) diff-files --name-only` output is not correct
> >
> > Steps to R
While working on better support for make check-docs on Windows, I noticed a
couple more things, e.g. some "commands" were reported as being listed but
not built, e.g. gitcli (i.e. the parts of command-list.txt that are marked
as "guide").
This patch series cleans up those loose ends: after this, m
From: Johannes Schindelin
In preparation for moving `git serve` into `test-tool` (because it
really is only used by the test suite), we teach the `test-tool` the
useful trick to change the working directory before running the test
command, which will avoid introducing subshells in the test code.
From: Johannes Schindelin
When building with certain build options, some commands are excluded
from the build. For example, `git-credential-cache` is skipped when
building with `NO_UNIX_SOCKETS`.
Let's not build or package documentation for those excluded commands.
This issue was pointed out ri
From: Johannes Schindelin
When built with NO_CURL or with NO_UNIX_SOCKETS, some commands are
skipped from the build. It does not make sense to list them in the
output of `git help -a`, so let's just not.
Signed-off-by: Johannes Schindelin
---
Makefile| 14 --
generate-c
From: Johannes Schindelin
In the previous commit, we taught `git help -a` to stop listing commands
that are excluded from the build.
In this commit, we stop `check-docs` from claiming that those commands
are listed.
Signed-off-by: Johannes Schindelin
---
Makefile | 1 +
1 file changed, 1 inse
From: Johannes Schindelin
In the recent years, there has been a big push to convert more and more
of Git's commands that are implemented as scripts to built-ins written
in pure, portable C, for robustness, speed and portability.
One strategy that served us well is to convert those scripts
increm
From: Johannes Schindelin
The `git-remote-testgit` script is really only used in
`t5801-remote-helpers.sh`. It does not even contain any ``
placeholders that would need to be interpolated via `make
git-remote-testgit`.
Let's just move it to a new home, decluttering the top-level directory
an
From: Johannes Schindelin
The `git serve` built-in was introduced in ed10cb952d31 (serve:
introduce git-serve, 2018-03-15) as a backend to serve Git protocol v2,
probably originally intended to be spawned by `git upload-pack`.
However, in the version that the protocol v2 patches made it into cor
From: Johannes Schindelin
Due to reasons (some XCode versions seem to include gettext, some
don't?), Homebrew does not expose the libraries and headers in
/usr/local/ by default anymore.
Let's help find them again.
Note: for some reason, this is a change of behavior caused by the
upgrade to Moj
From: Johannes Schindelin
Most notably, it seems that macOS' APFS does not allow that.
Signed-off-by: Johannes Schindelin
---
t/t9822-git-p4-path-encoding.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t9822-git-p4-path-encoding.sh b/t/t9822-git-p4-path-encoding.sh
index c7847
Yesterday, the macOS agents of Azure Pipelines were upgraded to Mojave, and
since that does not support HFS+ anymore, everything will be upgraded to
APFS.
As I just found yesterday, we have one test that fails on that filesystem
(t9822, which is only run if Perforce's p4d is available).
The first
Robin reported that
git submodule foreach --quiet git pull --quiet origin
is not really quiet anymore [1]. "git pull" behaves as if --quiet is not
given.
This happens because parseopt in submodule--helper will try to parse
both --quiet options as if they are foreach's options, not git-pull's
From: Johannes Schindelin
To use the singular form of a word, when the option wants the plural
form (and quietly expands it because it thinks it was abbreviated), is
an easy mistake to make, and t5317 contains almost two dozen of them.
However, using abbreviated options in tests is a bit fragile
From: Johannes Schindelin
Git's command-line parsers support uniquely abbreviated options, e.g.
`git init --ba` would automatically expand `--ba` to `--bare`.
This is a very convenient feature in every day life for Git users, in
particular when tab completion is not available.
However, it is no
From: Johannes Schindelin
To avoid future ambiguities, we really want to use full option names in
the test suite. `t7525-status-rename.sh` used an abbreviated form of the
`--find-renames` option, though, so let's change that.
Signed-off-by: Johannes Schindelin
---
t/t7525-status-rename.sh | 8
We do not want to have tests that need to be changed by completely unrelated
patch series, just because abbreviations that used to be unique are being
made non-unique by said patch series.
I stumbled over this while investigating the test failures in
dl/rebase-i-keep-base
[https://dev.azure.com/gi
From: Johannes Schindelin
This script used abbreviated options, which is unnecessarily fragile.
Signed-off-by: Johannes Schindelin
---
t/t7810-grep.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 43aa4161cf..2e1bb6
From: Johannes Schindelin
This test wants to run `git rebase` with the `--keep-empty` option, but
it really only spelled out `--keep` and trusted Git's option parsing to
determine that this was a unique abbreviation of the real option.
However, Denton Liu contributed a patch series in
https://pu
From: Johannes Schindelin
In quite a few test cases, we were sloppy and used the abbreviation
`--force`, but we really should be precise in what we want to test.
Signed-off-by: Johannes Schindelin
---
t/t3415-rebase-autosquash.sh | 2 +-
t/t3430-rebase-merges.sh | 4 ++--
2 files changed,
From: Johannes Schindelin
We really want to spell out the option in the full form, to avoid any
ambiguity that might be introduced by future patches.
Signed-off-by: Johannes Schindelin
---
t/t5516-fetch-push.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5516-fet
From: Johannes Schindelin
It was probably just an oversight: the `--recurse-submodules` option
puts the term "submodules" in the plural form, not the singular one.
To avoid future problems in case that another option is introduced that
starts with the prefix `--recurse-submodule`, let's just fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Forgot the link:
[0] https://github.com/farseer90718/vim-taskwarrior
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 9
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I seems to have found the bug.
My last debugging gave the hint. pending.data is a concept of
taskwarrior and have the .task directory on git control. And I also use
a vim addon for it[0].
It seems that it introduces that troubles. As the last commi
On Fri, Apr 12, 2019 at 2:09 PM Robin H. Johnson wrote:
> > -- 8< --
> (snip patch, please add my DCO signed-off-by)
> Tested-by: Robin H. Johnson
> Signed-off-by: Robin H. Johnson
> > -- 8< --
> >
> > I'm a bit reluctant to follow up with a proper patch because I can't
> > digest the t5572-subm
On Fri, Apr 12, 2019 at 5:05 AM Thomas Gummerer wrote:
> I'm not sure what the right solution for this is. I think one thing
> I'd like range-diff to do is to add the filename, or some context
> (e.g. is this part of the commit message etc.) to the @@ line (not
> sure what that is called?).
I do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Christian,
Am Fr den 12. Apr 2019 um 9:39 schrieb Christian Couder:
> On Thu, Apr 11, 2019 at 7:24 PM Klaus Ethgen wrote:
>
> > I am a heavy user of git now at version 2.20.1 on debian.
> >
> > Since some weeks I have the problem that I get of
Hi Junio,
On Mon, 1 Apr 2019, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > I don't get why having a configuration option is better for defending
> > scripts against this problem than a simple environment variable. It
> > seems easier for the script prologue to contain:
> >
> > GIT_TES
Hi Ævar,
On Mon, 25 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Mar 25 2019, Johannes Schindelin via GitGitGadget wrote:
>
> > +# Disallow the use of abbreviated options in the test suite by default
> > +test -n "$GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS" || {
> > + GIT_TEST_DISALLOW_ABBR
Hi Denton,
On Mon, 25 Mar 2019, Denton Liu wrote:
> Thanks for catching this. Perhaps I should've been more diligent and ran
> the entire test suite before submitting but I was running low on
> batteries only ran the rebase-related tests.
No worries.
> On Mon, Mar 25, 2019 at 11:14:23AM -0700,
Hi,
On Mon, 25 Mar 2019, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Mar 25 2019, Denton Liu wrote:
>
> > Hi Johannes,
> >
> > Thanks for catching this. Perhaps I should've been more diligent and ran
> > the entire test suite before submitting but I was running low on
> > batteries only ran the r
Hi Thomas,
On Thu, 11 Apr 2019, Thomas Gummerer wrote:
> On 04/11, Duy Nguyen wrote:
> > Try
> >
> > git range-diff from...to
> >
> > with those two branches from https://gitlab.com/pclouds/git.git. The
> > interesting part is this
> >
> > diff --git a/Documentation/gitcli.txt b/Documen
Hi,
On Thu, Apr 11, 2019 at 7:24 PM Klaus Ethgen wrote:
> I am a heavy user of git now at version 2.20.1 on debian.
>
> Since some weeks I have the problem that I get often "fatal: unable to
> read ..." and a unclear repository after a git commit. The commit itself
> is correct and so a git rese
On Wed, Apr 10, 2019 at 06:18:35PM +0700, Duy Nguyen wrote:
> ...
Thanks, I tested, and had good results in almost all of my tests.
Almost all: config setting of 'pull.rebase=preserve'
===
$ git submodule foreach --quiet git pull --quiet origin master >/dev/null
Successfully rebased and updated
ron writes:
> ... And it may not be uncommon since it comes from the fact that
> git merge normally follows git fetch where semicolon is supported
> as per normal.
I do not know what "git fetch" uses semicolon for here. Care to
elaborate?
77 matches
Mail list logo
