500 Internal Server Error

Hi team, Great work on the documentation provided for GIT on https://git-scm.com But found an error on the same, to just for testing, I switched to Hindi Language (Clicked on Hindi link on left panel) as for reading the pages/book in hindi language, I got 500 Internal server Error. I hope

Re: Current state of Git worktree used with submodules?

On Tue, Jul 19, 2016 at 10:59 PM, Lars Schneider wrote: > Hi, > > some time ago Michael wrote in a blog post [1]: > "It's not recommended to use git worktree with a repository that contains > submodules." > > Plus "Documentation/git-worktree.txt" states: > "Multiple

Re: t7063 failure on FreeBSD 10.3 i386/amd64

Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote: > > Oops, forgot to Cc some folks who worked on this :x > > > > Filesystem is ufs and it fails regardless of whether > > soft-updates is enabled or not. > > Nothing stands out to my eyes,

[PATCH] config.mak.uname: set PERL_PATH for FreeBSD 5.0+

Perl has not been part of the base system since FreeBSD 5.0: https://www.freebsd.org/releases/5.0R/relnotes-i386.html Signed-off-by: Eric Wong --- Does anybody still run git on FreeBSD 4.x or earlier? 4.11 was released a few months before git in 2005:

Re: Looking for help to understand external filter driver code

On 07/20/2016 12:01 AM, Lars Schneider wrote: On 19 Jul 2016, at 23:33, Junio C Hamano wrote: Lars Schneider writes: Git writes --> 4 byte filename length Git writes --> filename string Why limit to 32GB? Perhaps NUL termination is more

[RFC] git-svn: allow --version to work anywhere

Checking the version of the installed SVN libraries should not require a git repository at all. This matches the behavior of "git --version". Add a test for "git svn help" for the same behavior while we're at it, too. Signed-off-by: Eric Wong --- I'm hoping "cd /" in the test

Re: topological index field for commit objects

W dniu 2016-06-30 o 00:00, Jeff King pisze: > On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote: >> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still >> limited to object counting? > > At GitHub we are using them for --contains analysis, along with mass >

[PATCH] Documentation, git submodule: Note about --reference

Signed-off-by: Stefan Beller --- Is it too obvious? I was approached off list and this was only obvious after some discussion, so I think it is a valid warning. On the other hand this might show that we want to get worktree working with submodules.

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

> the logical place to pull that information from would be > ../../GIT-VERSION-FILE, I agree. It would make more sense to build this to a specific version or git revision rather than a time. Perhaps that would be a different patch? > So unless the "dynamic lookup in the Makefile" turns out to

What's cooking in git.git (Jul 2016, #06; Tue, 19)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

[PATCH v1 0/6] Porcelain Status V2

This patch series adds porcelain V2 format to status. This provides detailed information about file changes and about the current branch. The new output is accessed via: git status --porcelain=2 [--branch] An earlier draft of this work was submitted under the "Add very verbose porcelain

[PATCH v1 6/6] Unit tests for V2 porcelain status

This commit contains unit tests to exercise the V2 porcelain status format. Signed-off-by: Jeff Hostetler --- t/t7064-wtstatus-pv2.sh | 461 t/t7501-commit.sh | 9 + 2 files changed, 470 insertions(+) create mode

[PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

Simple unit tests to validate the argument parsing. Signed-off-by: Jeff Hostetler --- t/t7060-wtstatus.sh | 21 + t/t7501-commit.sh | 14 ++ 2 files changed, 35 insertions(+) diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh index

[PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

Update the --porcelain argument to take an optional version number. This will allow us to define new porcelain formats in the future. This default to 1 and represents the existing porcelain format. Signed-off-by: Jeff Hostetler --- Documentation/git-commit.txt | 2 +-

[PATCH v1 5/6] Add porcelain V2 documentation to status manpage

This commit updates the status manpage to include information about porcelain format V2. Signed-off-by: Jeff Hostetler --- Documentation/git-status.txt | 62 +--- 1 file changed, 59 insertions(+), 3 deletions(-) diff --git

[PATCH v1 3/6] Per-file output for Porcelain Status V2

This commit sets up version 2 porcelain status and defines the format of detail lines. This includes the usual XY and pathname fields. It adds the various file modes and SHAs and the rename score. For regular entries these values reflect the head, index and worktree. For unmerged entries these

[PATCH v1 4/6] Expanded branch header for Porcelain Status V2

This commit expand porcelain status V2 to print detailed information about the current branch. This includes the SHA of the current commit, the current branch name, the upstream branch name, and the ahead/behind counts. This additional information is included when the --branch argument is given.

Re: Looking for help to understand external filter driver code

On 19 Jul 2016, at 23:33, Junio C Hamano wrote: > Lars Schneider writes: > >> Git writes --> 4 byte filename length >> Git writes --> filename string > > Why limit to 32GB? Perhaps NUL termination is more appropriate > here? OK, I will use NUL

Re: Looking for help to understand external filter driver code

Lars Schneider writes: > Git writes --> 4 byte filename length > Git writes --> filename string Why limit to 32GB? Perhaps NUL termination is more appropriate here? > Git writes --> 4 byte content length > Git writes --> content string > Git reads <-- 4 byte filtered

Re: [PATCH 2/3] difftool: avoid $GIT_DIR and $GIT_WORK_TREE

Junio C Hamano writes: > It is not wrong per-se, but as you are in a subshell, you do not > have to unset these, I would think. Not worth a reroll, but unless > I am overlooking something (in which case please holler) I'm > inclined to remove these two lines myself while

Current state of Git worktree used with submodules?

Hi, some time ago Michael wrote in a blog post [1]: "It's not recommended to use git worktree with a repository that contains submodules." Plus "Documentation/git-worktree.txt" states: "Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT

Re: Looking for help to understand external filter driver code

On 19 Jul 2016, at 20:53, Junio C Hamano wrote: > Junio C Hamano writes: > >> The key benefit of this arrangement is the above can be done without >> having to do poll() to flip between reading and writing that is >> needed to avoid deadlocking, which

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

Jonathan Nieder writes: > In the stateless-rpc case, linear growth means getting a bounded > number of 'have's worth of benefit (new 'have's) in each round, in > exchange for a linearly increasing cost (existing 'have's). That is a > high cost for limited benefit.

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

Junio C Hamano wrote: > Even if it is conservative, I wonder if it is truly a good idea to > make it exponentially grow forever from that point of view. Would > it give essentially the same result to you if we discard the patch > in question and just raise LARGE_FLUSH to 10k instead? I don't

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote: > > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote: > >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote: > >> > >>

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

Johannes Schindelin writes: > I do not need cc/apply-am at all, it turns out, but my patch series has a > minor conflict with 'jc/renormalize-merge-kill-safer-crlf'. > > Since you indicated that you want to cook that branch a bit in 'next' > first, I will rebase to

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 12:08:11PM -0700, Junio C Hamano wrote: > Antoine Tenart writes: > > > Being able to manually define the name can also be useful in some (rare) > > cases, where you reorganize your project directory tree. But that's not > > a strong argument for

Re: [PATCH] submodule-config: use explicit empty string instead of strbuf in config_from()

On Tue, Jul 19, 2016 at 12:15 PM, Junio C Hamano wrote: > René Scharfe writes: > >> Use a string constant instead of an empty strbuf to shorten the code >> and make it easier to read. >> >> Signed-off-by: Rene Scharfe >> --- >> ... unless someone

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

Jonathan Tan writes: >> So I guess what I do not understand is why we need to slow down the >> exponential growth at all? > > The current code has an exponential (a' = a * 2) then a linear (a' = a > + 1024) growth. I'm not slowing down the exponential growth - that >

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 3:04 PM, Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote: >> Like moving a worktree (or is there a command for this?) > > Don't touch it. I've been waiting patiently for that patch series to > be reviewed

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

On Tue, Jul 19, 2016 at 12:03 PM, Jonathan Tan wrote: > On Tue, Jul 19, 2016 at 9:46 AM, Stefan Beller wrote: >> Care to elaborate on why you choose 11/10 as growth factor? >> >> (As someone who has a tick in micro optimizing: >> 9/8 is roughly the

Re: [PATCH] submodule-config: use explicit empty string instead of strbuf in config_from()

René Scharfe writes: > Use a string constant instead of an empty strbuf to shorten the code > and make it easier to read. > > Signed-off-by: Rene Scharfe > --- > ... unless someone can come up with a suitable non-empty string to feed > to git_config_from_mem() as its

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Jakub Narębski" W dniu 2016-07-13 o 00:11, Philip Oakley pisze: From: "Junio C Hamano" [...] I actually think this is a good place to have them described. ^ is about specifying a single commit. These two are not that (you can say HEAD^2^@ but you

Re: [PATCH] worktree: add: introduce the --name option

Antoine Tenart writes: > Being able to manually define the name can also be useful in some (rare) > cases, where you reorganize your project directory tree. But that's not > a strong argument for adding this option :-) Continuing the rationale that rejected the topic from

[PATCH] submodule-config: use explicit empty string instead of strbuf in config_from()

Use a string constant instead of an empty strbuf to shorten the code and make it easier to read. Signed-off-by: Rene Scharfe --- ... unless someone can come up with a suitable non-empty string to feed to git_config_from_mem() as its name parameter. submodule-config.c | 3 +-- 1

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart wrote: > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote: >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote: >> >> 080739b (worktree.c: find_worktree() search by path suffix - >>

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

On Tue, Jul 19, 2016 at 9:46 AM, Stefan Beller wrote: > Care to elaborate on why you choose 11/10 as growth factor? > > (As someone who has a tick in micro optimizing: > 9/8 is roughly the same exponent, but the division > by 8 is easier as it is just a shift by 3. Similar

Re: Git and SHA-1 security (again)

2016-07-19 20:04 GMT+02:00 Duy Nguyen : > On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: >> On Tue, 19 Jul 2016, Duy Nguyen wrote: >> >>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: On Tue, 19 Jul 2016, Duy Nguyen wrote:

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote: > > 080739b (worktree.c: find_worktree() search by path suffix - > 2016-06-13) from 'next' should help identify worktrees in this case by > specifying

Re: Looking for help to understand external filter driver code

Junio C Hamano writes: > The key benefit of this arrangement is the above can be done without > having to do poll() to flip between reading and writing that is > needed to avoid deadlocking, which kept the code simpler. A later > conversion of the write side into async does

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 2:04 PM, Junio C Hamano wrote: > Antoine Tenart writes: >> Adds a --name option allowing to specify the name of a worktree when >> creating it. This allows to have multiple worktrees in directories >> having the same name (e.g.

Re: Git and SHA-1 security (again)

Duy Nguyen writes: >> Even though that single operation might be possible, do not go >> there. A "pathname" identifies a "path", not its contents, and >> "appending crap after path" breaks the data model badly. > > I thought about that but I thought all those operations

Re: [PATCH] worktree: add: introduce the --name option

Hi, On Tue, Jul 19, 2016 at 11:04:59AM -0700, Junio C Hamano wrote: > > > Adds a --name option allowing to specify the name of a worktree when > > creating it. This allows to have multiple worktrees in directories > > having the same name (e.g. project0/foo, project1/foo etc...). This > > commit

[PATCH] use strbuf_addbuf() for appending a strbuf to another

Use strbuf_addbuf() where possible; it's shorter and more efficient. Signed-off-by: Rene Scharfe --- dir.c | 2 +- path.c | 2 +- wt-status.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/dir.c b/dir.c index 6172b34..0ea235f 100644 --- a/dir.c

Re: [PATCH 3/3] difftool: use Git::* functions instead of passing around state

David Aguilar writes: > Call Git::command() and friends directly wherever possible. > This makes it clear that these operations can be invoked directly > without needing to manage the current directory and related GIT_* > environment variables. Good. > @@ -88,11 +80,11 @@ sub

Re: [PATCH] worktree: add: introduce the --name option

On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano wrote: > Antoine Tenart writes: > >> Adds a --name option allowing to specify the name of a worktree when >> creating it. This allows to have multiple worktrees in directories >> having the same name (e.g.

Re: [PATCH 2/3] difftool: avoid $GIT_DIR and $GIT_WORK_TREE

David Aguilar writes: > Environment variables are global and hard to reason about. > Use the `--git-dir` and `--work-tree` arguments when invoking `git` > instead of relying on the environment. > > Add a test to ensure that difftool's dir-diff feature works when these >

Re: [PATCH 1/3] difftool: fix argument handling in subdirs

David Aguilar writes: > From: John Keeping > > When in a subdirectory of a repository, path arguments should be > ... > directory. > > Reported-by: Bernhard Kirchen > Signed-off-by: John Keeping >

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: > On Tue, 19 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: >>> >>> On Tue, 19 Jul 2016, Duy Nguyen wrote: >>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin

Re: [PATCH] worktree: add: introduce the --name option

Antoine Tenart writes: > Adds a --name option allowing to specify the name of a worktree when > creating it. This allows to have multiple worktrees in directories > having the same name (e.g. project0/foo, project1/foo etc...). This > commit keeps the previous behaviour by

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: But we can recreate SHA-1 from the same content and

Re: Looking for help to understand external filter driver code

Lars Schneider writes: > a long time ago in aa4ed4 Junio introduced the external filter > driver definition. Since that time we fork the Git process and > then we fork again to run the external filter. This is probably a > super stupid question with an obvious answer...

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: > On Tue, 19 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin >> wrote: But we can recreate SHA-1 from the same content and verify GPG, right? I know

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: But we can recreate SHA-1 from the same content and verify GPG, right? I know it's super expensive, but it feels safer to not carry SHA-1 around when it's not secure

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:06 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Post-shower thoughts. In a tree object, a submodule entry consists of >> perm (S_IFGITLINK), hash (which is the external hash) and path. We >> could fill the "hash" part with

Re: [PATCH] test-lib: stricter unzip(1) check

Johannes Schindelin writes: > On Mon, 18 Jul 2016, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > Hrm. That sounds a little magical, and fragile, to me. What if the next >> > person's unzip returns 0 and *still* cannot

Re: Git and SHA-1 security (again)

Duy Nguyen writes: > Post-shower thoughts. In a tree object, a submodule entry consists of > perm (S_IFGITLINK), hash (which is the external hash) and path. We > could fill the "hash" part with all zero (invalid, signature of new > submodule hash format), then append "/:" to >

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

Shawn Pearce writes: > On Mon, Jul 18, 2016 at 9:32 PM, Parker Moore wrote: >>> The label does not even identify the version of the source in any way, so I >>> am not sure how people are depending on that feature anyway ;-) >> >> Would it be a better

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

On Mon, Jul 18, 2016 at 3:21 PM, Jonathan Tan wrote: > When updating large repositories, the LARGE_FLUSH limit (that is, the > limit at which the window growth strategy switches from exponential to > linear) is reached quite quickly. Use a conservative exponential growth

Looking for help to understand external filter driver code

Hi, a long time ago in aa4ed4 Junio introduced the external filter driver definition. Since that time we fork the Git process and then we fork again to run the external filter. This is probably a super stupid question with an obvious answer... but can anyone help me to understand the code and

Re: t7063 failure on FreeBSD 10.3 i386/amd64

On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote: > Oops, forgot to Cc some folks who worked on this :x > > Filesystem is ufs and it fails regardless of whether > soft-updates is enabled or not. Nothing stands out to my eyes, so I'm going to install freebsd this weekend. I hope

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 6:51 PM, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: >> I'm going to end up having to do something similar because of the issue >> of submodules. Submodules may still be SHA-1, while the

Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

On Tue, Jul 19, 2016 at 3:07 AM, Jeff King wrote: > On Mon, Jul 18, 2016 at 10:28:25PM -0700, Stefan Beller wrote: > >> On Sat, Jul 16, 2016 at 12:56 AM, Jeff King wrote: >> >> > + if (use_keepalive == KEEPALIVE_AFTER_NUL && >> >> > !keepalive_active)

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

W dniu 2016-07-13 o 00:11, Philip Oakley pisze: > From: "Junio C Hamano" [...] >> I actually think this is a good place to have them described. >> ^ is about specifying a single commit. These two are >> not that (you can say HEAD^2^@ but you cannot say HEAD^@^2, for >>

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: >> But we can recreate SHA-1 from the same content and verify GPG, right? >> I know it's super expensive, but it feels safer to not carry SHA-1 >> around when it's not secure anymore (I recall something about

Re: Question: Getting 'git diff' to generate /usr/bin/diff output

Johannes Schindelin writes: > >A better method might be to use the `git difftool` command, e.g. > >git difftool -x diff Something like: git difftool --no-prompt --extcmd=diff or like: git difftool --no-prompt --extcmd="diff -b" "$@" works great for me. Thank you

[PATCH] worktree: add: introduce the --name option

Adds a --name option allowing to specify the name of a worktree when creating it. This allows to have multiple worktrees in directories having the same name (e.g. project0/foo, project1/foo etc...). This commit keeps the previous behaviour by making it the default value, i.e. by using $(basename )

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Hi Richard, On Tue, 19 Jul 2016, Richard Soderberg wrote: > Aha! Yes, this works precisely as intended: the prompt works > correctly, and quickly, with this change in place. Okay, next step for you: read http://github.com/git-for-windows/git/blob/master/Documentation/SubmittingPatches and

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

Hi Junio, On Tue, 19 Jul 2016, Johannes Schindelin wrote: > On Mon, 18 Jul 2016, Junio C Hamano wrote: > > > Junio C Hamano writes: > > > > You can assume that I'll merge bc/cocci and > > js/am-call-theirs-theirs-in-fallback-3way to 'master' during that time, > > so an

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Aha! Yes, this works precisely as intended: the prompt works correctly, and quickly, with this change in place. - R. On Tue, Jul 19, 2016 at 4:24 AM, Johannes Schindelin wrote: > Hi Richard, > > On Mon, 18 Jul 2016, Richard Soderberg wrote: > >> Hi, I wanted to

Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

Hi Junio, On Mon, 18 Jul 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> The two topics that are in 'pu' and conflict with this series are > >> 'jh/clean-smudge-annex' and 'bc/cocci'. > >> > >> It

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Tue, Jul 19, 2016 at 05:29:07AM -0600, Jeff King wrote: > On Sun, Jul 17, 2016 at 08:06:49PM +0300, Kirill Smelkov wrote: > > > > Anyway, please find below updated patch according to your suggestion. > > > Hope it is ok now. > > > > Ping. Is the patch ok or something needs to be improved

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Sun, Jul 17, 2016 at 08:06:49PM +0300, Kirill Smelkov wrote: > > Anyway, please find below updated patch according to your suggestion. > > Hope it is ok now. > > Ping. Is the patch ok or something needs to be improved still? Sorry, I'm traveling and haven't carefully reviewed it yet. It's

Re: [PATCH] test-lib: stricter unzip(1) check

Hi Junio, On Mon, 18 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Hrm. That sounds a little magical, and fragile, to me. What if the next > > person's unzip returns 0 and *still* cannot handle -a? > > That is a very sensible line of thought.

Re: git-prompt.sh incompatible with non-basic global grep.patternType

Hi Richard, On Mon, 18 Jul 2016, Richard Soderberg wrote: > Hi, I wanted to report something interesting that I found while tracing > a severe slowdown in git-prompt.sh. > > https://github.com/git/git/commit/6d158cba282f22fa1548af1188f78042fed30aed#diff-f37c4f4a898819f0ca4b5ff69e81d4d9R141 > >

[PATCH] git-svn: document svn.authorsProg in config

This has always been supported since we read config variables based on the command-line option parser. Document it explicitly since users usually want to maintain the same program across invocations. Signed-off-by: Eric Wong --- Pushed to master of bogomips.org/git-svn.git, but

Re: [PATCH 12/12] receive-pack: send keepalives during quiet periods

On Mon, Jul 18, 2016 at 10:28:25PM -0700, Stefan Beller wrote: > On Sat, Jul 16, 2016 at 12:56 AM, Jeff King wrote: > >> > + if (use_keepalive == KEEPALIVE_AFTER_NUL && > >> > !keepalive_active) { > >> > + const char *p = memchr(data, '\0',

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Johannes Schindelin wrote: Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: I'm going to end up having to do something similar because of the issue of submodules. Submodules may still

Re: Git and SHA-1 security (again)

Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: > > I'm going to end up having to do something similar because of the issue > > of submodules. Submodules may still be SHA-1, while the main repo may > > be

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> My point is not to throw out old hashes and break signatures. My point > >> is to convert the data storage, and use mapping to resolve problems > >> with those old hashes and signatures. > > > > If you convert the data storage, then the

Re: Git and SHA-1 security (again)

Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: > On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin > wrote: > > > > On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > > > >> >> I think converting is a much better option. Use a single-hash > >> >> storage, and convert