* Re: A puzzle: reset --hard and hard links
2022-01-19 20:37 4% A puzzle: reset --hard and hard links Michael Herrmann
@ 2022-01-19 22:20 0% ` brian m. carlson
0 siblings, 0 replies; 69+ results
From: brian m. carlson @ 2022-01-19 22:20 UTC (permalink / raw)
To: Michael Herrmann; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
On 2022-01-19 at 20:37:48, Michael Herrmann wrote:
> Hi all,
>
> It seems `git reset --hard` recreates files that have external hard
> links. Is this intended?
>
> The example below highlights the behavior. I have an unchanged Git
> repository. When I create an (outside) hard link to a file in the
> repository, then `git reset --hard` re-creates the file with a new
> modification time and inode. This occurs on Debian 11 with Git 2.30.2
> but not on Debian 10 with Git 2.20.1
>
> > git init
> Initialized empty Git repository in .../git-test/.git/
> > echo "test" > file.txt
> > git add file.txt
> > git commit -m "Import"
> [main (root-commit) f73709f] Import
> 1 file changed, 1 insertion(+)
> create mode 100644 file.txt
> > stat -c '%y' file.txt
> 2022-01-19 18:43:52.147781748 +0100
> > ls -i file.txt
> 74458979 file.txt
> > ln file.txt ../file.txt
> > git reset --hard
> HEAD is now at f73709f Import
> > stat -c '%y' file.txt
> 2022-01-19 18:44:47.013167127 +0100
> > ls -i file.txt
> 74458995 file.txt
>
> Can this behavior be avoided?
Git generally doesn't guarantee that it will preserve hard links in any
particular situation. It can and does replace files rather than writing
over the existing ones, so this behavior is expected in at least some
circumstances.
Whether it happens in this particular case probably depends on what data
is in the index and whether it's considered stale, since if the file is
out of date, I believe a git reset --hard will replace it rather than
try to determine whether it's up to date.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [relevance 0%]
* A puzzle: reset --hard and hard links
@ 2022-01-19 20:37 4% Michael Herrmann
2022-01-19 22:20 0% ` brian m. carlson
0 siblings, 1 reply; 69+ results
From: Michael Herrmann @ 2022-01-19 20:37 UTC (permalink / raw)
To: git
Hi all,
It seems `git reset --hard` recreates files that have external hard
links. Is this intended?
The example below highlights the behavior. I have an unchanged Git
repository. When I create an (outside) hard link to a file in the
repository, then `git reset --hard` re-creates the file with a new
modification time and inode. This occurs on Debian 11 with Git 2.30.2
but not on Debian 10 with Git 2.20.1
> git init
Initialized empty Git repository in .../git-test/.git/
> echo "test" > file.txt
> git add file.txt
> git commit -m "Import"
[main (root-commit) f73709f] Import
1 file changed, 1 insertion(+)
create mode 100644 file.txt
> stat -c '%y' file.txt
2022-01-19 18:43:52.147781748 +0100
> ls -i file.txt
74458979 file.txt
> ln file.txt ../file.txt
> git reset --hard
HEAD is now at f73709f Import
> stat -c '%y' file.txt
2022-01-19 18:44:47.013167127 +0100
> ls -i file.txt
74458995 file.txt
Can this behavior be avoided?
Best,
Michael
^ permalink raw reply [relevance 4%]
* Re: Regression in 8d92fb292706 ("dir: replace exponential algorithm with a linear one")
2021-12-07 5:29 0% ` Elijah Newren
@ 2021-12-07 7:14 0% ` Uwe Kleine-König
0 siblings, 0 replies; 69+ results
From: Uwe Kleine-König @ 2021-12-07 7:14 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List, Björn Lässig
[-- Attachment #1: Type: text/plain, Size: 6222 bytes --]
Hello,
first of all thanks for addressing my report, also to brian.
On Mon, Dec 06, 2021 at 09:29:59PM -0800, Elijah Newren wrote:
> On Mon, Dec 6, 2021 at 4:16 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > I admit this is somewhat of a corner case, still it happens in the
> > reality of our admin team ...
> > Initially this was noticed after upgrading the OS from Debian buster
> > (with git 2.20.1) to Debian bullseye (with git 2.30.2).
> >
> > (wgit is just a wrapper for git to call it from my ~/src/git.)
> >
> > This is the good ("old") case:
> >
> > uwe@taurus:~/tmp/8d92fb29270$ wgit version
> > git version 2.25.2.7.g0bbd0e8b5233
> >
> > uwe@taurus:~/tmp/8d92fb292706$ wgit init
> > Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
> >
> > uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
> > uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
> > uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
> > Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
> > uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
> >
> > uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
> > uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
> > uwe@taurus:~/tmp/8d92fb292706$ wgit status
> > On branch master
> >
> > No commits yet
> >
> > Changes to be committed:
> > (use "git rm --cached <file>..." to unstage)
> > new file: subdir/somefile
>
> Eek, that's bad. I think there's a number of dragons going down that route.
Yes, as soon as you start to checkout files in one of the involved
repositories you implicitly change the other one. In this case git is
only used to track files in /etc and elsewhere, and there are two
mechanisms to track them. (Don't ask for the reasons, I don't know them.
:-) In this setup (I think) the dragons should be well fixed to their
chains.
> > with 8d92fb292706, the following happens:
> >
> > uwe@taurus:~/tmp/8d92fb292706$ wgit version
> > git version 2.25.2.8.g8d92fb292706
> > uwe@taurus:~/tmp/8d92fb292706$ wgit init
> > Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
> > uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
> > uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
> > uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
> > Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
> > uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
> > uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
> > uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
>
> Not optimal; more on this below.
>
> > uwe@taurus:~/tmp/8d92fb292706$ wgit status
> > On branch master
> >
> > No commits yet
> >
> > Untracked files:
> > (use "git add <file>..." to include in what will be committed)
> > subdir/
> >
> > nothing added to commit but untracked files present (use "git add" to track)
>
> This part looks good to me.
>
> > So git after 8d92fb292706 doesn't add files from a subdirectory if
> > said subdirectory is tracked in git, too.
> >
> > While I'm not sure which of the two behaviours is the bogus one, this is
> > a change in behaviour that I guess wasn't intended in 8d92fb292706.
>
> I put some effort separate from that commit into avoiding accidentally
> recursing into nested git dirs; see e.g. commit 09487f2cba ("clean:
> avoid removing untracked files in a nested git repository",
> 2019-09-17). So, I was slightly surprised that some other commit
> hadn't fixed this.
>
> However, it's not all that surprising to me that 8d92fb292706 affected
> this. Prior to that commit, we visited untracked paths which were n
> directories deep a ridiculous 2^n times. But what made it even more
> fun was that the status returned for any given path (tracked, ignored,
> not interesting to the traversal, etc.) was not always the same; later
> traversals might return something different than earlier traversals.
> That confusion made it real "fun" trying to ensure no regressions when
> reducing the number of visits to any given path from 2^n down to 1.
> The fact that side effects of the traversals (the population of the
> dir.entries and dir.ignored) could have essentially functioned to
> override a later traversal's return status certainly didn't help; it
> was such a mess.
>
> But, interestingly, the fixed behavior here also depends pretty
> strongly on commit b9670c1f5e ("dir: fix checks on common prefix
> directory", 2019-12-19) which came months earlier. This is
> particularly important in combination with the following comment from
> dir.h:
> /**
> * If set, recurse into a directory that looks like a Git directory.
> * Otherwise it is shown as a directory.
> */
> DIR_NO_GITLINKS = 1<<3,
> which suggests that cmd_add() (which didn't set this flag) should have
> never been recursing into a Git-tracked directory. In other words,
> this was a bug all along.
>
> > Is this something that needs fixing?
>
> I agree with brian elsewhere in this thread that not adding the file
> is correct. However, two points:
>
> * I would prefer to see a warning/error from git add when it doesn't
> add a path (Any takers? #leftoverbits maybe?)
Agreed, also maybe return an exit code != 0?
> * It is possible that one might want to be able to force the addition
> of files to an outer repository despite existing within a directory
> tracked by an inner git repository, perhaps with a double `--force`
> being passed to git-add (much like git-clean allows). If so, that
> could be implemented via the addition of
> dir.flags |= DIR_NO_GITLINKS;
> to cmd_add() when the double force is detected.
I think this would be good.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [relevance 0%]
* Re: Regression in 8d92fb292706 ("dir: replace exponential algorithm with a linear one")
2021-12-06 12:16 3% Regression in 8d92fb292706 ("dir: replace exponential algorithm with a linear one") Uwe Kleine-König
@ 2021-12-07 5:29 0% ` Elijah Newren
2021-12-07 7:14 0% ` Uwe Kleine-König
0 siblings, 1 reply; 69+ results
From: Elijah Newren @ 2021-12-07 5:29 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Git Mailing List, Björn Lässig
On Mon, Dec 6, 2021 at 4:16 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> I admit this is somewhat of a corner case, still it happens in the
> reality of our admin team ...
> Initially this was noticed after upgrading the OS from Debian buster
> (with git 2.20.1) to Debian bullseye (with git 2.30.2).
>
> (wgit is just a wrapper for git to call it from my ~/src/git.)
>
> This is the good ("old") case:
>
> uwe@taurus:~/tmp/8d92fb29270$ wgit version
> git version 2.25.2.7.g0bbd0e8b5233
>
> uwe@taurus:~/tmp/8d92fb292706$ wgit init
> Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
>
> uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
> uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
> uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
> Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
> uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
>
> uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
> uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
> uwe@taurus:~/tmp/8d92fb292706$ wgit status
> On branch master
>
> No commits yet
>
> Changes to be committed:
> (use "git rm --cached <file>..." to unstage)
> new file: subdir/somefile
Eek, that's bad. I think there's a number of dragons going down that route.
> with 8d92fb292706, the following happens:
>
> uwe@taurus:~/tmp/8d92fb292706$ wgit version
> git version 2.25.2.8.g8d92fb292706
> uwe@taurus:~/tmp/8d92fb292706$ wgit init
> Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
> uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
> uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
> uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
> Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
> uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
> uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
> uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
Not optimal; more on this below.
> uwe@taurus:~/tmp/8d92fb292706$ wgit status
> On branch master
>
> No commits yet
>
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
> subdir/
>
> nothing added to commit but untracked files present (use "git add" to track)
This part looks good to me.
> So git after 8d92fb292706 doesn't add files from a subdirectory if
> said subdirectory is tracked in git, too.
>
> While I'm not sure which of the two behaviours is the bogus one, this is
> a change in behaviour that I guess wasn't intended in 8d92fb292706.
I put some effort separate from that commit into avoiding accidentally
recursing into nested git dirs; see e.g. commit 09487f2cba ("clean:
avoid removing untracked files in a nested git repository",
2019-09-17). So, I was slightly surprised that some other commit
hadn't fixed this.
However, it's not all that surprising to me that 8d92fb292706 affected
this. Prior to that commit, we visited untracked paths which were n
directories deep a ridiculous 2^n times. But what made it even more
fun was that the status returned for any given path (tracked, ignored,
not interesting to the traversal, etc.) was not always the same; later
traversals might return something different than earlier traversals.
That confusion made it real "fun" trying to ensure no regressions when
reducing the number of visits to any given path from 2^n down to 1.
The fact that side effects of the traversals (the population of the
dir.entries and dir.ignored) could have essentially functioned to
override a later traversal's return status certainly didn't help; it
was such a mess.
But, interestingly, the fixed behavior here also depends pretty
strongly on commit b9670c1f5e ("dir: fix checks on common prefix
directory", 2019-12-19) which came months earlier. This is
particularly important in combination with the following comment from
dir.h:
/**
* If set, recurse into a directory that looks like a Git directory.
* Otherwise it is shown as a directory.
*/
DIR_NO_GITLINKS = 1<<3,
which suggests that cmd_add() (which didn't set this flag) should have
never been recursing into a Git-tracked directory. In other words,
this was a bug all along.
> Is this something that needs fixing?
I agree with brian elsewhere in this thread that not adding the file
is correct. However, two points:
* I would prefer to see a warning/error from git add when it doesn't
add a path (Any takers? #leftoverbits maybe?)
* It is possible that one might want to be able to force the addition
of files to an outer repository despite existing within a directory
tracked by an inner git repository, perhaps with a double `--force`
being passed to git-add (much like git-clean allows). If so, that
could be implemented via the addition of
dir.flags |= DIR_NO_GITLINKS;
to cmd_add() when the double force is detected.
Hope that helps,
Elijah
^ permalink raw reply [relevance 0%]
* Regression in 8d92fb292706 ("dir: replace exponential algorithm with a linear one")
@ 2021-12-06 12:16 3% Uwe Kleine-König
2021-12-07 5:29 0% ` Elijah Newren
0 siblings, 1 reply; 69+ results
From: Uwe Kleine-König @ 2021-12-06 12:16 UTC (permalink / raw)
To: git; +Cc: Elijah Newren, Björn Lässig
[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]
Hello,
I admit this is somewhat of a corner case, still it happens in the
reality of our admin team ...
Initially this was noticed after upgrading the OS from Debian buster
(with git 2.20.1) to Debian bullseye (with git 2.30.2).
(wgit is just a wrapper for git to call it from my ~/src/git.)
This is the good ("old") case:
uwe@taurus:~/tmp/8d92fb29270$ wgit version
git version 2.25.2.7.g0bbd0e8b5233
uwe@taurus:~/tmp/8d92fb292706$ wgit init
Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
uwe@taurus:~/tmp/8d92fb292706$ wgit status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: subdir/somefile
with 8d92fb292706, the following happens:
uwe@taurus:~/tmp/8d92fb292706$ wgit version
git version 2.25.2.8.g8d92fb292706
uwe@taurus:~/tmp/8d92fb292706$ wgit init
Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/.git/
uwe@taurus:~/tmp/8d92fb292706$ mkdir subdir
uwe@taurus:~/tmp/8d92fb292706$ cd subdir/
uwe@taurus:~/tmp/8d92fb292706/subdir$ wgit init
Initialized empty Git repository in /home/uwe/tmp/8d92fb292706/subdir/.git/
uwe@taurus:~/tmp/8d92fb292706/subdir$ cd ..
uwe@taurus:~/tmp/8d92fb292706$ echo content > subdir/somefile
uwe@taurus:~/tmp/8d92fb292706$ wgit add subdir/somefile
uwe@taurus:~/tmp/8d92fb292706$ wgit status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
subdir/
nothing added to commit but untracked files present (use "git add" to track)
So git after 8d92fb292706 doesn't add files from a subdirectory if
said subdirectory is tracked in git, too.
While I'm not sure which of the two behaviours is the bogus one, this is
a change in behaviour that I guess wasn't intended in 8d92fb292706.
Is this something that needs fixing?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [relevance 3%]
* Re: Weird interaction between Git protocol versions and git:// and https:// URLs (was: Re: Bug with Git shallow clones and submodules)
2021-09-02 13:49 4% ` Weird interaction between Git protocol versions and git:// and https:// URLs (was: Re: Bug with Git shallow clones and submodules) Philippe Blain
@ 2021-09-04 12:57 0% ` Jeff King
0 siblings, 0 replies; 69+ results
From: Jeff King @ 2021-09-04 12:57 UTC (permalink / raw)
To: Philippe Blain
Cc: Kevin Phillips, git, Jonathan Tan, Emily Shaffer,
Brandon Williams, brian m . carlson
On Thu, Sep 02, 2021 at 09:49:38AM -0400, Philippe Blain wrote:
> > OK, it's running Git 2.20.1. And the list of capabilities above implies that it's responding
> > with protocol v0, even if my local Git version if 2.29, which defaults to protocol v2. If
> > it were responding with protocol v2, we would see:
> >
> > $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep agent
> > packet: git< agent=git/github-g78b452413e8b # server version
> > packet: git< agent=git/github-g78b452413e8b
> > packet: git> agent=git/2.29.2 # client version
> > packet: git< agent=git/2.29.2
> >
> > And grepping for "version" would confirm it:
> >
> > $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep version
> > packet: git< version 2
> > packet: git< version 2
> >
> > I can't explain why the server refuses to talk with protocol v2. Maybe Jonathan (CC-ed),
> > who worked on the implementation of protocol v2, would be able to explain that.
>
> I'm sorry to bump this, but I would really like to understand what is going on here.
> I'm not familiar at all with the protocol code, but my understanding was that after
> Git 2.18, if a client requested protocol v2, the server would answer with v2 (at least
> for git:// and http[s]://, and also for ssh:// if AcceptEnv is correctly configured).
> Here, Git 2.20.1 at https://dpdk.org/git/dpdk-stable answers with v0 for https://,
> but with v2 for git:// !
The server has to be configured correctly at the HTTP level, too. The v2
probe for HTTP is a "Git-Protocol: version=2" header in the HTTP
request. The webserver has to be configured to communicate that to the
rest of Git somehow. In our test setup for Apache, we do:
SetEnvIf Git-Protocol ".*" GIT_PROTOCOL=$0
If that doesn't happen, then the server doesn't see the header at all,
and just speaks v0 as usual.
I suspect this could be better documented. I have to admit that I have
not actually run a regular HTTP server with Git in a long time (at
GitHub, we have our own custom layer that terminates the HTTP
connections).
-Peff
^ permalink raw reply [relevance 0%]
* Weird interaction between Git protocol versions and git:// and https:// URLs (was: Re: Bug with Git shallow clones and submodules)
2021-08-15 14:31 4% ` Philippe Blain
@ 2021-09-02 13:49 4% ` Philippe Blain
2021-09-04 12:57 0% ` Jeff King
0 siblings, 1 reply; 69+ results
From: Philippe Blain @ 2021-09-02 13:49 UTC (permalink / raw)
To: Kevin Phillips, git, Jonathan Tan, Emily Shaffer
Cc: Jeff King, Brandon Williams, brian m . carlson
Hi everyone,
Le 2021-08-15 à 10:31, Philippe Blain a écrit :
> 5. It falls back to fetching the needed commit by its hash:
>
> start git fetch origin 78bc27846101e481438a98c68cac47e4476085c0
>
> 6. The server at https://dpdk.org/git/dpdk-stable refuses this request and you get
>
> error: Server does not allow request for unadvertised object 78bc27846101e481438a98c68cac47e4476085c0
>
> OK so why does the server refuses the request ? If you take a look at [4], you will
> understand that it's probably because the configs 'uploadpack.allowReachableSHA1InWant'
> and 'uploadpack.allowAnySHA1InWant' are both false (i.e. their default value) on the
> https://dpdk.org/git/dpdk-stable server. So the behaviour here is not a bug, it's
> working as it should (but leads to a bad experience for you).
>
> What is not unfortunately not mentioned in the documentation at [4]
> is that the two configs that I mention above only apply if version 0 of the Git transfer
> protocol is in effect. So this would mean that even though we specify '-c protocol.version=2'
> in the 'git clone' command in my script, the server uses protocol v0. Protocol v2 works
> starting in Git 2.18, so let's check what version is running at dpdk.org:
>
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://dpdk.org/git/dpdk-stable 2>&1 | grep agent
> packet: git< 6ee0521feb765d9105241a3f6693762c471655cf HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/default agent=git/2.20.1
>
> OK, it's running Git 2.20.1. And the list of capabilities above implies that it's responding
> with protocol v0, even if my local Git version if 2.29, which defaults to protocol v2. If
> it were responding with protocol v2, we would see:
>
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep agent
> packet: git< agent=git/github-g78b452413e8b # server version
> packet: git< agent=git/github-g78b452413e8b
> packet: git> agent=git/2.29.2 # client version
> packet: git< agent=git/2.29.2
>
> And grepping for "version" would confirm it:
>
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep version
> packet: git< version 2
> packet: git< version 2
>
> I can't explain why the server refuses to talk with protocol v2. Maybe Jonathan (CC-ed),
> who worked on the implementation of protocol v2, would be able to explain that.
I'm sorry to bump this, but I would really like to understand what is going on here.
I'm not familiar at all with the protocol code, but my understanding was that after
Git 2.18, if a client requested protocol v2, the server would answer with v2 (at least
for git:// and http[s]://, and also for ssh:// if AcceptEnv is correctly configured).
Here, Git 2.20.1 at https://dpdk.org/git/dpdk-stable answers with v0 for https://,
but with v2 for git:// !
>
> And it gets weirder. If you instead use the Git URL (instead of the HTTPS URL)
> for the dpdk-stable submodule [2], then the server responds with protocol v2!
>
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://dpdk.org/dpdk-stable 2>&1 | grep agent
> packet: git< agent=git/2.20.1
> packet: git> agent=git/2.29.2
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://dpdk.org/dpdk-stable 2>&1 | grep version
> packet: git> git-upload-pack /dpdk-stable\0host=dpdk.org\0\0version=2\0
> packet: git< version 2
>
> And indeed, if you use the 'git://' URL in the 'git submodule add' command in my reproducer
> script, it succeeds !
>
> It don't understand this behaviour either.
>
--- snip ---
>
> P.S. for Jonathan I noticed some additional weirdness while debugging this:
> Some servers respond with a different Git version depending on the protocol:
>
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://gcc.gnu.org/git/gcc.git 2>&1 | grep -E 'agent|version '
> packet: git< version 2
> packet: git< agent=git/2.26.2
> packet: git> agent=git/2.29.2
> $ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://gcc.gnu.org/git/gcc.git 2>&1 | grep agent -E 'agent|version '
> packet: git< 882f1d58bfa56737ff2de84c3cd1e0acfc318b86 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.27.0
>
> Here again, with HTTPS we fall back to protocol v0. The same behaviour happens
> with git://sourceware.org/git/binutils-gdb.git...
This is also puzzling to me...
Thanks,
Philippe.
^ permalink raw reply [relevance 4%]
* Re: Automatically Handling Using/Checking Out Branches With One or More Different Contained Submodules?
@ 2021-08-27 22:48 0% ` Philippe Blain
0 siblings, 0 replies; 69+ results
From: Philippe Blain @ 2021-08-27 22:48 UTC (permalink / raw)
To: Bryce Glover, git; +Cc: Emily Shaffer
Hi Bryce,
Le 2021-08-24 à 08:00, Bryce Glover a écrit :
> (Note: If this question would fit better on the git-users Google
> Group, I apologize, but I saw that, unlike there — unless I overlooked
> something? —, you could send messages here even if you weren't a list
> subscriber.)
>
> To whom it may concern,
>
> Currently, the only method I've seen that you can reliably use to
> switch between different branches when they don't all have the same
> contained submodules comes from the Stack Overflow answer at
> <https://stackoverflow.com/a/64690495/3319611>. I'll reproduce the
> Bash snippet it presents as a solution here for completeness's sake:
>
> ```
> export TARGET_BRANCH="my-branch-name"
> export CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
> if [ -f ".gitmodules" ]; then
> git submodules deinit --all
> mkdir -p .git/git-tools/modules
> mv .git/modules .git/git-tools/modules/$CURRENT_BRANCH
> fi
>
> git checkout $TARGET_BRANCH
>
> if [ -f ".gitmodules" ]; then
> if [ -f ".git/git-tools/modules/$TARGET_BRANCH" ]; then
> git mv .git/git-tools/modules/$TARGET_BRANCH .git/modules
> fi
>
> git submodule sync && git submodule update --init
> fi
> ```
>
> This involves invoking some actions before '`git checkout`,' so I
> couldn't have a couple of Git hooks handle this since, per '`git help
> hooks`,' Git doesn't implement a 'pre-checkout' hook, only a
> post-checkout one. That wouldn't be enough of a use case to motivate
> adding that, though, would it? Alternatively, '`git checkout`'
> would, ideally, handle this automatically, perhaps when requested by
> flag if it wouldn't make sense for this behavior to be the default
> one. I don't know if I'd personally be up to contributing either one
> or both of either of those approaches, at least not right away, but,
> hypothetically, how involved might that turn out to be?
The script above is in my opinion complicated and uneeded. I will copy below some content
from the original stackoverflow post, and reply inline. The bottom line is:
1. 'git checkout --recurse-submodules $ref' should always work in an ideal
world, but there are still some missing pieces as of today.
2. 'git checkout $ref && git submodule sync --recursive && git submodule update
--recursive' should always work.
Here goes:
> The problem I am facing is that I cannot figure out a set of git commands that
> will consistently work in all cases when switching between branches if the
> branch has submodules. In my test, I have one repo with 3 branches, one branch
> has no submodules (master), another module [sic, should be "branch"] has 1 submodule (submodule-test),
> and another branch has another submodule (submodule-test2) that points to a
> different repository (at the same path).
[...]
> In example here is one set of commands and their failure in git 2.20.1
>
> cd /tmp
> git clone git@github.com:simpleviewinc/git-tools-test.git ./checkout --recurse-submodules
> cd checkout
> git checkout submodule-test
> git submodule sync
> git submodule update
> # branch submodule-test fully checked out, all submodules downloaded, looking good!
> git submodule deinit --all
> git checkout submodule-test2
> git submodule sync
> git submodule update
> fatal: remote error: upload-pack: not our ref c1bba6e3969937125248ee46e308a8efec8ac654
> Fetched in submodule path 'submodule', but it did not contain c1bba6e3969937125248ee46e308a8efec8ac654. Direct fetching of that commit failed.
> It fails because it uses the wrong submodule remote, even though I thought that was the explicit purpose of submodule sync.
The reason it fails is because the 'git submodule sync' did *not* update the
'remote.origin.url' configuration in the Git config file of the submodule, i.e.
/tmp/checkout/.git/modules/submodule/config, despite (confusingly) outputing
"Synchronizing submodule url for 'submodule'". It does change the
'submodule.$name.url' value in the config file *of the superproject*, though,
(/tmp/checkout/.git/config) but 'git submodule update' only uses
'remote.origin.url' in the submodule's config file (if it exists).
The reason why the second 'git submodule sync' does not change
remote.origin.url is because the submodule has been deinitialized when the
command is run, because the previous command is 'git submodule deinit --all',
which deinitializes all submodules. So this second step of changing
'remote.origin.url' is skipped for deinitialized submodules (this fact is
missing from the doc).
The following sequence would be the correct one:
git clone git@github.com:simpleviewinc/git-tools-test.git ./checkout [--recurse-submodules] # --recurse-submodules is optional
cd checkout
git checkout submodule-test
git submodule update --init
git checkout submodule-test2
git submodule sync
git submodule update
# and we can switch back
git checkout submodule-test
git submodule sync
git submodule update
Note that the correct command to initialize all submodules is 'git submodule
init' or, to initialize, clone and check them out in a single step, 'git
submodule update --init'. The fact that the first 'git submodule sync' works to
initialize the submodule is in fact due to using '--recurse-submodules' for
'git clone', which sets 'submodule.active' to the match-all pathspec '.' in the
superproject's config, and 'git submodule sync' recurses into *active*
submodules (this is also missing from the doc).
So for 'git checkout', what you want to achieve can be done with a
post-checkout hook:
```shell
#!/bin/sh
# If the checkout was a branch checkout [1], update the submodules
# to the commits recorded in the superproject
# [1] https://git-scm.com/docs/githooks#_post_checkout
previous_head=$1
new_head=$2
checkout_type_flag=$3
if [ "$checkout_type_flag" -eq 1 ] ; then
git submodule sync --recursive
git submodule update --init --recursive
fi
```
Here I add '--recursive' to both commands for extra safety in case any of your
submodules themselve contain submodules.
Now, about 'git checkout --recurse-submodules':
> I tried --recurse-submodules but that fails too, but this time when checking
> from a branch without submodules to a branch with submodules.
>
> cd /tmp
> git clone git@github.com:simpleviewinc/git-tools-test.git ./checkout --recurse-submodules
> cd checkout
> git checkout submodule-test --recurse-submodules
> fatal: not a git repository: ../.git/modules/submodule
> fatal: could not reset submodule index
Yeah, that one is bad. The reason it fails is because:
1. 'git clone --recurse-submodules' in fact runs a simple 'git submodule update
--init --recursive' at the end of the process, at the step where it's checking
out the working tree. This means that only submodules present *in the branch
being checked out* get initialized and cloned.
2. 'git clone --recurse-submodules' *always* writes 'submodule.active=.' to the
superproject's config.
3. 'git checkout --recurse-submodules' recurses into active submodules, and for
that it needs access to the Git repository of the submodule, which does not
exist yet since it was not cloned.
This is the same error you get when you try to recursively checkout an older
revision that contains a submodule that was since deleted [1], [2].
I suggested in those threads a few ways all this could be improved; here is my
up to date take on the subject:
1. 'git clone --recurse-submodules' should be able to at least clone *all*
submodules for *all* branches that are cloned, and put their Git directory in
.git/modules/. This would allow your use case to "just work" with 'git
checkout --recurse-submodules'
2. 'git clone --recurse-submodules' could also be taught to clone all
submodules for *all* revisions of *all* branches that are cloned. This would
allow the "deleted submodule" cases I mentioned to work, but would not be
wanted in all situations, so it could be a supplementary flag to 'git clone'.
3. 'git fetch' should be taught to clone new submodules.
4. 'git checkout --recurse-submodules' could be taught to clone missing
submodules and fetch missing submodules commits. This would cover both your
use case as well as the "deleted submodule" use case.
5. In any case, 'git checkout --recurse-submodules' should not abort midway if
it can't find the Git repository of the submodule and leave '.gitmodules'
untracked in the working tree, and a 'config' file in .git/modules/$name/ with
only 'core.worktree' set.
Hope that helps,
Philippe Blain.
[1] https://lore.kernel.org/git/20200501005432.h62dnpkx7feb7rto@glandium.org/T/#u
[2] https://lore.kernel.org/git/CAE5ih78zCR0ZdHAjoxguUb3Y6KFkZcoxJjhS7rkbtZpr+d1n=g@mail.gmail.com/t/#u
^ permalink raw reply [relevance 0%]
* Re: Bug with Git shallow clones and submodules
@ 2021-08-15 14:31 4% ` Philippe Blain
2021-09-02 13:49 4% ` Weird interaction between Git protocol versions and git:// and https:// URLs (was: Re: Bug with Git shallow clones and submodules) Philippe Blain
0 siblings, 1 reply; 69+ results
From: Philippe Blain @ 2021-08-15 14:31 UTC (permalink / raw)
To: Kevin Phillips, git, Jonathan Tan, Emily Shaffer
Hi Kevin,
Le 2021-08-11 à 10:59, Kevin Phillips a écrit :
> We recently came across a bug in one of our Git projects which make
> use of submodules. The basic problem is we have a Git repo that has 1
> submodule within it which is set up to check out a specific branch,
Just to make sure we are on the same page: you can't have a submodule
"set up to check out a specific branch", at least
not in the sense that the submodule is always "checked out" on a branch,
and the superproject knows that the submodule should always be "on that branch";
that's not how submodules work. As specified in [1], the config `submodule.<name>.branch`
which your repo has in '.gitmodules' is only ever used by
`git submodule update --remote`. The superproject itself only records at which *commit* the
submodule is at.
> and when we attempt to perform a shallow clone on the parent repo the
> checkout fails with a "Server does not allow request for unadvertised
> object" error. After doing a lot of testing and reading online I found
> this StackOverflow thread (https://stackoverflow.com/a/61492323) that
> explains our problem in great detail, which indicates to me that this
> is likely not a problem specific to us, so I thought I'd report it to
> see if it could be fixed.
I think your situation is related, but not exactly the same as the SO
post. But torek's answer sure explains a lot of important points that
are relevant in your situation.
>
> In our specific use case, we found the problem specifically when
> running a build of our project using Gitlab CI. This tool
> automatically performs a shallow checkout of projects being built by
> using a "--depth=50" parameter. This caused odd Git checkout errors to
> appear on our CI builds which weren't directly reproducible by our
> developers local builds. Upon closer examination we were able to
> reproduce outside of the CI environment by performing a checkout as
> follows:
>
> git clone --recurse-submodules --depth=50 git@<path_to_repo>.git .
>
> Based on my initial research, which was helped greatly by the
> StackOverflow thread I linked to above, I was able to deduce the
> following contributing factors:
>
> The submodule that was causing us grief was the dpdk library located
> here: http://git.dpdk.org/dpdk-stable/
>
> This repository has a default branch named "default" which has only 2
> commits on it: one for initializing the repo and one additional commit
> All releases of this library are created from branches named by the
> release version, and they all seem disjoint from one another, and they
> are all disjoint from the default branch (ie: changes from the release
> branches are never merged into the default branch)
>
> our parent repo, which is an internal / non-public repository that can
> not be shared, has a single submodule defined in it with the following
> .gitmodule definition:
>
>
> [submodule "dpdk-stable"]
> path = dpdk-stable
> url = https://git@dpdk.org/git/dpdk-stable
> branch = 19.11
>
> the specific revision we are checking out has the OID
> 78bc27846101e481438a98c68cac47e4476085c0 which corresponds to the
> 19.11.8 tag
> the following git clone operation succeeds:
>
> git clone --recurse-submodules git@<path_to_repo>.git .
>
> the following git clone operation fails:
>
> git clone --recurse-submodules --depth=50 git@<path_to_repo>.git .
Thanks for the details here. I came up with this short reproducer script,
which I think shows the behaviour you are seeing:
~~~bash
#!/bin/bash
set -e
rm -rf test && mkdir test && cd test
rm -rf project clone
# Create project
git init project && cd project
echo "content">file
git add file
git commit -m "initial in proj"
git submodule add -b 19.11 https://dpdk.org/git/dpdk-stable
git -C dpdk-stable -q checkout 78bc27846101e481438a98c68cac47e4476085c0
git add dpdk-stable
git commit -m "add lib to project"
cd ../
# Clone project
GIT_TRACE2=3 git -c protocol.version=2 clone --no-local --recurse-submodules --depth=50 project clone 3> >(grep -E 'git clone|git fetch|git submodule|git rev-list' )
~~~
Note that in the "Create project" phase, I use the HTTPS URL
https://dpdk.org/git/dpdk-stable, which is the recommended HTTPS URL at [2].
>
> we can work around the problem by doing a shallow clone with the
> no-single-branch parameter, as in:
>
> git clone --recurse-submodules --depth=50 --no-single-branch
> git@<path_to_repo>.git .
>
> Based on my current level of understanding, Git is automatically
> setting the --single-branch flag when cloning submodules but only when
> doing a shallow clone of the parent. This seems wrong to me.
In fact, the logic in the code is twofold:
1. In 'git clone', '--depth' implies '--single-branch' [3]
2. In 'git clone', '--single-branch' is used to clone submodules if
'--recurse-submodules' is used. This is the case since 132f600b06
(clone: pass --single-branch during --recurse-submodules, 2020-02-20)
I'm not sure why you think this is wrong (in theory)...
> In
> addition, even if Git was going to enforce the single branch option on
> submodules it stands to reason that it should be respecting the branch
> defined in the .gitmodules file (ie: 19.11 in our case) instead of
> using the default branch (ie: "default" in this case).
... in practice, here you are right: it is indeed unfortunate that the
branch specified in '.gitmodules' is not used for the initial clone of
the submodule if they are cloned with '--single-branch'.
> My guess is, if
> it were respecting the branch name then we wouldn't be getting the
> "unadvertised object" error because the referenced OID would exist in
> the submodule checkout because it would have the correct branch
> checked out.
I think your are right, since the following command does work:
git clone --single-branch --branch 19.11 https://dpdk.org/git/dpdk-stable &&
git -C dpdk-stable checkout 78bc27846101e481438a98c68cac47e4476085c0
>
> For reference, this problem appears to be reproducible on several
> different platforms (ie: several different Linux distros and Mac OSX
> at least) and several different Git versions up to v2.32.0 which is
> the latest version at the moment. Hopefully this problem can be fixed
> in a future release of the command line tools. In the meantime we've
> had to hack around the problem in our Gitlab CI builds by disabling
> the shallow checkout features, which is less than ideal
If you run my reproducer script above, you should see the steps that the code
does to try to retrieve the commit you need, 78bc27846101e481438a98c68cac47e4476085c0:
1. It invokes 'git clone' for the submodule:
child_start[0] git clone --no-checkout --progress --separate-git-dir $PWD/test/clone/.git/modules/dpdk-stable --single-branch -- https://dpdk.org/git/dpdk-stable $PWD/test/clone/dpdk-stable
2. It checks if the clone downloaded the needed object:
start git rev-list -n 1 78bc27846101e481438a98c68cac47e4476085c0 --not --all
We know that it did not, because as noted above, the branch from '.gitmodules'
is not used in the single-branch clone, so only object from the 'default' branch
are available.
3. It realizes the object is not there, so it runs "git fetch" in the submodule
4. It checks again with the same 'git rev-list command' if the fetch downloaded
the needed object. Of course, it did not, because since the branch in '.gitmodules'
is not used for the initial single-branch clone, at that point the fetch refspec
in the submodule is '+refs/heads/default:refs/remotes/origin/default', and so a
simple 'git fetch' does not bring any new object.
5. It falls back to fetching the needed commit by its hash:
start git fetch origin 78bc27846101e481438a98c68cac47e4476085c0
6. The server at https://dpdk.org/git/dpdk-stable refuses this request and you get
error: Server does not allow request for unadvertised object 78bc27846101e481438a98c68cac47e4476085c0
OK so why does the server refuses the request ? If you take a look at [4], you will
understand that it's probably because the configs 'uploadpack.allowReachableSHA1InWant'
and 'uploadpack.allowAnySHA1InWant' are both false (i.e. their default value) on the
https://dpdk.org/git/dpdk-stable server. So the behaviour here is not a bug, it's
working as it should (but leads to a bad experience for you).
What is not unfortunately not mentioned in the documentation at [4]
is that the two configs that I mention above only apply if version 0 of the Git transfer
protocol is in effect. So this would mean that even though we specify '-c protocol.version=2'
in the 'git clone' command in my script, the server uses protocol v0. Protocol v2 works
starting in Git 2.18, so let's check what version is running at dpdk.org:
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://dpdk.org/git/dpdk-stable 2>&1 | grep agent
packet: git< 6ee0521feb765d9105241a3f6693762c471655cf HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/default agent=git/2.20.1
OK, it's running Git 2.20.1. And the list of capabilities above implies that it's responding
with protocol v0, even if my local Git version if 2.29, which defaults to protocol v2. If
it were responding with protocol v2, we would see:
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep agent
packet: git< agent=git/github-g78b452413e8b # server version
packet: git< agent=git/github-g78b452413e8b
packet: git> agent=git/2.29.2 # client version
packet: git< agent=git/2.29.2
And grepping for "version" would confirm it:
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://github.com/git/git 2>&1 | grep version
packet: git< version 2
packet: git< version 2
I can't explain why the server refuses to talk with protocol v2. Maybe Jonathan (CC-ed),
who worked on the implementation of protocol v2, would be able to explain that.
And it gets weirder. If you instead use the Git URL (instead of the HTTPS URL)
for the dpdk-stable submodule [2], then the server responds with protocol v2!
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://dpdk.org/dpdk-stable 2>&1 | grep agent
packet: git< agent=git/2.20.1
packet: git> agent=git/2.29.2
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://dpdk.org/dpdk-stable 2>&1 | grep version
packet: git> git-upload-pack /dpdk-stable\0host=dpdk.org\0\0version=2\0
packet: git< version 2
And indeed, if you use the 'git://' URL in the 'git submodule add' command in my reproducer
script, it succeeds !
It don't understand this behaviour either.
So a workaround for you would be to use the 'git://' URL in your '.gitmodules',
if the Git port (9418) is not blocked in your infrastructure.
I hope this helps,
Philippe.
P.S. for Jonathan I noticed some additional weirdness while debugging this:
Some servers respond with a different Git version depending on the protocol:
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote git://gcc.gnu.org/git/gcc.git 2>&1 | grep -E 'agent|version '
packet: git< version 2
packet: git< agent=git/2.26.2
packet: git> agent=git/2.29.2
$ GIT_TRACE_PACKET=1 GIT_TRACE_BARE=1 git ls-remote https://gcc.gnu.org/git/gcc.git 2>&1 | grep agent -E 'agent|version '
packet: git< 882f1d58bfa56737ff2de84c3cd1e0acfc318b86 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed no-done symref=HEAD:refs/heads/master agent=git/2.27.0
Here again, with HTTPS we fall back to protocol v0. The same behaviour happens
with git://sourceware.org/git/binutils-gdb.git...
1. https://git-scm.com/docs/git-submodule#Documentation/git-submodule.txt--bltbranchgt
2. https://core.dpdk.org/contribute/#clone
3. https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt
4. https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackallowReachableSHA1InWant
^ permalink raw reply [relevance 4%]
* segfault on invalid 'git grep' invocation
@ 2021-06-28 12:17 4% Matthew Hughes
0 siblings, 0 replies; 69+ results
From: Matthew Hughes @ 2021-06-28 12:17 UTC (permalink / raw)
To: git
Hi all,
It's my first time writing to this mailing list, so apologies in advance
for any mistakes/faux pas.
Summary
=======
Segfault seen when running:
$ ./git grep --and -e 'pattern' -- not_a_path
Expected Behaviour
==================
The above invocation doesn't appear particularly valid to me, I
accidentally ran it while editing a command. Not sure if this needs
addressing, but perhaps the expected behaviour would be an error message
about it not being valid?
Compare with, running without '--':
$ ./git grep --and -e 'pattern' not_a_path
fatal: ambiguous argument 'not_a_path': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Running with a valid path:
$ ./git grep --and -e 'pattern' -- common-main.c
fatal: Not a valid grep expression
$ ./git grep --and -e 'pattern' common-main.c
fatal: Not a valid grep expression
Background
==========
git version:
git version 2.32.0.93.g670b81a890
cpu: x86_64
built from commit: 670b81a890388c60b7032a4f5b879f2ece8c4558
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
compiler info: gnuc: 8.3
libc info: glibc: 2.28
$SHELL (typically, interactive shell): /bin/bash
Also reproduced on git 2.20.1 (packaged version on Debian 10)
The segfault is raised at free_pattern_expr (x=0x0) at grep.c:825 (on
commit 670b81a890388c60b7032a4f5b879f2ece8c4558)
Regards,
Matt
^ permalink raw reply [relevance 4%]
* Re: [RFC suggestion] Generate manpage directly with Asciidoctor
2021-05-11 6:13 0% ` Jeff King
@ 2021-05-11 8:03 0% ` Felipe Contreras
0 siblings, 0 replies; 69+ results
From: Felipe Contreras @ 2021-05-11 8:03 UTC (permalink / raw)
To: Jeff King, Felipe Contreras
Cc: Martin Ågren, brian m. carlson, Bagas Sanjaya, Git Users
Jeff King wrote:
> On Mon, May 10, 2021 at 11:27:54PM -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > It does create a situation where people like Randall on NonStop might
> > > need to do part of their dev work on another, more mainstream platform.
> > > But I suspect that is already the case.
> >
> > Or use distributed tarballs with already built documentation.
>
> For users, yes. But the context above is about people who are
> contributing to Git, and writing their own new documentation. Presumably
> they'd like to build it to see the output.
I'm a developer, I've added 261 lines and removed 212 lines to the
documentation, and I've very rarely built it. Why? Because it takes too
long.
But you were talking about Randall, who I don't know what his role is,
but my bet is that he is a packager. It's not the same thing. Randall
has contributed only one patch to the Documentation, and it was to
install pre-formatted documentation. Precisely what I thought he would be
interested in.
In fact, the bulk of his contribution was to install-doc-quick.sh, which
needs git-htmldocs and git-manpages. Two repositories I didn't even know
existed. So that's yet another option for him.
Of course Randall can say if he sees himself as a developer.
> > > That does make things a little less convenient; Debian stable, for
> > > instance, still has 1.5.8.
> >
> > And it has git 2.20.1, released at the end of 2018.
> >
> > I've never understood developers worried about how the bleeding edge
> > would build in ancient platforms, when ancient platforms don't care
> > about the bleeding edge.
>
> Again, this is about developers. Are there people contributing new
> documentation to Git who are doing so on Debian stable, and would be
> inconvenienced by needing to upgrade their toolchain?
Developers don't need to create (or use) debian packages. They can
simply do `gem install asciidoctor` and be done with it. Some may even
create a docker container to install all the doc toolchain in order to
avoid polluting their main environment.
I for one would start building the documentation more if all I needed is
one dependency.
> > > I'm unclear when support for python asciidoc goes away here. Is it part
> > > of step 6 (because it does not have another way of generating them)? Or
> > > does it live on forever as a non-default legacy system? I'd prefer not,
> > > but as long as we are clear about the primary target and leave it up to
> > > people interested in the legacy to do the compat fixes, that might be
> > > OK.
> >
> > How about we leave the legacy system in place as an alternative, and
> > decide later what to do with it?
>
> That's what I was asking.
>
> Leaving it forever does mean supporting xmlto forever, which complicates
> the Makefile (and that support will bitrot if people are not actually
> building it).
Indeed. If and when it's clear the xmlto part has bitrotten, and
people are happy with the asciidoc toolchain and output, then it can be
obsoleted.
That would be my vote (I don't think there will be a strong need to main
the xmlto parts).
It doesn't need to be decided today though.
--
Felipe Contreras
^ permalink raw reply [relevance 0%]
* Re: [RFC suggestion] Generate manpage directly with Asciidoctor
2021-05-11 4:27 4% ` Felipe Contreras
@ 2021-05-11 6:13 0% ` Jeff King
2021-05-11 8:03 0% ` Felipe Contreras
0 siblings, 1 reply; 69+ results
From: Jeff King @ 2021-05-11 6:13 UTC (permalink / raw)
To: Felipe Contreras
Cc: Martin Ågren, brian m. carlson, Bagas Sanjaya, Git Users
On Mon, May 10, 2021 at 11:27:54PM -0500, Felipe Contreras wrote:
> Jeff King wrote:
> > On Sun, May 09, 2021 at 10:20:37AM +0200, Martin Ågren wrote:
> > > In general, I agree. I do think it's important that "most people
> > > contributing to Git", whatever that means, can build the documentation
> > > to check the part they're adding/modifying and not find it broken left
> > > and right. They would then (quite rightly) not even bother building it.
> >
> > Agreed. But I think that is mostly the case (asciidoctor seems no harder
> > to acquire on most modern systems than asciidoc; there are system
> > packages in most cases, and decent binary-package systems for both ruby
> > and python if you really need it).
> >
> > It does create a situation where people like Randall on NonStop might
> > need to do part of their dev work on another, more mainstream platform.
> > But I suspect that is already the case.
>
> Or use distributed tarballs with already built documentation.
For users, yes. But the context above is about people who are
contributing to Git, and writing their own new documentation. Presumably
they'd like to build it to see the output.
> > That does make things a little less convenient; Debian stable, for
> > instance, still has 1.5.8.
>
> And it has git 2.20.1, released at the end of 2018.
>
> I've never understood developers worried about how the bleeding edge
> would build in ancient platforms, when ancient platforms don't care
> about the bleeding edge.
Again, this is about developers. Are there people contributing new
documentation to Git who are doing so on Debian stable, and would be
inconvenienced by needing to upgrade their toolchain?
> > > I think what I'm arguing for is
> > >
> > > 1) switch the default to asciidoctor,
> > > 2) enable optionally using it without xmlto,
> > > 3) figure out what broke and fix it, and document which is the minimum
> > > asciidoctor version we're going to bother with for (2),
> > > 4) lather, rinse, repeat (3),
> > > 5) switch the default to not using xmlto,
> > > 6) drop the xmlto way of generating the manpages(?).
> >
> > I'm unclear when support for python asciidoc goes away here. Is it part
> > of step 6 (because it does not have another way of generating them)? Or
> > does it live on forever as a non-default legacy system? I'd prefer not,
> > but as long as we are clear about the primary target and leave it up to
> > people interested in the legacy to do the compat fixes, that might be
> > OK.
>
> How about we leave the legacy system in place as an alternative, and
> decide later what to do with it?
That's what I was asking.
Leaving it forever does mean supporting xmlto forever, which complicates
the Makefile (and that support will bitrot if people are not actually
building it).
-Peff
^ permalink raw reply [relevance 0%]
* Re: [RFC suggestion] Generate manpage directly with Asciidoctor
@ 2021-05-11 4:27 4% ` Felipe Contreras
2021-05-11 6:13 0% ` Jeff King
0 siblings, 1 reply; 69+ results
From: Felipe Contreras @ 2021-05-11 4:27 UTC (permalink / raw)
To: Jeff King, Martin Ågren; +Cc: brian m. carlson, Bagas Sanjaya, Git Users
Jeff King wrote:
> On Sun, May 09, 2021 at 10:20:37AM +0200, Martin Ågren wrote:
> > In general, I agree. I do think it's important that "most people
> > contributing to Git", whatever that means, can build the documentation
> > to check the part they're adding/modifying and not find it broken left
> > and right. They would then (quite rightly) not even bother building it.
>
> Agreed. But I think that is mostly the case (asciidoctor seems no harder
> to acquire on most modern systems than asciidoc; there are system
> packages in most cases, and decent binary-package systems for both ruby
> and python if you really need it).
>
> It does create a situation where people like Randall on NonStop might
> need to do part of their dev work on another, more mainstream platform.
> But I suspect that is already the case.
Or use distributed tarballs with already built documentation.
I don't see any big issue with cross-compilation though.
> > When we looked at xmlto-less rendering around two years ago [1], we
> > found various asciidoctor bugs up to and around version 2.0. We would
> > likely need to require some >=2.0.x. The exact requirements will
> > probably only become clear when someone really does the work.
>
> That does make things a little less convenient; Debian stable, for
> instance, still has 1.5.8.
And it has git 2.20.1, released at the end of 2018.
I've never understood developers worried about how the bleeding edge
would build in ancient platforms, when ancient platforms don't care
about the bleeding edge.
> It's not too hard to install an updated gem, but not quite as nice as
> using the system package (it also makes things weird for building the
> stable Debian package itself, which would want to rely only on other
> packages; but of course any proposed change to the doc toolchain would
> be for new versions, and would not get backported there anyway).
Anyone trying to build git master on top of Debian stable 1. probably
can live with the output of the current doc toolchain, and 2. probably
doesn't exist.
I'm not sure how much the git project gains by worrying about such
a hypothetical person.
> > I think what I'm arguing for is
> >
> > 1) switch the default to asciidoctor,
> > 2) enable optionally using it without xmlto,
> > 3) figure out what broke and fix it, and document which is the minimum
> > asciidoctor version we're going to bother with for (2),
> > 4) lather, rinse, repeat (3),
> > 5) switch the default to not using xmlto,
> > 6) drop the xmlto way of generating the manpages(?).
>
> I'm unclear when support for python asciidoc goes away here. Is it part
> of step 6 (because it does not have another way of generating them)? Or
> does it live on forever as a non-default legacy system? I'd prefer not,
> but as long as we are clear about the primary target and leave it up to
> people interested in the legacy to do the compat fixes, that might be
> OK.
How about we leave the legacy system in place as an alternative, and
decide later what to do with it?
--
Felipe Contreras
^ permalink raw reply [relevance 4%]
* Re: git push over HTTP; long delay with no progress, then hang?
2020-05-16 4:09 4% git push over HTTP; long delay with no progress, then hang? Bryan Turner
@ 2020-05-16 6:37 0% ` SZEDER Gábor
0 siblings, 0 replies; 69+ results
From: SZEDER Gábor @ 2020-05-16 6:37 UTC (permalink / raw)
To: Bryan Turner; +Cc: Git Users
On Fri, May 15, 2020 at 09:09:27PM -0700, Bryan Turner wrote:
> When running a huge "git push" via protocol v0/v1 over HTTP
By huge push you mean a lot of refs?
> (repository is ~10GB, with ~104,000 refs), I observe that:
> * Git makes an initial connection for a ref advertisement. This
> completes almost instantly because the repository is empty
> * "git push" then sits in absolute silence for ~10 minutes
I've run into this a few years ago, remember waiting for 57 minutes ;)
> The process chain looks like:
> git push <URL>
> git-remote-http <URL> <URL>
> git send-pack --stateless-rpc --helper-status --thin
> --progress <URL> --stdin
>
> The "git send-pack" process runs at 100% usage for a single CPU core
> for this entire duration. Does anyone have any insight into what Git
> might be doing during this long delay?
Pathspec matching is, if I recall correctly,
O(nr of refspecs * (nr of local refs + nr of remote refs))
with remote.c:count_refspec_match() responsible the "nr of remote +
local refs" part and remote.c:match_explicit_refs() for the "nr of
refspecs" part.
This is particularly bad for http/https protocols, because 'git push'
expands your refspecs to fully qualified refspecs, passes them to 'git
send-pack', which then performs pathspec matching _again_. So if you
have a single pathspec with globbing, then 'git push' can do the
pathspec matching still fairly quickly, even if there are a lot of
local and remote refs and if that single globbing pathspec happens to
match a lot of refs, but then the refspec matching in 'git send-pack'
has a whole lot to do, spins the CPU like crazy, and there you are
writing a bug report on Friday evening.
This is less of an issue with other protocols, because they perform
pathspec matching only once, but of course all protocols suffer if you
pass a lot of refspecs to 'git push' or 'git send-pack'.
> Whatever it is, is it perhaps
> something Git should actually print some sort of status for? (I've
> reproduced this long silence with both Git 2.20.1 and the new Git
> 2.27.0-rc0.)
An immediate band-aid might be to teach 'git push' to pass on the
original refspecs to 'git send-pack', as this would reduce the
complexity of that second pathspec matching. This, of course,
wouldn't help if someone scripted around 'git push' and invoked it
with a lot of refspecs or fed lot of refspecs directly to 'git
send-pack's stdin.
Alternatively, teach 'git send-pack' a new option e.g.
'--only-fully-qualified-refspecs', and teach 'git push' to use it, so
'git send-pack' doesn't have to perform that second pathspec matching,
it would only have to verify that the refspecs it got are indeed all
fully qualified.
Or build the remote refs index earlier and sort refspecs and local
refs, so we could match the lhs of fully qualified refspecs to local
refs in one go while looking up their rhs in the remote ref index,
resulting in O((nr of refspecs + nr of local refs) * log(nr of remote
refs) complexity. Dunno, it was a long time ago when I last thought
about this.
All this assumes that if there are a lot of refspecs, then they are
fully qualified. I'd assume that if there are so many refspecs to
cause trouble, then they were generated programmatically, and I'd
(naively? :) assume that if something generates refspecs, then it's
careful and generates fully qualified refspecs. Anyway, all bets are
off if there are a lot of non-fully-qualified refspecs...
^ permalink raw reply [relevance 0%]
* git push over HTTP; long delay with no progress, then hang?
@ 2020-05-16 4:09 4% Bryan Turner
2020-05-16 6:37 0% ` SZEDER Gábor
0 siblings, 1 reply; 69+ results
From: Bryan Turner @ 2020-05-16 4:09 UTC (permalink / raw)
To: Git Users
When running a huge "git push" via protocol v0/v1 over HTTP
(repository is ~10GB, with ~104,000 refs), I observe that:
* Git makes an initial connection for a ref advertisement. This
completes almost instantly because the repository is empty
* "git push" then sits in absolute silence for ~10 minutes
The process chain looks like:
git push <URL>
git-remote-http <URL> <URL>
git send-pack --stateless-rpc --helper-status --thin
--progress <URL> --stdin
The "git send-pack" process runs at 100% usage for a single CPU core
for this entire duration. Does anyone have any insight into what Git
might be doing during this long delay? Whatever it is, is it perhaps
something Git should actually print some sort of status for? (I've
reproduced this long silence with both Git 2.20.1 and the new Git
2.27.0-rc0.)
After the long delay, I see another HTTP request to the server and
then the "git push" process finally goes into "Enumerating objects",
"Counting objects", "Compressing objects" and finally "Writing
objects".
Another thing I've noticed is that, during this latter part, it
_appears_ Git opens a connection to the remote server and _then_
starts enumerating/counting/compressing, without having actually said
anything to the server. For this huge push, that actually results in
the server aborting the connection due to a read timeout. Why would
"git push" open a server connection and _then_ do all the work
necessary to create a pack to actually send? (Perhaps this is really
an HTTP keepalive issue, where the connection had been used for a
previous request?) As with the long silence, I reproduced this with
both Git 2.20.1 and 2.27.0-rc0.
Lastly, after the timeout, I observed that my "git push" hung forever
with this output displayed:
bturner$ /opt/git/2.27.0-rc0/bin/git push <URL> --all
Enumerating objects: 13135246, done.
Counting objects: 100% (13135246/13135246), done.
Delta compression using up to 20 threads
Compressing objects: 100% (3867748/3867748), done.
Writing objects: 0% (1/13135246)
An lsof on the "git-remote-http" process showed:
bturner$ lsof -p 64855
COMMAND PID USER FD TYPE DEVICE SIZE/OFF
NODE NAME
git-remot 64855 bturner cwd DIR 1,4 352
168415036 <CWD>
git-remot 64855 bturner txt REG 1,4 2305984
170771507 /opt/git/2.27.0-rc0/libexec/git-core/git-remote-http
git-remot 64855 bturner txt REG 1,4 59156
165457100 /usr/local/Cellar/gettext/0.20.2_1/lib/libintl.8.dylib
git-remot 64855 bturner txt REG 1,4 28420
167195923 /Library/Preferences/Logging/.plist-cache.hR8QH5S4
git-remot 64855 bturner txt REG 1,4 1568368
1152921500312496125 /usr/lib/dyld
git-remot 64855 bturner 0 PIPE 0x9a358149ffa29591 65536
->0xa5ef9caffef8462c
git-remot 64855 bturner 1 PIPE 0x2dce7cc3b04ce8b8 16384
->0x3f62dce60d4a355
git-remot 64855 bturner 2u CHR 16,8 0t1903241
2841 /dev/ttys008
git-remot 64855 bturner 3u systm 0xb078b23901649d47 0t0
[ctl com.apple.netsrc id 7 unit 48]
git-remot 64855 bturner 4u unix 0xb078b238edae81ff 0t0
->0xb078b238edae8777
git-remot 64855 bturner 5u IPv6 0xb078b238f873ac47 0t0
TCP localhost:58980-><host>:<port> (CLOSED)
git-remot 64855 bturner 7 PIPE 0x8e4a8565c7dd32eb 65536
->0xaec041bd7407b713
git-remot 64855 bturner 8 PIPE 0x6ed7631819b64580 65536
->0x52e7cf331dfd1de7
So at some level it was known that the remote host had closed the
socket, but "git-remote-http" was still sitting there.
I can readily reproduce all of this, but unfortunately can't readily
share the repository. I'm happy to do anything I can to contribute to
debugging, if anyone has any thoughts to share!
Best regards,
Bryan Turner
^ permalink raw reply [relevance 4%]
* Re: [RFC][PATCH 0/2] submodule: port 'set-url' from shell to C
@ 2020-04-20 8:19 4% ` Denton Liu
0 siblings, 0 replies; 69+ results
From: Denton Liu @ 2020-04-20 8:19 UTC (permalink / raw)
To: Shourya Shukla
Cc: git, christian.couder, peff, heba.waly, Johannes.Schindelin,
gitster
Hi Shourya,
On Fri, Apr 17, 2020 at 02:34:54AM +0530, Shourya Shukla wrote:
> The issues I am facing are:
>
> 1. The patch fails test #2 in t7420, i.e., the test to verify the working of 'set-url'
> subcommand.
The 'set-url' command implicitly runs sync once it is changed. I would
go further than what Christian suggests and just call sync_submodule()
(in C) at the end of module_set_url().
> 2. Though not an issue affecting the patch, but the 'usage' prompt of 'git submodule'
> does not show the subcommands 'set-url' and 'set-branch'.
Hmmm, the first of the pair, 'set-branch', was introduced in v2.22.0. It
seems like you're running an older version of Git, 2.20.1. Stupid
question but are you sure you're running the correct git? For me this
runs correctly on the latest 'master':
$ ./bin-wrappers/git submodule -h
usage: git submodule [--quiet] [--cached]
or: git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: git submodule [--quiet] init [--] [<path>...]
or: git submodule [--quiet] deinit [-f|--force] (--all| [--] <path>...)
or: git submodule [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--[no-]recommend-shallow] [--reference <repository>] [--recursive] [--[no-]single-branch] [--] [<path>...]
or: git submodule [--quiet] set-branch (--default|--branch <branch>) [--] <path>
or: git submodule [--quiet] set-url [--] <path> <newurl>
or: git submodule [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: git submodule [--quiet] foreach [--recursive] <command>
or: git submodule [--quiet] sync [--recursive] [--] [<path>...]
or: git submodule [--quiet] absorbgitdirs [--] [<path>...]
Thanks,
Denton
^ permalink raw reply [relevance 4%]
* Re: git status --ignored hangs when a deep directory structure present in working tree
2020-01-28 5:06 0% ` Elijah Newren
@ 2020-01-29 22:10 0% ` Elijah Newren
0 siblings, 0 replies; 69+ results
From: Elijah Newren @ 2020-01-29 22:10 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Martin Melka, Git Mailing List, Samuel Lijin
On Mon, Jan 27, 2020 at 9:06 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, Jan 27, 2020 at 4:08 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> >
> > On Mon, Jan 27, 2020 at 11:55:01AM +0100, Martin Melka wrote:
> > > Hi all, I have ran across what might be a bug in git. When there is a
> > > deep directory structure (tried on 100+ nested dirs), then git status
> > > --ignored hangs indefinitely.
> > > Discovered this on OSX (Mojave, git 2.20.1 (Apple Git-117)), but it
> > > reproduces in Ubuntu (19.04, git 2.25.0) Docker container on OSX and
> > > also on baremetal Ubuntu server (16.04, git 2.17.1).
> > >
> > > Steps to reproduce:
> > >
> > > 1. Generate the deep dir structure:
> > >
> > > mkdir gittest; pushd gittest; git init; for i in $(seq 1 120); do
> > > mkdir dir; cd dir; done; touch leaf; popd
> > >
> > > 2. Try to get git status --ignored
> > >
> > > cd gittest && git status --ignored
> > >
> > >
> > > If there is a dir depth limit, git should probably exit with an error
> > > rather than getting stuck endlessly.
> >
> > This is interesting, thanks for the report.
>
> Agreed.
>
> > There is no such directory depth limit, but the runtime of 'git status
> > --ignored' grows quickly with the depth of the untracked directory.
> > Running this shell loop produces the numbers below:
> >
> > for depth in $(seq 10 30)
> > do
> > dirs=$(for i in $(seq 1 $depth) ; do printf 'dir/' ; done)
> > rm -rf dir
> > mkdir -p $dirs
> > >$dirs/untracked-file
> > /usr/bin/time --format="$depth: %e" git status --ignored >/dev/null
> > done
> >
> > 10: 0.01
> > 11: 0.03
> > 12: 0.05
> > 13: 0.11
> > 14: 0.23
> > 15: 0.47
> > 16: 0.97
> > 17: 1.97
> > 18: 3.88
> > 19: 7.85
> > 20: 16.29
> > 21: 32.92
> > 22: 76.24
>
> Wow.
>
> Really nice testcase, though, thanks.
>
[...]
> We'll see
> if my patch goes anywhere, or if it's just another dead-end among
> many.
Since gitgitgadget doesn't have an in-reply-to capability, for those
wanting to follow along see
https://lore.kernel.org/git/pull.700.git.git.1580335424.gitgitgadget@gmail.com/
^ permalink raw reply [relevance 0%]
* Re: git status --ignored hangs when a deep directory structure present in working tree
2020-01-27 12:08 0% ` SZEDER Gábor
@ 2020-01-28 5:06 0% ` Elijah Newren
2020-01-29 22:10 0% ` Elijah Newren
0 siblings, 1 reply; 69+ results
From: Elijah Newren @ 2020-01-28 5:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Martin Melka, Git Mailing List, Samuel Lijin
On Mon, Jan 27, 2020 at 4:08 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
>
> On Mon, Jan 27, 2020 at 11:55:01AM +0100, Martin Melka wrote:
> > Hi all, I have ran across what might be a bug in git. When there is a
> > deep directory structure (tried on 100+ nested dirs), then git status
> > --ignored hangs indefinitely.
> > Discovered this on OSX (Mojave, git 2.20.1 (Apple Git-117)), but it
> > reproduces in Ubuntu (19.04, git 2.25.0) Docker container on OSX and
> > also on baremetal Ubuntu server (16.04, git 2.17.1).
> >
> > Steps to reproduce:
> >
> > 1. Generate the deep dir structure:
> >
> > mkdir gittest; pushd gittest; git init; for i in $(seq 1 120); do
> > mkdir dir; cd dir; done; touch leaf; popd
> >
> > 2. Try to get git status --ignored
> >
> > cd gittest && git status --ignored
> >
> >
> > If there is a dir depth limit, git should probably exit with an error
> > rather than getting stuck endlessly.
>
> This is interesting, thanks for the report.
Agreed.
> There is no such directory depth limit, but the runtime of 'git status
> --ignored' grows quickly with the depth of the untracked directory.
> Running this shell loop produces the numbers below:
>
> for depth in $(seq 10 30)
> do
> dirs=$(for i in $(seq 1 $depth) ; do printf 'dir/' ; done)
> rm -rf dir
> mkdir -p $dirs
> >$dirs/untracked-file
> /usr/bin/time --format="$depth: %e" git status --ignored >/dev/null
> done
>
> 10: 0.01
> 11: 0.03
> 12: 0.05
> 13: 0.11
> 14: 0.23
> 15: 0.47
> 16: 0.97
> 17: 1.97
> 18: 3.88
> 19: 7.85
> 20: 16.29
> 21: 32.92
> 22: 76.24
Wow.
Really nice testcase, though, thanks.
> Beautifully quadratic, isn't it? :)
I think you mean exponential (in particular 2^n rather than n^2).
> Unless I messed up my numbers, with a depth of 120 directories it
> would take over 6*10^23 years to complete... so yeah, it does qualify
> as indefinitely.
No comment about how people today are spoiled and addicted to instant
gratification? I mean, can't folks just be a little patient? ;-)
> This slowdown was caused by commit df5bcdf83a (dir: recurse into
> untracked dirs for ignored files, 2017-05-18), which was part of a
> patch series to fix 'git clean -d' deleting untracked directories even
> if they contained ignored files.
>
> Cc'ing Samuel, author of that commit, and Elijah, who had quite some
> fun with 'dir.c' recently.
Heh, yes, what "fun" it was.
Anyway, after digging around for quite a bit today... that commit
added calling read_directory_recursive() directly from itself for
certain untracked paths. This means that read_directory_recursive()
(which I'll abbreviate to r_d_r()), when we're dealing with certain
untracked paths:
* Calls treat_path() -> treat_one_path() -> treat_directory() -> r_d_r()
* Calls r_d_r() directly as well
So, from the toplevel directory, r_d_r() will call itself twice on the
next directory down. For each of those, it'll call r_d_r() twice on
the second directory down. From each of those, it'll call r_d_r()
twice on the third directory in the hierarchy and so on until we have
2^n calls to r_d_r() for the nth level deep directory.
Trying to back out the underlying problem, I _think_ the cause behind
all this is that r_d_r() and friends all use the path_treatment enum,
which says that the treatment of any path has to be one of those four
types. The dichotomy between path_untracked and path_recurse in
particular means the system has no way to mark that something should
be both marked as untracked and recursed into, yet we definitely need
to have some directories marked as untracked and we also need to
recurse into them. This, I think led to Samuel's attempt to
workaround that dichotomy by having the code in r_d_r() check for
certain path_untracked cases which should also be recursed into. I
think adding another type to the enum and shifting the logic elsewhere
might enable us to both simplify the logic and avoid this expensive
exponential behavior, but I haven't gotten it working yet. We'll see
if my patch goes anywhere, or if it's just another dead-end among
many.
Elijah
^ permalink raw reply [relevance 0%]
* Re: git status --ignored hangs when a deep directory structure present in working tree
2020-01-27 10:55 4% git status --ignored hangs when a deep directory structure present in working tree Martin Melka
@ 2020-01-27 12:08 0% ` SZEDER Gábor
2020-01-28 5:06 0% ` Elijah Newren
0 siblings, 1 reply; 69+ results
From: SZEDER Gábor @ 2020-01-27 12:08 UTC (permalink / raw)
To: Martin Melka; +Cc: git, Samuel Lijin, Elijah Newren
On Mon, Jan 27, 2020 at 11:55:01AM +0100, Martin Melka wrote:
> Hi all, I have ran across what might be a bug in git. When there is a
> deep directory structure (tried on 100+ nested dirs), then git status
> --ignored hangs indefinitely.
> Discovered this on OSX (Mojave, git 2.20.1 (Apple Git-117)), but it
> reproduces in Ubuntu (19.04, git 2.25.0) Docker container on OSX and
> also on baremetal Ubuntu server (16.04, git 2.17.1).
>
> Steps to reproduce:
>
> 1. Generate the deep dir structure:
>
> mkdir gittest; pushd gittest; git init; for i in $(seq 1 120); do
> mkdir dir; cd dir; done; touch leaf; popd
>
> 2. Try to get git status --ignored
>
> cd gittest && git status --ignored
>
>
> If there is a dir depth limit, git should probably exit with an error
> rather than getting stuck endlessly.
This is interesting, thanks for the report.
There is no such directory depth limit, but the runtime of 'git status
--ignored' grows quickly with the depth of the untracked directory.
Running this shell loop produces the numbers below:
for depth in $(seq 10 30)
do
dirs=$(for i in $(seq 1 $depth) ; do printf 'dir/' ; done)
rm -rf dir
mkdir -p $dirs
>$dirs/untracked-file
/usr/bin/time --format="$depth: %e" git status --ignored >/dev/null
done
10: 0.01
11: 0.03
12: 0.05
13: 0.11
14: 0.23
15: 0.47
16: 0.97
17: 1.97
18: 3.88
19: 7.85
20: 16.29
21: 32.92
22: 76.24
Beautifully quadratic, isn't it? :)
Unless I messed up my numbers, with a depth of 120 directories it
would take over 6*10^23 years to complete... so yeah, it does qualify
as indefinitely.
This slowdown was caused by commit df5bcdf83a (dir: recurse into
untracked dirs for ignored files, 2017-05-18), which was part of a
patch series to fix 'git clean -d' deleting untracked directories even
if they contained ignored files.
Cc'ing Samuel, author of that commit, and Elijah, who had quite some
fun with 'dir.c' recently.
^ permalink raw reply [relevance 0%]
* git status --ignored hangs when a deep directory structure present in working tree
@ 2020-01-27 10:55 4% Martin Melka
2020-01-27 12:08 0% ` SZEDER Gábor
0 siblings, 1 reply; 69+ results
From: Martin Melka @ 2020-01-27 10:55 UTC (permalink / raw)
To: git
Hi all, I have ran across what might be a bug in git. When there is a
deep directory structure (tried on 100+ nested dirs), then git status
--ignored hangs indefinitely.
Discovered this on OSX (Mojave, git 2.20.1 (Apple Git-117)), but it
reproduces in Ubuntu (19.04, git 2.25.0) Docker container on OSX and
also on baremetal Ubuntu server (16.04, git 2.17.1).
Steps to reproduce:
1. Generate the deep dir structure:
mkdir gittest; pushd gittest; git init; for i in $(seq 1 120); do
mkdir dir; cd dir; done; touch leaf; popd
2. Try to get git status --ignored
cd gittest && git status --ignored
If there is a dir depth limit, git should probably exit with an error
rather than getting stuck endlessly.
StackOverflow report:
https://stackoverflow.com/questions/59928800/git-status-ignored-hangs-indefinitely
Best regards,
Martin Melka
^ permalink raw reply [relevance 4%]
* Re: Fedora 1 and Ubuntu 4
2019-07-19 18:41 4% Fedora 1 and Ubuntu 4 Jeffrey Walton
@ 2019-07-19 19:16 0% ` Junio C Hamano
0 siblings, 0 replies; 69+ results
From: Junio C Hamano @ 2019-07-19 19:16 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: Git List
Jeffrey Walton <noloader@gmail.com> writes:
> Just wanted to drop a quick note and let everyone know that Git 2.20.1
> builds on both Fedora 1 and Ubuntu 4. I use Fedora 1 and Ubuntu 4 for
> regression tests for some other libraries. It is easier to use the old
> distros then building old GCC's and glibc's on modern platforms.
I am somewhat impressed ;-) Thanks for a datapoint---I am guessing
that your note was triggered by our recent "let's have a CI build
job that uses gcc 4.8" discussion?
^ permalink raw reply [relevance 0%]
* Fedora 1 and Ubuntu 4
@ 2019-07-19 18:41 4% Jeffrey Walton
2019-07-19 19:16 0% ` Junio C Hamano
0 siblings, 1 reply; 69+ results
From: Jeffrey Walton @ 2019-07-19 18:41 UTC (permalink / raw)
To: Git List
Hi Everyone,
Just wanted to drop a quick note and let everyone know that Git 2.20.1
builds on both Fedora 1 and Ubuntu 4. I use Fedora 1 and Ubuntu 4 for
regression tests for some other libraries. It is easier to use the old
distros then building old GCC's and glibc's on modern platforms.
Git has some problems with some self tests, but they are few. For
example, 29 self tests fail on Fedora 1. I don't think it is worth
pursuing Python 2.2 or Perl 5.8 problems.
All the basic commands I use, like clone, checkout and pull, work as expected.
Jeff
^ permalink raw reply [relevance 4%]
* Re: Pull vs push messages
2019-07-11 22:01 0% ` brian m. carlson
@ 2019-07-12 6:39 0% ` Martin Ågren
0 siblings, 0 replies; 69+ results
From: Martin Ågren @ 2019-07-12 6:39 UTC (permalink / raw)
To: brian m. carlson, Michael Kielstra, Git Mailing List
On Fri, 12 Jul 2019 at 00:16, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2019-07-11 at 21:36:50, Michael Kielstra wrote:
> > Hi all,
> >
> > I noticed that git pull reports "Already up to date." but git push
> > reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
> > the Ubuntu repos.) Just for a consistent user experience, would it be
> > worth standardizing on:
> >
> > Hyphenation (up-to-date vs up to date)?
> > Periods at the end of one-sentence messages?
> > Colloquialisms and tone of voice? "Already up to date." sounds like a
> > terse error message but "Everything up-to-date" sounds like a chatty
> > friend.
>
> I'd be happy to review a patch that changes this, if you think it's
> worth changing. Generally the way things work here is that except for
> obvious bugs, people send patches for things they care about, and then
> other folks will review and make suggestions, or sometimes there won't
> be any interest in a change, and the patch is dropped.
>
> We'd probably want to standardize on "up to date", since that's the
> correct form here according to the Chicago Manual of Style, and drop the
> period, since this isn't a complete sentence.
There's 7560f547e6 ('treewide: correct several "up-to-date" to "up to
date"', 2017-08-23), which changed a few of these, but also explains why
it leaves "Everything up-to-date" unchanged. Whether that assessment is
the One True Way now 2 years later, I'm not the right person to say.
Michael, you can perhaps find some discussion leading up to / about that
patch on https://public-archive.org/git/
Martin
^ permalink raw reply [relevance 0%]
* Re: Pull vs push messages
2019-07-11 21:36 4% Pull vs push messages Michael Kielstra
@ 2019-07-11 22:01 0% ` brian m. carlson
2019-07-12 6:39 0% ` Martin Ågren
0 siblings, 1 reply; 69+ results
From: brian m. carlson @ 2019-07-11 22:01 UTC (permalink / raw)
To: Michael Kielstra; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
On 2019-07-11 at 21:36:50, Michael Kielstra wrote:
> Hi all,
>
> I noticed that git pull reports "Already up to date." but git push
> reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
> the Ubuntu repos.) Just for a consistent user experience, would it be
> worth standardizing on:
>
> Hyphenation (up-to-date vs up to date)?
> Periods at the end of one-sentence messages?
> Colloquialisms and tone of voice? "Already up to date." sounds like a
> terse error message but "Everything up-to-date" sounds like a chatty
> friend.
>
> Maybe none of this is worth the effort, but I thought I'd mention it
> just in case.
I'd be happy to review a patch that changes this, if you think it's
worth changing. Generally the way things work here is that except for
obvious bugs, people send patches for things they care about, and then
other folks will review and make suggestions, or sometimes there won't
be any interest in a change, and the patch is dropped.
We'd probably want to standardize on "up to date", since that's the
correct form here according to the Chicago Manual of Style, and drop the
period, since this isn't a complete sentence.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply [relevance 0%]
* Pull vs push messages
@ 2019-07-11 21:36 4% Michael Kielstra
2019-07-11 22:01 0% ` brian m. carlson
0 siblings, 1 reply; 69+ results
From: Michael Kielstra @ 2019-07-11 21:36 UTC (permalink / raw)
To: git
Hi all,
I noticed that git pull reports "Already up to date." but git push
reports "Everything up-to-date". (I'm using git 2.20.1, the latest in
the Ubuntu repos.) Just for a consistent user experience, would it be
worth standardizing on:
Hyphenation (up-to-date vs up to date)?
Periods at the end of one-sentence messages?
Colloquialisms and tone of voice? "Already up to date." sounds like a
terse error message but "Everything up-to-date" sounds like a chatty
friend.
Maybe none of this is worth the effort, but I thought I'd mention it
just in case.
Michael Kielstra
^ permalink raw reply [relevance 4%]
* git fetch --shallow-since hangs
@ 2019-06-20 10:59 3% Yuri D'Elia
0 siblings, 0 replies; 69+ results
From: Yuri D'Elia @ 2019-06-20 10:59 UTC (permalink / raw)
To: git
I'm trying to run git fetch using --shallow-since with a date range that
results in no commits to be selected.
In this scenario the command hangs indefinitely:
git fetch --shallow-since=2019-05-20 -vv
Server supports multi_ack_detailed
Server supports side-band-64k
Server supports ofs-delta
Server version is git/2.21.0
want 33eeead1a93fed4d25ff90b0b45acec5d822c13c (refs/heads/B-2012-04)
want 49455fcb45a950adf7702d96a2be0ff70cd06577 (refs/heads/B-2012-07)
want c9964f78fd7d1a43db7abca9d2ed2d04ffc7d9a3 (refs/heads/B-2012-08)
want bb8869e3c2697c901b27658cadeb994dd8193897 (refs/heads/B-2012-11)
want 386210eb1ed98abeaa678cc90de639a7773d0802 (refs/heads/B-2013-04)
want b1828494a89fe4532549df31ff93a7816b7c6341 (refs/heads/B-2013-07)
want ff6829912631132fe9b6d8880a6ea8a14676b5c9 (refs/heads/B-2013-09)
want 4c59a0e2317b3bbd6a8bfdad89dbc2c8ca172f8d (refs/heads/B-2013-12)
want ce9729b1c2f26f5a1eab6c623d710df50b4e87fc (refs/heads/B-2014-03)
want 39db34fc97fcafb43faaaba25618473cb2fa8ed6 (refs/heads/B-2014-08)
want f710bb0552db364c40cac542fb591af3b384210c (refs/heads/B-2014-12)
want d6569610cf5da4aced818ba246aa9bc3ad4d7c4a (refs/heads/B-2015-04)
want 3333479999a695f07c30ffca319fa38fc74e01e3 (refs/heads/B-2017-05)
want 111801742054e910a214fca96531824e6f806bd8 (refs/heads/V-2012-04)
want e64b751dd156ee7ee06521b9670284fbe2b79b8e (refs/heads/V-2012-04.1)
want 8bf4adb022e39d06872758d68672fc6f327513cb (refs/heads/V-2012-04.2)
want 31254791e193524c634e19dbcd766b0254f0f21b (refs/heads/V-2012-07)
want 245045e41db2e87c9467830d8fdb570a17b321ed (refs/heads/V-2012-07.1)
want 6ae10ad37c9083e83a43b1679d5514302ce0355d (refs/heads/V-2012-07.2)
want f07291acd0eddddb168d322e27c9425ca084f239 (refs/heads/V-2012-08.1)
want 4a5e3ab5f4eb412b905ddb7e91e0db70bd6cd17f (refs/heads/V-2012-11.1)
want 4b36f254523dbc1d2a80f29886d96cb9a6851584 (refs/heads/V-2013-04)
want f2040101186b31bc99e0f8d4c370101ad0f45ac8 (refs/heads/V-2013-07)
want ba38be154fb9b5627e8c74b2cd75df628961d998 (refs/heads/V-2013-07.1)
want 6029a5638a486886be507c78cc876f266dca2cc7 (refs/heads/V-2013-09)
want 370adcc9a4e82b75a83a999f6cf08d83cba31ce8 (refs/heads/V-2013-09.1)
want d89488b9e3dbd53e4b96bb00f1075901306fcf58 (refs/heads/V-2013-12)
want 86f8eb18bc5657566793ce7ec9c3c05de9de994b (refs/heads/V-2014-03)
want da6f1539444152bff219732ce694454a33444457 (refs/heads/V-2014-03.1)
want b68d4411d16d293817127856f396d460894e8978 (refs/heads/V-2014-03.2)
want d11d83083b31d44940ff78b0a8e656f21473ab46 (refs/heads/V-2014-08)
want 6d81e7ce60bf125c1cd5528a943e73164f8d3bbe (refs/heads/V-2014-08.1)
want 648f93cab60e4525b4278aa172b50740040ce817 (refs/heads/V-2014-12)
want baf41800559a7a3b0d0c6963f01c04bbd4d65be5 (refs/heads/V-2015-04)
want 619d51d2592cd8dc572c252f4c7b169c04aad6fb (refs/heads/V-2017-05)
want ef021b04df54a5f94e164b79133f1e64b9edc02e (refs/heads/master)
fatal: no commits selected for shallow requests
<hangs here>
I reproduced this on the client side using git 2.20.1 and git
2.22.0.455.g172b71a6c5 (the latest debian unstable package).
^ permalink raw reply [relevance 3%]
* Re: rebase / am separation problem
2019-06-10 15:07 4% rebase / am separation problem Michal Suchánek
@ 2019-06-10 18:46 0% ` Johannes Schindelin
0 siblings, 0 replies; 69+ results
From: Johannes Schindelin @ 2019-06-10 18:46 UTC (permalink / raw)
To: Michal Suchánek; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
Hi Michal
On Mon, 10 Jun 2019, Michal Suchánek wrote:
> I am using git 2.20.1 and just observed this behavior:
Have you tested this with v2.21.0 (which is over three months old by now),
or even v2.22.0?
Ciao,
Johannes
^ permalink raw reply [relevance 0%]
* rebase / am separation problem
@ 2019-06-10 15:07 4% Michal Suchánek
2019-06-10 18:46 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Michal Suchánek @ 2019-06-10 15:07 UTC (permalink / raw)
To: git
Hello,
there is an issue with rebase vs am separation.
I am using git 2.20.1 and just observed this behavior:
- rebase started ( possibly with previous am in progress on
different branch - not known)
- rebase stopped, used am --skip to continue
- renase was not able to finish
Does anybody else observe this issue?
There is some nesting possible - I am sure that at least one of
cherry-pick and am can be included on top of a commit where git stopped
during rebase -i. However, git should either isolate the three properly
so they can be layered one on top of another of reject the command if
it would corrupt state of currently running command.
Thanks
Michal
^ permalink raw reply [relevance 4%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-05-29 16:40 0% ` Bret Barkelew
@ 2019-05-29 18:07 0% ` Johannes Schindelin
0 siblings, 0 replies; 69+ results
From: Johannes Schindelin @ 2019-05-29 18:07 UTC (permalink / raw)
To: Bret Barkelew; +Cc: Bryan Turner, git
[-- Attachment #1: Type: text/plain, Size: 6791 bytes --]
Hi Bret,
On Wed, 29 May 2019, Bret Barkelew wrote:
> I know it's an incredibly late reply, but I have not seen this issue
> reappear since the patches. Thank you very much for helping!
It might be late, but it is even more welcome! Thanks for the feedback
(and I am particularly happy that it works for you).
Ciao,
Johannes
P.S.: For lurkers, I just realized that I never linked to the patches:
https://github.com/git-for-windows/git/pull/2170
As this PR really only touches code that is already in Git for Windows,
but not yet in git.git, I think I'll try to find some time post-v2.22.0 to
brush up those gitk patches and contribute them to the Git mailing list
for review.
> On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Hi Bret,
> >
> > On Thu, 18 Apr 2019, Bret Barkelew wrote:
> >
> > > This issue is now being reported by more users inside MS. I'll also
> > > reach out to the Git for Windows advocacy group to see if they have
> > > any ideas.
> > >
> > > I have not had time to figure out the inner workings of Tcl/Tk. Is
> > > there any way to turn on tracing/logging in Git for which commands are
> > > being called by gitk?
> >
> > Thank you for reaching out with detailed information internally, I am
> > happy to report that together with the help of Max Kirillov, this is now
> > resolved and a snapshot is available from
> > https://wingit.blob.core.windows.net/files/index.html that has the fix.
> >
> > Ciao,
> > Johannes
> >
> > > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:
> > > >
> > > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
> > > > <Johannes.Schindelin@gmx.de> wrote:
> > > > >
> > > > > Hi Bret,
> > > > >
> > > > > in that case, please try to find a way to trace the commands in a Tcl/Tk
> > > > > program (which gitk is) and see which command triggers the error.
> > > >
> > > > Er... that's a little out of my depth. I'll see if I can find time to learn.
> > > > Meanwhile, is there any way to request better instrumentation for the
> > > > error dialog so this data could have been collected for me?
> > > >
> > > > >
> > > > > Ciao,
> > > > > Johannes
> > > > >
> > > > >
> > > > > On Wed, 9 Jan 2019, Bret Barkelew wrote:
> > > > >
> > > > > > Will try to reply in-line, when appropriate.
> > > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> > > > > > has the issue.
> > > > > >
> > > > > > - Bret
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> > > > > > <Johannes.Schindelin@gmx.de> wrote:
> > > > > > >
> > > > > > > Hi Bret,
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> > > > > > >
> > > > > > > > They are the exact same path (with a different drive letter).
> > > > > > >
> > > > > > > [it's a bit hard to follow the thread if you top-post a reply to an
> > > > > > > inline-replied answer, maybe imitate the style of other mails in the
> > > > > > > future.]
> > > > > > >
> > > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > > > > > > and installed 2.19.0 on the failing system, and the older version of
> > > > > > > > Git works.
> > > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > > > > > > names in the Windows registry, which did not resolve the issue with
> > > > > > > > git 2.20.1.
> > > > > > > >
> > > > > > > > Happy to collect any additional data.
> > > > > > >
> > > > > > > Please try the latest snapshot at
> > > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > > > > > > might be fixed via
> > > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).
> > > > > > >
> > > > > > > Ciao,
> > > > > > > Johannes
> > > > > > >
> > > > > > > > - Bret
> > > > > > > >
> > > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > > > > > > >>
> > > > > > > > >> When I open gitk in a particular repository under this version of Git
> > > > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > > > > > > >> "git": file name too long". I've noticed that the most pronounced
> > > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > > > > > > >> narrowed down the following things:
> > > > > > > > >>
> > > > > > > > >> - This does not happen with the same repo if I use a system that has
> > > > > > > > >> git 2.19.0.windows.1 on another machine.
> > > > > > > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > > > > > > >
> > > > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >> However, as soon as the remote updates with any changes on a given
> > > > > > > > >> fetch/pull, the repo is put in a bad state permanently.
> > > > > > > > >>
> > > > > > > > >> I've pasted the output from gitk below...
> > > > > > > > >>
> > > > > > > > >> couldn't execute "git": file name too long
> > > > > > > > >> couldn't execute "git": file name too long
> > > > > > > > >> while executing
> > > > > > > > >> "open $cmd r"
> > > > > > > > >> (procedure "getallcommits" line 48)
> > > > > > > > >> invoked from within
> > > > > > > > >> "getallcommits"
> > > > > > > > >> (procedure "readcache" line 80)
> > > > > > > > >> invoked from within
> > > > > > > > >> "readcache file827e200"
> > > > > > > > >> ("eval" body line 1)
> > > > > > > > >> invoked from within
> > > > > > > > >> "eval $script"
> > > > > > > > >> (procedure "dorunq" line 11)
> > > > > > > > >> invoked from within
> > > > > > > > >> "dorunq"
> > > > > > > > >> ("after" script)
> > > > > > > > >>
> > > > > > > > >> Happy to gather whatever data needed.
> > > > > > > > >> Thanks!
> > > > > > > > >> - Bret Barkelew
> > > > > > > >
> > > > > >
> > >
>
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-04-27 23:20 0% ` Johannes Schindelin
@ 2019-05-29 16:40 0% ` Bret Barkelew
2019-05-29 18:07 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Bret Barkelew @ 2019-05-29 16:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bryan Turner, git
I know it's an incredibly late reply, but I have not seen this issue
reappear since the patches. Thank you very much for helping!
- Bret
On Sat, Apr 27, 2019 at 4:20 PM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Bret,
>
> On Thu, 18 Apr 2019, Bret Barkelew wrote:
>
> > This issue is now being reported by more users inside MS. I'll also
> > reach out to the Git for Windows advocacy group to see if they have
> > any ideas.
> >
> > I have not had time to figure out the inner workings of Tcl/Tk. Is
> > there any way to turn on tracing/logging in Git for which commands are
> > being called by gitk?
>
> Thank you for reaching out with detailed information internally, I am
> happy to report that together with the help of Max Kirillov, this is now
> resolved and a snapshot is available from
> https://wingit.blob.core.windows.net/files/index.html that has the fix.
>
> Ciao,
> Johannes
>
> > On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:
> > >
> > > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
> > > <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > Hi Bret,
> > > >
> > > > in that case, please try to find a way to trace the commands in a Tcl/Tk
> > > > program (which gitk is) and see which command triggers the error.
> > >
> > > Er... that's a little out of my depth. I'll see if I can find time to learn.
> > > Meanwhile, is there any way to request better instrumentation for the
> > > error dialog so this data could have been collected for me?
> > >
> > > >
> > > > Ciao,
> > > > Johannes
> > > >
> > > >
> > > > On Wed, 9 Jan 2019, Bret Barkelew wrote:
> > > >
> > > > > Will try to reply in-line, when appropriate.
> > > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> > > > > has the issue.
> > > > >
> > > > > - Bret
> > > > >
> > > > >
> > > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> > > > > <Johannes.Schindelin@gmx.de> wrote:
> > > > > >
> > > > > > Hi Bret,
> > > > > >
> > > > > >
> > > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> > > > > >
> > > > > > > They are the exact same path (with a different drive letter).
> > > > > >
> > > > > > [it's a bit hard to follow the thread if you top-post a reply to an
> > > > > > inline-replied answer, maybe imitate the style of other mails in the
> > > > > > future.]
> > > > > >
> > > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > > > > > and installed 2.19.0 on the failing system, and the older version of
> > > > > > > Git works.
> > > > > > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > > > > > names in the Windows registry, which did not resolve the issue with
> > > > > > > git 2.20.1.
> > > > > > >
> > > > > > > Happy to collect any additional data.
> > > > > >
> > > > > > Please try the latest snapshot at
> > > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > > > > > might be fixed via
> > > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).
> > > > > >
> > > > > > Ciao,
> > > > > > Johannes
> > > > > >
> > > > > > > - Bret
> > > > > > >
> > > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > > > > > >>
> > > > > > > >> When I open gitk in a particular repository under this version of Git
> > > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > > > > > >> "git": file name too long". I've noticed that the most pronounced
> > > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > > > > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > > > > > >> narrowed down the following things:
> > > > > > > >>
> > > > > > > >> - This does not happen with the same repo if I use a system that has
> > > > > > > >> git 2.19.0.windows.1 on another machine.
> > > > > > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > > > > > >
> > > > > > > >
> > > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > > > > > >
> > > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > > > > > >
> > > > > > > >>
> > > > > > > >> However, as soon as the remote updates with any changes on a given
> > > > > > > >> fetch/pull, the repo is put in a bad state permanently.
> > > > > > > >>
> > > > > > > >> I've pasted the output from gitk below...
> > > > > > > >>
> > > > > > > >> couldn't execute "git": file name too long
> > > > > > > >> couldn't execute "git": file name too long
> > > > > > > >> while executing
> > > > > > > >> "open $cmd r"
> > > > > > > >> (procedure "getallcommits" line 48)
> > > > > > > >> invoked from within
> > > > > > > >> "getallcommits"
> > > > > > > >> (procedure "readcache" line 80)
> > > > > > > >> invoked from within
> > > > > > > >> "readcache file827e200"
> > > > > > > >> ("eval" body line 1)
> > > > > > > >> invoked from within
> > > > > > > >> "eval $script"
> > > > > > > >> (procedure "dorunq" line 11)
> > > > > > > >> invoked from within
> > > > > > > >> "dorunq"
> > > > > > > >> ("after" script)
> > > > > > > >>
> > > > > > > >> Happy to gather whatever data needed.
> > > > > > > >> Thanks!
> > > > > > > >> - Bret Barkelew
> > > > > > >
> > > > >
> >
^ permalink raw reply [relevance 0%]
* HEAD and namespaces
@ 2019-05-21 2:59 3% Bryan Turner
0 siblings, 0 replies; 69+ results
From: Bryan Turner @ 2019-05-21 2:59 UTC (permalink / raw)
To: Git Users
When using GIT_NAMESPACE, it appears the "symref" added to the
capabilities advertisement doesn't get the namespace stripped. The
namespace is stripped for the advertised refs, including "HEAD", but
not on the "symref".
Lafiel:test bturner$ GIT_NAMESPACE=foo GIT_TRACE_PACKET=1 git ls-remote origin
19:51:54.012696 pkt-line.c:80 packet: git<
b9acca03606d4c674be8b7e79cd788cedbec957c HEAD\0multi_ack thin-pack
side-band side-band-64k ofs-delta shallow deepen-since deepen-not
deepen-relative no-progress include-tag multi_ack_detailed
symref=refs/namespaces/foo/HEAD:refs/namespaces/foo/refs/heads/master
agent=git/2.20.1
19:51:54.013017 pkt-line.c:80 packet: git<
b9acca03606d4c674be8b7e79cd788cedbec957c refs/heads/master
19:51:54.013028 pkt-line.c:80 packet: git< 0000
19:51:54.013035 pkt-line.c:80 packet: git> 0000
b9acca03606d4c674be8b7e79cd788cedbec957c HEAD
b9acca03606d4c674be8b7e79cd788cedbec957c refs/heads/master
I don't know whether the client somehow does some stripping on the
"symref" to decide that HEAD should be
"refs/namespaces/foo/refs/heads/master", but I'd assume not. Either
way, since the clone can't find the HEAD value (either because it
doesn't see "refs/namespaces/foo/HEAD" as HEAD, which I'd assume is
the case, or because it can't find
"refs/namespaces/foo/refs/heads/master"), it falls back on the old
behavior of picking the first branch with a matching commit. That
brings back all the "wrong branch" issues with cloning that adding
"symref" fixed.
Is this a bug? An oversight? An intentional decision? How is HEAD
supposed to work when using GIT_NAMESPACE? Perhaps the expectation is
that namespaces won't have their own HEADs? I'd say perhaps it's that
even in the namespace the target ref shouldn't be namespaced, but that
doesn't seem like it could possibly be correct since the namespace
could contain refs that don't exist outside it, so Git would see the
symbolic ref as broken.
Any insight would be greatly appreciated!
Bryan
^ permalink raw reply [relevance 3%]
* git blame doesn't respect diff algorithm?
@ 2019-05-14 9:19 4% Pierre Ossman
0 siblings, 0 replies; 69+ results
From: Pierre Ossman @ 2019-05-14 9:19 UTC (permalink / raw)
To: git
Hi,
It seems like there is a bug in git blame where it doesn't respect the
diff algorithm setting. It happily parses it on the command line, but
there is no change to the output.
The problem materialises in that git blame will claim a line comes from
a certain commit. But when I do "git show --patience" on that commit,
the relevant line was not changed.
I could not find anything about this on the mailing list, so is this a
previously overlooked issue?
If you want to test it for your self, then do:
1. Clone tigervnc's git repo
2. git blame --patience vncviewer/DesktopWindow.cxx
3. Check line 906, it should say 7e546feba
4. git show --patience 7e546feba
This was with git-2.20.1-1.fc29.x86_64.
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköping https://facebook.com/ThinLinc
Phone: +46-13-214600
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
^ permalink raw reply [relevance 4%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
2019-04-14 1:59 0% ` wh
2019-04-14 13:24 0% ` Phillip Wood
@ 2019-05-02 15:45 0% ` Phillip Wood
1 sibling, 0 replies; 69+ results
From: Phillip Wood @ 2019-05-02 15:45 UTC (permalink / raw)
To: wh, phillip.wood
Cc: git, Junio C Hamano, Johannes Schindelin,
Nguyễn Thái Ngọc Duy
Hi wh
On 14/04/2019 02:59, wh wrote:
> Thanks for the info about the upcoming "precious" attribute. Looks useful.
>
> I didn't get the impression that Git normally overwrites ignored
> files. I ran some more experiments:
>
> git rebase FETCH_HEAD # bails
> git rebase -i FETCH_HEAD # overwrites
> git merge FETCH_HEAD # bails
> git reset --keep FETCH_HEAD # bails
> git reset --merge FETCH_HEAD # bails
> git checkout FETCH_HEAD # overwrites
> # without feature 2 locally:
> git merge FETCH_HEAD # overwrites, fast-forwards
> git merge --no-ff FETCH_HEAD # bails
I've had a look at the rebase -i code and I think it only overwrites
ignored files when it is fast-forwarding. This matches what merge does
when fast-forwarding but I'm not convinced either of them should be
doing this by default (I think checkout doing it is probably asking for
trouble), as you point out most operations preserve ignored files. When
pull fast-forwards it does not overwrite ignored files.
Both checkout and merge have an undocumented --overwrite-ignore option
which is on by default. Checkout and fast-forward merges overwriting
ignored files dates back a long way to commit 1127148089 ("Loosen
"working file will be lost" check in Porcelain-ish", 2006-12-04). There
does not seem to have been much discussion of changing the semantics of
ignored files around the patches that implemented this [1,2]. There is a
brief mention of doing it in this thread [3] but no one seems to comment
on the idea as far as I can see. Before this change ignored files were
just ignored by status and add but otherwise treated like any other
untracked file.
I'll put a patch together to fix rebase -i, I'd like to see the defaults
for merge and checkout changed but I'm not sure that would be popular.
It does seem like surprising behavior though when most operations try to
preserve untracked files.
Best Wishes
Phillip
[1]
https://public-inbox.org/git/7vlklnkv39.fsf@assigned-by-dhcp.cox.net/T/#u
[2]
https://public-inbox.org/git/7vbqmjkuzd.fsf@assigned-by-dhcp.cox.net/T/#u
[3]https://public-inbox.org/git/Pine.LNX.4.64.0610081657400.3952@g5.osdl.org/
> On Fri, Apr 12, 2019 at 9:30 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> 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
>> not overwrite the ignored file. There has been some discussion about
>> introducing 'precious' files that are ignored but protected in the same
>> way as untracked files [1].
>>
>> Best Wishes
>>
>> Phillip
>>
>> [1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
>>
>> But interactive
>>> rebase doesn't detect this (non-interactive rebase works fine).
>>>
>>> Reproduction:
>>> -----
>>>
>>> #!/bin/sh
>>> mkdir upstream
>>> cd upstream
>>> git init
>>> echo 1 >feature-1
>>> git add feature-1
>>> git commit -m "feature 1"
>>>
>>> cd ..
>>> git clone upstream local
>>> cd local
>>> # write some tools for our own convenience
>>> echo ours >tools
>>> echo /tools >>.git/info/exclude
>>> # start working on a feature
>>> git checkout -b f2
>>> echo wip >feature-2
>>> git add feature-2
>>> git commit -m "wip"
>>>
>>> cd ../upstream
>>> # official tools are available
>>> echo theirs >tools
>>> git add tools
>>> git commit -m "tools"
>>>
>>> cd ../local
>>> git fetch ../upstream master
>>>
>>> # this would be okay
>>> #git rebase FETCH_HEAD
>>>
>>> # problem: overwrites tools silently
>>> GIT_EDITOR=true git rebase -i FETCH_HEAD
>>>
>>> cat tools
>>>
>>> -----
>>>
>>> Expected: `git rebase -i` fails because it would have to overwrite the
>>> untracked "tools" file. Contents of tools file remains `ours`.
>>>
>>> Actual: Contents of tools file becomes `theirs`.
>>>
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-04-18 18:16 0% ` Bret Barkelew
@ 2019-04-27 23:20 0% ` Johannes Schindelin
2019-05-29 16:40 0% ` Bret Barkelew
0 siblings, 1 reply; 69+ results
From: Johannes Schindelin @ 2019-04-27 23:20 UTC (permalink / raw)
To: Bret Barkelew; +Cc: Bryan Turner, git
[-- Attachment #1: Type: text/plain, Size: 5467 bytes --]
Hi Bret,
On Thu, 18 Apr 2019, Bret Barkelew wrote:
> This issue is now being reported by more users inside MS. I'll also
> reach out to the Git for Windows advocacy group to see if they have
> any ideas.
>
> I have not had time to figure out the inner workings of Tcl/Tk. Is
> there any way to turn on tracing/logging in Git for which commands are
> being called by gitk?
Thank you for reaching out with detailed information internally, I am
happy to report that together with the help of Max Kirillov, this is now
resolved and a snapshot is available from
https://wingit.blob.core.windows.net/files/index.html that has the fix.
Ciao,
Johannes
> On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:
> >
> > On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > Hi Bret,
> > >
> > > in that case, please try to find a way to trace the commands in a Tcl/Tk
> > > program (which gitk is) and see which command triggers the error.
> >
> > Er... that's a little out of my depth. I'll see if I can find time to learn.
> > Meanwhile, is there any way to request better instrumentation for the
> > error dialog so this data could have been collected for me?
> >
> > >
> > > Ciao,
> > > Johannes
> > >
> > >
> > > On Wed, 9 Jan 2019, Bret Barkelew wrote:
> > >
> > > > Will try to reply in-line, when appropriate.
> > > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> > > > has the issue.
> > > >
> > > > - Bret
> > > >
> > > >
> > > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> > > > <Johannes.Schindelin@gmx.de> wrote:
> > > > >
> > > > > Hi Bret,
> > > > >
> > > > >
> > > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> > > > >
> > > > > > They are the exact same path (with a different drive letter).
> > > > >
> > > > > [it's a bit hard to follow the thread if you top-post a reply to an
> > > > > inline-replied answer, maybe imitate the style of other mails in the
> > > > > future.]
> > > > >
> > > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > > > > and installed 2.19.0 on the failing system, and the older version of
> > > > > > Git works.
> > > > > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > > > > names in the Windows registry, which did not resolve the issue with
> > > > > > git 2.20.1.
> > > > > >
> > > > > > Happy to collect any additional data.
> > > > >
> > > > > Please try the latest snapshot at
> > > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > > > > might be fixed via
> > > > > https://github.com/git-for-windows/MINGW-packages/pull/32).
> > > > >
> > > > > Ciao,
> > > > > Johannes
> > > > >
> > > > > > - Bret
> > > > > >
> > > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > > > > >>
> > > > > > >> When I open gitk in a particular repository under this version of Git
> > > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > > > > >> "git": file name too long". I've noticed that the most pronounced
> > > > > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > > > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > > > > >> narrowed down the following things:
> > > > > > >>
> > > > > > >> - This does not happen with the same repo if I use a system that has
> > > > > > >> git 2.19.0.windows.1 on another machine.
> > > > > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > > > > >
> > > > > > >
> > > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > > > > >
> > > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > > > > >
> > > > > > >>
> > > > > > >> However, as soon as the remote updates with any changes on a given
> > > > > > >> fetch/pull, the repo is put in a bad state permanently.
> > > > > > >>
> > > > > > >> I've pasted the output from gitk below...
> > > > > > >>
> > > > > > >> couldn't execute "git": file name too long
> > > > > > >> couldn't execute "git": file name too long
> > > > > > >> while executing
> > > > > > >> "open $cmd r"
> > > > > > >> (procedure "getallcommits" line 48)
> > > > > > >> invoked from within
> > > > > > >> "getallcommits"
> > > > > > >> (procedure "readcache" line 80)
> > > > > > >> invoked from within
> > > > > > >> "readcache file827e200"
> > > > > > >> ("eval" body line 1)
> > > > > > >> invoked from within
> > > > > > >> "eval $script"
> > > > > > >> (procedure "dorunq" line 11)
> > > > > > >> invoked from within
> > > > > > >> "dorunq"
> > > > > > >> ("after" script)
> > > > > > >>
> > > > > > >> Happy to gather whatever data needed.
> > > > > > >> Thanks!
> > > > > > >> - Bret Barkelew
> > > > > >
> > > >
>
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-01-10 18:55 0% ` Bret Barkelew
@ 2019-04-18 18:16 0% ` Bret Barkelew
2019-04-27 23:20 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Bret Barkelew @ 2019-04-18 18:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bryan Turner, git
This issue is now being reported by more users inside MS. I'll also
reach out to the Git for Windows advocacy group to see if they have
any ideas.
I have not had time to figure out the inner workings of Tcl/Tk. Is
there any way to turn on tracing/logging in Git for which commands are
being called by gitk?
On Thu, Jan 10, 2019 at 10:55 AM Bret Barkelew <bret@corthon.com> wrote:
>
> On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Hi Bret,
> >
> > in that case, please try to find a way to trace the commands in a Tcl/Tk
> > program (which gitk is) and see which command triggers the error.
>
> Er... that's a little out of my depth. I'll see if I can find time to learn.
> Meanwhile, is there any way to request better instrumentation for the
> error dialog so this data could have been collected for me?
>
> >
> > Ciao,
> > Johannes
> >
> >
> > On Wed, 9 Jan 2019, Bret Barkelew wrote:
> >
> > > Will try to reply in-line, when appropriate.
> > > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> > > has the issue.
> > >
> > > - Bret
> > >
> > >
> > > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> > > <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > Hi Bret,
> > > >
> > > >
> > > > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> > > >
> > > > > They are the exact same path (with a different drive letter).
> > > >
> > > > [it's a bit hard to follow the thread if you top-post a reply to an
> > > > inline-replied answer, maybe imitate the style of other mails in the
> > > > future.]
> > > >
> > > > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > > > and installed 2.19.0 on the failing system, and the older version of
> > > > > Git works.
> > > > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > > > names in the Windows registry, which did not resolve the issue with
> > > > > git 2.20.1.
> > > > >
> > > > > Happy to collect any additional data.
> > > >
> > > > Please try the latest snapshot at
> > > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > > > might be fixed via
> > > > https://github.com/git-for-windows/MINGW-packages/pull/32).
> > > >
> > > > Ciao,
> > > > Johannes
> > > >
> > > > > - Bret
> > > > >
> > > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > > > >
> > > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > > > >>
> > > > > >> When I open gitk in a particular repository under this version of Git
> > > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > > > >> "git": file name too long". I've noticed that the most pronounced
> > > > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > > > >> narrowed down the following things:
> > > > > >>
> > > > > >> - This does not happen with the same repo if I use a system that has
> > > > > >> git 2.19.0.windows.1 on another machine.
> > > > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > > > >
> > > > > >
> > > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > > > >
> > > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > > > >
> > > > > >>
> > > > > >> However, as soon as the remote updates with any changes on a given
> > > > > >> fetch/pull, the repo is put in a bad state permanently.
> > > > > >>
> > > > > >> I've pasted the output from gitk below...
> > > > > >>
> > > > > >> couldn't execute "git": file name too long
> > > > > >> couldn't execute "git": file name too long
> > > > > >> while executing
> > > > > >> "open $cmd r"
> > > > > >> (procedure "getallcommits" line 48)
> > > > > >> invoked from within
> > > > > >> "getallcommits"
> > > > > >> (procedure "readcache" line 80)
> > > > > >> invoked from within
> > > > > >> "readcache file827e200"
> > > > > >> ("eval" body line 1)
> > > > > >> invoked from within
> > > > > >> "eval $script"
> > > > > >> (procedure "dorunq" line 11)
> > > > > >> invoked from within
> > > > > >> "dorunq"
> > > > > >> ("after" script)
> > > > > >>
> > > > > >> Happy to gather whatever data needed.
> > > > > >> Thanks!
> > > > > >> - Bret Barkelew
> > > > >
> > >
^ permalink raw reply [relevance 0%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
2019-04-14 1:59 0% ` wh
@ 2019-04-14 13:24 0% ` Phillip Wood
2019-05-02 15:45 0% ` Phillip Wood
1 sibling, 0 replies; 69+ results
From: Phillip Wood @ 2019-04-14 13:24 UTC (permalink / raw)
To: wh, phillip.wood; +Cc: git
On 14/04/2019 02:59, wh wrote:
> Thanks for the info about the upcoming "precious" attribute. Looks useful.
Hmm, unfortunately it's not looking so hopeful now [1]
> I didn't get the impression that Git normally overwrites ignored
> files. I ran some more experiments:
>
> git rebase FETCH_HEAD # bails
> git rebase -i FETCH_HEAD # overwrites
> git merge FETCH_HEAD # bails
> git reset --keep FETCH_HEAD # bails
> git reset --merge FETCH_HEAD # bails
> git checkout FETCH_HEAD # overwrites
> # without feature 2 locally:
> git merge FETCH_HEAD # overwrites, fast-forwards
> git merge --no-ff FETCH_HEAD # bails
Thanks for sharing that, I was assuming the other commands behaved like
checkout, I'm intrigued that merge behaves differently to rebase -i as
they use the same underlying machinery, I'm a bit snowed under at the
moment but I'll try and take a look at what's going sometime in the not
too distant future.
Best Wishes
Phillip
[1]
https://public-inbox.org/git/CACsJy8AEZ-Lz6zgEsuNukvphB9TTa9FAC1gK05fhnie2xtfc9w@mail.gmail.com/T/#u
> On Fri, Apr 12, 2019 at 9:30 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> 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
>> not overwrite the ignored file. There has been some discussion about
>> introducing 'precious' files that are ignored but protected in the same
>> way as untracked files [1].
>>
>> Best Wishes
>>
>> Phillip
>>
>> [1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
>>
>> But interactive
>>> rebase doesn't detect this (non-interactive rebase works fine).
>>>
>>> Reproduction:
>>> -----
>>>
>>> #!/bin/sh
>>> mkdir upstream
>>> cd upstream
>>> git init
>>> echo 1 >feature-1
>>> git add feature-1
>>> git commit -m "feature 1"
>>>
>>> cd ..
>>> git clone upstream local
>>> cd local
>>> # write some tools for our own convenience
>>> echo ours >tools
>>> echo /tools >>.git/info/exclude
>>> # start working on a feature
>>> git checkout -b f2
>>> echo wip >feature-2
>>> git add feature-2
>>> git commit -m "wip"
>>>
>>> cd ../upstream
>>> # official tools are available
>>> echo theirs >tools
>>> git add tools
>>> git commit -m "tools"
>>>
>>> cd ../local
>>> git fetch ../upstream master
>>>
>>> # this would be okay
>>> #git rebase FETCH_HEAD
>>>
>>> # problem: overwrites tools silently
>>> GIT_EDITOR=true git rebase -i FETCH_HEAD
>>>
>>> cat tools
>>>
>>> -----
>>>
>>> Expected: `git rebase -i` fails because it would have to overwrite the
>>> untracked "tools" file. Contents of tools file remains `ours`.
>>>
>>> Actual: Contents of tools file becomes `theirs`.
>>>
^ permalink raw reply [relevance 0%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
2019-04-12 16:30 0% ` Phillip Wood
@ 2019-04-14 1:59 0% ` wh
2019-04-14 13:24 0% ` Phillip Wood
2019-05-02 15:45 0% ` Phillip Wood
0 siblings, 2 replies; 69+ results
From: wh @ 2019-04-14 1:59 UTC (permalink / raw)
To: phillip.wood; +Cc: git
Thanks for the info about the upcoming "precious" attribute. Looks useful.
I didn't get the impression that Git normally overwrites ignored
files. I ran some more experiments:
git rebase FETCH_HEAD # bails
git rebase -i FETCH_HEAD # overwrites
git merge FETCH_HEAD # bails
git reset --keep FETCH_HEAD # bails
git reset --merge FETCH_HEAD # bails
git checkout FETCH_HEAD # overwrites
# without feature 2 locally:
git merge FETCH_HEAD # overwrites, fast-forwards
git merge --no-ff FETCH_HEAD # bails
On Fri, Apr 12, 2019 at 9:30 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> 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
> not overwrite the ignored file. There has been some discussion about
> introducing 'precious' files that are ignored but protected in the same
> way as untracked files [1].
>
> Best Wishes
>
> Phillip
>
> [1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
>
> But interactive
> > rebase doesn't detect this (non-interactive rebase works fine).
> >
> > Reproduction:
> > -----
> >
> > #!/bin/sh
> > mkdir upstream
> > cd upstream
> > git init
> > echo 1 >feature-1
> > git add feature-1
> > git commit -m "feature 1"
> >
> > cd ..
> > git clone upstream local
> > cd local
> > # write some tools for our own convenience
> > echo ours >tools
> > echo /tools >>.git/info/exclude
> > # start working on a feature
> > git checkout -b f2
> > echo wip >feature-2
> > git add feature-2
> > git commit -m "wip"
> >
> > cd ../upstream
> > # official tools are available
> > echo theirs >tools
> > git add tools
> > git commit -m "tools"
> >
> > cd ../local
> > git fetch ../upstream master
> >
> > # this would be okay
> > #git rebase FETCH_HEAD
> >
> > # problem: overwrites tools silently
> > GIT_EDITOR=true git rebase -i FETCH_HEAD
> >
> > cat tools
> >
> > -----
> >
> > Expected: `git rebase -i` fails because it would have to overwrite the
> > untracked "tools" file. Contents of tools file remains `ours`.
> >
> > Actual: Contents of tools file becomes `theirs`.
> >
^ permalink raw reply [relevance 0%]
* Re: [BUG] rebase --interactive silently overwrites ignored files
2019-04-11 23:56 4% [BUG] rebase --interactive silently overwrites ignored files wh
@ 2019-04-12 16:30 0% ` Phillip Wood
2019-04-14 1:59 0% ` wh
0 siblings, 1 reply; 69+ results
From: Phillip Wood @ 2019-04-12 16:30 UTC (permalink / raw)
To: wh, 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
not overwrite the ignored file. There has been some discussion about
introducing 'precious' files that are ignored but protected in the same
way as untracked files [1].
Best Wishes
Phillip
[1] https://public-inbox.org/git/20190409102649.22115-1-pclouds@gmail.com/
But interactive
> rebase doesn't detect this (non-interactive rebase works fine).
>
> Reproduction:
> -----
>
> #!/bin/sh
> mkdir upstream
> cd upstream
> git init
> echo 1 >feature-1
> git add feature-1
> git commit -m "feature 1"
>
> cd ..
> git clone upstream local
> cd local
> # write some tools for our own convenience
> echo ours >tools
> echo /tools >>.git/info/exclude
> # start working on a feature
> git checkout -b f2
> echo wip >feature-2
> git add feature-2
> git commit -m "wip"
>
> cd ../upstream
> # official tools are available
> echo theirs >tools
> git add tools
> git commit -m "tools"
>
> cd ../local
> git fetch ../upstream master
>
> # this would be okay
> #git rebase FETCH_HEAD
>
> # problem: overwrites tools silently
> GIT_EDITOR=true git rebase -i FETCH_HEAD
>
> cat tools
>
> -----
>
> Expected: `git rebase -i` fails because it would have to overwrite the
> untracked "tools" file. Contents of tools file remains `ours`.
>
> Actual: Contents of tools file becomes `theirs`.
>
^ permalink raw reply [relevance 0%]
* [BUG] rebase --interactive silently overwrites ignored files
@ 2019-04-11 23:56 4% wh
2019-04-12 16:30 0% ` Phillip Wood
0 siblings, 1 reply; 69+ results
From: wh @ 2019-04-11 23:56 UTC (permalink / raw)
To: git
I'm using git 2.20.1 from Debian. Git is usually careful not to
overwrite untracked files, including ignored files. But interactive
rebase doesn't detect this (non-interactive rebase works fine).
Reproduction:
-----
#!/bin/sh
mkdir upstream
cd upstream
git init
echo 1 >feature-1
git add feature-1
git commit -m "feature 1"
cd ..
git clone upstream local
cd local
# write some tools for our own convenience
echo ours >tools
echo /tools >>.git/info/exclude
# start working on a feature
git checkout -b f2
echo wip >feature-2
git add feature-2
git commit -m "wip"
cd ../upstream
# official tools are available
echo theirs >tools
git add tools
git commit -m "tools"
cd ../local
git fetch ../upstream master
# this would be okay
#git rebase FETCH_HEAD
# problem: overwrites tools silently
GIT_EDITOR=true git rebase -i FETCH_HEAD
cat tools
-----
Expected: `git rebase -i` fails because it would have to overwrite the
untracked "tools" file. Contents of tools file remains `ours`.
Actual: Contents of tools file becomes `theirs`.
^ permalink raw reply [relevance 4%]
* git push --atomic and HTTP(S) vs SSH
@ 2019-04-09 6:11 2% Bryan Turner
0 siblings, 0 replies; 69+ results
From: Bryan Turner @ 2019-04-09 6:11 UTC (permalink / raw)
To: Git Users
A question came up on Stack Overflow[1], and then again through our
support channels, about "git push --atomic" and a behavior mismatch
between HTTP(S) and SSH. I'm easily able to reproduce the behavior,
but I don't see anything Bitbucket Server-related about how this works
(and I get exactly the same mismatched behavior against GitHub; but
that's not really a surprise given what I see in the wire protocol.
First, a setup: 2 commits, with the second commit then amended to make
a 3rd commit.
git init foo
cd foo
echo 'Hello, World' > file.txt
git add file.txt
git commit -m "Initial commit"
echo 'Goodbye, World' > file.txt
git commit -am "Second commit"
git tag original-message
echo 'Goodbye, Cruel World' > file.txt
git commit -a --amend --no-edit
git tag amended-message
Now, given an HTTP remote: (Assume "atomic-pushes" is an empty,
just-created repository)
git remote add http https://github.com/bturner/atomic-pushes.git
git push http original-message:refs/heads/master
git push --atomic http amended-message:refs/heads/master
amended-message:refs/heads/branch-1
So we push the original message commit to master first, and then we
try to push (without --force) the amended commit to both master and a
new branch. That'll produce this:
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'branch-1' on GitHub by visiting:
remote: https://github.com/bturner/atomic-pushes/pull/new/branch-1
remote:
To https://github.com/bturner/atomic-pushes.git
* [new branch] HEAD -> branch-1
! [rejected] HEAD -> master (non-fast-forward)
error: failed to push some refs to
'https://github.com/bturner/atomic-pushes.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Now let's try it with SSH: (Using a different branch because the HTTP
push created branch-1)
git remote add ssh git@github.com:bturner/atomic-pushes.git
git push --atomic ssh amended-message:refs/heads/master
amended-message:refs/heads/branch-2
Now we see:
error: atomic push failed for ref refs/heads/master. status: 2
To git@github.com:bturner/atomic-pushes.git
! [rejected] HEAD -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:bturner/atomic-pushes.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
No mention of branch-2 at all, but if I do a "git ls-remote ssh" I see:
fe86a3eae65e18787040499c17a567096159b9ce HEAD
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-1
fe86a3eae65e18787040499c17a567096159b9ce refs/heads/master
So branch-2 didn't get created.
Looking at the wire protocol with GIT_TRACE_PACKET, I see this
conversation for HTTP: (At this point I've done several tests, which
have created various branches, so I'm now trying to push master and
branch-4)
22:16:06.562939 pkt-line.c:46 packet: git< #
service=git-receive-pack
22:16:06.562990 pkt-line.c:46 packet: git< 0000
22:16:06.562994 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319
refs/heads/branch-1\0report-status delete-refs side-band-64k quiet
atomic ofs-delta agent=git/github-g4f6c801f9475
22:16:06.563013 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-2
22:16:06.563016 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-3
22:16:06.563019 pkt-line.c:46 packet: git<
fe86a3eae65e18787040499c17a567096159b9ce refs/heads/master
22:16:06.563024 pkt-line.c:46 packet: git< 0000
22:16:06.563329 pkt-line.c:46 packet: git>
HEAD:refs/heads/branch-4
22:16:06.563346 pkt-line.c:46 packet: git> 0000
22:16:06.563357 run-command.c:347 trace: run_command:
'send-pack' '--stateless-rpc' '--helper-status' '--thin' '--progress'
'https://github.com/bturner/atomic-pushes.git/' '--stdin'
22:16:06.563765 exec_cmd.c:129 trace: exec: 'git' 'send-pack'
'--stateless-rpc' '--helper-status' '--thin' '--progress'
'https://github.com/bturner/atomic-pushes.git/' '--stdin'
22:16:06.564691 git.c:348 trace: built-in: git
'send-pack' '--stateless-rpc' '--helper-status' '--thin' '--progress'
'https://github.com/bturner/atomic-pushes.git/' '--stdin'
22:16:06.564788 pkt-line.c:46 packet: git<
HEAD:refs/heads/branch-4
22:16:06.564793 pkt-line.c:46 packet: git< 0000
22:16:06.564797 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319
refs/heads/branch-1\0report-status delete-refs side-band-64k quiet
atomic ofs-delta agent=git/github-g4f6c801f9475
22:16:06.564805 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-2
22:16:06.564826 pkt-line.c:46 packet: git<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-3
22:16:06.564830 pkt-line.c:46 packet: git<
fe86a3eae65e18787040499c17a567096159b9ce refs/heads/master
22:16:06.564834 pkt-line.c:46 packet: git< 0000
22:16:06.564970 pkt-line.c:46 packet: git>
0000000000000000000000000000000000000000
6925c65344e87c65e5cd2b56d392cd06ef96ca71 refs/heads/branch-4\0
report-status side-band-64k agent=git/2.4.0
22:16:06.564989 pkt-line.c:46 packet: git> 0000
22:16:06.565027 pkt-line.c:46 packet: git<
00960000000000000000000000000000000000000000
6925c65344e87c65e5cd2b56d392cd06ef96ca71 refs/heads/branch-4\0
report-status side-band-64k agent=git/2.4.00000
Based on that, I see that the server advertises the existing refs, and
"atomic" support, and then the client _only_ sends branch-4; it
doesn't send anything for master at all. That implies the
non-fast-forward rejection for master is actually being done locally,
not on the server. Only one ref change gets sent to the server, which
applies without issue.
Looking at SSH shows very different output: (branch-4 now exists
because of the HTTP test above, so now I'm pushing master and
branch-5)
22:56:08.609608 pkt-line.c:46 packet: push<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319
refs/heads/branch-1\0report-status delete-refs side-band-64k quiet
atomic ofs-delta agent=git/github-g4f6c801f9475
22:56:08.609774 pkt-line.c:46 packet: push<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-2
22:56:08.609798 pkt-line.c:46 packet: push<
1b9c21b7aeb6ad03957cc8a023b2406d3ccee319 refs/heads/branch-3
22:56:08.609801 pkt-line.c:46 packet: push<
6925c65344e87c65e5cd2b56d392cd06ef96ca71 refs/heads/branch-4
22:56:08.609825 pkt-line.c:46 packet: push<
fe86a3eae65e18787040499c17a567096159b9ce refs/heads/master
22:56:08.609831 pkt-line.c:46 packet: push< 0000
There are no "push>" lines at all. The server sends its ref
advertisement, and then it seems like the non-fast-forward rejection
for master happens locally, similar to HTTPS, but then, unlike HTTPS,
the SSH push is simply aborted without ever sending anything to the
server at all.
I've verified this with Git 2.4.0 as a client (which appears to be
where "git push --atomic" was first introduced), and with Git 2.20.1
as a client, to ensure there wasn't a regression somewhere, and the
behavior is identical for both versions. (I've also verified it with
both Linux and Windows clients, just for extra paranoia.)
The result seems unexpected from a user perspective, but looking at
the code it seems like it's working as implemented. "remote-curl.c"
doesn't include "--atomic" when it runs "git send-pack", so it looks
like HTTP(S) pushes simply ignore "git push --atomic" entirely.
Am I misunderstanding how this is supposed to work? If not, should the
documentation be updated to clarify that HTTP(S) remotes don't support
"--atomic"?
Best regards,
Bryan Turner
[1] https://stackoverflow.com/questions/37531663/git-push-atomic-not-failing
^ permalink raw reply [relevance 2%]
* Re: Fw: git describe issue
@ 2019-04-03 6:59 4% ` Bryan Turner
0 siblings, 0 replies; 69+ results
From: Bryan Turner @ 2019-04-03 6:59 UTC (permalink / raw)
To: Amiel Elboim; +Cc: git@vger.kernel.org
On Tue, Apr 2, 2019 at 11:47 PM Amiel Elboim <amielel@matrix.co.il> wrote:
> Hi!
>
> I've found strange behavior with 'git describe' command, look like for me as bug.
>
> In the case I create 2 tags on same commit and I run 'git describe --tags' I expect to get the latest tag, but always I get the first tag I created on the commit.
>
> Unlike git-describe documentations - "The command finds the most recent tag that is reachable from a commit. "
>
> Simple example -
>
> amiel@CLINIKALDEV10:~/Xpress$ git tag v1
> amiel@CLINIKALDEV10:~/Xpress$ git tag v2
> amiel@CLINIKALDEV10:~/Xpress$ git describe --tags
> v1
With this example, Git has no way to know which tag is "newer".
They're lightweight tags, which means they have no metadata of their
own; they just tag a commit. That means, as far as "age" goes, they're
both the same because their age is drawn from the tagged commit, which
is the same for both. (Since tag names are entirely free-form, I'm not
sure Git makes any effort to try and parse them to "guess" which is
newer; that seems like a Sisyphean task to me.)
If you run this with annotated tags, you get different output (at
least on Git 2.20.1, what I happened to have installed; you never
mentioned your Git version)
incom@Jael MINGW64 /c/Temp/first.git (BARE:master)
$ git tag -a v1
incom@Jael MINGW64 /c/Temp/first.git (BARE:master)
$ git tag -a v2
incom@Jael MINGW64 /c/Temp/first.git (BARE:master)
$ git describe --tags
v2
Hope this helps!
Bryan
^ permalink raw reply [relevance 4%]
* on fedora, "man gitweb" exists but actual gitweb command is missing
@ 2019-02-23 13:11 4% Robert P. J. Day
0 siblings, 0 replies; 69+ results
From: Robert P. J. Day @ 2019-02-23 13:11 UTC (permalink / raw)
To: Git Mailing list
not so much a git issue as what looks like a fedora packaging issue.
on my updated fedora 29 system, "man gitweb" works:
GITWEB(1) Git Manual GITWEB(1)
NAME
gitweb - Git web interface (web frontend to Git repositories)
SYNOPSIS
To get started with gitweb, run git-instaweb(1) from a Git
repository. This would configure and start your web server, and
run web browser pointing to gitweb.
... snip ...
and the corresponding man page source file clearly belongs to the
"git" package:
$ rpm -qf /usr/share/man/man1/gitweb.1.gz
git-2.20.1-1.fc29.x86_64
$
but there is no "git instaweb" command:
$ git instaweb
git: 'instaweb' is not a git command. See 'git --help'.
$
it took only a few seconds to determine that fedora bundles that
functionality in two separate packages which are not dependencies of
"git": "gitweb" and "git-instaweb" (output abbreviated):
$ sudo dnf install git-instaweb
...
Installing:
git-instaweb
Installing dependencies:
gitweb
perl-CGI
and now "git-instaweb" works fine.
the question is, is it not inconsistent for fedora's basic "git"
package to include the man page for gitweb, without including the
corresponding functionality? is this something i should submit a
fedora bugzilla report for? or am i misunderstanding something?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [relevance 4%]
* Re: git rebase --continue after solving conflicts doesn't work anymore
2019-02-19 14:03 3% ` Sebastián Mancilla
2019-02-19 14:18 0% ` Christian Couder
@ 2019-02-19 14:32 0% ` Phillip Wood
1 sibling, 0 replies; 69+ results
From: Phillip Wood @ 2019-02-19 14:32 UTC (permalink / raw)
To: Sebastián Mancilla, phillip.wood
Cc: Eric Sunshine, Christian Couder, git,
Nguyễn Thái Ngọc Duy
Hi Sebastián
On 19/02/2019 14:03, Sebastián Mancilla wrote:
> My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently
> Git 2.20.1).
>
> I investigated this further, and I think I found the problem on my end.
>
> When I actually run "git rebase --interactive <commit>" from the terminal,
> everything works fine.
>
> But almost every time I start my rebases from inside "tig" [0], for which I
> have this mapping:
>
> bind main R <git rebase -i %(commit)
>
> tig will exit after running that command, and then I normally continue working
> on the rebase from the shell. And it is when I start the rebase this way that
> "git rebase --continue" fails after solving conflicts.
>
> Second, I have tig installed with the Nix package manager [1], which shows
>
> $ ~/.nix-profile/bin/tig --version
> tig version 2.4.1
> ncursesw version 6.1.20180127
> readline version 6.3
>
> So, I decided to try with tig from Homebrew, and then the problem
> doesn't happen.
> The Hombrew version of tig shows:
>
> $ /usr/local/bin/tig --version
> tig version 2.4.1
> ncurses version 5.7.20081102
> readline version 8.0
>
> I will keep using tig from Homebrew to avoid issues for now.
>
>
> In summary, the problem only happens when I start the rebase from inside tig,
> but only when tig is the version from the Nix package manager, which has
> different dependencies than the Homebrew version of tig.
> And it happens for Git 2.20.x and master. Git <= 2.19.x works fine.
>
>
> I also did bisect Git (I never though I would be bisecting Git itself).
> It landed in this commit: 4d010a757c (sequencer: use read_author_script(),
> 2018-10-31).
>
> And the content of .git/rebase-merge/author-script is always the same:
>
> GIT_AUTHOR_NAME='Sebastián Mancilla'
> GIT_AUTHOR_EMAIL='smancill@jlab.org'
> GIT_AUTHOR_DATE='@1550530007 -0300
>
Thanks for all the details, the problem is that the older version of git
that the Nix tig uses to start the rebase creates author scripts that
are not correctly quoted (as you can see above) and cannot be read by
the newer version of git you were using to continue the rebase (it
should be possible to continue the rebase with the git bundled with Nix
tig). Anyway I'm glad the Homebrew tig is working for you. When we made
this change and discussed whether we needed backwards compatibility I
think we only discussed the possibility of git being upgrading while a
rebase was stopped for conflict resolution, not the possibility of
people having two different versions of git installed and using one to
start a rebase and the other to continue it.
Best Wishes
Phillip
> Regards
>
>
> [0]: https://github.com/jonas/tig
> [1]: https://nixos.org/nix/
>
> El mar., 19 de feb. de 2019 a la(s) 06:59, Phillip Wood
> (phillip.wood@talktalk.net) escribió:
>>
>> Dear Sebastián
>>
>> On 19/02/2019 07:22, Eric Sunshine wrote:
>>> [cc:+phillip.wood@talktalk.net]
>>
>> Thanks Eric
>>
>>> On Tue, Feb 19, 2019 at 1:45 AM Christian Couder
>>> <christian.couder@gmail.com> wrote:
>>>> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
>>>>> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
>>>>> and running "git rebase --continue" I get this error most of the time:
>>>>>
>>>>> error: unable to dequote value of 'GIT_AUTHOR_DATE'
>>>>
>>>> It looks like this can happen only when an "author-script" file (most
>>>> likely .git/rebase-merge/author-script)
>>
>> or it could be .git/rebase-apply/author-script depending on the options
>> passed to rebase when it started (the sequencer and am use the same code
>> for reading the author script now)
>>
>>>> is read by the sequencer
>>>> mechanism. Could you show us the content of this file on your machine?
>>>
>>> A very good suggestion considering that there have been changes
>>> recently specifically related to the parsing of GIT_AUTHOR_DATE in C
>>> code.
>>
>> That would be very helpful, without seeing that it's hard to know what
>> the problem is.
>>
>> Best Wishes
>>
>> Phillip
>>
>
>
^ permalink raw reply [relevance 0%]
* Re: git rebase --continue after solving conflicts doesn't work anymore
2019-02-19 14:03 3% ` Sebastián Mancilla
@ 2019-02-19 14:18 0% ` Christian Couder
2019-02-19 14:32 0% ` Phillip Wood
1 sibling, 0 replies; 69+ results
From: Christian Couder @ 2019-02-19 14:18 UTC (permalink / raw)
To: Sebastián Mancilla; +Cc: Phillip Wood, Eric Sunshine, git
On Tue, Feb 19, 2019 at 3:03 PM Sebastián Mancilla <smancill.m@gmail.com> wrote:
>
> My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently
> Git 2.20.1).
>
> I investigated this further, and I think I found the problem on my end.
[...]
> I also did bisect Git (I never though I would be bisecting Git itself).
> It landed in this commit: 4d010a757c (sequencer: use read_author_script(),
> 2018-10-31).
Thanks for investigating this.
> And the content of .git/rebase-merge/author-script is always the same:
>
> GIT_AUTHOR_NAME='Sebastián Mancilla'
> GIT_AUTHOR_EMAIL='smancill@jlab.org'
> GIT_AUTHOR_DATE='@1550530007 -0300
When I look at such a file I get the following:
GIT_AUTHOR_DATE='@1549569954 -0800'
so it seems to me that a single quote is missing at the end of the
line in your file, which might explain the error.
Not sure which software is writing this file, but from what you
described it might be the tig you had previously installed.
^ permalink raw reply [relevance 0%]
* Re: git rebase --continue after solving conflicts doesn't work anymore
@ 2019-02-19 14:03 3% ` Sebastián Mancilla
2019-02-19 14:18 0% ` Christian Couder
2019-02-19 14:32 0% ` Phillip Wood
0 siblings, 2 replies; 69+ results
From: Sebastián Mancilla @ 2019-02-19 14:03 UTC (permalink / raw)
To: phillip.wood; +Cc: Eric Sunshine, Christian Couder, git
My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently
Git 2.20.1).
I investigated this further, and I think I found the problem on my end.
When I actually run "git rebase --interactive <commit>" from the terminal,
everything works fine.
But almost every time I start my rebases from inside "tig" [0], for which I
have this mapping:
bind main R <git rebase -i %(commit)
tig will exit after running that command, and then I normally continue working
on the rebase from the shell. And it is when I start the rebase this way that
"git rebase --continue" fails after solving conflicts.
Second, I have tig installed with the Nix package manager [1], which shows
$ ~/.nix-profile/bin/tig --version
tig version 2.4.1
ncursesw version 6.1.20180127
readline version 6.3
So, I decided to try with tig from Homebrew, and then the problem
doesn't happen.
The Hombrew version of tig shows:
$ /usr/local/bin/tig --version
tig version 2.4.1
ncurses version 5.7.20081102
readline version 8.0
I will keep using tig from Homebrew to avoid issues for now.
In summary, the problem only happens when I start the rebase from inside tig,
but only when tig is the version from the Nix package manager, which has
different dependencies than the Homebrew version of tig.
And it happens for Git 2.20.x and master. Git <= 2.19.x works fine.
I also did bisect Git (I never though I would be bisecting Git itself).
It landed in this commit: 4d010a757c (sequencer: use read_author_script(),
2018-10-31).
And the content of .git/rebase-merge/author-script is always the same:
GIT_AUTHOR_NAME='Sebastián Mancilla'
GIT_AUTHOR_EMAIL='smancill@jlab.org'
GIT_AUTHOR_DATE='@1550530007 -0300
Regards
[0]: https://github.com/jonas/tig
[1]: https://nixos.org/nix/
El mar., 19 de feb. de 2019 a la(s) 06:59, Phillip Wood
(phillip.wood@talktalk.net) escribió:
>
> Dear Sebastián
>
> On 19/02/2019 07:22, Eric Sunshine wrote:
> > [cc:+phillip.wood@talktalk.net]
>
> Thanks Eric
>
> > On Tue, Feb 19, 2019 at 1:45 AM Christian Couder
> > <christian.couder@gmail.com> wrote:
> >> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
> >>> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
> >>> and running "git rebase --continue" I get this error most of the time:
> >>>
> >>> error: unable to dequote value of 'GIT_AUTHOR_DATE'
> >>
> >> It looks like this can happen only when an "author-script" file (most
> >> likely .git/rebase-merge/author-script)
>
> or it could be .git/rebase-apply/author-script depending on the options
> passed to rebase when it started (the sequencer and am use the same code
> for reading the author script now)
>
> >> is read by the sequencer
> >> mechanism. Could you show us the content of this file on your machine?
> >
> > A very good suggestion considering that there have been changes
> > recently specifically related to the parsing of GIT_AUTHOR_DATE in C
> > code.
>
> That would be very helpful, without seeing that it's hard to know what
> the problem is.
>
> Best Wishes
>
> Phillip
>
--
Sebastian Mancilla
^ permalink raw reply [relevance 3%]
* Re: [ANNOUNCE] Git v2.21.0-rc1
2019-02-14 3:32 1% [ANNOUNCE] Git v2.21.0-rc1 Junio C Hamano
@ 2019-02-18 15:45 0% ` Johannes Schindelin
0 siblings, 0 replies; 69+ results
From: Johannes Schindelin @ 2019-02-18 15:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-packagers, git-for-windows
[-- Attachment #1: Type: text/plain, Size: 52637 bytes --]
Sorry for the late reply,
Git for Windows v2.21.0-rc1 is available (since Thursday night, actually)
from here:
https://github.com/git-for-windows/git/releases/tag/v2.21.0-rc1.windows.1
I would be highly grateful for extensive testing, also for -rc2 (because
we just updated the MSYS2 runtime to be based on Cygwin v3.0.0) as soon as
that one comes out.
Thanks,
Johannes
On Wed, 13 Feb 2019, Junio C Hamano wrote:
> A release candidate Git v2.21.0-rc1 is now available for testing
> at the usual places. It is comprised of 464 non-merge commits
> since v2.20.0, contributed by 60 people, 14 of which are new faces.
>
> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/testing/
>
> The following public repositories all have a copy of the
> 'v2.21.0-rc1' tag and the 'master' branch that the tag points at:
>
> url = https://kernel.googlesource.com/pub/scm/git/git
> url = git://repo.or.cz/alt-git.git
> url = https://github.com/gitster/git
>
> New contributors whose contributions weren't in v2.20.0 are as follows.
> Welcome to the Git development community!
>
> Arti Zirk, Brandon Richardson, Chayoung You, Denis Ovsienko,
> Erin Dahlgren, Force Charlie, Frank Dana, Issac Trotts, Katrin
> Leinweber, Laura Abbott, Patrick Hogg, Peter Osterlund, Shahzad
> Lone, and Slavica Djukic.
>
> Returning contributors who helped this release are as follows.
> Thanks for your continued support.
>
> Ævar Arnfjörð Bjarmason, Ben Peart, Brandon Williams, brian
> m. carlson, Carlo Marcelo Arenas Belón, Christian Couder,
> David Turner, Derrick Stolee, Elijah Newren, Eric Sunshine,
> Eric Wong, Jean-Noël Avila, Jeff King, Johannes Schindelin,
> Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano,
> Kevin Daudt, Kim Gybels, Kyle Meyer, Linus Torvalds, Luke
> Diamand, Martin Ågren, Masaya Suzuki, Matthew DeVore, Matthieu
> Moy, Max Kirillov, Nguyễn Thái Ngọc Duy, Olga Telezhnaya,
> Orgad Shaneh, Phillip Wood, Pranit Bauva, Ramsay Jones,
> Randall S. Becker, René Scharfe, Sebastian Staudt, Sergey
> Organov, Stefan Beller, Stephen P. Smith, Sven van Haastregt,
> SZEDER Gábor, Thomas Braun, Thomas Gummerer, Todd Zullinger,
> and Torsten Bögershausen.
>
> ----------------------------------------------------------------
>
> Git 2.21 Release Notes (draft)
> ==============================
>
> Backward Compatibility Notes
> ----------------------------
>
> * Historically, the "-m" (mainline) option can only be used for "git
> cherry-pick" and "git revert" when working with a merge commit.
> This version of Git no longer warns or errors out when working with
> a single-parent commit, as long as the argument to the "-m" option
> is 1 (i.e. it has only one parent, and the request is to pick or
> revert relative to that first parent). Scripts that relied on the
> behaviour may get broken with this change.
>
>
> Updates since v2.20
> -------------------
>
> UI, Workflows & Features
>
> * The "http.version" configuration variable can be used with recent
> enough versions of cURL library to force the version of HTTP used
> to talk when fetching and pushing.
>
> * Small fixes and features for fast-export and fast-import, mostly on
> the fast-export side has been made.
>
> * "git push $there $src:$dst" rejects when $dst is not a fully
> qualified refname and it is not clear what the end user meant. The
> codepath has been taught to give a clearer error message, and also
> guess where the push should go by taking the type of the pushed
> object into account (e.g. a tag object would want to go under
> refs/tags/).
>
> * "git checkout [<tree-ish>] path..." learned to report the number of
> paths that have been checked out of the index or the tree-ish,
> which gives it the same degree of noisy-ness as the case in which
> the command checks out a branch. "git checkout -m <pathspec>" to
> undo conflict resolution gives a similar message.
>
> * "git quiltimport" learned "--keep-non-patch" option.
>
> * "git worktree remove" and "git worktree move" refused to work when
> there is a submodule involved. This has been loosened to ignore
> uninitialized submodules.
>
> * "git cherry-pick -m1" was forbidden when picking a non-merge
> commit, even though there _is_ parent number 1 for such a commit.
> This was done to avoid mistakes back when "cherry-pick" was about
> picking a single commit, but is no longer useful with "cherry-pick"
> that can pick a range of commits. Now the "-m$num" option is
> allowed when picking any commit, as long as $num names an existing
> parent of the commit.
>
> * Update "git multimail" from the upstream.
>
> * "git p4" update.
>
> * The "--format=<placeholder>" option of for-each-ref, branch and tag
> learned to show a few more traits of objects that can be learned by
> the object_info API.
>
> * "git rebase -i" learned to re-execute a command given with 'exec'
> to run after it failed the last time.
>
> * "git diff --color-moved-ws" updates.
>
> * Custom userformat "log --format" learned %S atom that stands for
> the tip the traversal reached the commit from, i.e. --source.
>
> * "git instaweb" learned to drive http.server that comes with
> "batteries included" Python installation (both Python2 & 3).
>
> * A new encoding UTF-16LE-BOM has been invented to force encoding to
> UTF-16 with BOM in little endian byte order, which cannot be directly
> generated by using iconv.
>
> * A new date format "--date=human" that morphs its output depending
> on how far the time is from the current time has been introduced.
> "--date=auto:human" can be used to use this new format (or any
> existing format) when the output is going to the pager or to the
> terminal, and otherwise the default format.
>
>
> Performance, Internal Implementation, Development Support etc.
>
> * Code clean-up with optimization for the codepath that checks
> (non-)existence of loose objects.
>
> * More codepaths have become aware of working with in-core repository
> instances other than the default "the_repository".
>
> * The "strncat()" function is now among the banned functions.
>
> * Portability updates for the HPE NonStop platform.
>
> * Earlier we added "-Wformat-security" to developer builds, assuming
> that "-Wall" (which includes "-Wformat" which in turn is required
> to use "-Wformat-security") is always in effect. This is not true
> when config.mak.autogen is in use, unfortunately. This has been
> fixed by unconditionally adding "-Wall" to developer builds.
>
> * The loose object cache used to optimize existence look-up has been
> updated.
>
> * Flaky tests can now be repeatedly run under load with the
> "--stress" option.
>
> * Documentation/Makefile is getting prepared for manpage
> localization.
>
> * "git fetch-pack" now can talk the version 2 protocol.
>
> * sha-256 hash has been added and plumbed through the code to allow
> building Git with the "NewHash".
>
> * Debugging help for http transport.
>
> * "git fetch --deepen=<more>" has been corrected to work over v2
> protocol.
>
> * The code to walk tree objects has been taught that we may be
> working with object names that are not computed with SHA-1.
>
> * The in-core repository instances are passed through more codepaths.
>
> * Update the protocol message specification to allow only the limited
> use of scaled quantities. This is to ensure potential compatibility
> issues will not get out of hand.
>
> * Micro-optimize the code that prepares commit objects to be walked
> by "git rev-list" when the commit-graph is available.
>
> * "git fetch" and "git upload-pack" learned to send all exchanges over
> the sideband channel while talking the v2 protocol.
>
> * The codepath to write out commit-graph has been optimized by
> following the usual pattern of visiting objects in in-pack order.
>
> * The codepath to show progress meter while writing out commit-graph
> file has been improved.
>
> * Cocci rules have been updated to encourage use of strbuf_addbuf().
>
> * "git rebase --merge" has been reimplemented by reusing the internal
> machinery used for "git rebase -i".
>
> * More code in "git bisect" has been rewritten in C.
>
> * Instead of going through "git-rebase--am" scriptlet to use the "am"
> backend, the built-in version of "git rebase" learned to drive the
> "am" backend directly.
>
> * The assumption to work on the single "in-core index" instance has
> been reduced from the library-ish part of the codebase.
>
> * The test lint learned to catch non-portable "sed" options.
>
> * "git pack-objects" learned another algorithm to compute the set of
> objects to send, that trades the resulting packfile off to save
> traversal cost to favor small pushes.
>
> * The travis CI scripts have been corrected to build Git with the
> compiler(s) of our choice.
>
> * "git submodule update" learned to abort early when core.worktree
> for the submodule is not set correctly to prevent spreading damage.
>
> * Test suite has been adjusted to run on Azure Pipeline.
>
> * Running "Documentation/doc-diff x" from anywhere other than the
> top-level of the working tree did not show the usage string
> correctly, which has been fixed.
>
> * Use of the sparse tool got easier to customize from the command
> line to help developers.
>
> * A new target "coverage-prove" to run the coverage test under
> "prove" has been added.
>
> * A flakey "p4" test has been removed.
>
> * The code and tests assume that the system supplied iconv() would
> always use BOM in its output when asked to encode to UTF-16 (or
> UTF-32), but apparently some implementations output big-endian
> without BOM. A compile-time knob has been added to help such
> systems (e.g. NonStop) to add BOM to the output to increase
> portability.
>
>
> Fixes since v2.20
> -----------------
>
> * Updates for corner cases in merge-recursive.
> (merge cc4cb0902c en/merge-path-collision later to maint).
>
> * "git checkout frotz" (without any double-dash) avoids ambiguity by
> making sure 'frotz' cannot be interpreted as a revision and as a
> path at the same time. This safety has been updated to check also
> a unique remote-tracking branch 'frotz' in a remote, when dwimming
> to create a local branch 'frotz' out of a remote-tracking branch
> 'frotz' from a remote.
> (merge be4908f103 nd/checkout-dwim-fix later to maint).
>
> * Refspecs configured with "git -c var=val clone" did not propagate
> to the resulting repository, which has been corrected.
> (merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint).
>
> * A properly configured username/email is required under
> user.useConfigOnly in order to create commits; now "git stash"
> (even though it creates commit objects to represent stash entries)
> command is exempt from the requirement.
> (merge 3bc2111fc2 sd/stash-wo-user-name later to maint).
>
> * The http-backend CGI process did not correctly clean up the child
> processes it spawns to run upload-pack etc. when it dies itself,
> which has been corrected.
> (merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint).
>
> * "git rev-list --exclude-promisor-objects" had to take an object
> that does not exist locally (and is lazily available) from the
> command line without barfing, but the code dereferenced NULL.
> (merge 4cf67869b2 md/list-lazy-objects-fix later to maint).
>
> * The traversal over tree objects has learned to honor
> ":(attr:label)" pathspec match, which has been implemented only for
> enumerating paths on the filesystem.
> (merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint).
>
> * BSD port updates.
> (merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint).
> (merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint).
> (merge 82cbc8cde2 cb/test-lint-cp-a later to maint).
>
> * Lines that begin with a certain keyword that come over the wire, as
> well as lines that consist only of one of these keywords, ought to
> be painted in color for easier eyeballing, but the latter was
> broken ever since the feature was introduced in 2.19, which has
> been corrected.
> (merge 1f67290450 hn/highlight-sideband-keywords later to maint).
>
> * "git log -G<regex>" looked for a hunk in the "git log -p" patch
> output that contained a string that matches the given pattern.
> Optimize this code to ignore binary files, which by default will
> not show any hunk that would match any pattern (unless textconv or
> the --text option is in effect, that is).
> (merge e0e7cb8080 tb/log-G-binary later to maint).
>
> * "git submodule update" ought to use a single job unless asked, but
> by mistake used multiple jobs, which has been fixed.
> (merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint).
>
> * "git stripspace" should be usable outside a git repository, but
> under the "-s" or "-c" mode, it didn't.
> (merge 957da75802 jn/stripspace-wo-repository later to maint).
>
> * Some of the documentation pages formatted incorrectly with
> Asciidoctor, which have been fixed.
> (merge b62eb1d2f4 ma/asciidoctor later to maint).
>
> * The core.worktree setting in a submodule repository should not be
> pointing at a directory when the submodule loses its working tree
> (e.g. getting deinit'ed), but the code did not properly maintain
> this invariant.
>
> * With zsh, "git cmd path<TAB>" was completed to "git cmd path name"
> when the completed path has a special character like SP in it,
> without any attempt to keep "path name" a single filename. This
> has been fixed to complete it to "git cmd path\ name" just like
> Bash completion does.
>
> * The test suite tried to see if it is run under bash, but the check
> itself failed under some other implementations of shell (notably
> under NetBSD). This has been corrected.
> (merge 54ea72f09c sg/test-bash-version-fix later to maint).
>
> * "git gc" and "git repack" did not close the open packfiles that
> they found unneeded before removing them, which didn't work on a
> platform incapable of removing an open file. This has been
> corrected.
> (merge 5bdece0d70 js/gc-repack-close-before-remove later to maint).
>
> * The code to drive GIT_EXTERNAL_DIFF command relied on the string
> returned from getenv() to be non-volatile, which is not true, that
> has been corrected.
> (merge 6776a84dae kg/external-diff-save-env later to maint).
>
> * There were many places the code relied on the string returned from
> getenv() to be non-volatile, which is not true, that have been
> corrected.
> (merge 0da0e9268b jk/save-getenv-result later to maint).
>
> * The v2 upload-pack protocol implementation failed to honor
> hidden-ref configuration, which has been corrected.
> (merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint).
>
> * "git fetch --recurse-submodules" may not fetch the necessary commit
> that is bound to the superproject, which is getting corrected.
> (merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint).
>
> * "git rebase" internally runs "checkout" to switch between branches,
> and the command used to call the post-checkout hook, but the
> reimplementation stopped doing so, which is getting fixed.
>
> * "git add -e" got confused when the change it wants to let the user
> edit is smaller than the previous change that was left over in a
> temporary file.
> (merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint).
>
> * "git p4" failed to update a shelved change when there were moved
> files, which has been corrected.
> (merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint).
>
> * The codepath to read from the commit-graph file attempted to read
> past the end of it when the file's table-of-contents was corrupt.
>
> * The compat/obstack code had casts that -Wcast-function-type
> compilation option found questionable.
> (merge 764473d257 sg/obstack-cast-function-type-fix later to maint).
>
> * An obvious typo in an assertion error message has been fixed.
> (merge 3c27e2e059 cc/test-ref-store-typofix later to maint).
>
> * In Git for Windows, "git clone \\server\share\path" etc. that uses
> UNC paths from command line had bad interaction with its shell
> emulation.
>
> * "git add --ignore-errors" did not work as advertised and instead
> worked as an unintended synonym for "git add --renormalize", which
> has been fixed.
> (merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint).
>
> * On a case-insensitive filesystem, we failed to compare the part of
> the path that is above the worktree directory in an absolute
> pathname, which has been corrected.
>
> * Asking "git check-attr" about a macro (e.g. "binary") on a specific
> path did not work correctly, even though "git check-attr -a" listed
> such a macro correctly. This has been corrected.
> (merge 7b95849be4 jk/attr-macro-fix later to maint).
>
> * "git pack-objects" incorrectly used uninitialized mutex, which has
> been corrected.
> (merge edb673cf10 ph/pack-objects-mutex-fix later to maint).
>
> * "git checkout -b <new> [HEAD]" to create a new branch from the
> current commit and check it out ought to be a no-op in the index
> and the working tree in normal cases, but there are corner cases
> that do require updates to the index and the working tree. Running
> it immediately after "git clone --no-checkout" is one of these
> cases that an earlier optimization kicked in incorrectly, which has
> been fixed.
> (merge 8424bfd45b bp/checkout-new-branch-optim later to maint).
>
> * "git diff --color-moved --cc --stat -p" did not work well due to
> funny interaction between a bug in color-moved and the rest, which
> has been fixed.
> (merge dac03b5518 jk/diff-cc-stat-fixes later to maint).
>
> * When GIT_SEQUENCE_EDITOR is set, the command was incorrectly
> started when modes of "git rebase" that implicitly uses the
> machinery for the interactive rebase are run, which has been
> corrected.
> (merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint).
>
> * The commit-graph facility did not work when in-core objects that
> are promoted from unknown type to commit (e.g. a commit that is
> accessed via a tag that refers to it) were involved, which has been
> corrected.
> (merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint).
>
> * "git fetch" output cleanup.
> (merge dc40b24df4 nd/fetch-compact-update later to maint).
>
> * "git cat-file --batch" reported a dangling symbolic link by
> mistake, when it wanted to report that a given name is ambiguous.
>
> * Documentation around core.crlf has been updated.
> (merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint).
>
> * The documentation of "git commit-tree" said that the command
> understands "--gpg-sign" in addition to "-S", but the command line
> parser did not know about the longhand, which has been corrected.
>
> * "git rebase -x $cmd" did not reject multi-line command, even though
> the command is incapable of handling such a command. It now is
> rejected upfront.
> (merge c762aada1a pw/rebase-x-sanity-check later to maint).
>
> * Output from "git help" was not correctly aligned, which has been
> fixed.
> (merge 6195a76da4 nd/help-align-command-desc later to maint).
>
> * The "git submodule summary" subcommand showed shortened commit
> object names by mechanically truncating them at 7-hexdigit, which
> has been improved to let "rev-parse --short" scale the length of
> the abbreviation with the size of the repository.
> (merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint).
>
> * The way the OSX build jobs updates its build environment used the
> "--quiet" option to "brew update" command, but it wasn't all that
> quiet to be useful. The use of the option has been replaced with
> an explicit redirection to the /dev/null (which incidentally would
> have worked around a breakage by recent updates to homebrew, which
> has fixed itself already).
> (merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint).
>
> * "git --work-tree=$there --git-dir=$here describe --dirty" did not
> work correctly as it did not pay attention to the location of the
> worktree specified by the user by mistake, which has been
> corrected.
> (merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint).
>
> * "git fetch" over protocol v2 that needs to make a second connection
> to backfill tags did not clear a variable that holds shallow
> repository information correctly, leading to an access of freed
> piece of memory.
>
> * Some errors from the other side coming over smart HTTP transport
> were not noticed, which has been corrected.
>
> * Code cleanup, docfix, build fix, etc.
> (merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint).
> (merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint).
> (merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint).
> (merge ec36c42a63 nd/indentation-fix later to maint).
> (merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint).
> (merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint).
> (merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint).
> (merge 57e9dcaa65 km/rebase-doc-typofix later to maint).
> (merge b8b4cb27e6 ds/gc-doc-typofix later to maint).
> (merge 3b3357626e nd/style-opening-brace later to maint).
> (merge b4583d5595 es/doc-worktree-guessremote-config later to maint).
> (merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint).
> (merge 0650614982 cy/completion-typofix later to maint).
> (merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint).
> (merge bd8d6f0def en/show-ref-doc-fix later to maint).
> (merge 1747125e2c cc/partial-clone-doc-typofix later to maint).
> (merge e01378753d cc/fetch-error-message-fix later to maint).
> (merge 54e8c11215 jk/remote-insteadof-cleanup later to maint).
> (merge d609615f48 js/test-git-installed later to maint).
> (merge ba170517be ja/doc-style-fix later to maint).
> (merge 86fb1c4e77 km/init-doc-typofix later to maint).
> (merge 5cfd4a9d10 nd/commit-doc later to maint).
> (merge 9fce19a431 ab/diff-tree-doc-fix later to maint).
> (merge 2e285e7803 tz/gpg-test-fix later to maint).
> (merge 5427de960b kl/pretty-doc-markup-fix later to maint).
> (merge 3815f64b0d js/mingw-host-cpu later to maint).
> (merge 5fe81438b5 rj/sequencer-sign-off-header-static later to maint).
> (merge 18a4f6be6b nd/fileno-may-be-macro later to maint).
> (merge 99e9ab54ab kd/t0028-octal-del-is-377-not-777 later to maint).
>
> ----------------------------------------------------------------
>
> Changes since v2.20.0 are as follows:
>
> Arti Zirk (1):
> git-instaweb: add Python builtin http.server support
>
> Ben Peart (2):
> checkout: add test demonstrating regression with checkout -b on initial commit
> checkout: fix regression in checkout -b on intitial checkout
>
> Brandon Richardson (1):
> commit-tree: add missing --gpg-sign flag
>
> Brandon Williams (1):
> mailmap: update brandon williams's email address
>
> Carlo Marcelo Arenas Belón (4):
> t6036: avoid non-portable "cp -a"
> tests: add lint for non portable cp -a
> t5004: avoid using tar for empty packages
> config.mak.uname: OpenBSD uses BSD semantics with fread for directories
>
> Chayoung You (3):
> zsh: complete unquoted paths with spaces correctly
> completion: treat results of git ls-tree as file paths
> completion: fix typo in git-completion.bash
>
> Christian Couder (3):
> fetch: fix extensions.partialclone name in error message
> partial-clone: add missing 'is' in doc
> helper/test-ref-store: fix "new-sha1" vs "old-sha1" typo
>
> David Turner (1):
> Do not print 'dangling' for cat-file in case of ambiguity
>
> Denis Ovsienko (1):
> docs: fix $strict_export text in gitweb.conf.txt
>
> Derrick Stolee (10):
> merge-recursive: combine error handling
> .gitattributes: ensure t/oid-info/* has eol=lf
> commit-graph: writing missing parents is a BUG
> git-gc.txt: fix typo about gc.writeCommitGraph
> revision: add mark_tree_uninteresting_sparse
> list-objects: consume sparse tree walk
> revision: implement sparse algorithm
> pack-objects: create pack.useSparse setting
> pack-objects: create GIT_TEST_PACK_SPARSE
> Makefile: add coverage-prove target
>
> Elijah Newren (30):
> t6042: add tests for consistency in file collision conflict handling
> t6036, t6042: testcases for rename collision of already conflicting files
> merge-recursive: increase marker length with depth of recursion
> merge-recursive: new function for better colliding conflict resolutions
> merge-recursive: fix rename/add conflict handling
> merge-recursive: improve handling for rename/rename(2to1) conflicts
> merge-recursive: use handle_file_collision for add/add conflicts
> merge-recursive: improve rename/rename(1to2)/add[/add] handling
> t6036, t6043: increase code coverage for file collision handling
> fast-export: convert sha1 to oid
> git-fast-import.txt: fix documentation for --quiet option
> git-fast-export.txt: clarify misleading documentation about rev-list args
> fast-export: use value from correct enum
> fast-export: avoid dying when filtering by paths and old tags exist
> fast-export: move commit rewriting logic into a function for reuse
> fast-export: when using paths, avoid corrupt stream with non-existent mark
> fast-export: ensure we export requested refs
> fast-export: add --reference-excluded-parents option
> fast-import: remove unmaintained duplicate documentation
> fast-export: add a --show-original-ids option to show original names
> git-rebase.txt: update note about directory rename detection and am
> rebase: make builtin and legacy script error messages the same
> rebase: fix incompatible options error message
> t5407: add a test demonstrating how interactive handles --skip differently
> am, rebase--merge: do not overlook --skip'ed commits with post-rewrite
> git-rebase, sequencer: extend --quiet option for the interactive machinery
> git-legacy-rebase: simplify unnecessary triply-nested if
> rebase: define linearization ordering and enforce it
> rebase: implement --merge via the interactive machinery
> git-show-ref.txt: fix order of flags
>
> Eric Sunshine (1):
> doc/config: do a better job of introducing 'worktree.guessRemote'
>
> Eric Wong (2):
> banned.h: mark strncat() as banned
> t1512: test ambiguous cat-file --batch and --batch-output
>
> Erin Dahlgren (1):
> Simplify handling of setup_git_directory_gently() failure cases.
>
> Force Charlie (1):
> http: add support selecting http version
>
> Frank Dana (1):
> docs/gitweb.conf: config variable typo
>
> Issac Trotts (1):
> log: add %S option (like --source) to log --format
>
> Jean-Noël Avila (3):
> Documentation/Makefile add optional targets for l10n
> doc: tidy asciidoc style
> Fix typos in translatable strings for v2.21.0
>
> Jeff King (54):
> fsck: do not reuse child_process structs
> submodule--helper: prefer strip_suffix() to ends_with()
> rename "alternate_object_database" to "object_directory"
> sha1_file_name(): overwrite buffer instead of appending
> handle alternates paths the same as the main object dir
> sha1-file: use an object_directory for the main object dir
> object-store: provide helpers for loose_objects_cache
> sha1-file: use loose object cache for quick existence check
> fetch-pack: drop custom loose object cache
> odb_load_loose_cache: fix strbuf leak
> transport-helper: drop read/write errno checks
> sha1-file: fix outdated sha1 comment references
> update comment references to sha1_object_info()
> http: use struct object_id instead of bare sha1
> sha1-file: modernize loose object file functions
> sha1-file: modernize loose header/stream functions
> sha1-file: convert pass-through functions to object_id
> convert has_sha1_file() callers to has_object_file()
> sha1-file: drop has_sha1_file()
> sha1-file: prefer "loose object file" to "sha1 file" in messages
> sha1-file: avoid "sha1 file" for generic use in messages
> prefer "hash mismatch" to "sha1 mismatch"
> upload-pack: support hidden refs with protocol v2
> remote: check config validity before creating rewrite struct
> get_super_prefix(): copy getenv() result
> commit: copy saved getenv() result
> config: make a copy of $GIT_CONFIG string
> init: make a copy of $GIT_DIR string
> merge-recursive: copy $GITHEAD strings
> builtin_diff(): read $GIT_DIFF_OPTS closer to use
> add: use separate ADD_CACHE_RENORMALIZE flag
> attr: do not mark queried macros as unset
> t4006: resurrect commented-out tests
> diff: clear emitted_symbols flag after use
> combine-diff: factor out stat-format mask
> combine-diff: treat --shortstat like --stat
> combine-diff: treat --summary like --stat
> combine-diff: treat --dirstat like --stat
> match-trees: drop unused path parameter from score functions
> apply: drop unused "def" parameter from find_name_gnu()
> create_bundle(): drop unused "header" parameter
> column: drop unused "opts" parameter in item_length()
> show_date_relative(): drop unused "tz" parameter
> config: drop unused parameter from maybe_remove_section()
> convert: drop len parameter from conversion checks
> convert: drop path parameter from actual conversion functions
> doc/gitattributes: clarify "autocrlf overrides eol"
> docs/config: clarify "text property" in core.eol
> test-date: drop unused parameter to getnanos()
> remote-curl: refactor smart-http discovery
> remote-curl: tighten "version 2" check for smart-http
> add_to_index(): convert forgotten HASH_RENORMALIZE check
> RelNotes/2.21: tweak "--date=auto" mention
> RelNotes/2.21: misc typo/English fixups
>
> Johannes Schindelin (43):
> rebase: introduce --reschedule-failed-exec
> rebase: add a config option to default to --reschedule-failed-exec
> rebase: introduce a shortcut for --reschedule-failed-exec
> help.h: fix coding style
> help -a: handle aliases with long names gracefully
> t4256: mark support files as LF-only
> t9902: 'send-email' test case requires PERL
> gc/repack: release packs when needed
> add --edit: truncate the patch file
> t6042: work around speed optimization on Windows
> abspath_part_inside_repo: respect core.ignoreCase
> rebase: move `reset_head()` into a better spot
> rebase: avoid double reflog entry when switching branches
> rebase: teach `reset_head()` to optionally skip the worktree
> built-in rebase: call `git am` directly
> mingw (t5580): document bug when cloning from backslashed UNC paths
> mingw: special-case arguments to `sh`
> tests: explicitly use `test-tool.exe` on Windows
> travis: fix skipping tagged releases
> ci: rename the library of common functions
> ci/lib.sh: encapsulate Travis-specific things
> ci: inherit --jobs via MAKEFLAGS in run-build-and-tests
> ci: use a junction on Windows instead of a symlink
> test-date: add a subcommand to measure times in shell scripts
> tests: optionally write results as JUnit-style .xml
> ci/lib.sh: add support for Azure Pipelines
> Add a build definition for Azure DevOps
> ci: add a Windows job to the Azure Pipelines definition
> ci: use git-sdk-64-minimal build artifact
> mingw: be more generous when wrapping up the setitimer() emulation
> README: add a build badge (status of the Azure Pipelines build)
> tests: avoid calling Perl just to determine file sizes
> tests: include detailed trace logs with --write-junit-xml upon failure
> mingw: try to work around issues with the test cleanup
> tests: add t/helper/ to the PATH with --with-dashes
> t0061: workaround issues with --with-dashes and RUNTIME_PREFIX
> tests: optionally skip bin-wrappers/
> ci: speed up Windows phase
> ci: parallelize testing on Windows
> Revert "rebase: introduce a shortcut for --reschedule-failed-exec"
> mingw: fix CPU reporting in `git version --build-options`
> .mailmap: map Clemens Buchacher's mail addresses
> mingw: use a more canonical method to fix the CPU reporting
>
> Jonathan Nieder (1):
> stripspace: allow -s/-c outside git repository
>
> Jonathan Tan (9):
> revision: use commit graph in get_reference()
> fetch-pack: support protocol version 2
> fetch-pack: do not take shallow lock unnecessarily
> upload-pack: teach deepen-relative in protocol v2
> pkt-line: introduce struct packet_writer
> sideband: reverse its dependency on pkt-line
> {fetch,upload}-pack: sideband v2 fetch response
> tests: define GIT_TEST_SIDEBAND_ALL
> ls-refs: filter refs using namespace-stripped name
>
> Josh Steadmon (7):
> filter-options: expand scaled numbers
> commit-graph, fuzz: add fuzzer for commit-graph
> commit-graph: fix buffer read-overflow
> Makefile: correct example fuzz build
> t5551: test server-side ERR packet
> fuzz-commit-graph: initialize repo object
> object: fix leak of shallow_stat
>
> Junio C Hamano (16):
> t0027: squelch checkout path run outside test_expect_* block
> t0061: do not fail test if '.' is part of $PATH
> run-command: report exec failure
> submodule update: run at most one fetch job unless otherwise set
> Git 2.20.1
> Prepare for 2.21 cycle to start soonish
> First batch after 2.20.1
> ref-filter: give uintmax_t to format with %PRIuMAX
> Second batch after 2.20
> Third batch after 2.20
> Fourth batch after 2.20
> Fifth batch for 2.21
> Git 2.21-rc0
> ci: clear and mark MAKEFLAGS exported just once
> Seventh batch for 2.21
> Git 2.21-rc1
>
> Katrin Leinweber (1):
> doc: prevent overflowing <code> tag in rendered HTML
>
> Kevin Daudt (1):
> t0028: fix wrong octal values for BOM in setup
>
> Kim Gybels (1):
> diff: ensure correct lifetime of external_diff_cmd
>
> Kyle Meyer (2):
> rebase docs: drop stray word in merge command description
> init docs: correct a punctuation typo
>
> Laura Abbott (1):
> git-quiltimport: add --keep-non-patch option
>
> Linus Torvalds (1):
> Add 'human' date format
>
> Luke Diamand (3):
> git-p4: add failing test for shelved CL update involving move/copy
> git-p4: handle update of moved/copied files when updating a shelve
> git-p4: remove ticket expiry test
>
> Martin Ågren (5):
> git-column.txt: fix section header
> Documentation: do not nest open blocks
> git-status.txt: render tables correctly under Asciidoctor
> t7510: invoke git as part of &&-chain
> doc-diff: don't `cd_to_toplevel`
>
> Masaya Suzuki (7):
> Use packet_reader instead of packet_read_line
> pack-protocol.txt: accept error packets in any context
> http: support file handles for HTTP_KEEP_ERROR
> http: enable keep_error for HTTP requests
> remote-curl: define struct for CURLOPT_WRITEFUNCTION
> remote-curl: unset CURLOPT_FAILONERROR
> test: test GIT_CURL_VERBOSE=1 shows an error
>
> Matthew DeVore (4):
> list-objects.c: don't segfault for missing cmdline objects
> revision.c: put promisor option in specialized struct
> list-objects-filter: teach tree:# how to handle >0
> tree:<depth>: skip some trees even when collecting omits
>
> Matthieu Moy (1):
> git-multimail: update to release 1.5.0
>
> Max Kirillov (1):
> http-backend: enable cleaning up forked upload/receive-pack on exit
>
> Nguyễn Thái Ngọc Duy (68):
> git.c: mark more strings for translation
> alias.c: mark split_cmdline_strerror() strings for translation
> archive.c: mark more strings for translation
> attr.c: mark more string for translation
> read-cache.c: turn die("internal error") to BUG()
> read-cache.c: mark more strings for translation
> read-cache.c: add missing colon separators
> reflog: mark strings for translation
> remote.c: turn some error() or die() to BUG()
> remote.c: mark messages for translation
> repack: mark more strings for translation
> parse-options: replace opterror() with optname()
> parse-options.c: turn some die() to BUG()
> parse-options.c: mark more strings for translation
> fsck: reduce word legos to help i18n
> fsck: mark strings for translation
> wt-status.c: remove implicit dependency on the_index
> wt-status.c: remove implicit dependency the_repository
> list-objects-filter.c: remove implicit dependency on the_index
> list-objects.c: reduce the_repository references
> notes-merge.c: remove implicit dependency on the_index
> notes-merge.c: remove implicit dependency the_repository
> transport.c: remove implicit dependency on the_index
> sequencer.c: remove implicit dependency on the_index
> sequencer.c: remove implicit dependency on the_repository
> blame.c: remove implicit dependency the_repository
> bisect.c: remove the_repository reference
> branch.c: remove the_repository reference
> bundle.c: remove the_repository references
> cache-tree.c: remove the_repository references
> delta-islands.c: remove the_repository references
> diff-lib.c: remove the_repository references
> line-log.c: remove the_repository reference
> notes-cache.c: remove the_repository references
> pack-check.c: remove the_repository references
> pack-*.c: remove the_repository references
> rerere.c: remove the_repository references
> rebase-interactive.c: remove the_repository references
> checkout: disambiguate dwim tracking branches and local files
> checkout: print something when checking out paths
> tree.c: make read_tree*() take 'struct repository *'
> tree-walk.c: make tree_entry_interesting() take an index
> pathspec.h: clean up "extern" in function declarations
> dir.c: move, rename and export match_attrs()
> tree-walk: support :(attr) matching
> Indent code with TABs
> style: the opening '{' of a function is in a separate line
> parse-options: fix SunCC compiler warning
> worktree: allow to (re)move worktrees with uninitialized submodules
> grep: use grep_opt->repo instead of explict repo argument
> notes-utils.c: remove the_repository references
> repository.c: replace hold_locked_index() with repo_hold_locked_index()
> checkout: avoid the_index when possible
> read-cache.c: kill read_index()
> read-cache.c: replace update_index_if_able with repo_&
> sha1-name.c: remove implicit dependency on the_index
> merge-recursive.c: remove implicit dependency on the_index
> merge-recursive.c: remove implicit dependency on the_repository
> read-cache.c: remove the_* from index_has_changes()
> cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch
> fetch: prefer suffix substitution in compact fetch.output
> help: align the longest command in the command listing
> git-commit.txt: better description what it does
> checkout: update count-checkouts messages
> checkout: count and print -m paths separately
> imap-send.c: add a missing space in error message
> git-compat-util: work around fileno(fp) that is a macro
> get_oid_with_context(): match prototype and implementation
>
> Olga Telezhnaya (6):
> ref-filter: add objectsize:disk option
> ref-filter: add check for negative file size
> ref-filter: add tests for objectsize:disk
> ref-filter: add deltabase option
> ref-filter: add tests for deltabase
> ref-filter: add docs for new options
>
> Orgad Shaneh (2):
> t5403: simplify by using a single repository
> rebase: run post-checkout hook on checkout
>
> Patrick Hogg (2):
> pack-objects: move read mutex to packing_data struct
> pack-objects: merge read_lock and lock in packing_data struct
>
> Peter Osterlund (1):
> git-p4: fix problem when p4 login is not necessary
>
> Phillip Wood (11):
> diff: document --no-color-moved
> Use "whitespace" consistently
> diff: allow --no-color-moved-ws
> diff --color-moved-ws: demonstrate false positives
> diff --color-moved-ws: fix false positives
> diff --color-moved=zebra: be stricter with color alternation
> diff --color-moved-ws: optimize allow-indentation-change
> diff --color-moved-ws: modify allow-indentation-change
> diff --color-moved-ws: handle blank lines
> implicit interactive rebase: don't run sequence editor
> rebase -x: sanity check command
>
> Pranit Bauva (7):
> bisect--helper: `bisect_reset` shell function in C
> bisect--helper: `bisect_write` shell function in C
> wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
> bisect--helper: `check_and_set_terms` shell function in C
> bisect--helper: `bisect_next_check` shell function in C
> bisect--helper: `get_terms` & `bisect_terms` shell function in C
> bisect--helper: `bisect_start` shell function partially in C
>
> Ramsay Jones (3):
> config.mak.uname: remove obsolete SPARSE_FLAGS setting
> Makefile: improve SPARSE_FLAGS customisation
> sequencer: make sign_off_header a file local symbol
>
> Randall S. Becker (10):
> transport-helper: use xread instead of read
> config.mak.uname: support for modern HPE NonStop config.
> git-compat-util.h: add FLOSS headers for HPE NonStop
> compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
> t5403: correct bash ambiguous redirect error in subtest 8 by quoting $GIT_DIR
> config.mak.uname: add FREAD_READS_DIRECTORIES for NonStop platform
> test-lib-functions.sh: add generate_zero_bytes function
> t5318: replace use of /dev/zero with generate_zero_bytes
> t5562: replace /dev/zero with a pipe from generate_zero_bytes
> config.mak.uname: move location of bash on NonStop to CoreUtils
>
> René Scharfe (5):
> sha1-file: close fd of empty file in map_sha1_file_1()
> object-store: factor out odb_loose_cache()
> object-store: factor out odb_clear_loose_cache()
> object-store: use one oid_array per subdirectory for loose cache
> object-store: retire odb_load_loose_cache()
>
> SZEDER Gábor (25):
> clone: use a more appropriate variable name for the default refspec
> clone: respect additional configured fetch refspecs during initial fetch
> Documentation/clone: document ignored configuration variables
> test-lib: check Bash version for '-x' without using shell arrays
> test-lib: translate SIGTERM and SIGHUP to an exit
> test-lib: extract Bash version check for '-x' tracing
> test-lib: parse options in a for loop to keep $@ intact
> test-lib: parse command line options earlier
> test-lib: consolidate naming of test-results paths
> test-lib: set $TRASH_DIRECTORY earlier
> test-lib-functions: introduce the 'test_set_port' helper function
> test-lib: add the '--stress' option to run a test repeatedly under load
> compat/obstack: fix -Wcast-function-type warnings
> .gitignore: ignore external debug symbols from GCC on macOS
> travis-ci: don't be '--quiet' when running the tests
> travis-ci: switch to Xcode 10.1 macOS image
> travis-ci: build with the right compiler
> commit-graph: rename "large edges" to "extra edges"
> commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily
> strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
> object_as_type: initialize commit-graph-related fields of 'struct commit'
> travis-ci: make the OSX build jobs' 'brew update' more quiet
> ci: make sure we build Git parallel
> test-lib: make '--stress' more bisect-friendly
> test-lib: fix non-portable pattern bracket expressions
>
> Sebastian Staudt (2):
> describe: setup working tree for --dirty
> t6120: test for describe with a bare repository
>
> Sergey Organov (4):
> t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
> cherry-pick: do not error on non-merge commits when '-m 1' is specified
> t3502: validate '-m 1' argument is now accepted for non-merge commits
> t3506: validate '-m 1 -ff' is now accepted for non-merge commits
>
> Shahzad Lone (1):
> various: tighten constness of some local variables
>
> Slavica Djukic (1):
> stash: tolerate missing user identity
>
> Stefan Beller (39):
> sha1_file: allow read_object to read objects in arbitrary repositories
> packfile: allow has_packed_and_bad to handle arbitrary repositories
> diff: align move detection error handling with other options
> object-store: allow read_object_file_extended to read from any repo
> object-store: prepare read_object_file to deal with any repo
> object-store: prepare has_{sha1, object}_file to handle any repo
> object: parse_object to honor its repository argument
> commit: allow parse_commit* to handle any repo
> commit-reach.c: allow paint_down_to_common to handle any repo
> commit-reach.c: allow merge_bases_many to handle any repo
> commit-reach.c: allow remove_redundant to handle any repo
> commit-reach.c: allow get_merge_bases_many_0 to handle any repo
> commit-reach: prepare get_merge_bases to handle any repo
> commit-reach: prepare in_merge_bases[_many] to handle any repo
> commit: prepare get_commit_buffer to handle any repo
> commit: prepare repo_unuse_commit_buffer to handle any repo
> commit: prepare logmsg_reencode to handle arbitrary repositories
> pretty: prepare format_commit_message to handle arbitrary repositories
> sideband: color lines with keyword only
> sha1-array: provide oid_array_filter
> submodule.c: fix indentation
> submodule.c: sort changed_submodule_names before searching it
> submodule.c: tighten scope of changed_submodule_names struct
> submodule: store OIDs in changed_submodule_names
> repository: repo_submodule_init to take a submodule struct
> submodule: migrate get_next_submodule to use repository structs
> submodule.c: fetch in submodules git directory instead of in worktree
> fetch: ensure submodule objects fetched
> submodule update: add regression test with old style setups
> submodule: unset core.worktree if no working tree is present
> submodule--helper: fix BUG message in ensure_core_worktree
> submodule deinit: unset core.worktree
> submodule: use submodule repos for object lookup
> submodule: don't add submodule as odb for push
> commit-graph: convert remaining functions to handle any repo
> commit: prepare free_commit_buffer and release_commit_memory for any repo
> path.h: make REPO_GIT_PATH_FUNC repository agnostic
> t/helper/test-repository: celebrate independence from the_repository
> git-submodule: abort if core.worktree could not be set correctly
>
> Stephen P. Smith (4):
> Replace the proposed 'auto' mode with 'auto:'
> Add 'human' date format documentation
> Add `human` format to test-tool
> Add `human` date format tests.
>
> Sven van Haastregt (1):
> git-submodule.sh: shorten submodule SHA-1s using rev-parse
>
> Thomas Braun (1):
> log -G: ignore binary files
>
> Thomas Gummerer (3):
> t5570: drop racy test
> Revert "t/lib-git-daemon: record daemon log"
> config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf users
>
> Todd Zullinger (2):
> t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt
> t/lib-gpg: drop redundant killing of gpg-agent
>
> Torsten Bögershausen (3):
> git clone <url> C:\cygwin\home\USER\repo' is working (again)
> test-lint: only use only sed [-n] [-e command] [-f command_file]
> Support working-tree-encoding "UTF-16LE-BOM"
>
> brian m. carlson (20):
> sha1-file: rename algorithm to "sha1"
> sha1-file: provide functions to look up hash algorithms
> hex: introduce functions to print arbitrary hashes
> cache: make hashcmp and hasheq work with larger hashes
> t: add basic tests for our SHA-1 implementation
> t: make the sha1 test-tool helper generic
> sha1-file: add a constant for hash block size
> t/helper: add a test helper to compute hash speed
> commit-graph: convert to using the_hash_algo
> Add a base implementation of SHA-256 support
> sha256: add an SHA-256 implementation using libgcrypt
> hash: add an SHA-256 implementation using OpenSSL
> tree-walk: copy object ID before use
> match-trees: compute buffer offset correctly when splicing
> match-trees: use hashcpy to splice trees
> tree-walk: store object_id in a separate member
> cache: make oidcpy always copy GIT_MAX_RAWSZ bytes
> fetch-pack: clear alternate shallow when complete
> fetch-pack: clear alternate shallow in one more place
> utf8: handle systems that don't write BOM for UTF-16
>
> Ævar Arnfjörð Bjarmason (18):
> remote.c: add braces in anticipation of a follow-up change
> i18n: remote.c: mark error(...) messages for translation
> push: improve the error shown on unqualified <dst> push
> push: move unqualified refname error into a function
> push: add an advice on unqualified <dst> push
> push: test that <src> doesn't DWYM if <dst> is unqualified
> push doc: document the DWYM behavior pushing to unqualified <dst>
> commit-graph: split up close_reachable() progress output
> commit-graph write: use pack order when finding commits
> commit-graph write: add "Writing out" progress output
> commit-graph write: more descriptive "writing out" output
> commit-graph write: show progress for object search
> commit-graph write: add more descriptive progress output
> commit-graph write: remove empty line for readability
> commit-graph write: add itermediate progress
> commit-graph write: emit a percentage for all progress
> diff-tree doc: correct & remove wrong documentation
> rebase: fix regression in rebase.useBuiltin=false test mode
>
> --
> You received this message because you are subscribed to the Google Groups "git-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to git-packagers+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/git-packagers/xmqq8syj9h9b.fsf%40gitster-ct.c.googlers.com.
> For more options, visit https://groups.google.com/d/optout.
>
^ permalink raw reply [relevance 0%]
* [ANNOUNCE] Git v2.21.0-rc1
@ 2019-02-14 3:32 1% Junio C Hamano
2019-02-18 15:45 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Junio C Hamano @ 2019-02-14 3:32 UTC (permalink / raw)
To: git; +Cc: Linux Kernel, git-packagers
A release candidate Git v2.21.0-rc1 is now available for testing
at the usual places. It is comprised of 464 non-merge commits
since v2.20.0, contributed by 60 people, 14 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.21.0-rc1' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.20.0 are as follows.
Welcome to the Git development community!
Arti Zirk, Brandon Richardson, Chayoung You, Denis Ovsienko,
Erin Dahlgren, Force Charlie, Frank Dana, Issac Trotts, Katrin
Leinweber, Laura Abbott, Patrick Hogg, Peter Osterlund, Shahzad
Lone, and Slavica Djukic.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Ævar Arnfjörð Bjarmason, Ben Peart, Brandon Williams, brian
m. carlson, Carlo Marcelo Arenas Belón, Christian Couder,
David Turner, Derrick Stolee, Elijah Newren, Eric Sunshine,
Eric Wong, Jean-Noël Avila, Jeff King, Johannes Schindelin,
Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano,
Kevin Daudt, Kim Gybels, Kyle Meyer, Linus Torvalds, Luke
Diamand, Martin Ågren, Masaya Suzuki, Matthew DeVore, Matthieu
Moy, Max Kirillov, Nguyễn Thái Ngọc Duy, Olga Telezhnaya,
Orgad Shaneh, Phillip Wood, Pranit Bauva, Ramsay Jones,
Randall S. Becker, René Scharfe, Sebastian Staudt, Sergey
Organov, Stefan Beller, Stephen P. Smith, Sven van Haastregt,
SZEDER Gábor, Thomas Braun, Thomas Gummerer, Todd Zullinger,
and Torsten Bögershausen.
----------------------------------------------------------------
Git 2.21 Release Notes (draft)
==============================
Backward Compatibility Notes
----------------------------
* Historically, the "-m" (mainline) option can only be used for "git
cherry-pick" and "git revert" when working with a merge commit.
This version of Git no longer warns or errors out when working with
a single-parent commit, as long as the argument to the "-m" option
is 1 (i.e. it has only one parent, and the request is to pick or
revert relative to that first parent). Scripts that relied on the
behaviour may get broken with this change.
Updates since v2.20
-------------------
UI, Workflows & Features
* The "http.version" configuration variable can be used with recent
enough versions of cURL library to force the version of HTTP used
to talk when fetching and pushing.
* Small fixes and features for fast-export and fast-import, mostly on
the fast-export side has been made.
* "git push $there $src:$dst" rejects when $dst is not a fully
qualified refname and it is not clear what the end user meant. The
codepath has been taught to give a clearer error message, and also
guess where the push should go by taking the type of the pushed
object into account (e.g. a tag object would want to go under
refs/tags/).
* "git checkout [<tree-ish>] path..." learned to report the number of
paths that have been checked out of the index or the tree-ish,
which gives it the same degree of noisy-ness as the case in which
the command checks out a branch. "git checkout -m <pathspec>" to
undo conflict resolution gives a similar message.
* "git quiltimport" learned "--keep-non-patch" option.
* "git worktree remove" and "git worktree move" refused to work when
there is a submodule involved. This has been loosened to ignore
uninitialized submodules.
* "git cherry-pick -m1" was forbidden when picking a non-merge
commit, even though there _is_ parent number 1 for such a commit.
This was done to avoid mistakes back when "cherry-pick" was about
picking a single commit, but is no longer useful with "cherry-pick"
that can pick a range of commits. Now the "-m$num" option is
allowed when picking any commit, as long as $num names an existing
parent of the commit.
* Update "git multimail" from the upstream.
* "git p4" update.
* The "--format=<placeholder>" option of for-each-ref, branch and tag
learned to show a few more traits of objects that can be learned by
the object_info API.
* "git rebase -i" learned to re-execute a command given with 'exec'
to run after it failed the last time.
* "git diff --color-moved-ws" updates.
* Custom userformat "log --format" learned %S atom that stands for
the tip the traversal reached the commit from, i.e. --source.
* "git instaweb" learned to drive http.server that comes with
"batteries included" Python installation (both Python2 & 3).
* A new encoding UTF-16LE-BOM has been invented to force encoding to
UTF-16 with BOM in little endian byte order, which cannot be directly
generated by using iconv.
* A new date format "--date=human" that morphs its output depending
on how far the time is from the current time has been introduced.
"--date=auto:human" can be used to use this new format (or any
existing format) when the output is going to the pager or to the
terminal, and otherwise the default format.
Performance, Internal Implementation, Development Support etc.
* Code clean-up with optimization for the codepath that checks
(non-)existence of loose objects.
* More codepaths have become aware of working with in-core repository
instances other than the default "the_repository".
* The "strncat()" function is now among the banned functions.
* Portability updates for the HPE NonStop platform.
* Earlier we added "-Wformat-security" to developer builds, assuming
that "-Wall" (which includes "-Wformat" which in turn is required
to use "-Wformat-security") is always in effect. This is not true
when config.mak.autogen is in use, unfortunately. This has been
fixed by unconditionally adding "-Wall" to developer builds.
* The loose object cache used to optimize existence look-up has been
updated.
* Flaky tests can now be repeatedly run under load with the
"--stress" option.
* Documentation/Makefile is getting prepared for manpage
localization.
* "git fetch-pack" now can talk the version 2 protocol.
* sha-256 hash has been added and plumbed through the code to allow
building Git with the "NewHash".
* Debugging help for http transport.
* "git fetch --deepen=<more>" has been corrected to work over v2
protocol.
* The code to walk tree objects has been taught that we may be
working with object names that are not computed with SHA-1.
* The in-core repository instances are passed through more codepaths.
* Update the protocol message specification to allow only the limited
use of scaled quantities. This is to ensure potential compatibility
issues will not get out of hand.
* Micro-optimize the code that prepares commit objects to be walked
by "git rev-list" when the commit-graph is available.
* "git fetch" and "git upload-pack" learned to send all exchanges over
the sideband channel while talking the v2 protocol.
* The codepath to write out commit-graph has been optimized by
following the usual pattern of visiting objects in in-pack order.
* The codepath to show progress meter while writing out commit-graph
file has been improved.
* Cocci rules have been updated to encourage use of strbuf_addbuf().
* "git rebase --merge" has been reimplemented by reusing the internal
machinery used for "git rebase -i".
* More code in "git bisect" has been rewritten in C.
* Instead of going through "git-rebase--am" scriptlet to use the "am"
backend, the built-in version of "git rebase" learned to drive the
"am" backend directly.
* The assumption to work on the single "in-core index" instance has
been reduced from the library-ish part of the codebase.
* The test lint learned to catch non-portable "sed" options.
* "git pack-objects" learned another algorithm to compute the set of
objects to send, that trades the resulting packfile off to save
traversal cost to favor small pushes.
* The travis CI scripts have been corrected to build Git with the
compiler(s) of our choice.
* "git submodule update" learned to abort early when core.worktree
for the submodule is not set correctly to prevent spreading damage.
* Test suite has been adjusted to run on Azure Pipeline.
* Running "Documentation/doc-diff x" from anywhere other than the
top-level of the working tree did not show the usage string
correctly, which has been fixed.
* Use of the sparse tool got easier to customize from the command
line to help developers.
* A new target "coverage-prove" to run the coverage test under
"prove" has been added.
* A flakey "p4" test has been removed.
* The code and tests assume that the system supplied iconv() would
always use BOM in its output when asked to encode to UTF-16 (or
UTF-32), but apparently some implementations output big-endian
without BOM. A compile-time knob has been added to help such
systems (e.g. NonStop) to add BOM to the output to increase
portability.
Fixes since v2.20
-----------------
* Updates for corner cases in merge-recursive.
(merge cc4cb0902c en/merge-path-collision later to maint).
* "git checkout frotz" (without any double-dash) avoids ambiguity by
making sure 'frotz' cannot be interpreted as a revision and as a
path at the same time. This safety has been updated to check also
a unique remote-tracking branch 'frotz' in a remote, when dwimming
to create a local branch 'frotz' out of a remote-tracking branch
'frotz' from a remote.
(merge be4908f103 nd/checkout-dwim-fix later to maint).
* Refspecs configured with "git -c var=val clone" did not propagate
to the resulting repository, which has been corrected.
(merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint).
* A properly configured username/email is required under
user.useConfigOnly in order to create commits; now "git stash"
(even though it creates commit objects to represent stash entries)
command is exempt from the requirement.
(merge 3bc2111fc2 sd/stash-wo-user-name later to maint).
* The http-backend CGI process did not correctly clean up the child
processes it spawns to run upload-pack etc. when it dies itself,
which has been corrected.
(merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint).
* "git rev-list --exclude-promisor-objects" had to take an object
that does not exist locally (and is lazily available) from the
command line without barfing, but the code dereferenced NULL.
(merge 4cf67869b2 md/list-lazy-objects-fix later to maint).
* The traversal over tree objects has learned to honor
":(attr:label)" pathspec match, which has been implemented only for
enumerating paths on the filesystem.
(merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint).
* BSD port updates.
(merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint).
(merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint).
(merge 82cbc8cde2 cb/test-lint-cp-a later to maint).
* Lines that begin with a certain keyword that come over the wire, as
well as lines that consist only of one of these keywords, ought to
be painted in color for easier eyeballing, but the latter was
broken ever since the feature was introduced in 2.19, which has
been corrected.
(merge 1f67290450 hn/highlight-sideband-keywords later to maint).
* "git log -G<regex>" looked for a hunk in the "git log -p" patch
output that contained a string that matches the given pattern.
Optimize this code to ignore binary files, which by default will
not show any hunk that would match any pattern (unless textconv or
the --text option is in effect, that is).
(merge e0e7cb8080 tb/log-G-binary later to maint).
* "git submodule update" ought to use a single job unless asked, but
by mistake used multiple jobs, which has been fixed.
(merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint).
* "git stripspace" should be usable outside a git repository, but
under the "-s" or "-c" mode, it didn't.
(merge 957da75802 jn/stripspace-wo-repository later to maint).
* Some of the documentation pages formatted incorrectly with
Asciidoctor, which have been fixed.
(merge b62eb1d2f4 ma/asciidoctor later to maint).
* The core.worktree setting in a submodule repository should not be
pointing at a directory when the submodule loses its working tree
(e.g. getting deinit'ed), but the code did not properly maintain
this invariant.
* With zsh, "git cmd path<TAB>" was completed to "git cmd path name"
when the completed path has a special character like SP in it,
without any attempt to keep "path name" a single filename. This
has been fixed to complete it to "git cmd path\ name" just like
Bash completion does.
* The test suite tried to see if it is run under bash, but the check
itself failed under some other implementations of shell (notably
under NetBSD). This has been corrected.
(merge 54ea72f09c sg/test-bash-version-fix later to maint).
* "git gc" and "git repack" did not close the open packfiles that
they found unneeded before removing them, which didn't work on a
platform incapable of removing an open file. This has been
corrected.
(merge 5bdece0d70 js/gc-repack-close-before-remove later to maint).
* The code to drive GIT_EXTERNAL_DIFF command relied on the string
returned from getenv() to be non-volatile, which is not true, that
has been corrected.
(merge 6776a84dae kg/external-diff-save-env later to maint).
* There were many places the code relied on the string returned from
getenv() to be non-volatile, which is not true, that have been
corrected.
(merge 0da0e9268b jk/save-getenv-result later to maint).
* The v2 upload-pack protocol implementation failed to honor
hidden-ref configuration, which has been corrected.
(merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint).
* "git fetch --recurse-submodules" may not fetch the necessary commit
that is bound to the superproject, which is getting corrected.
(merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint).
* "git rebase" internally runs "checkout" to switch between branches,
and the command used to call the post-checkout hook, but the
reimplementation stopped doing so, which is getting fixed.
* "git add -e" got confused when the change it wants to let the user
edit is smaller than the previous change that was left over in a
temporary file.
(merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint).
* "git p4" failed to update a shelved change when there were moved
files, which has been corrected.
(merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint).
* The codepath to read from the commit-graph file attempted to read
past the end of it when the file's table-of-contents was corrupt.
* The compat/obstack code had casts that -Wcast-function-type
compilation option found questionable.
(merge 764473d257 sg/obstack-cast-function-type-fix later to maint).
* An obvious typo in an assertion error message has been fixed.
(merge 3c27e2e059 cc/test-ref-store-typofix later to maint).
* In Git for Windows, "git clone \\server\share\path" etc. that uses
UNC paths from command line had bad interaction with its shell
emulation.
* "git add --ignore-errors" did not work as advertised and instead
worked as an unintended synonym for "git add --renormalize", which
has been fixed.
(merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint).
* On a case-insensitive filesystem, we failed to compare the part of
the path that is above the worktree directory in an absolute
pathname, which has been corrected.
* Asking "git check-attr" about a macro (e.g. "binary") on a specific
path did not work correctly, even though "git check-attr -a" listed
such a macro correctly. This has been corrected.
(merge 7b95849be4 jk/attr-macro-fix later to maint).
* "git pack-objects" incorrectly used uninitialized mutex, which has
been corrected.
(merge edb673cf10 ph/pack-objects-mutex-fix later to maint).
* "git checkout -b <new> [HEAD]" to create a new branch from the
current commit and check it out ought to be a no-op in the index
and the working tree in normal cases, but there are corner cases
that do require updates to the index and the working tree. Running
it immediately after "git clone --no-checkout" is one of these
cases that an earlier optimization kicked in incorrectly, which has
been fixed.
(merge 8424bfd45b bp/checkout-new-branch-optim later to maint).
* "git diff --color-moved --cc --stat -p" did not work well due to
funny interaction between a bug in color-moved and the rest, which
has been fixed.
(merge dac03b5518 jk/diff-cc-stat-fixes later to maint).
* When GIT_SEQUENCE_EDITOR is set, the command was incorrectly
started when modes of "git rebase" that implicitly uses the
machinery for the interactive rebase are run, which has been
corrected.
(merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint).
* The commit-graph facility did not work when in-core objects that
are promoted from unknown type to commit (e.g. a commit that is
accessed via a tag that refers to it) were involved, which has been
corrected.
(merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint).
* "git fetch" output cleanup.
(merge dc40b24df4 nd/fetch-compact-update later to maint).
* "git cat-file --batch" reported a dangling symbolic link by
mistake, when it wanted to report that a given name is ambiguous.
* Documentation around core.crlf has been updated.
(merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint).
* The documentation of "git commit-tree" said that the command
understands "--gpg-sign" in addition to "-S", but the command line
parser did not know about the longhand, which has been corrected.
* "git rebase -x $cmd" did not reject multi-line command, even though
the command is incapable of handling such a command. It now is
rejected upfront.
(merge c762aada1a pw/rebase-x-sanity-check later to maint).
* Output from "git help" was not correctly aligned, which has been
fixed.
(merge 6195a76da4 nd/help-align-command-desc later to maint).
* The "git submodule summary" subcommand showed shortened commit
object names by mechanically truncating them at 7-hexdigit, which
has been improved to let "rev-parse --short" scale the length of
the abbreviation with the size of the repository.
(merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint).
* The way the OSX build jobs updates its build environment used the
"--quiet" option to "brew update" command, but it wasn't all that
quiet to be useful. The use of the option has been replaced with
an explicit redirection to the /dev/null (which incidentally would
have worked around a breakage by recent updates to homebrew, which
has fixed itself already).
(merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint).
* "git --work-tree=$there --git-dir=$here describe --dirty" did not
work correctly as it did not pay attention to the location of the
worktree specified by the user by mistake, which has been
corrected.
(merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint).
* "git fetch" over protocol v2 that needs to make a second connection
to backfill tags did not clear a variable that holds shallow
repository information correctly, leading to an access of freed
piece of memory.
* Some errors from the other side coming over smart HTTP transport
were not noticed, which has been corrected.
* Code cleanup, docfix, build fix, etc.
(merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint).
(merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint).
(merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint).
(merge ec36c42a63 nd/indentation-fix later to maint).
(merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint).
(merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint).
(merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint).
(merge 57e9dcaa65 km/rebase-doc-typofix later to maint).
(merge b8b4cb27e6 ds/gc-doc-typofix later to maint).
(merge 3b3357626e nd/style-opening-brace later to maint).
(merge b4583d5595 es/doc-worktree-guessremote-config later to maint).
(merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint).
(merge 0650614982 cy/completion-typofix later to maint).
(merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint).
(merge bd8d6f0def en/show-ref-doc-fix later to maint).
(merge 1747125e2c cc/partial-clone-doc-typofix later to maint).
(merge e01378753d cc/fetch-error-message-fix later to maint).
(merge 54e8c11215 jk/remote-insteadof-cleanup later to maint).
(merge d609615f48 js/test-git-installed later to maint).
(merge ba170517be ja/doc-style-fix later to maint).
(merge 86fb1c4e77 km/init-doc-typofix later to maint).
(merge 5cfd4a9d10 nd/commit-doc later to maint).
(merge 9fce19a431 ab/diff-tree-doc-fix later to maint).
(merge 2e285e7803 tz/gpg-test-fix later to maint).
(merge 5427de960b kl/pretty-doc-markup-fix later to maint).
(merge 3815f64b0d js/mingw-host-cpu later to maint).
(merge 5fe81438b5 rj/sequencer-sign-off-header-static later to maint).
(merge 18a4f6be6b nd/fileno-may-be-macro later to maint).
(merge 99e9ab54ab kd/t0028-octal-del-is-377-not-777 later to maint).
----------------------------------------------------------------
Changes since v2.20.0 are as follows:
Arti Zirk (1):
git-instaweb: add Python builtin http.server support
Ben Peart (2):
checkout: add test demonstrating regression with checkout -b on initial commit
checkout: fix regression in checkout -b on intitial checkout
Brandon Richardson (1):
commit-tree: add missing --gpg-sign flag
Brandon Williams (1):
mailmap: update brandon williams's email address
Carlo Marcelo Arenas Belón (4):
t6036: avoid non-portable "cp -a"
tests: add lint for non portable cp -a
t5004: avoid using tar for empty packages
config.mak.uname: OpenBSD uses BSD semantics with fread for directories
Chayoung You (3):
zsh: complete unquoted paths with spaces correctly
completion: treat results of git ls-tree as file paths
completion: fix typo in git-completion.bash
Christian Couder (3):
fetch: fix extensions.partialclone name in error message
partial-clone: add missing 'is' in doc
helper/test-ref-store: fix "new-sha1" vs "old-sha1" typo
David Turner (1):
Do not print 'dangling' for cat-file in case of ambiguity
Denis Ovsienko (1):
docs: fix $strict_export text in gitweb.conf.txt
Derrick Stolee (10):
merge-recursive: combine error handling
.gitattributes: ensure t/oid-info/* has eol=lf
commit-graph: writing missing parents is a BUG
git-gc.txt: fix typo about gc.writeCommitGraph
revision: add mark_tree_uninteresting_sparse
list-objects: consume sparse tree walk
revision: implement sparse algorithm
pack-objects: create pack.useSparse setting
pack-objects: create GIT_TEST_PACK_SPARSE
Makefile: add coverage-prove target
Elijah Newren (30):
t6042: add tests for consistency in file collision conflict handling
t6036, t6042: testcases for rename collision of already conflicting files
merge-recursive: increase marker length with depth of recursion
merge-recursive: new function for better colliding conflict resolutions
merge-recursive: fix rename/add conflict handling
merge-recursive: improve handling for rename/rename(2to1) conflicts
merge-recursive: use handle_file_collision for add/add conflicts
merge-recursive: improve rename/rename(1to2)/add[/add] handling
t6036, t6043: increase code coverage for file collision handling
fast-export: convert sha1 to oid
git-fast-import.txt: fix documentation for --quiet option
git-fast-export.txt: clarify misleading documentation about rev-list args
fast-export: use value from correct enum
fast-export: avoid dying when filtering by paths and old tags exist
fast-export: move commit rewriting logic into a function for reuse
fast-export: when using paths, avoid corrupt stream with non-existent mark
fast-export: ensure we export requested refs
fast-export: add --reference-excluded-parents option
fast-import: remove unmaintained duplicate documentation
fast-export: add a --show-original-ids option to show original names
git-rebase.txt: update note about directory rename detection and am
rebase: make builtin and legacy script error messages the same
rebase: fix incompatible options error message
t5407: add a test demonstrating how interactive handles --skip differently
am, rebase--merge: do not overlook --skip'ed commits with post-rewrite
git-rebase, sequencer: extend --quiet option for the interactive machinery
git-legacy-rebase: simplify unnecessary triply-nested if
rebase: define linearization ordering and enforce it
rebase: implement --merge via the interactive machinery
git-show-ref.txt: fix order of flags
Eric Sunshine (1):
doc/config: do a better job of introducing 'worktree.guessRemote'
Eric Wong (2):
banned.h: mark strncat() as banned
t1512: test ambiguous cat-file --batch and --batch-output
Erin Dahlgren (1):
Simplify handling of setup_git_directory_gently() failure cases.
Force Charlie (1):
http: add support selecting http version
Frank Dana (1):
docs/gitweb.conf: config variable typo
Issac Trotts (1):
log: add %S option (like --source) to log --format
Jean-Noël Avila (3):
Documentation/Makefile add optional targets for l10n
doc: tidy asciidoc style
Fix typos in translatable strings for v2.21.0
Jeff King (54):
fsck: do not reuse child_process structs
submodule--helper: prefer strip_suffix() to ends_with()
rename "alternate_object_database" to "object_directory"
sha1_file_name(): overwrite buffer instead of appending
handle alternates paths the same as the main object dir
sha1-file: use an object_directory for the main object dir
object-store: provide helpers for loose_objects_cache
sha1-file: use loose object cache for quick existence check
fetch-pack: drop custom loose object cache
odb_load_loose_cache: fix strbuf leak
transport-helper: drop read/write errno checks
sha1-file: fix outdated sha1 comment references
update comment references to sha1_object_info()
http: use struct object_id instead of bare sha1
sha1-file: modernize loose object file functions
sha1-file: modernize loose header/stream functions
sha1-file: convert pass-through functions to object_id
convert has_sha1_file() callers to has_object_file()
sha1-file: drop has_sha1_file()
sha1-file: prefer "loose object file" to "sha1 file" in messages
sha1-file: avoid "sha1 file" for generic use in messages
prefer "hash mismatch" to "sha1 mismatch"
upload-pack: support hidden refs with protocol v2
remote: check config validity before creating rewrite struct
get_super_prefix(): copy getenv() result
commit: copy saved getenv() result
config: make a copy of $GIT_CONFIG string
init: make a copy of $GIT_DIR string
merge-recursive: copy $GITHEAD strings
builtin_diff(): read $GIT_DIFF_OPTS closer to use
add: use separate ADD_CACHE_RENORMALIZE flag
attr: do not mark queried macros as unset
t4006: resurrect commented-out tests
diff: clear emitted_symbols flag after use
combine-diff: factor out stat-format mask
combine-diff: treat --shortstat like --stat
combine-diff: treat --summary like --stat
combine-diff: treat --dirstat like --stat
match-trees: drop unused path parameter from score functions
apply: drop unused "def" parameter from find_name_gnu()
create_bundle(): drop unused "header" parameter
column: drop unused "opts" parameter in item_length()
show_date_relative(): drop unused "tz" parameter
config: drop unused parameter from maybe_remove_section()
convert: drop len parameter from conversion checks
convert: drop path parameter from actual conversion functions
doc/gitattributes: clarify "autocrlf overrides eol"
docs/config: clarify "text property" in core.eol
test-date: drop unused parameter to getnanos()
remote-curl: refactor smart-http discovery
remote-curl: tighten "version 2" check for smart-http
add_to_index(): convert forgotten HASH_RENORMALIZE check
RelNotes/2.21: tweak "--date=auto" mention
RelNotes/2.21: misc typo/English fixups
Johannes Schindelin (43):
rebase: introduce --reschedule-failed-exec
rebase: add a config option to default to --reschedule-failed-exec
rebase: introduce a shortcut for --reschedule-failed-exec
help.h: fix coding style
help -a: handle aliases with long names gracefully
t4256: mark support files as LF-only
t9902: 'send-email' test case requires PERL
gc/repack: release packs when needed
add --edit: truncate the patch file
t6042: work around speed optimization on Windows
abspath_part_inside_repo: respect core.ignoreCase
rebase: move `reset_head()` into a better spot
rebase: avoid double reflog entry when switching branches
rebase: teach `reset_head()` to optionally skip the worktree
built-in rebase: call `git am` directly
mingw (t5580): document bug when cloning from backslashed UNC paths
mingw: special-case arguments to `sh`
tests: explicitly use `test-tool.exe` on Windows
travis: fix skipping tagged releases
ci: rename the library of common functions
ci/lib.sh: encapsulate Travis-specific things
ci: inherit --jobs via MAKEFLAGS in run-build-and-tests
ci: use a junction on Windows instead of a symlink
test-date: add a subcommand to measure times in shell scripts
tests: optionally write results as JUnit-style .xml
ci/lib.sh: add support for Azure Pipelines
Add a build definition for Azure DevOps
ci: add a Windows job to the Azure Pipelines definition
ci: use git-sdk-64-minimal build artifact
mingw: be more generous when wrapping up the setitimer() emulation
README: add a build badge (status of the Azure Pipelines build)
tests: avoid calling Perl just to determine file sizes
tests: include detailed trace logs with --write-junit-xml upon failure
mingw: try to work around issues with the test cleanup
tests: add t/helper/ to the PATH with --with-dashes
t0061: workaround issues with --with-dashes and RUNTIME_PREFIX
tests: optionally skip bin-wrappers/
ci: speed up Windows phase
ci: parallelize testing on Windows
Revert "rebase: introduce a shortcut for --reschedule-failed-exec"
mingw: fix CPU reporting in `git version --build-options`
.mailmap: map Clemens Buchacher's mail addresses
mingw: use a more canonical method to fix the CPU reporting
Jonathan Nieder (1):
stripspace: allow -s/-c outside git repository
Jonathan Tan (9):
revision: use commit graph in get_reference()
fetch-pack: support protocol version 2
fetch-pack: do not take shallow lock unnecessarily
upload-pack: teach deepen-relative in protocol v2
pkt-line: introduce struct packet_writer
sideband: reverse its dependency on pkt-line
{fetch,upload}-pack: sideband v2 fetch response
tests: define GIT_TEST_SIDEBAND_ALL
ls-refs: filter refs using namespace-stripped name
Josh Steadmon (7):
filter-options: expand scaled numbers
commit-graph, fuzz: add fuzzer for commit-graph
commit-graph: fix buffer read-overflow
Makefile: correct example fuzz build
t5551: test server-side ERR packet
fuzz-commit-graph: initialize repo object
object: fix leak of shallow_stat
Junio C Hamano (16):
t0027: squelch checkout path run outside test_expect_* block
t0061: do not fail test if '.' is part of $PATH
run-command: report exec failure
submodule update: run at most one fetch job unless otherwise set
Git 2.20.1
Prepare for 2.21 cycle to start soonish
First batch after 2.20.1
ref-filter: give uintmax_t to format with %PRIuMAX
Second batch after 2.20
Third batch after 2.20
Fourth batch after 2.20
Fifth batch for 2.21
Git 2.21-rc0
ci: clear and mark MAKEFLAGS exported just once
Seventh batch for 2.21
Git 2.21-rc1
Katrin Leinweber (1):
doc: prevent overflowing <code> tag in rendered HTML
Kevin Daudt (1):
t0028: fix wrong octal values for BOM in setup
Kim Gybels (1):
diff: ensure correct lifetime of external_diff_cmd
Kyle Meyer (2):
rebase docs: drop stray word in merge command description
init docs: correct a punctuation typo
Laura Abbott (1):
git-quiltimport: add --keep-non-patch option
Linus Torvalds (1):
Add 'human' date format
Luke Diamand (3):
git-p4: add failing test for shelved CL update involving move/copy
git-p4: handle update of moved/copied files when updating a shelve
git-p4: remove ticket expiry test
Martin Ågren (5):
git-column.txt: fix section header
Documentation: do not nest open blocks
git-status.txt: render tables correctly under Asciidoctor
t7510: invoke git as part of &&-chain
doc-diff: don't `cd_to_toplevel`
Masaya Suzuki (7):
Use packet_reader instead of packet_read_line
pack-protocol.txt: accept error packets in any context
http: support file handles for HTTP_KEEP_ERROR
http: enable keep_error for HTTP requests
remote-curl: define struct for CURLOPT_WRITEFUNCTION
remote-curl: unset CURLOPT_FAILONERROR
test: test GIT_CURL_VERBOSE=1 shows an error
Matthew DeVore (4):
list-objects.c: don't segfault for missing cmdline objects
revision.c: put promisor option in specialized struct
list-objects-filter: teach tree:# how to handle >0
tree:<depth>: skip some trees even when collecting omits
Matthieu Moy (1):
git-multimail: update to release 1.5.0
Max Kirillov (1):
http-backend: enable cleaning up forked upload/receive-pack on exit
Nguyễn Thái Ngọc Duy (68):
git.c: mark more strings for translation
alias.c: mark split_cmdline_strerror() strings for translation
archive.c: mark more strings for translation
attr.c: mark more string for translation
read-cache.c: turn die("internal error") to BUG()
read-cache.c: mark more strings for translation
read-cache.c: add missing colon separators
reflog: mark strings for translation
remote.c: turn some error() or die() to BUG()
remote.c: mark messages for translation
repack: mark more strings for translation
parse-options: replace opterror() with optname()
parse-options.c: turn some die() to BUG()
parse-options.c: mark more strings for translation
fsck: reduce word legos to help i18n
fsck: mark strings for translation
wt-status.c: remove implicit dependency on the_index
wt-status.c: remove implicit dependency the_repository
list-objects-filter.c: remove implicit dependency on the_index
list-objects.c: reduce the_repository references
notes-merge.c: remove implicit dependency on the_index
notes-merge.c: remove implicit dependency the_repository
transport.c: remove implicit dependency on the_index
sequencer.c: remove implicit dependency on the_index
sequencer.c: remove implicit dependency on the_repository
blame.c: remove implicit dependency the_repository
bisect.c: remove the_repository reference
branch.c: remove the_repository reference
bundle.c: remove the_repository references
cache-tree.c: remove the_repository references
delta-islands.c: remove the_repository references
diff-lib.c: remove the_repository references
line-log.c: remove the_repository reference
notes-cache.c: remove the_repository references
pack-check.c: remove the_repository references
pack-*.c: remove the_repository references
rerere.c: remove the_repository references
rebase-interactive.c: remove the_repository references
checkout: disambiguate dwim tracking branches and local files
checkout: print something when checking out paths
tree.c: make read_tree*() take 'struct repository *'
tree-walk.c: make tree_entry_interesting() take an index
pathspec.h: clean up "extern" in function declarations
dir.c: move, rename and export match_attrs()
tree-walk: support :(attr) matching
Indent code with TABs
style: the opening '{' of a function is in a separate line
parse-options: fix SunCC compiler warning
worktree: allow to (re)move worktrees with uninitialized submodules
grep: use grep_opt->repo instead of explict repo argument
notes-utils.c: remove the_repository references
repository.c: replace hold_locked_index() with repo_hold_locked_index()
checkout: avoid the_index when possible
read-cache.c: kill read_index()
read-cache.c: replace update_index_if_able with repo_&
sha1-name.c: remove implicit dependency on the_index
merge-recursive.c: remove implicit dependency on the_index
merge-recursive.c: remove implicit dependency on the_repository
read-cache.c: remove the_* from index_has_changes()
cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch
fetch: prefer suffix substitution in compact fetch.output
help: align the longest command in the command listing
git-commit.txt: better description what it does
checkout: update count-checkouts messages
checkout: count and print -m paths separately
imap-send.c: add a missing space in error message
git-compat-util: work around fileno(fp) that is a macro
get_oid_with_context(): match prototype and implementation
Olga Telezhnaya (6):
ref-filter: add objectsize:disk option
ref-filter: add check for negative file size
ref-filter: add tests for objectsize:disk
ref-filter: add deltabase option
ref-filter: add tests for deltabase
ref-filter: add docs for new options
Orgad Shaneh (2):
t5403: simplify by using a single repository
rebase: run post-checkout hook on checkout
Patrick Hogg (2):
pack-objects: move read mutex to packing_data struct
pack-objects: merge read_lock and lock in packing_data struct
Peter Osterlund (1):
git-p4: fix problem when p4 login is not necessary
Phillip Wood (11):
diff: document --no-color-moved
Use "whitespace" consistently
diff: allow --no-color-moved-ws
diff --color-moved-ws: demonstrate false positives
diff --color-moved-ws: fix false positives
diff --color-moved=zebra: be stricter with color alternation
diff --color-moved-ws: optimize allow-indentation-change
diff --color-moved-ws: modify allow-indentation-change
diff --color-moved-ws: handle blank lines
implicit interactive rebase: don't run sequence editor
rebase -x: sanity check command
Pranit Bauva (7):
bisect--helper: `bisect_reset` shell function in C
bisect--helper: `bisect_write` shell function in C
wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
bisect--helper: `check_and_set_terms` shell function in C
bisect--helper: `bisect_next_check` shell function in C
bisect--helper: `get_terms` & `bisect_terms` shell function in C
bisect--helper: `bisect_start` shell function partially in C
Ramsay Jones (3):
config.mak.uname: remove obsolete SPARSE_FLAGS setting
Makefile: improve SPARSE_FLAGS customisation
sequencer: make sign_off_header a file local symbol
Randall S. Becker (10):
transport-helper: use xread instead of read
config.mak.uname: support for modern HPE NonStop config.
git-compat-util.h: add FLOSS headers for HPE NonStop
compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
t5403: correct bash ambiguous redirect error in subtest 8 by quoting $GIT_DIR
config.mak.uname: add FREAD_READS_DIRECTORIES for NonStop platform
test-lib-functions.sh: add generate_zero_bytes function
t5318: replace use of /dev/zero with generate_zero_bytes
t5562: replace /dev/zero with a pipe from generate_zero_bytes
config.mak.uname: move location of bash on NonStop to CoreUtils
René Scharfe (5):
sha1-file: close fd of empty file in map_sha1_file_1()
object-store: factor out odb_loose_cache()
object-store: factor out odb_clear_loose_cache()
object-store: use one oid_array per subdirectory for loose cache
object-store: retire odb_load_loose_cache()
SZEDER Gábor (25):
clone: use a more appropriate variable name for the default refspec
clone: respect additional configured fetch refspecs during initial fetch
Documentation/clone: document ignored configuration variables
test-lib: check Bash version for '-x' without using shell arrays
test-lib: translate SIGTERM and SIGHUP to an exit
test-lib: extract Bash version check for '-x' tracing
test-lib: parse options in a for loop to keep $@ intact
test-lib: parse command line options earlier
test-lib: consolidate naming of test-results paths
test-lib: set $TRASH_DIRECTORY earlier
test-lib-functions: introduce the 'test_set_port' helper function
test-lib: add the '--stress' option to run a test repeatedly under load
compat/obstack: fix -Wcast-function-type warnings
.gitignore: ignore external debug symbols from GCC on macOS
travis-ci: don't be '--quiet' when running the tests
travis-ci: switch to Xcode 10.1 macOS image
travis-ci: build with the right compiler
commit-graph: rename "large edges" to "extra edges"
commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily
strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
object_as_type: initialize commit-graph-related fields of 'struct commit'
travis-ci: make the OSX build jobs' 'brew update' more quiet
ci: make sure we build Git parallel
test-lib: make '--stress' more bisect-friendly
test-lib: fix non-portable pattern bracket expressions
Sebastian Staudt (2):
describe: setup working tree for --dirty
t6120: test for describe with a bare repository
Sergey Organov (4):
t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
cherry-pick: do not error on non-merge commits when '-m 1' is specified
t3502: validate '-m 1' argument is now accepted for non-merge commits
t3506: validate '-m 1 -ff' is now accepted for non-merge commits
Shahzad Lone (1):
various: tighten constness of some local variables
Slavica Djukic (1):
stash: tolerate missing user identity
Stefan Beller (39):
sha1_file: allow read_object to read objects in arbitrary repositories
packfile: allow has_packed_and_bad to handle arbitrary repositories
diff: align move detection error handling with other options
object-store: allow read_object_file_extended to read from any repo
object-store: prepare read_object_file to deal with any repo
object-store: prepare has_{sha1, object}_file to handle any repo
object: parse_object to honor its repository argument
commit: allow parse_commit* to handle any repo
commit-reach.c: allow paint_down_to_common to handle any repo
commit-reach.c: allow merge_bases_many to handle any repo
commit-reach.c: allow remove_redundant to handle any repo
commit-reach.c: allow get_merge_bases_many_0 to handle any repo
commit-reach: prepare get_merge_bases to handle any repo
commit-reach: prepare in_merge_bases[_many] to handle any repo
commit: prepare get_commit_buffer to handle any repo
commit: prepare repo_unuse_commit_buffer to handle any repo
commit: prepare logmsg_reencode to handle arbitrary repositories
pretty: prepare format_commit_message to handle arbitrary repositories
sideband: color lines with keyword only
sha1-array: provide oid_array_filter
submodule.c: fix indentation
submodule.c: sort changed_submodule_names before searching it
submodule.c: tighten scope of changed_submodule_names struct
submodule: store OIDs in changed_submodule_names
repository: repo_submodule_init to take a submodule struct
submodule: migrate get_next_submodule to use repository structs
submodule.c: fetch in submodules git directory instead of in worktree
fetch: ensure submodule objects fetched
submodule update: add regression test with old style setups
submodule: unset core.worktree if no working tree is present
submodule--helper: fix BUG message in ensure_core_worktree
submodule deinit: unset core.worktree
submodule: use submodule repos for object lookup
submodule: don't add submodule as odb for push
commit-graph: convert remaining functions to handle any repo
commit: prepare free_commit_buffer and release_commit_memory for any repo
path.h: make REPO_GIT_PATH_FUNC repository agnostic
t/helper/test-repository: celebrate independence from the_repository
git-submodule: abort if core.worktree could not be set correctly
Stephen P. Smith (4):
Replace the proposed 'auto' mode with 'auto:'
Add 'human' date format documentation
Add `human` format to test-tool
Add `human` date format tests.
Sven van Haastregt (1):
git-submodule.sh: shorten submodule SHA-1s using rev-parse
Thomas Braun (1):
log -G: ignore binary files
Thomas Gummerer (3):
t5570: drop racy test
Revert "t/lib-git-daemon: record daemon log"
config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf users
Todd Zullinger (2):
t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt
t/lib-gpg: drop redundant killing of gpg-agent
Torsten Bögershausen (3):
git clone <url> C:\cygwin\home\USER\repo' is working (again)
test-lint: only use only sed [-n] [-e command] [-f command_file]
Support working-tree-encoding "UTF-16LE-BOM"
brian m. carlson (20):
sha1-file: rename algorithm to "sha1"
sha1-file: provide functions to look up hash algorithms
hex: introduce functions to print arbitrary hashes
cache: make hashcmp and hasheq work with larger hashes
t: add basic tests for our SHA-1 implementation
t: make the sha1 test-tool helper generic
sha1-file: add a constant for hash block size
t/helper: add a test helper to compute hash speed
commit-graph: convert to using the_hash_algo
Add a base implementation of SHA-256 support
sha256: add an SHA-256 implementation using libgcrypt
hash: add an SHA-256 implementation using OpenSSL
tree-walk: copy object ID before use
match-trees: compute buffer offset correctly when splicing
match-trees: use hashcpy to splice trees
tree-walk: store object_id in a separate member
cache: make oidcpy always copy GIT_MAX_RAWSZ bytes
fetch-pack: clear alternate shallow when complete
fetch-pack: clear alternate shallow in one more place
utf8: handle systems that don't write BOM for UTF-16
Ævar Arnfjörð Bjarmason (18):
remote.c: add braces in anticipation of a follow-up change
i18n: remote.c: mark error(...) messages for translation
push: improve the error shown on unqualified <dst> push
push: move unqualified refname error into a function
push: add an advice on unqualified <dst> push
push: test that <src> doesn't DWYM if <dst> is unqualified
push doc: document the DWYM behavior pushing to unqualified <dst>
commit-graph: split up close_reachable() progress output
commit-graph write: use pack order when finding commits
commit-graph write: add "Writing out" progress output
commit-graph write: more descriptive "writing out" output
commit-graph write: show progress for object search
commit-graph write: add more descriptive progress output
commit-graph write: remove empty line for readability
commit-graph write: add itermediate progress
commit-graph write: emit a percentage for all progress
diff-tree doc: correct & remove wrong documentation
rebase: fix regression in rebase.useBuiltin=false test mode
^ permalink raw reply [relevance 1%]
* Re: [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question
2019-02-08 3:17 3% [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question Todd Zullinger
2019-02-08 8:33 0% ` Henning Schild
@ 2019-02-09 14:06 0% ` SZEDER Gábor
1 sibling, 0 replies; 69+ results
From: SZEDER Gábor @ 2019-02-09 14:06 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git, Henning Schild
On Thu, Feb 07, 2019 at 10:17:44PM -0500, Todd Zullinger wrote:
> Looking through the build logs for the fedora git packages, I noticed it
> was missing the GPGSM prereq.
Just curious: how did you noticed the missing GPGSM prereq?
I'm asking because I use a patch for a good couple of months now that
collects the prereqs missed by test cases and prints them at the end
of 'make test'. Its output looks like this:
https://travis-ci.org/szeder/git/jobs/490944032#L2358
Since you seem to be interested in that sort of thing as well, perhaps
it would be worth to have something like this in git.git? It's just
that I have been too wary of potentially annoying other contributors
by adding (what might be perceived as) clutter to their 'make test'
output :)
> Lastly, the GPG test prereq was failing in two of the tests where it was
> used, t5573-pull-verify-signatures and t7612-merge-verify-signatures. I
> tracked this down to an annoying issue with gnugp-2¹, which recently
> became the default /bin/gpg in fedora².
>
> Using gnupg2 as /bin/gpg means using gpg-agent by default. When using a
> non-standard GNUPGHOME, gpg-agent defaults to putting its socket files
> in GNUPGHOME and fails if the path for any of them is longer than
> sun_path (108 chars on linux, 104 on OpenBSD and FreeBSD, and likely
> similar on other unices).
>
> When building in the typical fedora build tool (mock), the path to the
> git test dir is "/builddir/build/BUILD/git-2.20.1/t." That path then
> has "trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" appended and a
> "gpghome" directory within. For t5573 and t7612, the gpg-agent socket
> path for S.gpg-agent.browser exceeds the sun_path limit and gpg-agent
> fails to start. Sadly, this is handled poorly by gpg and makes the
> tests fail to set either the GPG or GPGSM prereqs.
>
> For the fedora packages, I decided to pass --root=/tmp/git-t.XXXX (via
> mktemp, of course) to the test suite which ensures a path short enough
> to keep gpg-agent happy.
>
> I don't know if there are other packagers or builders who run into this,
> so maybe it's not worth much effort to try and have the test suite cope
> better. It took me longer than I would have liked to track it down, so
> I thought I'd mention it in case anyone else has run into this or has
> thoughts on how to improve lib-gpg.sh while waiting for GnuPG to improve
> this area.
I stumbled upon this when Dscho inadvertently broke a test script on
setups without gpg last year; sorry for not speaking about it. I
noticed it in our Travis CI builds on macOS, because it (macOS itself
or Homebrew? I don't know) defaulted to gpg2 already back then, and to
make matters worse its sun_path is on the shorter end, and the path
to the build dir on Travis CI includes the GitHub user/repo as well.
> A GIT_TEST_GNUPGHOME_ROOT var to set the root path for the GNUPGHOME
> dirs in the tests is one thought I had, but didn't try to put it into
> patch form. Setting the --root test option is probably enough control
> for most cases.
A potential issue I see with GIT_TEST_GNUPGHOME_ROOT is that there are
several test scripts involving gpg, and if GIT_TEST_GNUPGHOME_ROOT is
set for the whole 'make test', then they might interfere with each
other when they happen to be run at the same time.
In the meantime I came up with a '--short-trash-dir' option to
test-lib, which turns 'trash directory.t7612-merge-verify-signatures'
into 'trash dir.t7612'. It works, but I don't really like it, and it
required various adjustments to the CI build scripts, notably to the
part in 'ci/print-test-failures.sh' that includes the trash dir of
failed test scripts in the build log.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question
2019-02-08 3:17 3% [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question Todd Zullinger
@ 2019-02-08 8:33 0% ` Henning Schild
2019-02-09 14:06 0% ` SZEDER Gábor
1 sibling, 0 replies; 69+ results
From: Henning Schild @ 2019-02-08 8:33 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git
Hi,
both patches look good to me. Killing the agent once should be enough,
i remember manually killing it many times as i was looking for a way to
generate certs and trust (configure gpgsm for the test). That is
probably why i copied it over in the first place.
Henning
Am Thu, 7 Feb 2019 22:17:44 -0500
schrieb Todd Zullinger <tmz@pobox.com>:
> Hi,
>
> Looking through the build logs for the fedora git packages, I noticed
> it was missing the GPGSM prereq. I added the necessary package to the
> build requirements but GPGSM was still failing to be set. This turned
> out to be due to a use of ${GNUPGHOME} without quoting, which leads
> to a non-zero exit from echo and the end of the happy && chain when
> using bash as the test shell. Fixing this allows the GPGSM test
> prereq to be set.
>
> While I was poking around I also saw an extra gpgconf call to kill
> gpg-agent. This was copied from the GPG block earlier in lib-gpg.sh,
> but should not be needed (as far as I can tell). I don't think it can
> cause any real harm apart from causing gpg and gpgsm to start the
> agent more often than necessary. But I didn't run the tests with the
> --stress option to look for potential issues that could be more
> serious.
>
> Lastly, the GPG test prereq was failing in two of the tests where it
> was used, t5573-pull-verify-signatures and
> t7612-merge-verify-signatures. I tracked this down to an annoying
> issue with gnugp-2¹, which recently became the default /bin/gpg in
> fedora².
>
> Using gnupg2 as /bin/gpg means using gpg-agent by default. When
> using a non-standard GNUPGHOME, gpg-agent defaults to putting its
> socket files in GNUPGHOME and fails if the path for any of them is
> longer than sun_path (108 chars on linux, 104 on OpenBSD and FreeBSD,
> and likely similar on other unices).
>
> When building in the typical fedora build tool (mock), the path to the
> git test dir is "/builddir/build/BUILD/git-2.20.1/t." That path then
> has "trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" appended and a
> "gpghome" directory within. For t5573 and t7612, the gpg-agent socket
> path for S.gpg-agent.browser exceeds the sun_path limit and gpg-agent
> fails to start. Sadly, this is handled poorly by gpg and makes the
> tests fail to set either the GPG or GPGSM prereqs.
>
> For the fedora packages, I decided to pass --root=/tmp/git-t.XXXX (via
> mktemp, of course) to the test suite which ensures a path short enough
> to keep gpg-agent happy.
>
> I don't know if there are other packagers or builders who run into
> this, so maybe it's not worth much effort to try and have the test
> suite cope better. It took me longer than I would have liked to
> track it down, so I thought I'd mention it in case anyone else has
> run into this or has thoughts on how to improve lib-gpg.sh while
> waiting for GnuPG to improve this area.
>
> A GIT_TEST_GNUPGHOME_ROOT var to set the root path for the GNUPGHOME
> dirs in the tests is one thought I had, but didn't try to put it into
> patch form. Setting the --root test option is probably enough control
> for most cases.
>
> ¹ https://dev.gnupg.org/T2964
> ²
> https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
>
> Todd Zullinger (2):
> t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt
> t/lib-gpg: drop redundant killing of gpg-agent
>
> t/lib-gpg.sh | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
^ permalink raw reply [relevance 0%]
* [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question
@ 2019-02-08 3:17 3% Todd Zullinger
2019-02-08 8:33 0% ` Henning Schild
2019-02-09 14:06 0% ` SZEDER Gábor
0 siblings, 2 replies; 69+ results
From: Todd Zullinger @ 2019-02-08 3:17 UTC (permalink / raw)
To: git; +Cc: Henning Schild
Hi,
Looking through the build logs for the fedora git packages, I noticed it
was missing the GPGSM prereq. I added the necessary package to the
build requirements but GPGSM was still failing to be set. This turned
out to be due to a use of ${GNUPGHOME} without quoting, which leads to a
non-zero exit from echo and the end of the happy && chain when using
bash as the test shell. Fixing this allows the GPGSM test prereq to be
set.
While I was poking around I also saw an extra gpgconf call to kill
gpg-agent. This was copied from the GPG block earlier in lib-gpg.sh,
but should not be needed (as far as I can tell). I don't think it can
cause any real harm apart from causing gpg and gpgsm to start the agent
more often than necessary. But I didn't run the tests with the --stress
option to look for potential issues that could be more serious.
Lastly, the GPG test prereq was failing in two of the tests where it was
used, t5573-pull-verify-signatures and t7612-merge-verify-signatures. I
tracked this down to an annoying issue with gnugp-2¹, which recently
became the default /bin/gpg in fedora².
Using gnupg2 as /bin/gpg means using gpg-agent by default. When using a
non-standard GNUPGHOME, gpg-agent defaults to putting its socket files
in GNUPGHOME and fails if the path for any of them is longer than
sun_path (108 chars on linux, 104 on OpenBSD and FreeBSD, and likely
similar on other unices).
When building in the typical fedora build tool (mock), the path to the
git test dir is "/builddir/build/BUILD/git-2.20.1/t." That path then
has "trash directory.$TEST_NAME$TEST_STRESS_JOB_SFX" appended and a
"gpghome" directory within. For t5573 and t7612, the gpg-agent socket
path for S.gpg-agent.browser exceeds the sun_path limit and gpg-agent
fails to start. Sadly, this is handled poorly by gpg and makes the
tests fail to set either the GPG or GPGSM prereqs.
For the fedora packages, I decided to pass --root=/tmp/git-t.XXXX (via
mktemp, of course) to the test suite which ensures a path short enough
to keep gpg-agent happy.
I don't know if there are other packagers or builders who run into this,
so maybe it's not worth much effort to try and have the test suite cope
better. It took me longer than I would have liked to track it down, so
I thought I'd mention it in case anyone else has run into this or has
thoughts on how to improve lib-gpg.sh while waiting for GnuPG to improve
this area.
A GIT_TEST_GNUPGHOME_ROOT var to set the root path for the GNUPGHOME
dirs in the tests is one thought I had, but didn't try to put it into
patch form. Setting the --root test option is probably enough control
for most cases.
¹ https://dev.gnupg.org/T2964
² https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
Todd Zullinger (2):
t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt
t/lib-gpg: drop redundant killing of gpg-agent
t/lib-gpg.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--
Todd
^ permalink raw reply [relevance 3%]
* Re: [ANNOUNCE] Git v2.21.0-rc0
2019-02-07 7:28 1% [ANNOUNCE] Git v2.21.0-rc0 Junio C Hamano
@ 2019-02-07 19:47 0% ` Johannes Schindelin
0 siblings, 0 replies; 69+ results
From: Johannes Schindelin @ 2019-02-07 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-packagers, git-for-windows
[-- Attachment #1: Type: text/plain, Size: 48551 bytes --]
Team,
the Windows version of v2.21.0-rc0 can be found here:
https://github.com/git-for-windows/git/releases/tag/v2.21.0-rc0.windows.1
Thanks for testing!
Johannes
On Wed, 6 Feb 2019, Junio C Hamano wrote:
> An early preview release Git v2.21.0-rc0 is now available for
> testing at the usual places. It is comprised of 426 non-merge
> commits since v2.20.0, contributed by 57 people, 13 of which are
> new faces.
>
> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/testing/
>
> The following public repositories all have a copy of the
> 'v2.21.0-rc0' tag and the 'master' branch that the tag points at:
>
> url = https://kernel.googlesource.com/pub/scm/git/git
> url = git://repo.or.cz/alt-git.git
> url = https://github.com/gitster/git
>
> New contributors whose contributions weren't in v2.20.0 are as follows.
> Welcome to the Git development community!
>
> Arti Zirk, Brandon Richardson, Chayoung You, Denis Ovsienko, Erin
> Dahlgren, Force Charlie, Frank Dana, Issac Trotts, Laura Abbott,
> Patrick Hogg, Peter Osterlund, Shahzad Lone, and Slavica Djukic.
>
> Returning contributors who helped this release are as follows.
> Thanks for your continued support.
>
> Ævar Arnfjörð Bjarmason, Ben Peart, Brandon Williams, brian
> m. carlson, Carlo Marcelo Arenas Belón, Christian Couder,
> David Turner, Derrick Stolee, Elijah Newren, Eric Sunshine,
> Eric Wong, Jean-Noël Avila, Jeff King, Johannes Schindelin,
> Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Kim
> Gybels, Kyle Meyer, Linus Torvalds, Luke Diamand, Martin Ågren,
> Masaya Suzuki, Matthew DeVore, Matthieu Moy, Max Kirillov,
> Nguyễn Thái Ngọc Duy, Olga Telezhnaya, Orgad Shaneh,
> Phillip Wood, Pranit Bauva, Ramsay Jones, Randall S. Becker,
> René Scharfe, Sebastian Staudt, Sergey Organov, Stefan Beller,
> Stephen P. Smith, Sven van Haastregt, SZEDER Gábor, Thomas
> Braun, Thomas Gummerer, and Torsten Bögershausen.
>
> ----------------------------------------------------------------
>
> Git 2.21 Release Notes (draft)
> ==============================
>
> Backward Compatibility Notes
> ----------------------------
>
> * Historically, the "-m" (mainline) option can only be used for "git
> cherry-pick" and "git revert" when working with a merge commit.
> This version of Git no longer warns or errors out when working with
> a single-parent commit, as long as the argument to the "-m" option
> is 1 (i.e. it has only one parent, and the request is to pick or
> revert relative to that first parent). Scripts that relied on the
> behaviour may get broken with this change.
>
>
> Updates since v2.20
> -------------------
>
> UI, Workflows & Features
>
> * The "http.version" configuration variable can be used with recent
> enough versions of cURL library to force the version of HTTP used
> to talk when fetching and pushing.
>
> * Small fixes and features for fast-export and fast-import, mostly on
> the fast-export side has been made.
>
> * "git push $there $src:$dst" rejects when $dst is not a fully
> qualified refname and not clear what the end user meant. The
> codepath has been taught to give a clearer error message, and also
> guess where the push should go by taking the type of the pushed
> object into account (e.g. a tag object would want to go under
> refs/tags/).
>
> * "git checkout [<tree-ish>] path..." learned to report the number of
> paths that have been checked out of the index or the tree-ish,
> which gives it the same degree of noisy-ness as the case in which
> the command checks out a branch.
>
> * "git quiltimport" learned "--keep-non-patch" option.
>
> * "git worktree remove" and "git worktree move" refused to work when
> there is a submodule involved. This has been loosened to ignore
> uninitialized submodules.
>
> * "git cherry-pick -m1" was forbidden when picking a non-merge
> commit, even though there _is_ parent number 1 for such a commit.
> This was done to avoid mistakes back when "cherry-pick" was about
> picking a single commit, but is no longer useful with "cherry-pick"
> that can pick a range of commits. Now the "-m$num" option is
> allowed when picking any commit, as long as $num names an existing
> parent of the commit.
>
> * Update "git multimail" from the upstream.
>
> * "git p4" update.
>
> * The "--format=<placeholder>" option of for-each-ref, branch and tag
> learned to show a few more traits of objects that can be learned by
> the object_info API.
>
> * "git rebase -i" learned to re-execute a command given with 'exec'
> to run after it failed the last time.
>
> * "git diff --color-moved-ws" updates.
>
> * Custom userformat "log --format" learned %S atom that stands for
> the tip the traversal reached the commit from, i.e. --source.
>
> * "git instaweb" learned to drive http.server that comes with
> "batteries included" Python installation (both Python2 & 3).
>
> * A new encoding UTF-16LE-BOM has been invented to force encoding to
> UTF-16 with BOM in little endian byte order, which cannot be directly
> generated by using iconv.
>
> * A new date format "--date=human" that morphs its output depending
> on how far the time is from the current time has been introduced.
> "--date=auto" can be used to use this new format when the output is
> going to the pager or to the terminal and otherwise the default
> format.
>
>
> Performance, Internal Implementation, Development Support etc.
>
> * Code clean-up with optimization for the codepath that checks
> (non-)existence of loose objects.
>
> * More codepaths have become aware of working with in-core repository
> instance other than the default "the_repository".
>
> * The "strncat()" function is now among the banned functions.
>
> * Portability updates for the HPE NonStop platform.
>
> * Earlier we added "-Wformat-security" to developer builds, assuming
> that "-Wall" (which includes "-Wformat" which in turn is required
> to use "-Wformat-security") is always in effect. This is not true
> when config.mak.autogen is in use, unfortunately. This has been
> fixed by unconditionally adding "-Wall" to developer builds.
>
> * The loose object cache used to optimize existence look-up has been
> updated.
>
> * Flaky tests can now be repeatedly run under load with the
> "--stress" option.
>
> * Documentation/Makefile is getting prepared for manpage
> localization.
>
> * "git fetch-pack" now can talk the version 2 protocol.
>
> * sha-256 hash has been added and plumbed through the code to allow
> building Git with the "NewHash".
>
> * Debugging help for http transport.
>
> * "git fetch --deepen=<more>" has been corrected to work over v2
> protocol.
>
> * The code to walk tree objects has been taught that we may be
> working with object names that are not computed with SHA-1.
>
> * The in-core repository instances are passed through more codepaths.
>
> * Update the protocol message specification to allow only the limited
> use of scaled quantities. This is ensure potential compatibility
> issues will not go out of hand.
>
> * Micro-optimize the code that prepares commit objects to be walked
> by "git rev-list" when the commit-graph is available.
>
> * "git fetch" and "git upload-pack" learned to send all exchange over
> the sideband channel while talking the v2 protocol.
>
> * The codepath to write out commit-graph has been optimized by
> following the usual pattern of visiting objects in in-pack order.
>
> * The codepath to show progress meter while writing out commit-graph
> file has been improved.
>
> * Cocci rules have been updated to encourage use of strbuf_addbuf().
>
> * "git rebase --merge" has been reimplemented by reusing the internal
> machinery used for "git rebase -i".
>
> * More code in "git bisect" has been rewritten in C.
>
> * Instead of going through "git-rebase--am" scriptlet to use the "am"
> backend, the built-in version of "git rebase" learned to drive the
> "am" backend directly.
>
> * The assumption to work on the single "in-core index" instance has
> been reduced from the library-ish part of the codebase.
>
> * The test lint learned to catch non-portable "sed" options.
>
> * "git pack-objects" learned another algorithm to compute the set of
> objects to send, that trades the resulting packfile off to save
> traversal cost to favor small pushes.
>
> * The travis CI scripts have been corrected to build Git with the
> compiler(s) of our choice.
>
> * "git submodule update" learned to abort early when core.worktree
> for the submodule is not set correctly to prevent spreading damage.
>
> * Test suite has been adjusted to run on Azure Pipeline.
>
> * Running "Documentation/doc-diff x" from anywhere other than the
> top-level of the working tree did not show the usage string
> correctly, which has been fixed.
>
> * Use of the sparse tool got easier to customize from the command
> line to help developers.
>
>
> Fixes since v2.20
> -----------------
>
> * Updates for corner cases in merge-recursive.
> (merge cc4cb0902c en/merge-path-collision later to maint).
>
> * "git checkout frotz" (without any double-dash) avoids ambiguity by
> making sure 'frotz' cannot be interpreted as a revision and as a
> path at the same time. This safety has been updated to check also
> a unique remote-tracking branch 'frotz' in a remote, when dwimming
> to create a local branch 'frotz' out of a remote-tracking branch
> 'frotz' from a remote.
> (merge be4908f103 nd/checkout-dwim-fix later to maint).
>
> * Refspecs configured with "git -c var=val clone" did not propagate
> to the resulting repository, which has been corrected.
> (merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint).
>
> * A properly configured username/email is required under
> user.useConfigOnly in order to create commits; now "git stash"
> (even though it creates commit objects to represent stash entries)
> command is exempt from the requirement.
> (merge 3bc2111fc2 sd/stash-wo-user-name later to maint).
>
> * The http-backend CGI process did not correctly clean up the child
> processes it spawns to run upload-pack etc. when it dies itself,
> which has been corrected.
> (merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint).
>
> * "git rev-list --exclude-promisor-objects" had to take an object
> that does not exist locally (and is lazily available) from the
> command line without barfing, but the code dereferenced NULL.
> (merge 4cf67869b2 md/list-lazy-objects-fix later to maint).
>
> * The traversal over tree objects has learned to honor
> ":(attr:label)" pathspec match, which has been implemented only for
> enumerating paths on the filesystem.
> (merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint).
>
> * BSD port updates.
> (merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint).
> (merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint).
> (merge 82cbc8cde2 cb/test-lint-cp-a later to maint).
>
> * Lines that begin with a certain keyword that come over the wire, as
> well as lines that consist only of one of these keywords, ought to
> be painted in color for easier eyeballing, but the latter was
> broken ever since the feature was introduced in 2.19, which has
> been corrected.
> (merge 1f67290450 hn/highlight-sideband-keywords later to maint).
>
> * "git log -G<regex>" looked for a hunk in the "git log -p" patch
> output that contained a string that matches the given pattern.
> Optimize this code to ignore binary files, which by default will
> not show any hunk that would match any pattern (unless textconv or
> the --text option is in effect, that is).
> (merge e0e7cb8080 tb/log-G-binary later to maint).
>
> * "git submodule update" ought to use a single job unless asked, but
> by mistake used multiple jobs, which has been fixed.
> (merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint).
>
> * "git stripspace" should be usable outside a git repository, but
> under the "-s" or "-c" mode, it didn't.
> (merge 957da75802 jn/stripspace-wo-repository later to maint).
>
> * Some of the documentation pages formatted incorrectly with
> Asciidoctor, which have been fixed.
> (merge b62eb1d2f4 ma/asciidoctor later to maint).
>
> * The core.worktree setting in a submodule repository should not be
> pointing at a directory when the submodule loses its working tree
> (e.g. getting deinit'ed), but the code did not properly maintain
> this invariant.
>
> * With zsh, "git cmd path<TAB>" was completed to "git cmd path name"
> when the completed path has a special character like SP in it,
> without any attempt to keep "path name" a single filename. This
> has been fixed to complete it to "git cmd path\ name" just like
> Bash completion does.
>
> * The test suite tried to see if it is run under bash, but the check
> itself failed under some other implementations of shell (notably
> under NetBSD). This has been corrected.
> (merge 54ea72f09c sg/test-bash-version-fix later to maint).
>
> * "git gc" and "git repack" did not close the open packfiles that
> they found unneeded before removing them, which didn't work on a
> platform incapable of removing an open file. This has been
> corrected.
> (merge 5bdece0d70 js/gc-repack-close-before-remove later to maint).
>
> * The code to drive GIT_EXTERNAL_DIFF command relied on the string
> returned from getenv() to be non-volatile, which is not true, that
> has been corrected.
> (merge 6776a84dae kg/external-diff-save-env later to maint).
>
> * There were many places the code relied on the string returned from
> getenv() to be non-volatile, which is not true, that have been
> corrected.
> (merge 0da0e9268b jk/save-getenv-result later to maint).
>
> * The v2 upload-pack protocol implementation failed to honor
> hidden-ref configuration, which has been corrected.
> (merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint).
>
> * "git fetch --recurse-submodules" may not fetch the necessary commit
> that is bound to the superproject, which is getting corrected.
> (merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint).
>
> * "git rebase" internally runs "checkout" to switch between branches,
> and the command used to call the post-checkout hook, but the
> reimplementation stopped doing so, which is getting fixed.
>
> * "git add -e" got confused when the change it wants to let the user
> edit is smaller than the previous change that was left over in a
> temporary file.
> (merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint).
>
> * "git p4" failed to update a shelved change when there were moved
> files, which has been corrected.
> (merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint).
>
> * The codepath to read from the commit-graph file attempted to read
> past the end of it when the file's table-of-contents was corrupt.
>
> * The compat/obstack code had casts that -Wcast-function-type
> compilation option found questionable.
> (merge 764473d257 sg/obstack-cast-function-type-fix later to maint).
>
> * An obvious typo in an assertion error message has been fixed.
> (merge 3c27e2e059 cc/test-ref-store-typofix later to maint).
>
> * In Git for Windows, "git clone \\server\share\path" etc. that uses
> UNC paths from command line had bad interaction with its shell
> emulation.
>
> * "git add --ignore-errors" did not work as advertised and instead
> worked as an unintended synonym for "git add --renormalize", which
> has been fixed.
> (merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint).
>
> * On a case-insensitive filesystem, we failed to compare the part of
> the path that is above the worktree directory in an absolute
> pathname, which has been corrected.
>
> * Asking "git check-attr" about a macro (e.g. "binary") on a specific
> path did not work correctly, even though "git check-attr -a" listed
> such a macro correctly. This has been corrected.
> (merge 7b95849be4 jk/attr-macro-fix later to maint).
>
> * "git pack-objects" incorrectly used uninitialized mutex, which has
> been corrected.
> (merge edb673cf10 ph/pack-objects-mutex-fix later to maint).
>
> * "git checkout -b <new> [HEAD]" to create a new branch from the
> current commit and check it out ought to be a no-op in the index
> and the working tree in normal cases, but there are corner cases
> that do require updates to the index and the working tree. Running
> it immediately after "git clone --no-checkout" is one of these
> cases that an earlier optimization kicked in incorrectly, which has
> been fixed.
> (merge 8424bfd45b bp/checkout-new-branch-optim later to maint).
>
> * "git diff --color-moved --cc --stat -p" did not work well due to
> funny interaction between a bug in color-moved and the rest, which
> has been fixed.
> (merge dac03b5518 jk/diff-cc-stat-fixes later to maint).
>
> * When GIT_SEQUENCE_EDITOR is set, the command was incorrectly
> started when modes of "git rebase" that implicitly uses the
> machinery for the interactive rebase are run, which has been
> corrected.
> (merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint).
>
> * The commit-graph facility did not work when in-core objects that
> are promoted from unknown type to commit (e.g. a commit that is
> accessed via a tag that refers to it) were involved, which has been
> corrected.
> (merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint).
>
> * "git fetch" output cleanup.
> (merge dc40b24df4 nd/fetch-compact-update later to maint).
>
> * "git cat-file --batch" reported a dangling symbolic link by
> mistake, when it wanted to report that a given name is ambiguous.
>
> * Documentation around core.crlf has been updated.
> (merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint).
>
> * The documentation of "git commit-tree" said that the command
> understands "--gpg-sign" in addition to "-S", but the command line
> parser did not know about the longhand, which has been corrected.
>
> * "git rebase -x $cmd" did not reject multi-line command, even though
> the command is incapable of handling such a command. It now is
> rejected upfront.
> (merge c762aada1a pw/rebase-x-sanity-check later to maint).
>
> * Output from "git help" was not correctly aligned, which has been
> fixed.
> (merge 6195a76da4 nd/help-align-command-desc later to maint).
>
> * The "git submodule summary" subcommand showed shortened commit
> object names by mechanically truncating them at 7-hexdigit, which
> has been improved to let "rev-parse --short" scale the length of
> the abbreviation with the size of the repository.
> (merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint).
>
> * The way the OSX build jobs updates its build environment used the
> "--quiet" option to "brew update" command, but it wasn't all that
> quiet to be useful. The use of the option has been replaced with
> an explicit redirection to the /dev/null (which incidentally would
> have worked around a breakage by recent updates to homebrew, which
> has fixed itself already).
> (merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint).
>
> * "git --work-tree=$there --git-dir=$here describe --dirty" did not
> work correctly as it did not pay attention to the location of the
> worktree specified by the user by mistake, which has been
> corrected.
> (merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint).
>
> * "git fetch" over protocol v2 that needs to make a second connection
> to backfill tags did not clear a variable that holds shallow
> repository information correctly, leading to an access of freed
> piece of memory.
>
> * Code cleanup, docfix, build fix, etc.
> (merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint).
> (merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint).
> (merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint).
> (merge ec36c42a63 nd/indentation-fix later to maint).
> (merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint).
> (merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint).
> (merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint).
> (merge 57e9dcaa65 km/rebase-doc-typofix later to maint).
> (merge b8b4cb27e6 ds/gc-doc-typofix later to maint).
> (merge 3b3357626e nd/style-opening-brace later to maint).
> (merge b4583d5595 es/doc-worktree-guessremote-config later to maint).
> (merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint).
> (merge 0650614982 cy/completion-typofix later to maint).
> (merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint).
> (merge bd8d6f0def en/show-ref-doc-fix later to maint).
> (merge 1747125e2c cc/partial-clone-doc-typofix later to maint).
> (merge e01378753d cc/fetch-error-message-fix later to maint).
> (merge 54e8c11215 jk/remote-insteadof-cleanup later to maint).
> (merge d609615f48 js/test-git-installed later to maint).
> (merge ba170517be ja/doc-style-fix later to maint).
> (merge 86fb1c4e77 km/init-doc-typofix later to maint).
> (merge 5cfd4a9d10 nd/commit-doc later to maint).
> (merge 9fce19a431 ab/diff-tree-doc-fix later to maint).
>
> ----------------------------------------------------------------
>
> Changes since v2.20.0 are as follows:
>
> Arti Zirk (1):
> git-instaweb: add Python builtin http.server support
>
> Ben Peart (2):
> checkout: add test demonstrating regression with checkout -b on initial commit
> checkout: fix regression in checkout -b on intitial checkout
>
> Brandon Richardson (1):
> commit-tree: add missing --gpg-sign flag
>
> Brandon Williams (1):
> mailmap: update brandon williams's email address
>
> Carlo Marcelo Arenas Belón (4):
> t6036: avoid non-portable "cp -a"
> tests: add lint for non portable cp -a
> t5004: avoid using tar for empty packages
> config.mak.uname: OpenBSD uses BSD semantics with fread for directories
>
> Chayoung You (3):
> zsh: complete unquoted paths with spaces correctly
> completion: treat results of git ls-tree as file paths
> completion: fix typo in git-completion.bash
>
> Christian Couder (3):
> fetch: fix extensions.partialclone name in error message
> partial-clone: add missing 'is' in doc
> helper/test-ref-store: fix "new-sha1" vs "old-sha1" typo
>
> David Turner (1):
> Do not print 'dangling' for cat-file in case of ambiguity
>
> Denis Ovsienko (1):
> docs: fix $strict_export text in gitweb.conf.txt
>
> Derrick Stolee (9):
> merge-recursive: combine error handling
> .gitattributes: ensure t/oid-info/* has eol=lf
> commit-graph: writing missing parents is a BUG
> git-gc.txt: fix typo about gc.writeCommitGraph
> revision: add mark_tree_uninteresting_sparse
> list-objects: consume sparse tree walk
> revision: implement sparse algorithm
> pack-objects: create pack.useSparse setting
> pack-objects: create GIT_TEST_PACK_SPARSE
>
> Elijah Newren (30):
> t6042: add tests for consistency in file collision conflict handling
> t6036, t6042: testcases for rename collision of already conflicting files
> merge-recursive: increase marker length with depth of recursion
> merge-recursive: new function for better colliding conflict resolutions
> merge-recursive: fix rename/add conflict handling
> merge-recursive: improve handling for rename/rename(2to1) conflicts
> merge-recursive: use handle_file_collision for add/add conflicts
> merge-recursive: improve rename/rename(1to2)/add[/add] handling
> t6036, t6043: increase code coverage for file collision handling
> fast-export: convert sha1 to oid
> git-fast-import.txt: fix documentation for --quiet option
> git-fast-export.txt: clarify misleading documentation about rev-list args
> fast-export: use value from correct enum
> fast-export: avoid dying when filtering by paths and old tags exist
> fast-export: move commit rewriting logic into a function for reuse
> fast-export: when using paths, avoid corrupt stream with non-existent mark
> fast-export: ensure we export requested refs
> fast-export: add --reference-excluded-parents option
> fast-import: remove unmaintained duplicate documentation
> fast-export: add a --show-original-ids option to show original names
> git-rebase.txt: update note about directory rename detection and am
> rebase: make builtin and legacy script error messages the same
> rebase: fix incompatible options error message
> t5407: add a test demonstrating how interactive handles --skip differently
> am, rebase--merge: do not overlook --skip'ed commits with post-rewrite
> git-rebase, sequencer: extend --quiet option for the interactive machinery
> git-legacy-rebase: simplify unnecessary triply-nested if
> rebase: define linearization ordering and enforce it
> rebase: implement --merge via the interactive machinery
> git-show-ref.txt: fix order of flags
>
> Eric Sunshine (1):
> doc/config: do a better job of introducing 'worktree.guessRemote'
>
> Eric Wong (2):
> banned.h: mark strncat() as banned
> t1512: test ambiguous cat-file --batch and --batch-output
>
> Erin Dahlgren (1):
> Simplify handling of setup_git_directory_gently() failure cases.
>
> Force Charlie (1):
> http: add support selecting http version
>
> Frank Dana (1):
> docs/gitweb.conf: config variable typo
>
> Issac Trotts (1):
> log: add %S option (like --source) to log --format
>
> Jean-Noël Avila (2):
> Documentation/Makefile add optional targets for l10n
> doc: tidy asciidoc style
>
> Jeff King (50):
> fsck: do not reuse child_process structs
> submodule--helper: prefer strip_suffix() to ends_with()
> rename "alternate_object_database" to "object_directory"
> sha1_file_name(): overwrite buffer instead of appending
> handle alternates paths the same as the main object dir
> sha1-file: use an object_directory for the main object dir
> object-store: provide helpers for loose_objects_cache
> sha1-file: use loose object cache for quick existence check
> fetch-pack: drop custom loose object cache
> odb_load_loose_cache: fix strbuf leak
> transport-helper: drop read/write errno checks
> sha1-file: fix outdated sha1 comment references
> update comment references to sha1_object_info()
> http: use struct object_id instead of bare sha1
> sha1-file: modernize loose object file functions
> sha1-file: modernize loose header/stream functions
> sha1-file: convert pass-through functions to object_id
> convert has_sha1_file() callers to has_object_file()
> sha1-file: drop has_sha1_file()
> sha1-file: prefer "loose object file" to "sha1 file" in messages
> sha1-file: avoid "sha1 file" for generic use in messages
> prefer "hash mismatch" to "sha1 mismatch"
> upload-pack: support hidden refs with protocol v2
> remote: check config validity before creating rewrite struct
> get_super_prefix(): copy getenv() result
> commit: copy saved getenv() result
> config: make a copy of $GIT_CONFIG string
> init: make a copy of $GIT_DIR string
> merge-recursive: copy $GITHEAD strings
> builtin_diff(): read $GIT_DIFF_OPTS closer to use
> add: use separate ADD_CACHE_RENORMALIZE flag
> attr: do not mark queried macros as unset
> t4006: resurrect commented-out tests
> diff: clear emitted_symbols flag after use
> combine-diff: factor out stat-format mask
> combine-diff: treat --shortstat like --stat
> combine-diff: treat --summary like --stat
> combine-diff: treat --dirstat like --stat
> match-trees: drop unused path parameter from score functions
> apply: drop unused "def" parameter from find_name_gnu()
> create_bundle(): drop unused "header" parameter
> column: drop unused "opts" parameter in item_length()
> show_date_relative(): drop unused "tz" parameter
> config: drop unused parameter from maybe_remove_section()
> convert: drop len parameter from conversion checks
> convert: drop path parameter from actual conversion functions
> doc/gitattributes: clarify "autocrlf overrides eol"
> docs/config: clarify "text property" in core.eol
> test-date: drop unused parameter to getnanos()
> add_to_index(): convert forgotten HASH_RENORMALIZE check
>
> Johannes Schindelin (39):
> rebase: introduce --reschedule-failed-exec
> rebase: add a config option to default to --reschedule-failed-exec
> rebase: introduce a shortcut for --reschedule-failed-exec
> help.h: fix coding style
> help -a: handle aliases with long names gracefully
> t4256: mark support files as LF-only
> t9902: 'send-email' test case requires PERL
> gc/repack: release packs when needed
> add --edit: truncate the patch file
> t6042: work around speed optimization on Windows
> abspath_part_inside_repo: respect core.ignoreCase
> rebase: move `reset_head()` into a better spot
> rebase: avoid double reflog entry when switching branches
> rebase: teach `reset_head()` to optionally skip the worktree
> built-in rebase: call `git am` directly
> mingw (t5580): document bug when cloning from backslashed UNC paths
> mingw: special-case arguments to `sh`
> tests: explicitly use `test-tool.exe` on Windows
> travis: fix skipping tagged releases
> ci: rename the library of common functions
> ci/lib.sh: encapsulate Travis-specific things
> ci: inherit --jobs via MAKEFLAGS in run-build-and-tests
> ci: use a junction on Windows instead of a symlink
> test-date: add a subcommand to measure times in shell scripts
> tests: optionally write results as JUnit-style .xml
> ci/lib.sh: add support for Azure Pipelines
> Add a build definition for Azure DevOps
> ci: add a Windows job to the Azure Pipelines definition
> ci: use git-sdk-64-minimal build artifact
> mingw: be more generous when wrapping up the setitimer() emulation
> README: add a build badge (status of the Azure Pipelines build)
> tests: avoid calling Perl just to determine file sizes
> tests: include detailed trace logs with --write-junit-xml upon failure
> mingw: try to work around issues with the test cleanup
> tests: add t/helper/ to the PATH with --with-dashes
> t0061: workaround issues with --with-dashes and RUNTIME_PREFIX
> tests: optionally skip bin-wrappers/
> ci: speed up Windows phase
> ci: parallelize testing on Windows
>
> Jonathan Nieder (1):
> stripspace: allow -s/-c outside git repository
>
> Jonathan Tan (9):
> revision: use commit graph in get_reference()
> fetch-pack: support protocol version 2
> fetch-pack: do not take shallow lock unnecessarily
> upload-pack: teach deepen-relative in protocol v2
> pkt-line: introduce struct packet_writer
> sideband: reverse its dependency on pkt-line
> {fetch,upload}-pack: sideband v2 fetch response
> tests: define GIT_TEST_SIDEBAND_ALL
> ls-refs: filter refs using namespace-stripped name
>
> Josh Steadmon (4):
> filter-options: expand scaled numbers
> commit-graph, fuzz: add fuzzer for commit-graph
> commit-graph: fix buffer read-overflow
> Makefile: correct example fuzz build
>
> Junio C Hamano (13):
> t0027: squelch checkout path run outside test_expect_* block
> t0061: do not fail test if '.' is part of $PATH
> run-command: report exec failure
> submodule update: run at most one fetch job unless otherwise set
> Git 2.20.1
> Prepare for 2.21 cycle to start soonish
> First batch after 2.20.1
> ref-filter: give uintmax_t to format with %PRIuMAX
> Second batch after 2.20
> Third batch after 2.20
> Fourth batch after 2.20
> Fifth batch for 2.21
> Git 2.21-rc0
>
> Kim Gybels (1):
> diff: ensure correct lifetime of external_diff_cmd
>
> Kyle Meyer (2):
> rebase docs: drop stray word in merge command description
> init docs: correct a punctuation typo
>
> Laura Abbott (1):
> git-quiltimport: add --keep-non-patch option
>
> Linus Torvalds (1):
> Add 'human' date format
>
> Luke Diamand (2):
> git-p4: add failing test for shelved CL update involving move/copy
> git-p4: handle update of moved/copied files when updating a shelve
>
> Martin Ågren (5):
> git-column.txt: fix section header
> Documentation: do not nest open blocks
> git-status.txt: render tables correctly under Asciidoctor
> t7510: invoke git as part of &&-chain
> doc-diff: don't `cd_to_toplevel`
>
> Masaya Suzuki (7):
> Use packet_reader instead of packet_read_line
> pack-protocol.txt: accept error packets in any context
> http: support file handles for HTTP_KEEP_ERROR
> http: enable keep_error for HTTP requests
> remote-curl: define struct for CURLOPT_WRITEFUNCTION
> remote-curl: unset CURLOPT_FAILONERROR
> test: test GIT_CURL_VERBOSE=1 shows an error
>
> Matthew DeVore (4):
> list-objects.c: don't segfault for missing cmdline objects
> revision.c: put promisor option in specialized struct
> list-objects-filter: teach tree:# how to handle >0
> tree:<depth>: skip some trees even when collecting omits
>
> Matthieu Moy (1):
> git-multimail: update to release 1.5.0
>
> Max Kirillov (1):
> http-backend: enable cleaning up forked upload/receive-pack on exit
>
> Nguyễn Thái Ngọc Duy (63):
> git.c: mark more strings for translation
> alias.c: mark split_cmdline_strerror() strings for translation
> archive.c: mark more strings for translation
> attr.c: mark more string for translation
> read-cache.c: turn die("internal error") to BUG()
> read-cache.c: mark more strings for translation
> read-cache.c: add missing colon separators
> reflog: mark strings for translation
> remote.c: turn some error() or die() to BUG()
> remote.c: mark messages for translation
> repack: mark more strings for translation
> parse-options: replace opterror() with optname()
> parse-options.c: turn some die() to BUG()
> parse-options.c: mark more strings for translation
> fsck: reduce word legos to help i18n
> fsck: mark strings for translation
> wt-status.c: remove implicit dependency on the_index
> wt-status.c: remove implicit dependency the_repository
> list-objects-filter.c: remove implicit dependency on the_index
> list-objects.c: reduce the_repository references
> notes-merge.c: remove implicit dependency on the_index
> notes-merge.c: remove implicit dependency the_repository
> transport.c: remove implicit dependency on the_index
> sequencer.c: remove implicit dependency on the_index
> sequencer.c: remove implicit dependency on the_repository
> blame.c: remove implicit dependency the_repository
> bisect.c: remove the_repository reference
> branch.c: remove the_repository reference
> bundle.c: remove the_repository references
> cache-tree.c: remove the_repository references
> delta-islands.c: remove the_repository references
> diff-lib.c: remove the_repository references
> line-log.c: remove the_repository reference
> notes-cache.c: remove the_repository references
> pack-check.c: remove the_repository references
> pack-*.c: remove the_repository references
> rerere.c: remove the_repository references
> rebase-interactive.c: remove the_repository references
> checkout: disambiguate dwim tracking branches and local files
> checkout: print something when checking out paths
> tree.c: make read_tree*() take 'struct repository *'
> tree-walk.c: make tree_entry_interesting() take an index
> pathspec.h: clean up "extern" in function declarations
> dir.c: move, rename and export match_attrs()
> tree-walk: support :(attr) matching
> Indent code with TABs
> style: the opening '{' of a function is in a separate line
> parse-options: fix SunCC compiler warning
> worktree: allow to (re)move worktrees with uninitialized submodules
> grep: use grep_opt->repo instead of explict repo argument
> notes-utils.c: remove the_repository references
> repository.c: replace hold_locked_index() with repo_hold_locked_index()
> checkout: avoid the_index when possible
> read-cache.c: kill read_index()
> read-cache.c: replace update_index_if_able with repo_&
> sha1-name.c: remove implicit dependency on the_index
> merge-recursive.c: remove implicit dependency on the_index
> merge-recursive.c: remove implicit dependency on the_repository
> read-cache.c: remove the_* from index_has_changes()
> cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch
> fetch: prefer suffix substitution in compact fetch.output
> help: align the longest command in the command listing
> git-commit.txt: better description what it does
>
> Olga Telezhnaya (6):
> ref-filter: add objectsize:disk option
> ref-filter: add check for negative file size
> ref-filter: add tests for objectsize:disk
> ref-filter: add deltabase option
> ref-filter: add tests for deltabase
> ref-filter: add docs for new options
>
> Orgad Shaneh (2):
> t5403: simplify by using a single repository
> rebase: run post-checkout hook on checkout
>
> Patrick Hogg (2):
> pack-objects: move read mutex to packing_data struct
> pack-objects: merge read_lock and lock in packing_data struct
>
> Peter Osterlund (1):
> git-p4: fix problem when p4 login is not necessary
>
> Phillip Wood (11):
> diff: document --no-color-moved
> Use "whitespace" consistently
> diff: allow --no-color-moved-ws
> diff --color-moved-ws: demonstrate false positives
> diff --color-moved-ws: fix false positives
> diff --color-moved=zebra: be stricter with color alternation
> diff --color-moved-ws: optimize allow-indentation-change
> diff --color-moved-ws: modify allow-indentation-change
> diff --color-moved-ws: handle blank lines
> implicit interactive rebase: don't run sequence editor
> rebase -x: sanity check command
>
> Pranit Bauva (7):
> bisect--helper: `bisect_reset` shell function in C
> bisect--helper: `bisect_write` shell function in C
> wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
> bisect--helper: `check_and_set_terms` shell function in C
> bisect--helper: `bisect_next_check` shell function in C
> bisect--helper: `get_terms` & `bisect_terms` shell function in C
> bisect--helper: `bisect_start` shell function partially in C
>
> Ramsay Jones (2):
> config.mak.uname: remove obsolete SPARSE_FLAGS setting
> Makefile: improve SPARSE_FLAGS customisation
>
> Randall S. Becker (4):
> transport-helper: use xread instead of read
> config.mak.uname: support for modern HPE NonStop config.
> git-compat-util.h: add FLOSS headers for HPE NonStop
> compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
>
> René Scharfe (5):
> sha1-file: close fd of empty file in map_sha1_file_1()
> object-store: factor out odb_loose_cache()
> object-store: factor out odb_clear_loose_cache()
> object-store: use one oid_array per subdirectory for loose cache
> object-store: retire odb_load_loose_cache()
>
> SZEDER Gábor (22):
> clone: use a more appropriate variable name for the default refspec
> clone: respect additional configured fetch refspecs during initial fetch
> Documentation/clone: document ignored configuration variables
> test-lib: check Bash version for '-x' without using shell arrays
> test-lib: translate SIGTERM and SIGHUP to an exit
> test-lib: extract Bash version check for '-x' tracing
> test-lib: parse options in a for loop to keep $@ intact
> test-lib: parse command line options earlier
> test-lib: consolidate naming of test-results paths
> test-lib: set $TRASH_DIRECTORY earlier
> test-lib-functions: introduce the 'test_set_port' helper function
> test-lib: add the '--stress' option to run a test repeatedly under load
> compat/obstack: fix -Wcast-function-type warnings
> .gitignore: ignore external debug symbols from GCC on macOS
> travis-ci: don't be '--quiet' when running the tests
> travis-ci: switch to Xcode 10.1 macOS image
> travis-ci: build with the right compiler
> commit-graph: rename "large edges" to "extra edges"
> commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily
> strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
> object_as_type: initialize commit-graph-related fields of 'struct commit'
> travis-ci: make the OSX build jobs' 'brew update' more quiet
>
> Sebastian Staudt (2):
> describe: setup working tree for --dirty
> t6120: test for describe with a bare repository
>
> Sergey Organov (4):
> t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
> cherry-pick: do not error on non-merge commits when '-m 1' is specified
> t3502: validate '-m 1' argument is now accepted for non-merge commits
> t3506: validate '-m 1 -ff' is now accepted for non-merge commits
>
> Shahzad Lone (1):
> various: tighten constness of some local variables
>
> Slavica Djukic (1):
> stash: tolerate missing user identity
>
> Stefan Beller (39):
> sha1_file: allow read_object to read objects in arbitrary repositories
> packfile: allow has_packed_and_bad to handle arbitrary repositories
> diff: align move detection error handling with other options
> object-store: allow read_object_file_extended to read from any repo
> object-store: prepare read_object_file to deal with any repo
> object-store: prepare has_{sha1, object}_file to handle any repo
> object: parse_object to honor its repository argument
> commit: allow parse_commit* to handle any repo
> commit-reach.c: allow paint_down_to_common to handle any repo
> commit-reach.c: allow merge_bases_many to handle any repo
> commit-reach.c: allow remove_redundant to handle any repo
> commit-reach.c: allow get_merge_bases_many_0 to handle any repo
> commit-reach: prepare get_merge_bases to handle any repo
> commit-reach: prepare in_merge_bases[_many] to handle any repo
> commit: prepare get_commit_buffer to handle any repo
> commit: prepare repo_unuse_commit_buffer to handle any repo
> commit: prepare logmsg_reencode to handle arbitrary repositories
> pretty: prepare format_commit_message to handle arbitrary repositories
> sideband: color lines with keyword only
> sha1-array: provide oid_array_filter
> submodule.c: fix indentation
> submodule.c: sort changed_submodule_names before searching it
> submodule.c: tighten scope of changed_submodule_names struct
> submodule: store OIDs in changed_submodule_names
> repository: repo_submodule_init to take a submodule struct
> submodule: migrate get_next_submodule to use repository structs
> submodule.c: fetch in submodules git directory instead of in worktree
> fetch: ensure submodule objects fetched
> submodule update: add regression test with old style setups
> submodule: unset core.worktree if no working tree is present
> submodule--helper: fix BUG message in ensure_core_worktree
> submodule deinit: unset core.worktree
> submodule: use submodule repos for object lookup
> submodule: don't add submodule as odb for push
> commit-graph: convert remaining functions to handle any repo
> commit: prepare free_commit_buffer and release_commit_memory for any repo
> path.h: make REPO_GIT_PATH_FUNC repository agnostic
> t/helper/test-repository: celebrate independence from the_repository
> git-submodule: abort if core.worktree could not be set correctly
>
> Stephen P. Smith (4):
> Replace the proposed 'auto' mode with 'auto:'
> Add 'human' date format documentation
> Add `human` format to test-tool
> Add `human` date format tests.
>
> Sven van Haastregt (1):
> git-submodule.sh: shorten submodule SHA-1s using rev-parse
>
> Thomas Braun (1):
> log -G: ignore binary files
>
> Thomas Gummerer (3):
> t5570: drop racy test
> Revert "t/lib-git-daemon: record daemon log"
> config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf users
>
> Torsten Bögershausen (3):
> git clone <url> C:\cygwin\home\USER\repo' is working (again)
> test-lint: only use only sed [-n] [-e command] [-f command_file]
> Support working-tree-encoding "UTF-16LE-BOM"
>
> brian m. carlson (19):
> sha1-file: rename algorithm to "sha1"
> sha1-file: provide functions to look up hash algorithms
> hex: introduce functions to print arbitrary hashes
> cache: make hashcmp and hasheq work with larger hashes
> t: add basic tests for our SHA-1 implementation
> t: make the sha1 test-tool helper generic
> sha1-file: add a constant for hash block size
> t/helper: add a test helper to compute hash speed
> commit-graph: convert to using the_hash_algo
> Add a base implementation of SHA-256 support
> sha256: add an SHA-256 implementation using libgcrypt
> hash: add an SHA-256 implementation using OpenSSL
> tree-walk: copy object ID before use
> match-trees: compute buffer offset correctly when splicing
> match-trees: use hashcpy to splice trees
> tree-walk: store object_id in a separate member
> cache: make oidcpy always copy GIT_MAX_RAWSZ bytes
> fetch-pack: clear alternate shallow when complete
> fetch-pack: clear alternate shallow in one more place
>
> Ævar Arnfjörð Bjarmason (17):
> remote.c: add braces in anticipation of a follow-up change
> i18n: remote.c: mark error(...) messages for translation
> push: improve the error shown on unqualified <dst> push
> push: move unqualified refname error into a function
> push: add an advice on unqualified <dst> push
> push: test that <src> doesn't DWYM if <dst> is unqualified
> push doc: document the DWYM behavior pushing to unqualified <dst>
> commit-graph: split up close_reachable() progress output
> commit-graph write: use pack order when finding commits
> commit-graph write: add "Writing out" progress output
> commit-graph write: more descriptive "writing out" output
> commit-graph write: show progress for object search
> commit-graph write: add more descriptive progress output
> commit-graph write: remove empty line for readability
> commit-graph write: add itermediate progress
> commit-graph write: emit a percentage for all progress
> diff-tree doc: correct & remove wrong documentation
>
>
^ permalink raw reply [relevance 0%]
* [ANNOUNCE] Git v2.21.0-rc0
@ 2019-02-07 7:28 1% Junio C Hamano
2019-02-07 19:47 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Junio C Hamano @ 2019-02-07 7:28 UTC (permalink / raw)
To: git; +Cc: Linux Kernel, git-packagers
An early preview release Git v2.21.0-rc0 is now available for
testing at the usual places. It is comprised of 426 non-merge
commits since v2.20.0, contributed by 57 people, 13 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.21.0-rc0' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.20.0 are as follows.
Welcome to the Git development community!
Arti Zirk, Brandon Richardson, Chayoung You, Denis Ovsienko, Erin
Dahlgren, Force Charlie, Frank Dana, Issac Trotts, Laura Abbott,
Patrick Hogg, Peter Osterlund, Shahzad Lone, and Slavica Djukic.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Ævar Arnfjörð Bjarmason, Ben Peart, Brandon Williams, brian
m. carlson, Carlo Marcelo Arenas Belón, Christian Couder,
David Turner, Derrick Stolee, Elijah Newren, Eric Sunshine,
Eric Wong, Jean-Noël Avila, Jeff King, Johannes Schindelin,
Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Kim
Gybels, Kyle Meyer, Linus Torvalds, Luke Diamand, Martin Ågren,
Masaya Suzuki, Matthew DeVore, Matthieu Moy, Max Kirillov,
Nguyễn Thái Ngọc Duy, Olga Telezhnaya, Orgad Shaneh,
Phillip Wood, Pranit Bauva, Ramsay Jones, Randall S. Becker,
René Scharfe, Sebastian Staudt, Sergey Organov, Stefan Beller,
Stephen P. Smith, Sven van Haastregt, SZEDER Gábor, Thomas
Braun, Thomas Gummerer, and Torsten Bögershausen.
----------------------------------------------------------------
Git 2.21 Release Notes (draft)
==============================
Backward Compatibility Notes
----------------------------
* Historically, the "-m" (mainline) option can only be used for "git
cherry-pick" and "git revert" when working with a merge commit.
This version of Git no longer warns or errors out when working with
a single-parent commit, as long as the argument to the "-m" option
is 1 (i.e. it has only one parent, and the request is to pick or
revert relative to that first parent). Scripts that relied on the
behaviour may get broken with this change.
Updates since v2.20
-------------------
UI, Workflows & Features
* The "http.version" configuration variable can be used with recent
enough versions of cURL library to force the version of HTTP used
to talk when fetching and pushing.
* Small fixes and features for fast-export and fast-import, mostly on
the fast-export side has been made.
* "git push $there $src:$dst" rejects when $dst is not a fully
qualified refname and not clear what the end user meant. The
codepath has been taught to give a clearer error message, and also
guess where the push should go by taking the type of the pushed
object into account (e.g. a tag object would want to go under
refs/tags/).
* "git checkout [<tree-ish>] path..." learned to report the number of
paths that have been checked out of the index or the tree-ish,
which gives it the same degree of noisy-ness as the case in which
the command checks out a branch.
* "git quiltimport" learned "--keep-non-patch" option.
* "git worktree remove" and "git worktree move" refused to work when
there is a submodule involved. This has been loosened to ignore
uninitialized submodules.
* "git cherry-pick -m1" was forbidden when picking a non-merge
commit, even though there _is_ parent number 1 for such a commit.
This was done to avoid mistakes back when "cherry-pick" was about
picking a single commit, but is no longer useful with "cherry-pick"
that can pick a range of commits. Now the "-m$num" option is
allowed when picking any commit, as long as $num names an existing
parent of the commit.
* Update "git multimail" from the upstream.
* "git p4" update.
* The "--format=<placeholder>" option of for-each-ref, branch and tag
learned to show a few more traits of objects that can be learned by
the object_info API.
* "git rebase -i" learned to re-execute a command given with 'exec'
to run after it failed the last time.
* "git diff --color-moved-ws" updates.
* Custom userformat "log --format" learned %S atom that stands for
the tip the traversal reached the commit from, i.e. --source.
* "git instaweb" learned to drive http.server that comes with
"batteries included" Python installation (both Python2 & 3).
* A new encoding UTF-16LE-BOM has been invented to force encoding to
UTF-16 with BOM in little endian byte order, which cannot be directly
generated by using iconv.
* A new date format "--date=human" that morphs its output depending
on how far the time is from the current time has been introduced.
"--date=auto" can be used to use this new format when the output is
going to the pager or to the terminal and otherwise the default
format.
Performance, Internal Implementation, Development Support etc.
* Code clean-up with optimization for the codepath that checks
(non-)existence of loose objects.
* More codepaths have become aware of working with in-core repository
instance other than the default "the_repository".
* The "strncat()" function is now among the banned functions.
* Portability updates for the HPE NonStop platform.
* Earlier we added "-Wformat-security" to developer builds, assuming
that "-Wall" (which includes "-Wformat" which in turn is required
to use "-Wformat-security") is always in effect. This is not true
when config.mak.autogen is in use, unfortunately. This has been
fixed by unconditionally adding "-Wall" to developer builds.
* The loose object cache used to optimize existence look-up has been
updated.
* Flaky tests can now be repeatedly run under load with the
"--stress" option.
* Documentation/Makefile is getting prepared for manpage
localization.
* "git fetch-pack" now can talk the version 2 protocol.
* sha-256 hash has been added and plumbed through the code to allow
building Git with the "NewHash".
* Debugging help for http transport.
* "git fetch --deepen=<more>" has been corrected to work over v2
protocol.
* The code to walk tree objects has been taught that we may be
working with object names that are not computed with SHA-1.
* The in-core repository instances are passed through more codepaths.
* Update the protocol message specification to allow only the limited
use of scaled quantities. This is ensure potential compatibility
issues will not go out of hand.
* Micro-optimize the code that prepares commit objects to be walked
by "git rev-list" when the commit-graph is available.
* "git fetch" and "git upload-pack" learned to send all exchange over
the sideband channel while talking the v2 protocol.
* The codepath to write out commit-graph has been optimized by
following the usual pattern of visiting objects in in-pack order.
* The codepath to show progress meter while writing out commit-graph
file has been improved.
* Cocci rules have been updated to encourage use of strbuf_addbuf().
* "git rebase --merge" has been reimplemented by reusing the internal
machinery used for "git rebase -i".
* More code in "git bisect" has been rewritten in C.
* Instead of going through "git-rebase--am" scriptlet to use the "am"
backend, the built-in version of "git rebase" learned to drive the
"am" backend directly.
* The assumption to work on the single "in-core index" instance has
been reduced from the library-ish part of the codebase.
* The test lint learned to catch non-portable "sed" options.
* "git pack-objects" learned another algorithm to compute the set of
objects to send, that trades the resulting packfile off to save
traversal cost to favor small pushes.
* The travis CI scripts have been corrected to build Git with the
compiler(s) of our choice.
* "git submodule update" learned to abort early when core.worktree
for the submodule is not set correctly to prevent spreading damage.
* Test suite has been adjusted to run on Azure Pipeline.
* Running "Documentation/doc-diff x" from anywhere other than the
top-level of the working tree did not show the usage string
correctly, which has been fixed.
* Use of the sparse tool got easier to customize from the command
line to help developers.
Fixes since v2.20
-----------------
* Updates for corner cases in merge-recursive.
(merge cc4cb0902c en/merge-path-collision later to maint).
* "git checkout frotz" (without any double-dash) avoids ambiguity by
making sure 'frotz' cannot be interpreted as a revision and as a
path at the same time. This safety has been updated to check also
a unique remote-tracking branch 'frotz' in a remote, when dwimming
to create a local branch 'frotz' out of a remote-tracking branch
'frotz' from a remote.
(merge be4908f103 nd/checkout-dwim-fix later to maint).
* Refspecs configured with "git -c var=val clone" did not propagate
to the resulting repository, which has been corrected.
(merge 7eae4a3ac4 sg/clone-initial-fetch-configuration later to maint).
* A properly configured username/email is required under
user.useConfigOnly in order to create commits; now "git stash"
(even though it creates commit objects to represent stash entries)
command is exempt from the requirement.
(merge 3bc2111fc2 sd/stash-wo-user-name later to maint).
* The http-backend CGI process did not correctly clean up the child
processes it spawns to run upload-pack etc. when it dies itself,
which has been corrected.
(merge 02818a98d7 mk/http-backend-kill-children-before-exit later to maint).
* "git rev-list --exclude-promisor-objects" had to take an object
that does not exist locally (and is lazily available) from the
command line without barfing, but the code dereferenced NULL.
(merge 4cf67869b2 md/list-lazy-objects-fix later to maint).
* The traversal over tree objects has learned to honor
":(attr:label)" pathspec match, which has been implemented only for
enumerating paths on the filesystem.
(merge 5a0b97b34c nd/attr-pathspec-in-tree-walk later to maint).
* BSD port updates.
(merge 4e3ecbd439 cb/openbsd-allows-reading-directory later to maint).
(merge b6bdc2a0f5 cb/t5004-empty-tar-archive-fix later to maint).
(merge 82cbc8cde2 cb/test-lint-cp-a later to maint).
* Lines that begin with a certain keyword that come over the wire, as
well as lines that consist only of one of these keywords, ought to
be painted in color for easier eyeballing, but the latter was
broken ever since the feature was introduced in 2.19, which has
been corrected.
(merge 1f67290450 hn/highlight-sideband-keywords later to maint).
* "git log -G<regex>" looked for a hunk in the "git log -p" patch
output that contained a string that matches the given pattern.
Optimize this code to ignore binary files, which by default will
not show any hunk that would match any pattern (unless textconv or
the --text option is in effect, that is).
(merge e0e7cb8080 tb/log-G-binary later to maint).
* "git submodule update" ought to use a single job unless asked, but
by mistake used multiple jobs, which has been fixed.
(merge e3a9d1aca9 sb/submodule-fetchjobs-default-to-one later to maint).
* "git stripspace" should be usable outside a git repository, but
under the "-s" or "-c" mode, it didn't.
(merge 957da75802 jn/stripspace-wo-repository later to maint).
* Some of the documentation pages formatted incorrectly with
Asciidoctor, which have been fixed.
(merge b62eb1d2f4 ma/asciidoctor later to maint).
* The core.worktree setting in a submodule repository should not be
pointing at a directory when the submodule loses its working tree
(e.g. getting deinit'ed), but the code did not properly maintain
this invariant.
* With zsh, "git cmd path<TAB>" was completed to "git cmd path name"
when the completed path has a special character like SP in it,
without any attempt to keep "path name" a single filename. This
has been fixed to complete it to "git cmd path\ name" just like
Bash completion does.
* The test suite tried to see if it is run under bash, but the check
itself failed under some other implementations of shell (notably
under NetBSD). This has been corrected.
(merge 54ea72f09c sg/test-bash-version-fix later to maint).
* "git gc" and "git repack" did not close the open packfiles that
they found unneeded before removing them, which didn't work on a
platform incapable of removing an open file. This has been
corrected.
(merge 5bdece0d70 js/gc-repack-close-before-remove later to maint).
* The code to drive GIT_EXTERNAL_DIFF command relied on the string
returned from getenv() to be non-volatile, which is not true, that
has been corrected.
(merge 6776a84dae kg/external-diff-save-env later to maint).
* There were many places the code relied on the string returned from
getenv() to be non-volatile, which is not true, that have been
corrected.
(merge 0da0e9268b jk/save-getenv-result later to maint).
* The v2 upload-pack protocol implementation failed to honor
hidden-ref configuration, which has been corrected.
(merge e20b4192a3 jk/proto-v2-hidden-refs-fix later to maint).
* "git fetch --recurse-submodules" may not fetch the necessary commit
that is bound to the superproject, which is getting corrected.
(merge be76c21282 sb/submodule-recursive-fetch-gets-the-tip later to maint).
* "git rebase" internally runs "checkout" to switch between branches,
and the command used to call the post-checkout hook, but the
reimplementation stopped doing so, which is getting fixed.
* "git add -e" got confused when the change it wants to let the user
edit is smaller than the previous change that was left over in a
temporary file.
(merge fa6f225e01 js/add-e-clear-patch-before-stating later to maint).
* "git p4" failed to update a shelved change when there were moved
files, which has been corrected.
(merge 7a10946ab9 ld/git-p4-shelve-update-fix later to maint).
* The codepath to read from the commit-graph file attempted to read
past the end of it when the file's table-of-contents was corrupt.
* The compat/obstack code had casts that -Wcast-function-type
compilation option found questionable.
(merge 764473d257 sg/obstack-cast-function-type-fix later to maint).
* An obvious typo in an assertion error message has been fixed.
(merge 3c27e2e059 cc/test-ref-store-typofix later to maint).
* In Git for Windows, "git clone \\server\share\path" etc. that uses
UNC paths from command line had bad interaction with its shell
emulation.
* "git add --ignore-errors" did not work as advertised and instead
worked as an unintended synonym for "git add --renormalize", which
has been fixed.
(merge e2c2a37545 jk/add-ignore-errors-bit-assignment-fix later to maint).
* On a case-insensitive filesystem, we failed to compare the part of
the path that is above the worktree directory in an absolute
pathname, which has been corrected.
* Asking "git check-attr" about a macro (e.g. "binary") on a specific
path did not work correctly, even though "git check-attr -a" listed
such a macro correctly. This has been corrected.
(merge 7b95849be4 jk/attr-macro-fix later to maint).
* "git pack-objects" incorrectly used uninitialized mutex, which has
been corrected.
(merge edb673cf10 ph/pack-objects-mutex-fix later to maint).
* "git checkout -b <new> [HEAD]" to create a new branch from the
current commit and check it out ought to be a no-op in the index
and the working tree in normal cases, but there are corner cases
that do require updates to the index and the working tree. Running
it immediately after "git clone --no-checkout" is one of these
cases that an earlier optimization kicked in incorrectly, which has
been fixed.
(merge 8424bfd45b bp/checkout-new-branch-optim later to maint).
* "git diff --color-moved --cc --stat -p" did not work well due to
funny interaction between a bug in color-moved and the rest, which
has been fixed.
(merge dac03b5518 jk/diff-cc-stat-fixes later to maint).
* When GIT_SEQUENCE_EDITOR is set, the command was incorrectly
started when modes of "git rebase" that implicitly uses the
machinery for the interactive rebase are run, which has been
corrected.
(merge 891d4a0313 pw/no-editor-in-rebase-i-implicit later to maint).
* The commit-graph facility did not work when in-core objects that
are promoted from unknown type to commit (e.g. a commit that is
accessed via a tag that refers to it) were involved, which has been
corrected.
(merge 4468d4435c sg/object-as-type-commit-graph-fix later to maint).
* "git fetch" output cleanup.
(merge dc40b24df4 nd/fetch-compact-update later to maint).
* "git cat-file --batch" reported a dangling symbolic link by
mistake, when it wanted to report that a given name is ambiguous.
* Documentation around core.crlf has been updated.
(merge c9446f0504 jk/autocrlf-overrides-eol-doc later to maint).
* The documentation of "git commit-tree" said that the command
understands "--gpg-sign" in addition to "-S", but the command line
parser did not know about the longhand, which has been corrected.
* "git rebase -x $cmd" did not reject multi-line command, even though
the command is incapable of handling such a command. It now is
rejected upfront.
(merge c762aada1a pw/rebase-x-sanity-check later to maint).
* Output from "git help" was not correctly aligned, which has been
fixed.
(merge 6195a76da4 nd/help-align-command-desc later to maint).
* The "git submodule summary" subcommand showed shortened commit
object names by mechanically truncating them at 7-hexdigit, which
has been improved to let "rev-parse --short" scale the length of
the abbreviation with the size of the repository.
(merge 0586a438f6 sh/submodule-summary-abbrev-fix later to maint).
* The way the OSX build jobs updates its build environment used the
"--quiet" option to "brew update" command, but it wasn't all that
quiet to be useful. The use of the option has been replaced with
an explicit redirection to the /dev/null (which incidentally would
have worked around a breakage by recent updates to homebrew, which
has fixed itself already).
(merge a1ccaedd62 sg/travis-osx-brew-breakage-workaround later to maint).
* "git --work-tree=$there --git-dir=$here describe --dirty" did not
work correctly as it did not pay attention to the location of the
worktree specified by the user by mistake, which has been
corrected.
(merge c801170b0c ss/describe-dirty-in-the-right-directory later to maint).
* "git fetch" over protocol v2 that needs to make a second connection
to backfill tags did not clear a variable that holds shallow
repository information correctly, leading to an access of freed
piece of memory.
* Code cleanup, docfix, build fix, etc.
(merge 89ba9a79ae hb/t0061-dot-in-path-fix later to maint).
(merge d173e799ea sb/diff-color-moved-config-option-fixup later to maint).
(merge a8f5a59067 en/directory-renames-nothanks-doc-update later to maint).
(merge ec36c42a63 nd/indentation-fix later to maint).
(merge f116ee21cd do/gitweb-strict-export-conf-doc later to maint).
(merge 112ea42663 fd/gitweb-snapshot-conf-doc-fix later to maint).
(merge 1cadad6f65 tb/use-common-win32-pathfuncs-on-cygwin later to maint).
(merge 57e9dcaa65 km/rebase-doc-typofix later to maint).
(merge b8b4cb27e6 ds/gc-doc-typofix later to maint).
(merge 3b3357626e nd/style-opening-brace later to maint).
(merge b4583d5595 es/doc-worktree-guessremote-config later to maint).
(merge cce99cd8c6 ds/commit-graph-assert-missing-parents later to maint).
(merge 0650614982 cy/completion-typofix later to maint).
(merge 6881925ef5 rs/sha1-file-close-mapped-file-on-error later to maint).
(merge bd8d6f0def en/show-ref-doc-fix later to maint).
(merge 1747125e2c cc/partial-clone-doc-typofix later to maint).
(merge e01378753d cc/fetch-error-message-fix later to maint).
(merge 54e8c11215 jk/remote-insteadof-cleanup later to maint).
(merge d609615f48 js/test-git-installed later to maint).
(merge ba170517be ja/doc-style-fix later to maint).
(merge 86fb1c4e77 km/init-doc-typofix later to maint).
(merge 5cfd4a9d10 nd/commit-doc later to maint).
(merge 9fce19a431 ab/diff-tree-doc-fix later to maint).
----------------------------------------------------------------
Changes since v2.20.0 are as follows:
Arti Zirk (1):
git-instaweb: add Python builtin http.server support
Ben Peart (2):
checkout: add test demonstrating regression with checkout -b on initial commit
checkout: fix regression in checkout -b on intitial checkout
Brandon Richardson (1):
commit-tree: add missing --gpg-sign flag
Brandon Williams (1):
mailmap: update brandon williams's email address
Carlo Marcelo Arenas Belón (4):
t6036: avoid non-portable "cp -a"
tests: add lint for non portable cp -a
t5004: avoid using tar for empty packages
config.mak.uname: OpenBSD uses BSD semantics with fread for directories
Chayoung You (3):
zsh: complete unquoted paths with spaces correctly
completion: treat results of git ls-tree as file paths
completion: fix typo in git-completion.bash
Christian Couder (3):
fetch: fix extensions.partialclone name in error message
partial-clone: add missing 'is' in doc
helper/test-ref-store: fix "new-sha1" vs "old-sha1" typo
David Turner (1):
Do not print 'dangling' for cat-file in case of ambiguity
Denis Ovsienko (1):
docs: fix $strict_export text in gitweb.conf.txt
Derrick Stolee (9):
merge-recursive: combine error handling
.gitattributes: ensure t/oid-info/* has eol=lf
commit-graph: writing missing parents is a BUG
git-gc.txt: fix typo about gc.writeCommitGraph
revision: add mark_tree_uninteresting_sparse
list-objects: consume sparse tree walk
revision: implement sparse algorithm
pack-objects: create pack.useSparse setting
pack-objects: create GIT_TEST_PACK_SPARSE
Elijah Newren (30):
t6042: add tests for consistency in file collision conflict handling
t6036, t6042: testcases for rename collision of already conflicting files
merge-recursive: increase marker length with depth of recursion
merge-recursive: new function for better colliding conflict resolutions
merge-recursive: fix rename/add conflict handling
merge-recursive: improve handling for rename/rename(2to1) conflicts
merge-recursive: use handle_file_collision for add/add conflicts
merge-recursive: improve rename/rename(1to2)/add[/add] handling
t6036, t6043: increase code coverage for file collision handling
fast-export: convert sha1 to oid
git-fast-import.txt: fix documentation for --quiet option
git-fast-export.txt: clarify misleading documentation about rev-list args
fast-export: use value from correct enum
fast-export: avoid dying when filtering by paths and old tags exist
fast-export: move commit rewriting logic into a function for reuse
fast-export: when using paths, avoid corrupt stream with non-existent mark
fast-export: ensure we export requested refs
fast-export: add --reference-excluded-parents option
fast-import: remove unmaintained duplicate documentation
fast-export: add a --show-original-ids option to show original names
git-rebase.txt: update note about directory rename detection and am
rebase: make builtin and legacy script error messages the same
rebase: fix incompatible options error message
t5407: add a test demonstrating how interactive handles --skip differently
am, rebase--merge: do not overlook --skip'ed commits with post-rewrite
git-rebase, sequencer: extend --quiet option for the interactive machinery
git-legacy-rebase: simplify unnecessary triply-nested if
rebase: define linearization ordering and enforce it
rebase: implement --merge via the interactive machinery
git-show-ref.txt: fix order of flags
Eric Sunshine (1):
doc/config: do a better job of introducing 'worktree.guessRemote'
Eric Wong (2):
banned.h: mark strncat() as banned
t1512: test ambiguous cat-file --batch and --batch-output
Erin Dahlgren (1):
Simplify handling of setup_git_directory_gently() failure cases.
Force Charlie (1):
http: add support selecting http version
Frank Dana (1):
docs/gitweb.conf: config variable typo
Issac Trotts (1):
log: add %S option (like --source) to log --format
Jean-Noël Avila (2):
Documentation/Makefile add optional targets for l10n
doc: tidy asciidoc style
Jeff King (50):
fsck: do not reuse child_process structs
submodule--helper: prefer strip_suffix() to ends_with()
rename "alternate_object_database" to "object_directory"
sha1_file_name(): overwrite buffer instead of appending
handle alternates paths the same as the main object dir
sha1-file: use an object_directory for the main object dir
object-store: provide helpers for loose_objects_cache
sha1-file: use loose object cache for quick existence check
fetch-pack: drop custom loose object cache
odb_load_loose_cache: fix strbuf leak
transport-helper: drop read/write errno checks
sha1-file: fix outdated sha1 comment references
update comment references to sha1_object_info()
http: use struct object_id instead of bare sha1
sha1-file: modernize loose object file functions
sha1-file: modernize loose header/stream functions
sha1-file: convert pass-through functions to object_id
convert has_sha1_file() callers to has_object_file()
sha1-file: drop has_sha1_file()
sha1-file: prefer "loose object file" to "sha1 file" in messages
sha1-file: avoid "sha1 file" for generic use in messages
prefer "hash mismatch" to "sha1 mismatch"
upload-pack: support hidden refs with protocol v2
remote: check config validity before creating rewrite struct
get_super_prefix(): copy getenv() result
commit: copy saved getenv() result
config: make a copy of $GIT_CONFIG string
init: make a copy of $GIT_DIR string
merge-recursive: copy $GITHEAD strings
builtin_diff(): read $GIT_DIFF_OPTS closer to use
add: use separate ADD_CACHE_RENORMALIZE flag
attr: do not mark queried macros as unset
t4006: resurrect commented-out tests
diff: clear emitted_symbols flag after use
combine-diff: factor out stat-format mask
combine-diff: treat --shortstat like --stat
combine-diff: treat --summary like --stat
combine-diff: treat --dirstat like --stat
match-trees: drop unused path parameter from score functions
apply: drop unused "def" parameter from find_name_gnu()
create_bundle(): drop unused "header" parameter
column: drop unused "opts" parameter in item_length()
show_date_relative(): drop unused "tz" parameter
config: drop unused parameter from maybe_remove_section()
convert: drop len parameter from conversion checks
convert: drop path parameter from actual conversion functions
doc/gitattributes: clarify "autocrlf overrides eol"
docs/config: clarify "text property" in core.eol
test-date: drop unused parameter to getnanos()
add_to_index(): convert forgotten HASH_RENORMALIZE check
Johannes Schindelin (39):
rebase: introduce --reschedule-failed-exec
rebase: add a config option to default to --reschedule-failed-exec
rebase: introduce a shortcut for --reschedule-failed-exec
help.h: fix coding style
help -a: handle aliases with long names gracefully
t4256: mark support files as LF-only
t9902: 'send-email' test case requires PERL
gc/repack: release packs when needed
add --edit: truncate the patch file
t6042: work around speed optimization on Windows
abspath_part_inside_repo: respect core.ignoreCase
rebase: move `reset_head()` into a better spot
rebase: avoid double reflog entry when switching branches
rebase: teach `reset_head()` to optionally skip the worktree
built-in rebase: call `git am` directly
mingw (t5580): document bug when cloning from backslashed UNC paths
mingw: special-case arguments to `sh`
tests: explicitly use `test-tool.exe` on Windows
travis: fix skipping tagged releases
ci: rename the library of common functions
ci/lib.sh: encapsulate Travis-specific things
ci: inherit --jobs via MAKEFLAGS in run-build-and-tests
ci: use a junction on Windows instead of a symlink
test-date: add a subcommand to measure times in shell scripts
tests: optionally write results as JUnit-style .xml
ci/lib.sh: add support for Azure Pipelines
Add a build definition for Azure DevOps
ci: add a Windows job to the Azure Pipelines definition
ci: use git-sdk-64-minimal build artifact
mingw: be more generous when wrapping up the setitimer() emulation
README: add a build badge (status of the Azure Pipelines build)
tests: avoid calling Perl just to determine file sizes
tests: include detailed trace logs with --write-junit-xml upon failure
mingw: try to work around issues with the test cleanup
tests: add t/helper/ to the PATH with --with-dashes
t0061: workaround issues with --with-dashes and RUNTIME_PREFIX
tests: optionally skip bin-wrappers/
ci: speed up Windows phase
ci: parallelize testing on Windows
Jonathan Nieder (1):
stripspace: allow -s/-c outside git repository
Jonathan Tan (9):
revision: use commit graph in get_reference()
fetch-pack: support protocol version 2
fetch-pack: do not take shallow lock unnecessarily
upload-pack: teach deepen-relative in protocol v2
pkt-line: introduce struct packet_writer
sideband: reverse its dependency on pkt-line
{fetch,upload}-pack: sideband v2 fetch response
tests: define GIT_TEST_SIDEBAND_ALL
ls-refs: filter refs using namespace-stripped name
Josh Steadmon (4):
filter-options: expand scaled numbers
commit-graph, fuzz: add fuzzer for commit-graph
commit-graph: fix buffer read-overflow
Makefile: correct example fuzz build
Junio C Hamano (13):
t0027: squelch checkout path run outside test_expect_* block
t0061: do not fail test if '.' is part of $PATH
run-command: report exec failure
submodule update: run at most one fetch job unless otherwise set
Git 2.20.1
Prepare for 2.21 cycle to start soonish
First batch after 2.20.1
ref-filter: give uintmax_t to format with %PRIuMAX
Second batch after 2.20
Third batch after 2.20
Fourth batch after 2.20
Fifth batch for 2.21
Git 2.21-rc0
Kim Gybels (1):
diff: ensure correct lifetime of external_diff_cmd
Kyle Meyer (2):
rebase docs: drop stray word in merge command description
init docs: correct a punctuation typo
Laura Abbott (1):
git-quiltimport: add --keep-non-patch option
Linus Torvalds (1):
Add 'human' date format
Luke Diamand (2):
git-p4: add failing test for shelved CL update involving move/copy
git-p4: handle update of moved/copied files when updating a shelve
Martin Ågren (5):
git-column.txt: fix section header
Documentation: do not nest open blocks
git-status.txt: render tables correctly under Asciidoctor
t7510: invoke git as part of &&-chain
doc-diff: don't `cd_to_toplevel`
Masaya Suzuki (7):
Use packet_reader instead of packet_read_line
pack-protocol.txt: accept error packets in any context
http: support file handles for HTTP_KEEP_ERROR
http: enable keep_error for HTTP requests
remote-curl: define struct for CURLOPT_WRITEFUNCTION
remote-curl: unset CURLOPT_FAILONERROR
test: test GIT_CURL_VERBOSE=1 shows an error
Matthew DeVore (4):
list-objects.c: don't segfault for missing cmdline objects
revision.c: put promisor option in specialized struct
list-objects-filter: teach tree:# how to handle >0
tree:<depth>: skip some trees even when collecting omits
Matthieu Moy (1):
git-multimail: update to release 1.5.0
Max Kirillov (1):
http-backend: enable cleaning up forked upload/receive-pack on exit
Nguyễn Thái Ngọc Duy (63):
git.c: mark more strings for translation
alias.c: mark split_cmdline_strerror() strings for translation
archive.c: mark more strings for translation
attr.c: mark more string for translation
read-cache.c: turn die("internal error") to BUG()
read-cache.c: mark more strings for translation
read-cache.c: add missing colon separators
reflog: mark strings for translation
remote.c: turn some error() or die() to BUG()
remote.c: mark messages for translation
repack: mark more strings for translation
parse-options: replace opterror() with optname()
parse-options.c: turn some die() to BUG()
parse-options.c: mark more strings for translation
fsck: reduce word legos to help i18n
fsck: mark strings for translation
wt-status.c: remove implicit dependency on the_index
wt-status.c: remove implicit dependency the_repository
list-objects-filter.c: remove implicit dependency on the_index
list-objects.c: reduce the_repository references
notes-merge.c: remove implicit dependency on the_index
notes-merge.c: remove implicit dependency the_repository
transport.c: remove implicit dependency on the_index
sequencer.c: remove implicit dependency on the_index
sequencer.c: remove implicit dependency on the_repository
blame.c: remove implicit dependency the_repository
bisect.c: remove the_repository reference
branch.c: remove the_repository reference
bundle.c: remove the_repository references
cache-tree.c: remove the_repository references
delta-islands.c: remove the_repository references
diff-lib.c: remove the_repository references
line-log.c: remove the_repository reference
notes-cache.c: remove the_repository references
pack-check.c: remove the_repository references
pack-*.c: remove the_repository references
rerere.c: remove the_repository references
rebase-interactive.c: remove the_repository references
checkout: disambiguate dwim tracking branches and local files
checkout: print something when checking out paths
tree.c: make read_tree*() take 'struct repository *'
tree-walk.c: make tree_entry_interesting() take an index
pathspec.h: clean up "extern" in function declarations
dir.c: move, rename and export match_attrs()
tree-walk: support :(attr) matching
Indent code with TABs
style: the opening '{' of a function is in a separate line
parse-options: fix SunCC compiler warning
worktree: allow to (re)move worktrees with uninitialized submodules
grep: use grep_opt->repo instead of explict repo argument
notes-utils.c: remove the_repository references
repository.c: replace hold_locked_index() with repo_hold_locked_index()
checkout: avoid the_index when possible
read-cache.c: kill read_index()
read-cache.c: replace update_index_if_able with repo_&
sha1-name.c: remove implicit dependency on the_index
merge-recursive.c: remove implicit dependency on the_index
merge-recursive.c: remove implicit dependency on the_repository
read-cache.c: remove the_* from index_has_changes()
cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch
fetch: prefer suffix substitution in compact fetch.output
help: align the longest command in the command listing
git-commit.txt: better description what it does
Olga Telezhnaya (6):
ref-filter: add objectsize:disk option
ref-filter: add check for negative file size
ref-filter: add tests for objectsize:disk
ref-filter: add deltabase option
ref-filter: add tests for deltabase
ref-filter: add docs for new options
Orgad Shaneh (2):
t5403: simplify by using a single repository
rebase: run post-checkout hook on checkout
Patrick Hogg (2):
pack-objects: move read mutex to packing_data struct
pack-objects: merge read_lock and lock in packing_data struct
Peter Osterlund (1):
git-p4: fix problem when p4 login is not necessary
Phillip Wood (11):
diff: document --no-color-moved
Use "whitespace" consistently
diff: allow --no-color-moved-ws
diff --color-moved-ws: demonstrate false positives
diff --color-moved-ws: fix false positives
diff --color-moved=zebra: be stricter with color alternation
diff --color-moved-ws: optimize allow-indentation-change
diff --color-moved-ws: modify allow-indentation-change
diff --color-moved-ws: handle blank lines
implicit interactive rebase: don't run sequence editor
rebase -x: sanity check command
Pranit Bauva (7):
bisect--helper: `bisect_reset` shell function in C
bisect--helper: `bisect_write` shell function in C
wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
bisect--helper: `check_and_set_terms` shell function in C
bisect--helper: `bisect_next_check` shell function in C
bisect--helper: `get_terms` & `bisect_terms` shell function in C
bisect--helper: `bisect_start` shell function partially in C
Ramsay Jones (2):
config.mak.uname: remove obsolete SPARSE_FLAGS setting
Makefile: improve SPARSE_FLAGS customisation
Randall S. Becker (4):
transport-helper: use xread instead of read
config.mak.uname: support for modern HPE NonStop config.
git-compat-util.h: add FLOSS headers for HPE NonStop
compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
René Scharfe (5):
sha1-file: close fd of empty file in map_sha1_file_1()
object-store: factor out odb_loose_cache()
object-store: factor out odb_clear_loose_cache()
object-store: use one oid_array per subdirectory for loose cache
object-store: retire odb_load_loose_cache()
SZEDER Gábor (22):
clone: use a more appropriate variable name for the default refspec
clone: respect additional configured fetch refspecs during initial fetch
Documentation/clone: document ignored configuration variables
test-lib: check Bash version for '-x' without using shell arrays
test-lib: translate SIGTERM and SIGHUP to an exit
test-lib: extract Bash version check for '-x' tracing
test-lib: parse options in a for loop to keep $@ intact
test-lib: parse command line options earlier
test-lib: consolidate naming of test-results paths
test-lib: set $TRASH_DIRECTORY earlier
test-lib-functions: introduce the 'test_set_port' helper function
test-lib: add the '--stress' option to run a test repeatedly under load
compat/obstack: fix -Wcast-function-type warnings
.gitignore: ignore external debug symbols from GCC on macOS
travis-ci: don't be '--quiet' when running the tests
travis-ci: switch to Xcode 10.1 macOS image
travis-ci: build with the right compiler
commit-graph: rename "large edges" to "extra edges"
commit-graph: don't call write_graph_chunk_extra_edges() unnecessarily
strbuf.cocci: suggest strbuf_addbuf() to add one strbuf to an other
object_as_type: initialize commit-graph-related fields of 'struct commit'
travis-ci: make the OSX build jobs' 'brew update' more quiet
Sebastian Staudt (2):
describe: setup working tree for --dirty
t6120: test for describe with a bare repository
Sergey Organov (4):
t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
cherry-pick: do not error on non-merge commits when '-m 1' is specified
t3502: validate '-m 1' argument is now accepted for non-merge commits
t3506: validate '-m 1 -ff' is now accepted for non-merge commits
Shahzad Lone (1):
various: tighten constness of some local variables
Slavica Djukic (1):
stash: tolerate missing user identity
Stefan Beller (39):
sha1_file: allow read_object to read objects in arbitrary repositories
packfile: allow has_packed_and_bad to handle arbitrary repositories
diff: align move detection error handling with other options
object-store: allow read_object_file_extended to read from any repo
object-store: prepare read_object_file to deal with any repo
object-store: prepare has_{sha1, object}_file to handle any repo
object: parse_object to honor its repository argument
commit: allow parse_commit* to handle any repo
commit-reach.c: allow paint_down_to_common to handle any repo
commit-reach.c: allow merge_bases_many to handle any repo
commit-reach.c: allow remove_redundant to handle any repo
commit-reach.c: allow get_merge_bases_many_0 to handle any repo
commit-reach: prepare get_merge_bases to handle any repo
commit-reach: prepare in_merge_bases[_many] to handle any repo
commit: prepare get_commit_buffer to handle any repo
commit: prepare repo_unuse_commit_buffer to handle any repo
commit: prepare logmsg_reencode to handle arbitrary repositories
pretty: prepare format_commit_message to handle arbitrary repositories
sideband: color lines with keyword only
sha1-array: provide oid_array_filter
submodule.c: fix indentation
submodule.c: sort changed_submodule_names before searching it
submodule.c: tighten scope of changed_submodule_names struct
submodule: store OIDs in changed_submodule_names
repository: repo_submodule_init to take a submodule struct
submodule: migrate get_next_submodule to use repository structs
submodule.c: fetch in submodules git directory instead of in worktree
fetch: ensure submodule objects fetched
submodule update: add regression test with old style setups
submodule: unset core.worktree if no working tree is present
submodule--helper: fix BUG message in ensure_core_worktree
submodule deinit: unset core.worktree
submodule: use submodule repos for object lookup
submodule: don't add submodule as odb for push
commit-graph: convert remaining functions to handle any repo
commit: prepare free_commit_buffer and release_commit_memory for any repo
path.h: make REPO_GIT_PATH_FUNC repository agnostic
t/helper/test-repository: celebrate independence from the_repository
git-submodule: abort if core.worktree could not be set correctly
Stephen P. Smith (4):
Replace the proposed 'auto' mode with 'auto:'
Add 'human' date format documentation
Add `human` format to test-tool
Add `human` date format tests.
Sven van Haastregt (1):
git-submodule.sh: shorten submodule SHA-1s using rev-parse
Thomas Braun (1):
log -G: ignore binary files
Thomas Gummerer (3):
t5570: drop racy test
Revert "t/lib-git-daemon: record daemon log"
config.mak.dev: add -Wall, primarily for -Wformat, to help autoconf users
Torsten Bögershausen (3):
git clone <url> C:\cygwin\home\USER\repo' is working (again)
test-lint: only use only sed [-n] [-e command] [-f command_file]
Support working-tree-encoding "UTF-16LE-BOM"
brian m. carlson (19):
sha1-file: rename algorithm to "sha1"
sha1-file: provide functions to look up hash algorithms
hex: introduce functions to print arbitrary hashes
cache: make hashcmp and hasheq work with larger hashes
t: add basic tests for our SHA-1 implementation
t: make the sha1 test-tool helper generic
sha1-file: add a constant for hash block size
t/helper: add a test helper to compute hash speed
commit-graph: convert to using the_hash_algo
Add a base implementation of SHA-256 support
sha256: add an SHA-256 implementation using libgcrypt
hash: add an SHA-256 implementation using OpenSSL
tree-walk: copy object ID before use
match-trees: compute buffer offset correctly when splicing
match-trees: use hashcpy to splice trees
tree-walk: store object_id in a separate member
cache: make oidcpy always copy GIT_MAX_RAWSZ bytes
fetch-pack: clear alternate shallow when complete
fetch-pack: clear alternate shallow in one more place
Ævar Arnfjörð Bjarmason (17):
remote.c: add braces in anticipation of a follow-up change
i18n: remote.c: mark error(...) messages for translation
push: improve the error shown on unqualified <dst> push
push: move unqualified refname error into a function
push: add an advice on unqualified <dst> push
push: test that <src> doesn't DWYM if <dst> is unqualified
push doc: document the DWYM behavior pushing to unqualified <dst>
commit-graph: split up close_reachable() progress output
commit-graph write: use pack order when finding commits
commit-graph write: add "Writing out" progress output
commit-graph write: more descriptive "writing out" output
commit-graph write: show progress for object search
commit-graph write: add more descriptive progress output
commit-graph write: remove empty line for readability
commit-graph write: add itermediate progress
commit-graph write: emit a percentage for all progress
diff-tree doc: correct & remove wrong documentation
^ permalink raw reply [relevance 1%]
* [PATCH (Apple Git) 00/13] Differences between git-2.20.1 and Apple Git-116
@ 2019-01-29 19:38 6% Jeremy Huddleston Sequoia
0 siblings, 0 replies; 69+ results
From: Jeremy Huddleston Sequoia @ 2019-01-29 19:38 UTC (permalink / raw)
To: git; +Cc: peff
Xcode 10.2 Beta 1 contains Apple Git-116. A couple months ago, Peff encouraged
me to re-send our changes in a patch series to the mailing list, so here they
are!
As reference, these (and past patch series for Apple Git) are availale at:
https://github.com/jeremyhu/git
Some of these patches are upstreamable as is, but othes represent areas where
customization options could be provided upstream to allow similar behavior.
Note that I am very grateful for the recent changes in mainline to support
RUNTIME_PREFIX on darwin. It almost completely replaced our RUNTIME_PREFIX
implementation and made the few remaining changes much more maintainale.
Please integrate the changes that are upstreamable and let's use the others
as a starting point for discussing how to accomplish the same effect through
configuration options or other means.
Thanks,
Jeremy
^ permalink raw reply [relevance 6%]
* Re: unclear docs
2019-01-28 16:09 0% ` Jeff King
@ 2019-01-28 18:12 0% ` Sergey Lukashev
0 siblings, 0 replies; 69+ results
From: Sergey Lukashev @ 2019-01-28 18:12 UTC (permalink / raw)
To: Jeff King; +Cc: git@vger.kernel.org
Thank you. Does the paragraph about core.eol refers to the text attribute? It's written 'property' there. I was thinking it means whether git thinks file is text, using .gitattributes OR otherwise. Maybe changing this word will make it clearer?
28.01.2019, 19:09, "Jeff King" <peff@peff.net>:
> On Sun, Jan 27, 2019 at 02:55:23PM +0300, Sergey Lukashev wrote:
>
>> Well, I have two problems:
>> 1) The endings I get with core.autocrlf=false depend on whether I have
>> * text=auto (a file was commited with LFs). At least in git 2.20.1
>
> That sounds right. The default is that Git will never touch your line
> endings (going into or out of the working tree). Turning on the
> "text=auto" attribute for everything will tell it to start doing so
> (according to core.eol, which on Windows is CRLF).
>
>> 2) If the quote holds true then autocrlf=false is actually "true" (for
>> output conversion) on Windows by default because default core.eol
>> is 'native', which is CRLF. I believe autocrlf=false is supposed to
>> mean "no any conversion, input or output, read or write the repo as
>> is".
>
> No, it only means "do not use the autocrlf feature". If you've
> separately configured text attributes, it does not disable them.
>
> -Peff
^ permalink raw reply [relevance 0%]
* Re: unclear docs
2019-01-27 11:55 4% ` Sergey Lukashev
2019-01-28 16:09 0% ` Jeff King
@ 2019-01-28 17:31 0% ` Torsten Bögershausen
1 sibling, 0 replies; 69+ results
From: Torsten Bögershausen @ 2019-01-28 17:31 UTC (permalink / raw)
To: Sergey Lukashev; +Cc: git@vger.kernel.org
On Sun, Jan 27, 2019 at 02:55:23PM +0300, Sergey Lukashev wrote:
> A follow up on my previous mail.
>
> Well, I have two problems:
> 1) The endings I get with core.autocrlf=false depend on whether I have * text=auto (a file was commited with LFs). At least in git 2.20.1
> 2) If the quote holds true then autocrlf=false is actually "true" (for output conversion) on Windows by default because default core.eol is 'native', which is CRLF. I believe autocrlf=false is supposed to mean "no any conversion, input or output, read or write the repo as is".
>
> 27.01.2019, 13:05, "Sergey Lukashev" <lukashev.s@ya.ru>:
> > Hello!
> >
> > Could somebody please explain what 'core.autocrlf overrides core.eol' means given that we have the following statement in core.eol docs:
> > "Sets the line ending type to use in the working directory for files that have the text property set when core.autocrlf is false".
> >
> > I would like to know which line endings I'm supposed to get in the working tree if I have core.autocrlf=false and '* text=auto' in .gitattributes on windows. I get CRLFs which is consistent with the last quote but I don't understand what 'core.autocrlf overrides core.eol' means in this case.
> >
> > Links:
> > https://git-scm.com/docs/git-config#git-config-coreeol
> > https://git-scm.com/docs/gitattributes#_checking_out_and_checking_in
Given your .gitattributes file, you will get:
core.autocrlf=false core.eol=CRLF gives CRLF
core.autocrlf=false core.eol=LF gives LF
core.autocrlf=false core.eol=native gives CRLF under Windows, LF everywhere else
core.autocrlf=true gives CRLF (regardless of core.eol)
Does this help ?
^ permalink raw reply [relevance 0%]
* Re: unclear docs
2019-01-27 11:55 4% ` Sergey Lukashev
@ 2019-01-28 16:09 0% ` Jeff King
2019-01-28 18:12 0% ` Sergey Lukashev
2019-01-28 17:31 0% ` Torsten Bögershausen
1 sibling, 1 reply; 69+ results
From: Jeff King @ 2019-01-28 16:09 UTC (permalink / raw)
To: Sergey Lukashev; +Cc: git@vger.kernel.org
On Sun, Jan 27, 2019 at 02:55:23PM +0300, Sergey Lukashev wrote:
> Well, I have two problems:
> 1) The endings I get with core.autocrlf=false depend on whether I have
> * text=auto (a file was commited with LFs). At least in git 2.20.1
That sounds right. The default is that Git will never touch your line
endings (going into or out of the working tree). Turning on the
"text=auto" attribute for everything will tell it to start doing so
(according to core.eol, which on Windows is CRLF).
> 2) If the quote holds true then autocrlf=false is actually "true" (for
> output conversion) on Windows by default because default core.eol
> is 'native', which is CRLF. I believe autocrlf=false is supposed to
> mean "no any conversion, input or output, read or write the repo as
> is".
No, it only means "do not use the autocrlf feature". If you've
separately configured text attributes, it does not disable them.
-Peff
^ permalink raw reply [relevance 0%]
* Re: unclear docs
@ 2019-01-27 11:55 4% ` Sergey Lukashev
2019-01-28 16:09 0% ` Jeff King
2019-01-28 17:31 0% ` Torsten Bögershausen
0 siblings, 2 replies; 69+ results
From: Sergey Lukashev @ 2019-01-27 11:55 UTC (permalink / raw)
To: git@vger.kernel.org
A follow up on my previous mail.
Well, I have two problems:
1) The endings I get with core.autocrlf=false depend on whether I have * text=auto (a file was commited with LFs). At least in git 2.20.1
2) If the quote holds true then autocrlf=false is actually "true" (for output conversion) on Windows by default because default core.eol is 'native', which is CRLF. I believe autocrlf=false is supposed to mean "no any conversion, input or output, read or write the repo as is".
27.01.2019, 13:05, "Sergey Lukashev" <lukashev.s@ya.ru>:
> Hello!
>
> Could somebody please explain what 'core.autocrlf overrides core.eol' means given that we have the following statement in core.eol docs:
> "Sets the line ending type to use in the working directory for files that have the text property set when core.autocrlf is false".
>
> I would like to know which line endings I'm supposed to get in the working tree if I have core.autocrlf=false and '* text=auto' in .gitattributes on windows. I get CRLFs which is consistent with the last quote but I don't understand what 'core.autocrlf overrides core.eol' means in this case.
>
> Links:
> https://git-scm.com/docs/git-config#git-config-coreeol
> https://git-scm.com/docs/gitattributes#_checking_out_and_checking_in
^ permalink raw reply [relevance 4%]
* Re: Broken interactive rebase text after some UTF-8 characters
2019-01-16 21:36 0% ` Michal Nowak
@ 2019-01-17 11:04 0% ` Phillip Wood
0 siblings, 0 replies; 69+ results
From: Phillip Wood @ 2019-01-17 11:04 UTC (permalink / raw)
To: Michal Nowak, phillip.wood, git
Hi Michal
On 16/01/2019 21:36, Michal Nowak wrote:
> Hello Phillip, thanks for reaching out.
>
> This is what I see with your suggested command:
>
>
> $ GIT_SEQUENCE_EDITOR=cat git rebase -i
> 08487eea68a2fa501b5042131c6db068089f82e1
> hint: Waiting for your editor to close the file... pick 1ea94c756c 10202
> loader: use screen-#rows to find bottom left co-ordinates Reviewed by:
> Toomas Soome <tsoome@me.com> Reviewed by: Gergő Mihály Doma
> <domag02@gmail.com> Approved by: Robert Mustacchi <rm@joyent.com>
> p
That's really weird, I'm not sure what's going on. One thing that would
be useful would be to check whether the output of
git log --pretty='%s' --reverse 08487eea68a2fa5..
includes the stray 'p' or not. I had a look through the configure output
you attached to your previous mail and it seems you're building without
iconv and gettext support, I've built git on linux with
make NO_ICONV=1 NO_GETTEXT=1
to try and test that and the rebase todo list was fine. Building with
configure rather than the Makefile that comes with git can be a bit
flaky sometimes as occasionally when a new compile option gets added to
the Makefile updating the configure script gets overlooked but I don't
know if that is the problem here or not.
Best Wishes
Phillip
> pick cadd68ea00 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by: Robert
> Mustacchi <rm@joyent.com>
> pick 05ede3db5e 10079 smatch Makefile changes for usr/src/lib Reviewed
> by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
> <rm@joyent.com>
> pick 5661bb7641 10080 smatch Makefile changes for usr/src/cmd Reviewed
> by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
> <rm@joyent.com>
> pick 15c07adc1c 10081 smatch indenting fixes for usr/src/uts Reviewed
> by: Toomas Soome <tsoome@me.com> Reviewed by: Peter Tribble
> <peter.tribble@gmail.com> Reviewed by: Andy Fiddaman <andy@omniosce.org>
> Approved by: Robert Mustacchi <rm@joyent.com>
> pick c653bb4713 10197 build smatch in parallel Reviewed by: Andy
> Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi <rm@joyent.com>
>
> # Rebase 08487eea68..c653bb4713 onto 08487eea68 (6 commands)
> #
> # Commands:
> # p, pick <commit> = use commit
> # r, reword <commit> = use commit, but edit the commit message
> # e, edit <commit> = use commit, but stop for amending
> # s, squash <commit> = use commit, but meld into previous commit
> # f, fixup <commit> = like "squash", but discard this commit's log message
> # x, exec <command> = run command (the rest of the line) using shell
> # b, break = stop here (continue rebase later with 'git rebase --continue')
> # d, drop <commit> = remove commit
> # l, label <label> = label current HEAD with a name
> # t, reset <label> = reset HEAD to a label
> # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
> # . create a merge commit using the original merge commit's
> # . message (or the oneline, if no original merge commit was
> # . specified). Use -c <commit> to reword the commit message.
> #
> # These lines can be re-ordered; they are executed from top to bottom.
> #
> # If you remove a line here THAT COMMIT WILL BE LOST.
> #
> # However, if you remove everything, the rebase will be aborted.
> #
> # Note that empty commits are commented out
> error: missing arguments for pick
> error: invalid line 2: p
> You can fix this with 'git rebase --edit-todo' and then run 'git rebase
> --continue'.
> Or you can abort the rebase with 'git rebase --abort'.
>
>
> Let me know, if there's anything I can try myself to gather more
> information. Should you want to reproduce this on OpenIndiana on your
> own, Vagrant is the more straightforward way to deploy OpenIndiana.
>
> Thanks,
> Michal
>
> On 01/16/19 11:33 AM, Phillip Wood wrote:
>> Dear Michal
>>
>> Thanks for the bug report, unfortunately I'm unable to reproduce it
>> here using git 2.20.1 (see below). Knowing a little about how the todo
>> list is created I cannot think how multibyte characters would break
>> it. What command line were you using to start the rebase?
>>
>> Best Wishes
>>
>> Phillip
>>
>> $ git clone --shallow-since='11-1-2019'
>> https://github.com/illumos/illumos-gate.git
>> Cloning into 'illumos-gate'...
>> remote: Enumerating objects: 54348, done.
>> remote: Counting objects: 100% (54348/54348), done.
>> remote: Compressing objects: 100% (39008/39008), done.
>> remote: Total 54348 (delta 19671), reused 31187 (delta 11884),
>> pack-reused 0
>> Receiving objects: 100% (54348/54348), 148.91 MiB | 1.18 MiB/s, done.
>> Resolving deltas: 100% (19671/19671), done.
>> Checking out files: 100% (47352/47352), done.
>>
>> $ cd ~/src/illumos-gate
>> $ git log --oneline -1
>> f482e26c (HEAD -> master, origin/master, origin/HEAD) 10233 dboot:
>> process_module() is missing newline at the end of the string Reviewed
>> by: Sebastian Wiedenroth <wiedi@frubar.net> Reviewed by: Jason King
>> <jbk@joyent.com> Reviewed by: Andy Stormont
>> <astormont@racktopsystems.com> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>>
>> $ GIT_SEQUENCE_EDITOR=cat git rebase -i
>> 08487eea68a2fa501b5042131c6db068089f82e1
>>
>> hint: Waiting for your editor to close the file...
>> pick 1ea94c75 10202 loader: use screen-#rows to find bottom left
>> co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
>> Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>> pick cadd68ea 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
>> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
>> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by:
>> Robert Mustacchi <rm@joyent.com>
>> pick 05ede3db 10079 smatch Makefile changes for usr/src/lib Reviewed
>> by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>> pick 5661bb76 10080 smatch Makefile changes for usr/src/cmd Reviewed
>> by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>> pick 15c07adc 10081 smatch indenting fixes for usr/src/uts Reviewed
>> by: Toomas Soome <tsoome@me.com> Reviewed by: Peter Tribble
>> <peter.tribble@gmail.com> Reviewed by: Andy Fiddaman
>> <andy@omniosce.org> Approved by: Robert Mustacchi <rm@joyent.com>
>> pick c653bb47 10197 build smatch in parallel Reviewed by: Andy
>> Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>> pick 161294fe 10217 mdb: r9w isn't r8w 10218 CONV_CAP_VAL_HW2_BUFSIZE
>> wasn't updated 10219 AV_386_2_AVX512VPOPCDQ elfcap name should be
>> consistent Reviewed by: Dan McDonald <danmcd@joyent.com> Reviewed by:
>> Rob Johnston <rob.johnston@joyent.com> Reviewed by: Patrick Mooney
>> <patrick.mooney@joyent.com> Reviewed by: Andy Fiddaman
>> <andy@omniosce.org> Approved by: Dan McDonald <danmcd@joyent.com>
>> pick f482e26c 10233 dboot: process_module() is missing newline at the
>> end of the string Reviewed by: Sebastian Wiedenroth <wiedi@frubar.net>
>> Reviewed by: Jason King <jbk@joyent.com> Reviewed by: Andy Stormont
>> <astormont@racktopsystems.com> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>>
>> # Rebase 08487eea..f482e26c onto 08487eea (8 commands)
>> #
>> # Commands:
>> # p, pick <commit> = use commit
>> # r, reword <commit> = use commit, but edit the commit message
>> # e, edit <commit> = use commit, but stop for amending
>> # s, squash <commit> = use commit, but meld into previous commit
>> # f, fixup <commit> = like "squash", but discard this commit's log
>> message
>> # x, exec <command> = run command (the rest of the line) using shell
>> # b, break = stop here (continue rebase later with 'git rebase
>> --continue')
>> # d, drop <commit> = remove commit
>> # l, label <label> = label current HEAD with a name
>> # t, reset <label> = reset HEAD to a label
>> # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
>> # . create a merge commit using the original merge commit's
>> # . message (or the oneline, if no original merge commit was
>> # . specified). Use -c <commit> to reword the commit message.
>> #
>> # These lines can be re-ordered; they are executed from top to bottom.
>> #
>> # If you remove a line here THAT COMMIT WILL BE LOST.
>> #
>> # However, if you remove everything, the rebase will be aborted.
>> #
>> # Note that empty commits are commented out
>> Successfully rebased and updated refs/heads/master.
>>
>>
>> On 15/01/2019 19:29, Michal Nowak wrote:
>>> Hello,
>>>
>>> on OpenIndiana 2018.10 (illumos kernel) line of the interactive
>>> rebase text after a particular name (Gergő Mihály Doma) is broken:
>>>
>>> pick 1ea94c756c 10202 loader: use screen-#rows to find bottom left
>>> co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
>>> Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
>>> <rm@joyent.com>
>>> p
>>> pick cadd68ea00 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
>>> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
>>> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by:
>>> Robert Mustacchi <rm@joyent.com>
>>>
>>>
>>> Source: https://github.com/illumos/illumos-gate.git
>>>
>>> See the second item which only has "p".
>>>
>>> This is with LC_ALL=en_US.UTF-8 (same with cs_CZ.UTF-8), with
>>> LC_ALL=C the text is fine.
>>>
>>> I checked various editors (vim, nano, cat), they are all the same.
>>>
>>> `git log` (PAGER is set to `/usr/bin/less -ins`) shows the particular
>>> commit correctly.
>>>
>>> I tested following git version: 2.16.5, 2.19.2, 2.20.1, git.next branch.
>>>
>>> Here's the configure output:
>>> https://paste.ec/paste/oDdydNxZ#r3avan8BL+8lldFMo928cw3eXSServTsSkGPW4jRBOd
>>>
>>>
>>> Michal
>>>
>>
^ permalink raw reply [relevance 0%]
* Re: Broken interactive rebase text after some UTF-8 characters
2019-01-16 10:33 3% ` Phillip Wood
@ 2019-01-16 21:36 0% ` Michal Nowak
2019-01-17 11:04 0% ` Phillip Wood
0 siblings, 1 reply; 69+ results
From: Michal Nowak @ 2019-01-16 21:36 UTC (permalink / raw)
To: phillip.wood, git
Hello Phillip, thanks for reaching out.
This is what I see with your suggested command:
$ GIT_SEQUENCE_EDITOR=cat git rebase -i
08487eea68a2fa501b5042131c6db068089f82e1
hint: Waiting for your editor to close the file... pick 1ea94c756c 10202
loader: use screen-#rows to find bottom left co-ordinates Reviewed by:
Toomas Soome <tsoome@me.com> Reviewed by: Gergő Mihály Doma
<domag02@gmail.com> Approved by: Robert Mustacchi <rm@joyent.com>
p
pick cadd68ea00 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
<omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by: Robert
Mustacchi <rm@joyent.com>
pick 05ede3db5e 10079 smatch Makefile changes for usr/src/lib Reviewed
by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
<rm@joyent.com>
pick 5661bb7641 10080 smatch Makefile changes for usr/src/cmd Reviewed
by: Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
<rm@joyent.com>
pick 15c07adc1c 10081 smatch indenting fixes for usr/src/uts Reviewed
by: Toomas Soome <tsoome@me.com> Reviewed by: Peter Tribble
<peter.tribble@gmail.com> Reviewed by: Andy Fiddaman <andy@omniosce.org>
Approved by: Robert Mustacchi <rm@joyent.com>
pick c653bb4713 10197 build smatch in parallel Reviewed by: Andy
Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi <rm@joyent.com>
# Rebase 08487eea68..c653bb4713 onto 08487eea68 (6 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
error: missing arguments for pick
error: invalid line 2: p
You can fix this with 'git rebase --edit-todo' and then run 'git rebase
--continue'.
Or you can abort the rebase with 'git rebase --abort'.
Let me know, if there's anything I can try myself to gather more
information. Should you want to reproduce this on OpenIndiana on your
own, Vagrant is the more straightforward way to deploy OpenIndiana.
Thanks,
Michal
On 01/16/19 11:33 AM, Phillip Wood wrote:
> Dear Michal
>
> Thanks for the bug report, unfortunately I'm unable to reproduce it here
> using git 2.20.1 (see below). Knowing a little about how the todo list
> is created I cannot think how multibyte characters would break it. What
> command line were you using to start the rebase?
>
> Best Wishes
>
> Phillip
>
> $ git clone --shallow-since='11-1-2019'
> https://github.com/illumos/illumos-gate.git
> Cloning into 'illumos-gate'...
> remote: Enumerating objects: 54348, done.
> remote: Counting objects: 100% (54348/54348), done.
> remote: Compressing objects: 100% (39008/39008), done.
> remote: Total 54348 (delta 19671), reused 31187 (delta 11884),
> pack-reused 0
> Receiving objects: 100% (54348/54348), 148.91 MiB | 1.18 MiB/s, done.
> Resolving deltas: 100% (19671/19671), done.
> Checking out files: 100% (47352/47352), done.
>
> $ cd ~/src/illumos-gate
> $ git log --oneline -1
> f482e26c (HEAD -> master, origin/master, origin/HEAD) 10233 dboot:
> process_module() is missing newline at the end of the string Reviewed
> by: Sebastian Wiedenroth <wiedi@frubar.net> Reviewed by: Jason King
> <jbk@joyent.com> Reviewed by: Andy Stormont
> <astormont@racktopsystems.com> Approved by: Robert Mustacchi
> <rm@joyent.com>
>
> $ GIT_SEQUENCE_EDITOR=cat git rebase -i
> 08487eea68a2fa501b5042131c6db068089f82e1
>
> hint: Waiting for your editor to close the file...
> pick 1ea94c75 10202 loader: use screen-#rows to find bottom left
> co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
> Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
> <rm@joyent.com>
> pick cadd68ea 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by: Robert
> Mustacchi <rm@joyent.com>
> pick 05ede3db 10079 smatch Makefile changes for usr/src/lib Reviewed by:
> Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
> <rm@joyent.com>
> pick 5661bb76 10080 smatch Makefile changes for usr/src/cmd Reviewed by:
> Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
> <rm@joyent.com>
> pick 15c07adc 10081 smatch indenting fixes for usr/src/uts Reviewed by:
> Toomas Soome <tsoome@me.com> Reviewed by: Peter Tribble
> <peter.tribble@gmail.com> Reviewed by: Andy Fiddaman <andy@omniosce.org>
> Approved by: Robert Mustacchi <rm@joyent.com>
> pick c653bb47 10197 build smatch in parallel Reviewed by: Andy Fiddaman
> <andy@omniosce.org> Approved by: Robert Mustacchi <rm@joyent.com>
> pick 161294fe 10217 mdb: r9w isn't r8w 10218 CONV_CAP_VAL_HW2_BUFSIZE
> wasn't updated 10219 AV_386_2_AVX512VPOPCDQ elfcap name should be
> consistent Reviewed by: Dan McDonald <danmcd@joyent.com> Reviewed by:
> Rob Johnston <rob.johnston@joyent.com> Reviewed by: Patrick Mooney
> <patrick.mooney@joyent.com> Reviewed by: Andy Fiddaman
> <andy@omniosce.org> Approved by: Dan McDonald <danmcd@joyent.com>
> pick f482e26c 10233 dboot: process_module() is missing newline at the
> end of the string Reviewed by: Sebastian Wiedenroth <wiedi@frubar.net>
> Reviewed by: Jason King <jbk@joyent.com> Reviewed by: Andy Stormont
> <astormont@racktopsystems.com> Approved by: Robert Mustacchi
> <rm@joyent.com>
>
> # Rebase 08487eea..f482e26c onto 08487eea (8 commands)
> #
> # Commands:
> # p, pick <commit> = use commit
> # r, reword <commit> = use commit, but edit the commit message
> # e, edit <commit> = use commit, but stop for amending
> # s, squash <commit> = use commit, but meld into previous commit
> # f, fixup <commit> = like "squash", but discard this commit's log message
> # x, exec <command> = run command (the rest of the line) using shell
> # b, break = stop here (continue rebase later with 'git rebase --continue')
> # d, drop <commit> = remove commit
> # l, label <label> = label current HEAD with a name
> # t, reset <label> = reset HEAD to a label
> # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
> # . create a merge commit using the original merge commit's
> # . message (or the oneline, if no original merge commit was
> # . specified). Use -c <commit> to reword the commit message.
> #
> # These lines can be re-ordered; they are executed from top to bottom.
> #
> # If you remove a line here THAT COMMIT WILL BE LOST.
> #
> # However, if you remove everything, the rebase will be aborted.
> #
> # Note that empty commits are commented out
> Successfully rebased and updated refs/heads/master.
>
>
> On 15/01/2019 19:29, Michal Nowak wrote:
>> Hello,
>>
>> on OpenIndiana 2018.10 (illumos kernel) line of the interactive rebase
>> text after a particular name (Gergő Mihály Doma) is broken:
>>
>> pick 1ea94c756c 10202 loader: use screen-#rows to find bottom left
>> co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
>> Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
>> <rm@joyent.com>
>> p
>> pick cadd68ea00 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
>> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
>> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by:
>> Robert Mustacchi <rm@joyent.com>
>>
>>
>> Source: https://github.com/illumos/illumos-gate.git
>>
>> See the second item which only has "p".
>>
>> This is with LC_ALL=en_US.UTF-8 (same with cs_CZ.UTF-8), with LC_ALL=C
>> the text is fine.
>>
>> I checked various editors (vim, nano, cat), they are all the same.
>>
>> `git log` (PAGER is set to `/usr/bin/less -ins`) shows the particular
>> commit correctly.
>>
>> I tested following git version: 2.16.5, 2.19.2, 2.20.1, git.next branch.
>>
>> Here's the configure output:
>> https://paste.ec/paste/oDdydNxZ#r3avan8BL+8lldFMo928cw3eXSServTsSkGPW4jRBOd
>>
>>
>> Michal
>>
>
^ permalink raw reply [relevance 0%]
* Re: Broken interactive rebase text after some UTF-8 characters
@ 2019-01-16 10:33 3% ` Phillip Wood
2019-01-16 21:36 0% ` Michal Nowak
0 siblings, 1 reply; 69+ results
From: Phillip Wood @ 2019-01-16 10:33 UTC (permalink / raw)
To: Michal Nowak, git
Dear Michal
Thanks for the bug report, unfortunately I'm unable to reproduce it here
using git 2.20.1 (see below). Knowing a little about how the todo list
is created I cannot think how multibyte characters would break it. What
command line were you using to start the rebase?
Best Wishes
Phillip
$ git clone --shallow-since='11-1-2019'
https://github.com/illumos/illumos-gate.git
Cloning into 'illumos-gate'...
remote: Enumerating objects: 54348, done.
remote: Counting objects: 100% (54348/54348), done.
remote: Compressing objects: 100% (39008/39008), done.
remote: Total 54348 (delta 19671), reused 31187 (delta 11884), pack-reused 0
Receiving objects: 100% (54348/54348), 148.91 MiB | 1.18 MiB/s, done.
Resolving deltas: 100% (19671/19671), done.
Checking out files: 100% (47352/47352), done.
$ cd ~/src/illumos-gate
$ git log --oneline -1
f482e26c (HEAD -> master, origin/master, origin/HEAD) 10233 dboot:
process_module() is missing newline at the end of the string Reviewed
by: Sebastian Wiedenroth <wiedi@frubar.net> Reviewed by: Jason King
<jbk@joyent.com> Reviewed by: Andy Stormont
<astormont@racktopsystems.com> Approved by: Robert Mustacchi <rm@joyent.com>
$ GIT_SEQUENCE_EDITOR=cat git rebase -i
08487eea68a2fa501b5042131c6db068089f82e1
hint: Waiting for your editor to close the file...
pick 1ea94c75 10202 loader: use screen-#rows to find bottom left
co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
<rm@joyent.com>
pick cadd68ea 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
<omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by: Robert
Mustacchi <rm@joyent.com>
pick 05ede3db 10079 smatch Makefile changes for usr/src/lib Reviewed by:
Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
<rm@joyent.com>
pick 5661bb76 10080 smatch Makefile changes for usr/src/cmd Reviewed by:
Andy Fiddaman <andy@omniosce.org> Approved by: Robert Mustacchi
<rm@joyent.com>
pick 15c07adc 10081 smatch indenting fixes for usr/src/uts Reviewed by:
Toomas Soome <tsoome@me.com> Reviewed by: Peter Tribble
<peter.tribble@gmail.com> Reviewed by: Andy Fiddaman <andy@omniosce.org>
Approved by: Robert Mustacchi <rm@joyent.com>
pick c653bb47 10197 build smatch in parallel Reviewed by: Andy Fiddaman
<andy@omniosce.org> Approved by: Robert Mustacchi <rm@joyent.com>
pick 161294fe 10217 mdb: r9w isn't r8w 10218 CONV_CAP_VAL_HW2_BUFSIZE
wasn't updated 10219 AV_386_2_AVX512VPOPCDQ elfcap name should be
consistent Reviewed by: Dan McDonald <danmcd@joyent.com> Reviewed by:
Rob Johnston <rob.johnston@joyent.com> Reviewed by: Patrick Mooney
<patrick.mooney@joyent.com> Reviewed by: Andy Fiddaman
<andy@omniosce.org> Approved by: Dan McDonald <danmcd@joyent.com>
pick f482e26c 10233 dboot: process_module() is missing newline at the
end of the string Reviewed by: Sebastian Wiedenroth <wiedi@frubar.net>
Reviewed by: Jason King <jbk@joyent.com> Reviewed by: Andy Stormont
<astormont@racktopsystems.com> Approved by: Robert Mustacchi <rm@joyent.com>
# Rebase 08487eea..f482e26c onto 08487eea (8 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
Successfully rebased and updated refs/heads/master.
On 15/01/2019 19:29, Michal Nowak wrote:
> Hello,
>
> on OpenIndiana 2018.10 (illumos kernel) line of the interactive rebase
> text after a particular name (Gergő Mihály Doma) is broken:
>
> pick 1ea94c756c 10202 loader: use screen-#rows to find bottom left
> co-ordinates Reviewed by: Toomas Soome <tsoome@me.com> Reviewed by:
> Gergő Mihály Doma <domag02@gmail.com> Approved by: Robert Mustacchi
> <rm@joyent.com>
> p
> pick cadd68ea00 10078 smatch fixes for UCB Reviewed by: Andy Fiddaman
> <omnios@citrus-it.net> Reviewed by: Toomas Soome <tsoome@me.com>
> Reviewed by: Peter Tribble <peter.tribble@gmail.com> Approved by: Robert
> Mustacchi <rm@joyent.com>
>
>
> Source: https://github.com/illumos/illumos-gate.git
>
> See the second item which only has "p".
>
> This is with LC_ALL=en_US.UTF-8 (same with cs_CZ.UTF-8), with LC_ALL=C
> the text is fine.
>
> I checked various editors (vim, nano, cat), they are all the same.
>
> `git log` (PAGER is set to `/usr/bin/less -ins`) shows the particular
> commit correctly.
>
> I tested following git version: 2.16.5, 2.19.2, 2.20.1, git.next branch.
>
> Here's the configure output:
> https://paste.ec/paste/oDdydNxZ#r3avan8BL+8lldFMo928cw3eXSServTsSkGPW4jRBOd
>
> Michal
>
^ permalink raw reply [relevance 3%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-01-10 15:19 0% ` Johannes Schindelin
@ 2019-01-10 18:55 0% ` Bret Barkelew
2019-04-18 18:16 0% ` Bret Barkelew
0 siblings, 1 reply; 69+ results
From: Bret Barkelew @ 2019-01-10 18:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bryan Turner, git
On Thu, Jan 10, 2019 at 7:20 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Bret,
>
> in that case, please try to find a way to trace the commands in a Tcl/Tk
> program (which gitk is) and see which command triggers the error.
Er... that's a little out of my depth. I'll see if I can find time to learn.
Meanwhile, is there any way to request better instrumentation for the
error dialog so this data could have been collected for me?
>
> Ciao,
> Johannes
>
>
> On Wed, 9 Jan 2019, Bret Barkelew wrote:
>
> > Will try to reply in-line, when appropriate.
> > The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> > has the issue.
> >
> > - Bret
> >
> >
> > On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > Hi Bret,
> > >
> > >
> > > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> > >
> > > > They are the exact same path (with a different drive letter).
> > >
> > > [it's a bit hard to follow the thread if you top-post a reply to an
> > > inline-replied answer, maybe imitate the style of other mails in the
> > > future.]
> > >
> > > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > > and installed 2.19.0 on the failing system, and the older version of
> > > > Git works.
> > > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > > names in the Windows registry, which did not resolve the issue with
> > > > git 2.20.1.
> > > >
> > > > Happy to collect any additional data.
> > >
> > > Please try the latest snapshot at
> > > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > > might be fixed via
> > > https://github.com/git-for-windows/MINGW-packages/pull/32).
> > >
> > > Ciao,
> > > Johannes
> > >
> > > > - Bret
> > > >
> > > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > > >
> > > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > > >>
> > > > >> When I open gitk in a particular repository under this version of Git
> > > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > > >> "git": file name too long". I've noticed that the most pronounced
> > > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > > >> narrowed down the following things:
> > > > >>
> > > > >> - This does not happen with the same repo if I use a system that has
> > > > >> git 2.19.0.windows.1 on another machine.
> > > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > > >
> > > > >
> > > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > > >
> > > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > > >
> > > > >>
> > > > >> However, as soon as the remote updates with any changes on a given
> > > > >> fetch/pull, the repo is put in a bad state permanently.
> > > > >>
> > > > >> I've pasted the output from gitk below...
> > > > >>
> > > > >> couldn't execute "git": file name too long
> > > > >> couldn't execute "git": file name too long
> > > > >> while executing
> > > > >> "open $cmd r"
> > > > >> (procedure "getallcommits" line 48)
> > > > >> invoked from within
> > > > >> "getallcommits"
> > > > >> (procedure "readcache" line 80)
> > > > >> invoked from within
> > > > >> "readcache file827e200"
> > > > >> ("eval" body line 1)
> > > > >> invoked from within
> > > > >> "eval $script"
> > > > >> (procedure "dorunq" line 11)
> > > > >> invoked from within
> > > > >> "dorunq"
> > > > >> ("after" script)
> > > > >>
> > > > >> Happy to gather whatever data needed.
> > > > >> Thanks!
> > > > >> - Bret Barkelew
> > > >
> >
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-01-09 18:48 0% ` Bret Barkelew
@ 2019-01-10 15:19 0% ` Johannes Schindelin
2019-01-10 18:55 0% ` Bret Barkelew
0 siblings, 1 reply; 69+ results
From: Johannes Schindelin @ 2019-01-10 15:19 UTC (permalink / raw)
To: Bret Barkelew; +Cc: Bryan Turner, git
[-- Attachment #1: Type: text/plain, Size: 3685 bytes --]
Hi Bret,
in that case, please try to find a way to trace the commands in a Tcl/Tk
program (which gitk is) and see which command triggers the error.
Ciao,
Johannes
On Wed, 9 Jan 2019, Bret Barkelew wrote:
> Will try to reply in-line, when appropriate.
> The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
> has the issue.
>
> - Bret
>
>
> On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Hi Bret,
> >
> >
> > On Thu, 3 Jan 2019, Bret Barkelew wrote:
> >
> > > They are the exact same path (with a different drive letter).
> >
> > [it's a bit hard to follow the thread if you top-post a reply to an
> > inline-replied answer, maybe imitate the style of other mails in the
> > future.]
> >
> > > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > > and installed 2.19.0 on the failing system, and the older version of
> > > Git works.
> > > I've also tried a suggested fix I saw elsewhere to enable long path
> > > names in the Windows registry, which did not resolve the issue with
> > > git 2.20.1.
> > >
> > > Happy to collect any additional data.
> >
> > Please try the latest snapshot at
> > https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> > might be fixed via
> > https://github.com/git-for-windows/MINGW-packages/pull/32).
> >
> > Ciao,
> > Johannes
> >
> > > - Bret
> > >
> > > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > > >
> > > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > > >>
> > > >> When I open gitk in a particular repository under this version of Git
> > > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > > >> "git": file name too long". I've noticed that the most pronounced
> > > >> effect is that I cannot see the file diffs (or sometimes the file name
> > > >> list) for any of the commits. I don't know the exact repro, but I've
> > > >> narrowed down the following things:
> > > >>
> > > >> - This does not happen with the same repo if I use a system that has
> > > >> git 2.19.0.windows.1 on another machine.
> > > >> - This does not happen on my current machine in a freshly cloned repo.
> > > >
> > > >
> > > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > > >
> > > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > > >
> > > >>
> > > >> However, as soon as the remote updates with any changes on a given
> > > >> fetch/pull, the repo is put in a bad state permanently.
> > > >>
> > > >> I've pasted the output from gitk below...
> > > >>
> > > >> couldn't execute "git": file name too long
> > > >> couldn't execute "git": file name too long
> > > >> while executing
> > > >> "open $cmd r"
> > > >> (procedure "getallcommits" line 48)
> > > >> invoked from within
> > > >> "getallcommits"
> > > >> (procedure "readcache" line 80)
> > > >> invoked from within
> > > >> "readcache file827e200"
> > > >> ("eval" body line 1)
> > > >> invoked from within
> > > >> "eval $script"
> > > >> (procedure "dorunq" line 11)
> > > >> invoked from within
> > > >> "dorunq"
> > > >> ("after" script)
> > > >>
> > > >> Happy to gather whatever data needed.
> > > >> Thanks!
> > > >> - Bret Barkelew
> > >
>
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-01-09 18:39 0% ` Johannes Schindelin
@ 2019-01-09 18:48 0% ` Bret Barkelew
2019-01-10 15:19 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Bret Barkelew @ 2019-01-09 18:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bryan Turner, git
Will try to reply in-line, when appropriate.
The latest snapshot (git version 2.20.1.windows.1.5.g6b286585b1) still
has the issue.
- Bret
On Wed, Jan 9, 2019 at 10:39 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Bret,
>
>
> On Thu, 3 Jan 2019, Bret Barkelew wrote:
>
> > They are the exact same path (with a different drive letter).
>
> [it's a bit hard to follow the thread if you top-post a reply to an
> inline-replied answer, maybe imitate the style of other mails in the
> future.]
>
> > Another thing I've been able to confirm is I uninstalled git 2.20.1
> > and installed 2.19.0 on the failing system, and the older version of
> > Git works.
> > I've also tried a suggested fix I saw elsewhere to enable long path
> > names in the Windows registry, which did not resolve the issue with
> > git 2.20.1.
> >
> > Happy to collect any additional data.
>
> Please try the latest snapshot at
> https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
> might be fixed via
> https://github.com/git-for-windows/MINGW-packages/pull/32).
>
> Ciao,
> Johannes
>
> > - Bret
> >
> > On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> > >
> > > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> > >>
> > >> When I open gitk in a particular repository under this version of Git
> > >> for Windows, I now get a dialog box that says "Error: couldn't execute
> > >> "git": file name too long". I've noticed that the most pronounced
> > >> effect is that I cannot see the file diffs (or sometimes the file name
> > >> list) for any of the commits. I don't know the exact repro, but I've
> > >> narrowed down the following things:
> > >>
> > >> - This does not happen with the same repo if I use a system that has
> > >> git 2.19.0.windows.1 on another machine.
> > >> - This does not happen on my current machine in a freshly cloned repo.
> > >
> > >
> > > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> > >
> > > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> > >
> > >>
> > >> However, as soon as the remote updates with any changes on a given
> > >> fetch/pull, the repo is put in a bad state permanently.
> > >>
> > >> I've pasted the output from gitk below...
> > >>
> > >> couldn't execute "git": file name too long
> > >> couldn't execute "git": file name too long
> > >> while executing
> > >> "open $cmd r"
> > >> (procedure "getallcommits" line 48)
> > >> invoked from within
> > >> "getallcommits"
> > >> (procedure "readcache" line 80)
> > >> invoked from within
> > >> "readcache file827e200"
> > >> ("eval" body line 1)
> > >> invoked from within
> > >> "eval $script"
> > >> (procedure "dorunq" line 11)
> > >> invoked from within
> > >> "dorunq"
> > >> ("after" script)
> > >>
> > >> Happy to gather whatever data needed.
> > >> Thanks!
> > >> - Bret Barkelew
> >
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
2019-01-04 3:38 5% ` Bret Barkelew
@ 2019-01-09 18:39 0% ` Johannes Schindelin
2019-01-09 18:48 0% ` Bret Barkelew
0 siblings, 1 reply; 69+ results
From: Johannes Schindelin @ 2019-01-09 18:39 UTC (permalink / raw)
To: Bret Barkelew; +Cc: Bryan Turner, git
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
Hi Bret,
On Thu, 3 Jan 2019, Bret Barkelew wrote:
> They are the exact same path (with a different drive letter).
[it's a bit hard to follow the thread if you top-post a reply to an
inline-replied answer, maybe imitate the style of other mails in the
future.]
> Another thing I've been able to confirm is I uninstalled git 2.20.1
> and installed 2.19.0 on the failing system, and the older version of
> Git works.
> I've also tried a suggested fix I saw elsewhere to enable long path
> names in the Windows registry, which did not resolve the issue with
> git 2.20.1.
>
> Happy to collect any additional data.
Please try the latest snapshot at
https://wingit.blob.core.windows.net/files/index.html (I *think* the bug
might be fixed via
https://github.com/git-for-windows/MINGW-packages/pull/32).
Ciao,
Johannes
> - Bret
>
> On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
> >
> > On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
> >>
> >> When I open gitk in a particular repository under this version of Git
> >> for Windows, I now get a dialog box that says "Error: couldn't execute
> >> "git": file name too long". I've noticed that the most pronounced
> >> effect is that I cannot see the file diffs (or sometimes the file name
> >> list) for any of the commits. I don't know the exact repro, but I've
> >> narrowed down the following things:
> >>
> >> - This does not happen with the same repo if I use a system that has
> >> git 2.19.0.windows.1 on another machine.
> >> - This does not happen on my current machine in a freshly cloned repo.
> >
> >
> > How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
> >
> > Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
> >
> >>
> >> However, as soon as the remote updates with any changes on a given
> >> fetch/pull, the repo is put in a bad state permanently.
> >>
> >> I've pasted the output from gitk below...
> >>
> >> couldn't execute "git": file name too long
> >> couldn't execute "git": file name too long
> >> while executing
> >> "open $cmd r"
> >> (procedure "getallcommits" line 48)
> >> invoked from within
> >> "getallcommits"
> >> (procedure "readcache" line 80)
> >> invoked from within
> >> "readcache file827e200"
> >> ("eval" body line 1)
> >> invoked from within
> >> "eval $script"
> >> (procedure "dorunq" line 11)
> >> invoked from within
> >> "dorunq"
> >> ("after" script)
> >>
> >> Happy to gather whatever data needed.
> >> Thanks!
> >> - Bret Barkelew
>
^ permalink raw reply [relevance 0%]
* Re: git version 2.20.1.windows.1 throws file name too long in gitk
[not found] ` <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com>
@ 2019-01-04 3:38 5% ` Bret Barkelew
2019-01-09 18:39 0% ` Johannes Schindelin
0 siblings, 1 reply; 69+ results
From: Bret Barkelew @ 2019-01-04 3:38 UTC (permalink / raw)
To: Bryan Turner; +Cc: git
They are the exact same path (with a different drive letter).
Another thing I've been able to confirm is I uninstalled git 2.20.1
and installed 2.19.0 on the failing system, and the older version of
Git works.
I've also tried a suggested fix I saw elsewhere to enable long path
names in the Windows registry, which did not resolve the issue with
git 2.20.1.
Happy to collect any additional data.
- Bret
On Thu, Jan 3, 2019 at 7:10 PM Bryan Turner <bturner@atlassian.com> wrote:
>
> On Thu, Jan 3, 2019 at 6:21 PM Bret Barkelew <bret@corthon.com> wrote:
>>
>> When I open gitk in a particular repository under this version of Git
>> for Windows, I now get a dialog box that says "Error: couldn't execute
>> "git": file name too long". I've noticed that the most pronounced
>> effect is that I cannot see the file diffs (or sometimes the file name
>> list) for any of the commits. I don't know the exact repro, but I've
>> narrowed down the following things:
>>
>> - This does not happen with the same repo if I use a system that has
>> git 2.19.0.windows.1 on another machine.
>> - This does not happen on my current machine in a freshly cloned repo.
>
>
> How “deep” are the paths to the different clones on the different systems? Are all of the clones at exactly the same path on disk?
>
> Git on Windows is (by defaulted) limited by MAX_PATH, which is 260 characters. That length is calculated including the path to the repository itself and then to the file inside the repository. That means, for example, a given repository cloned to C:\repo may not have issues, but the same repository cloned to C:\Users\Bryan\Documents\workspaces\repo may.
>
>>
>> However, as soon as the remote updates with any changes on a given
>> fetch/pull, the repo is put in a bad state permanently.
>>
>> I've pasted the output from gitk below...
>>
>> couldn't execute "git": file name too long
>> couldn't execute "git": file name too long
>> while executing
>> "open $cmd r"
>> (procedure "getallcommits" line 48)
>> invoked from within
>> "getallcommits"
>> (procedure "readcache" line 80)
>> invoked from within
>> "readcache file827e200"
>> ("eval" body line 1)
>> invoked from within
>> "eval $script"
>> (procedure "dorunq" line 11)
>> invoked from within
>> "dorunq"
>> ("after" script)
>>
>> Happy to gather whatever data needed.
>> Thanks!
>> - Bret Barkelew
^ permalink raw reply [relevance 5%]
* Re: git-send-email warnings & process dying of signal 11
2019-01-01 22:45 3% git-send-email warnings & process dying of signal 11 Rafał Miłecki
@ 2019-01-03 7:22 0% ` Rafał Miłecki
0 siblings, 0 replies; 69+ results
From: Rafał Miłecki @ 2019-01-03 7:22 UTC (permalink / raw)
To: git
On 2019-01-01 23:45, Rafał Miłecki wrote:
> Hello & Happy New Year!
>
> I've recently switched from openSUSE 42.3 (perl 5.18.2 & git 2.13.7) to
> the openSUSE Tumbleweed (perl 5.28.1 & git 2.20.1) and send-email
> doesn't work for me anymore.
>
> FWIW it doesn't seem like a git regression. I've manually installed
> 2.13.7 in my new OS and it also fails.
>
> It basically fails with the:
> Warning: unable to close filehandle __ANONIO__ properly: Bad file
> descriptor at /usr/lib/git/git-send-email line 812.
> Warning: unable to close filehandle __ANONIO__ properly: Bad file
> descriptor at /usr/lib/git/git-send-email line 812.
> error: git-send-email died of signal 11
It appears to be a problem with (my?) perl. I've tried reporting it:
https://rt.perl.org/Public/Bug/Display.html?id=133750
^ permalink raw reply [relevance 0%]
* git-send-email warnings & process dying of signal 11
@ 2019-01-01 22:45 3% Rafał Miłecki
2019-01-03 7:22 0% ` Rafał Miłecki
0 siblings, 1 reply; 69+ results
From: Rafał Miłecki @ 2019-01-01 22:45 UTC (permalink / raw)
To: git
Hello & Happy New Year!
I've recently switched from openSUSE 42.3 (perl 5.18.2 & git 2.13.7) to
the openSUSE Tumbleweed (perl 5.28.1 & git 2.20.1) and send-email
doesn't work for me anymore.
FWIW it doesn't seem like a git regression. I've manually installed
2.13.7 in my new OS and it also fails.
It basically fails with the:
Warning: unable to close filehandle __ANONIO__ properly: Bad file descriptor at /usr/lib/git/git-send-email line 812.
Warning: unable to close filehandle __ANONIO__ properly: Bad file descriptor at /usr/lib/git/git-send-email line 812.
error: git-send-email died of signal 11
Relevant perl source:
802 sub ask {
803 my ($prompt, %arg) = @_;
804 my $valid_re = $arg{valid_re};
805 my $default = $arg{default};
806 my $confirm_only = $arg{confirm_only};
807 my $resp;
808 my $i = 0;
809 return defined $default ? $default : undef
810 unless defined $term->IN and defined fileno($term->IN) and
811 defined $term->OUT and defined fileno($term->OUT);
812 while ($i++ < 10) {
813 $resp = $term->readline($prompt);
814 if (!defined $resp) { # EOF
815 print "\n";
816 return defined $default ? $default : undef;
817 }
818 if ($resp eq '' and defined $default) {
819 return $default;
820 }
821 if (!defined $valid_re or $resp =~ /$valid_re/) {
822 return $resp;
823 }
824 if ($confirm_only) {
825 my $yesno = $term->readline(
826 # TRANSLATORS: please keep [y/N] as is.
827 sprintf(__("Are you sure you want to use <%s> [y/N]? "), $resp));
828 if (defined $yesno && $yesno =~ /y/i) {
829 return $resp;
830 }
831 }
832 }
833 return;
834 }
It seems that the "return defined" line causes warnings.
I don't know perl but I tried patching /usr/lib/git/git-send-email with
the attached diff and got a following output:
Warning: unable to close filehandle __ANONIO__ properly: Bad file descriptor at /usr/lib/git/git-send-email line 812.
Warning: unable to close filehandle __ANONIO__ properly: Bad file descriptor at /usr/lib/git/git-send-email line 812.
term: Term::ReadLine=HASH(0x56138dd97c50)
*** buffer overflow detected ***: /usr/bin/perl terminated
error: git-send-email died of signal 6
It makes me suspect that maybe readline() call causes a crash.
Does this report make sense? Is there anything else I can provide?
--- /usr/lib/git/git-send-email.orig 2019-01-01 23:38:35.980954492 +0100
+++ /usr/lib/git/git-send-email 2019-01-01 23:37:58.964956240 +0100
@@ -810,7 +810,9 @@
unless defined $term->IN and defined fileno($term->IN) and
defined $term->OUT and defined fileno($term->OUT);
while ($i++ < 10) {
+ print STDERR "term: $term\n";
$resp = $term->readline($prompt);
+ print STDERR "readline done\n";
if (!defined $resp) { # EOF
print "\n";
return defined $default ? $default : undef;
^ permalink raw reply [relevance 3%]
* [ANNOUNCE] Git for Windows 2.20.1
@ 2018-12-15 16:59 7% Johannes Schindelin
0 siblings, 0 replies; 69+ results
From: Johannes Schindelin @ 2018-12-15 16:59 UTC (permalink / raw)
To: git-for-windows, git, git-packagers
Dear Git users,
It is my pleasure to announce that Git for Windows 2.20.1 is available from:
https://gitforwindows.org/
Changes since Git for Windows v2.20.0 (December 10th 2018)
New Features
* Comes with Git v2.20.1.
* Comes with cURL v7.63.0.
Bug Fixes
* Fixes a speed regression in the built-in rebase.
Filename | SHA-256
-------- | -------
Git-2.20.1-64-bit.exe | 0dce453188d4aed938e3fd1919393a3600dd3dfe100f3fc92f54f80e372e031f
Git-2.20.1-32-bit.exe | f9ee8d72bed562e01e41ca335f4d1db6ec1b3ac5ffe4494bf8bce0a38bb527bd
PortableGit-2.20.1-64-bit.7z.exe | 4c0fc0c77d577f8dbb3d7711283458ba1d0ce1781cfe0d49c940abbcdf18faa0
PortableGit-2.20.1-32-bit.7z.exe | 64e9b5cfb9b6381f9791225287d80a3705341ca93e7483af9ded54bfff731dbe
MinGit-2.20.1-64-bit.zip | 02328f37eeefe8d8f5396553ac8f91c98d09e533d49d93c617a4643915a76552
MinGit-2.20.1-32-bit.zip | a51b66795c45e3cd1a6041fa6bcc606175870bb2c777f4cfc3dc12c7973ae634
MinGit-2.20.1-busybox-64-bit.zip | 9817ab455d9cbd0b09d8664b4afbe4bbf78d18b556b3541d09238501a749486c
MinGit-2.20.1-busybox-32-bit.zip | da0c03e3b6e77004efafd7c244dc62e92b4f78642d83234b0c62367c6ab2ad95
Git-2.20.1-64-bit.tar.bz2 | 8a35be30f2a5de01b173d81de6355bff9090cc069e265f7e996116acbf21fd78
Git-2.20.1-32-bit.tar.bz2 | 3bace612f3e0c8fd0a470bc4f0a7af88b3fcf051550102b399997e75eb1d887e
pdbs-for-git-64-bit-2.20.1.1.7c9fbc07db-1.zip | 6f0178fcf26a6eaaf9a0d2aea3504e828d3b92735967bacefe9bc743608a9471
pdbs-for-git-32-bit-2.20.1.1.7c9fbc07db-1.zip | e1f601c22e3e7142b96d468ff949db741d38200ca77d0d27e4e0b839261f0cd6
Ciao,
Johannes
^ permalink raw reply [relevance 7%]
* [ANNOUNCE] Git v2.20.1
@ 2018-12-15 5:01 4% Junio C Hamano
0 siblings, 0 replies; 69+ results
From: Junio C Hamano @ 2018-12-15 5:01 UTC (permalink / raw)
To: git; +Cc: Linux Kernel, git-packagers
The latest maintenance release Git v2.20.1 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.20.1'
tag and the 'maint' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://github.com/gitster/git
----------------------------------------------------------------
Git v2.20.1 Release Notes
=========================
This release is primarily to fix brown-paper-bag breakages in the
2.20.0 release.
Fixes since v2.20
-----------------
* A few newly added tests were not portable and caused minority
platforms to report false breakages, which have been fixed.
* Portability fix for a recent update to parse-options API.
* "git help -a" did not work well when an overly long alias is
defined, which has been corrected.
* A recent update accidentally squelched an error message when the
run_command API failed to run a missing command, which has been
corrected.
----------------------------------------------------------------
Changes since v2.20.0 are as follows:
Derrick Stolee (1):
.gitattributes: ensure t/oid-info/* has eol=lf
Johannes Schindelin (4):
help.h: fix coding style
help -a: handle aliases with long names gracefully
t4256: mark support files as LF-only
t9902: 'send-email' test case requires PERL
Junio C Hamano (2):
run-command: report exec failure
Git 2.20.1
Nguyễn Thái Ngọc Duy (1):
parse-options: fix SunCC compiler warning
^ permalink raw reply [relevance 4%]
Results 1-69 of 69 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-12-15 5:01 4% [ANNOUNCE] Git v2.20.1 Junio C Hamano
2018-12-15 16:59 7% [ANNOUNCE] Git for Windows 2.20.1 Johannes Schindelin
2019-01-01 22:45 3% git-send-email warnings & process dying of signal 11 Rafał Miłecki
2019-01-03 7:22 0% ` Rafał Miłecki
2019-01-04 2:21 git version 2.20.1.windows.1 throws file name too long in gitk Bret Barkelew
[not found] ` <CAGyf7-HcncFOfmm5McEkOvCTkHNdePDSEQDZwEAK=z1bmC=QKw@mail.gmail.com>
2019-01-04 3:38 5% ` Bret Barkelew
2019-01-09 18:39 0% ` Johannes Schindelin
2019-01-09 18:48 0% ` Bret Barkelew
2019-01-10 15:19 0% ` Johannes Schindelin
2019-01-10 18:55 0% ` Bret Barkelew
2019-04-18 18:16 0% ` Bret Barkelew
2019-04-27 23:20 0% ` Johannes Schindelin
2019-05-29 16:40 0% ` Bret Barkelew
2019-05-29 18:07 0% ` Johannes Schindelin
2019-01-15 19:29 Broken interactive rebase text after some UTF-8 characters Michal Nowak
2019-01-16 10:33 3% ` Phillip Wood
2019-01-16 21:36 0% ` Michal Nowak
2019-01-17 11:04 0% ` Phillip Wood
2019-01-27 9:58 unclear docs Sergey Lukashev
2019-01-27 11:55 4% ` Sergey Lukashev
2019-01-28 16:09 0% ` Jeff King
2019-01-28 18:12 0% ` Sergey Lukashev
2019-01-28 17:31 0% ` Torsten Bögershausen
2019-01-29 19:38 6% [PATCH (Apple Git) 00/13] Differences between git-2.20.1 and Apple Git-116 Jeremy Huddleston Sequoia
2019-02-07 7:28 1% [ANNOUNCE] Git v2.21.0-rc0 Junio C Hamano
2019-02-07 19:47 0% ` Johannes Schindelin
2019-02-08 3:17 3% [PATCH 0/2] t/lib-gpg: a gpgsm fix, a minor improvement, and a question Todd Zullinger
2019-02-08 8:33 0% ` Henning Schild
2019-02-09 14:06 0% ` SZEDER Gábor
2019-02-14 3:32 1% [ANNOUNCE] Git v2.21.0-rc1 Junio C Hamano
2019-02-18 15:45 0% ` Johannes Schindelin
2019-02-19 4:17 git rebase --continue after solving conflicts doesn't work anymore Sebastián Mancilla
2019-02-19 6:45 ` Christian Couder
2019-02-19 7:22 ` Eric Sunshine
2019-02-19 9:59 ` Phillip Wood
2019-02-19 14:03 3% ` Sebastián Mancilla
2019-02-19 14:18 0% ` Christian Couder
2019-02-19 14:32 0% ` Phillip Wood
2019-02-23 13:11 4% on fedora, "man gitweb" exists but actual gitweb command is missing Robert P. J. Day
[not found] <AM6PR08MB41993844F57794DDF4B33B8F8D570@AM6PR08MB4199.eurprd08.prod.outlook.com>
2019-04-03 6:47 ` Fw: git describe issue Amiel Elboim
2019-04-03 6:59 4% ` Bryan Turner
2019-04-09 6:11 2% git push --atomic and HTTP(S) vs SSH Bryan Turner
2019-04-11 23:56 4% [BUG] rebase --interactive silently overwrites ignored files wh
2019-04-12 16:30 0% ` Phillip Wood
2019-04-14 1:59 0% ` wh
2019-04-14 13:24 0% ` Phillip Wood
2019-05-02 15:45 0% ` Phillip Wood
2019-05-14 9:19 4% git blame doesn't respect diff algorithm? Pierre Ossman
2019-05-21 2:59 3% HEAD and namespaces Bryan Turner
2019-06-10 15:07 4% rebase / am separation problem Michal Suchánek
2019-06-10 18:46 0% ` Johannes Schindelin
2019-06-20 10:59 3% git fetch --shallow-since hangs Yuri D'Elia
2019-07-11 21:36 4% Pull vs push messages Michael Kielstra
2019-07-11 22:01 0% ` brian m. carlson
2019-07-12 6:39 0% ` Martin Ågren
2019-07-19 18:41 4% Fedora 1 and Ubuntu 4 Jeffrey Walton
2019-07-19 19:16 0% ` Junio C Hamano
2020-01-27 10:55 4% git status --ignored hangs when a deep directory structure present in working tree Martin Melka
2020-01-27 12:08 0% ` SZEDER Gábor
2020-01-28 5:06 0% ` Elijah Newren
2020-01-29 22:10 0% ` Elijah Newren
2020-04-16 21:04 [RFC][PATCH 0/2] submodule: port 'set-url' from shell to C Shourya Shukla
2020-04-20 8:19 4% ` Denton Liu
2020-05-16 4:09 4% git push over HTTP; long delay with no progress, then hang? Bryan Turner
2020-05-16 6:37 0% ` SZEDER Gábor
2021-05-07 6:06 [RFC suggestion] Generate manpage directly with Asciidoctor Bagas Sanjaya
2021-05-07 20:25 ` brian m. carlson
2021-05-07 22:19 ` Jeff King
2021-05-09 8:20 ` Martin Ågren
2021-05-10 22:24 ` Jeff King
2021-05-11 4:27 4% ` Felipe Contreras
2021-05-11 6:13 0% ` Jeff King
2021-05-11 8:03 0% ` Felipe Contreras
2021-06-28 12:17 4% segfault on invalid 'git grep' invocation Matthew Hughes
2021-08-11 14:59 Bug with Git shallow clones and submodules Kevin Phillips
2021-08-15 14:31 4% ` Philippe Blain
2021-09-02 13:49 4% ` Weird interaction between Git protocol versions and git:// and https:// URLs (was: Re: Bug with Git shallow clones and submodules) Philippe Blain
2021-09-04 12:57 0% ` Jeff King
[not found] <CALH-JHvNHVvPWap8eiMaQ6HAJOBa4W5xuA9V_s7zPLubgwaRow@mail.gmail.com>
2021-08-24 12:00 ` Automatically Handling Using/Checking Out Branches With One or More Different Contained Submodules? Bryce Glover
2021-08-27 22:48 0% ` Philippe Blain
2021-12-06 12:16 3% Regression in 8d92fb292706 ("dir: replace exponential algorithm with a linear one") Uwe Kleine-König
2021-12-07 5:29 0% ` Elijah Newren
2021-12-07 7:14 0% ` Uwe Kleine-König
2022-01-19 20:37 4% A puzzle: reset --hard and hard links Michael Herrmann
2022-01-19 22:20 0% ` brian m. carlson
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).