[PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

I found no evidence of such behavior in the source code. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- This is based on the maint branch, a08595f.  Documentation/git-clean.txt | 4 +---  1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Documentation/git-clean

Making the "Note from the maintainer" information discoverable

On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote: > Jeff King writes: > > > FWIW, as the person who wrote that section, I think that is a good > > addition.  We do have a link to Simon Tatham's bug-reporting guide, > > but > > this is a good place to put project-specific

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

On Mon, 2016-02-08 at 14:16 -0800, Junio C Hamano wrote: > Jeff King writes: > > > FWIW, as the person who wrote that section, I think that is a good > > addition.  We do have a link to Simon Tatham's bug-reporting guide, but > > this is a good place to put project-specific

git(1) man page has link to out-of-date googlecode site

I noticed that near the top of the git(1) man page, there is a link to  http://git-htmldocs.googlecode.com/git/git.html, which apparently has not been updated since August 2015 (https://code.google.com/archive/p/git-htmldocs/source/default/commits). Should this link just be removed, or replaced

[PATCH] git.txt: encourage bug reporters to test recent versions

Specifically, the latest released version or the "next" branch, as reporters are willing. This is based on: http://marc.info/?l=git=145496979420513=2 Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- Documentation/git.txt | 6 +- 1 file changed, 5 insertion

update_linked_gitdir writes relative path to .git/worktrees//gitdir

I noticed that when update_linked_gitdir chooses to update .git/worktrees//gitdir, the path it writes is relative, at least under some circumstances.  This contradicts the gitrepository-layout man page, which says: worktrees//gitdir:: A text file containing the absolute path back to the

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

t in removing the second part. > > Thanks, then let's do this. Looks good except for a typo (below).  I'll try to write better commit messages in the future. > -- >8 -- > From: Matt McCutchen <m...@mattmccutchen.net> > Date: Sat, 6 Feb 2016 15:25:41 -0500 > Subject: [PATCH]

Re: [PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > I found no evidence of such behavior in the source code. > > > > Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> > > ---

[PATCH] Documentation/git-clean.txt: don't mention deletion of .git/modules/*

I found no evidence of such behavior in the source code. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- This is based on the maint branch, a08595f. Try #2 to get correct email formatting. Documentation/git-clean.txt | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

Re: update_linked_gitdir writes relative path to .git/worktrees//gitdir

On Sun, 2016-02-07 at 15:56 -0800, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > I noticed that when update_linked_gitdir chooses to update > > .git/worktrees//gitdir, the path it writes is relative, at > > least > > under s

Re: [PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths

On Wed, 2017-02-01 at 12:56 -0800, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > > Matt McCutchen <m...@mattmccutchen.net> writes: > > ... > > > Please check that my refactoring is indeed correct!  All the > > > existin

[PATCH] t0001: don't let a default ACL interfere with the umask test

Same idea as 8ed0a740dd42bd0724aebed6e3b07c4ea2a2d5e8. (I guess I'm the only one who ever runs the test suite with a default ACL set.) Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- t/t0001-init.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/t/t0001-init.sh b/t/t0001-init.sh index b8fc588

[PATCH] merge-recursive: make "CONFLICT (rename/delete)" message show both paths

r of cases in handle_change_delete (modify vs. rename), refactor the code to halve the number of cases again by merging the cases where o->branch1 has the change and o->branch2 has the delete with the cases that are the other way around. Also add a simple test of the new conflict message. Sig

[PATCH] fetch: print an error when declining to request an unadvertised object

bject". Finally, add a simple test case for "git fetch REMOTE SHA1". Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- builtin/fetch-pack.c | 7 +-- fetch-pack.c | 51 ++- fetch-pack.h | 9

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

On Sun, 2017-02-12 at 15:49 -0800, Junio C Hamano wrote: > The fact that we have the above two choices tells me that a two-step > approach may be an appropriate approach. [...] > Even if you did only the first step, as long as the second step can > be done without reverting what the first step

Re: [PATCH 1/3] fetch-pack: move code to report unmatched refs to a function

On Wed, 2017-02-22 at 09:11 -0800, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > We're preparing to reuse this code in transport.c for "git fetch". > > > > While I'm here, internationalize the existing error message. &g

[PATCH v2 2/3] fetch_refs_via_pack: call report_unmatched_refs

esn't allow requests for unadvertised objects. Make fetch_refs_via_pack (which is on the "git fetch" code path) call report_unmatched_refs so that we at least get an error message in that case. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- t/t5516-fetch-push.sh

[PATCH v2 1/3] fetch-pack: move code to report unmatched refs to a function

We're preparing to reuse this code in transport.c for "git fetch". While I'm here, internationalize the existing error message. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- builtin/fetch-pack.c | 7 +-- fetch-pack.c | 13 + fetch-pack

[PATCH v2 3/3] fetch-pack: add specific error for fetching an unadvertised object

uot;Server does not allow request for unadvertised object". Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- fetch-pack.c | 42 +++--- remote.h | 9 +++-- t/t5516-fetch-push.sh | 2 +- 3 files changed, 35 insertions(+), 1

[PATCH 2/3] fetch_refs_via_pack: call report_unmatched_refs

"git fetch" currently doesn't bother to check that it got all refs it sought, because the common case of requesting a nonexistent ref triggers a die() in get_fetch_map. However, there's at least one case that slipped through: "git fetch REMOTE SHA1" if the server doesn't allow requests for

[PATCH 1/3] fetch-pack: move code to report unmatched refs to a function

We're preparing to reuse this code in transport.c for "git fetch". While I'm here, internationalize the existing error message. --- builtin/fetch-pack.c | 7 +-- fetch-pack.c | 13 + fetch-pack.h | 9 + t/t5500-fetch-pack.sh | 6 +++--- 4 files

[PATCH 3/3] fetch-pack: add specific error for fetching an unadvertised object

Enhance filter_refs (which decides whether a request for an unadvertised object should be sent to the server) to record a new match status on the "struct ref" when a request is not allowed, and have report_unmatched_refs check for this status and print a special error message, "Server does not

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

On Mon, 2017-02-20 at 22:36 -0800, Junio C Hamano wrote: > Hmph, I would have expected this to be done as a three-patch series, > >  * move the loop at the end of cmd_fetch_pack() to a separate helper >    function report_unmatched_refs() and call it; > >  * add a call to report_unmatched_refs()

[PATCH] fetch: print an error when declining to request an unadvertised object

Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't allow requests for unadvertised objects by sha1. Change it to print a meaningful error message. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- The fetch code looks unbelievably complicated t

Re: [PATCH] fetch: print an error when declining to request an unadvertised object

On Fri, 2017-02-10 at 10:36 -0800, Junio C Hamano wrote: > > > There is this piece of code near the end of builtin/fetch-pack.c: > > [...] > > that happens before the command shows the list of fetched refs, and > this code is prepared to inspect what happend to the requests it (in > response to

"git diff --ignore-space-change --stat" lists files with only whitespace differences as "changed"

A bug report: I noticed that "git diff --ignore-space-change --stat" lists files with only whitespace differences as having changed with 0 differing lines. This is inconsistent with the behavior without -- stat, which doesn't list such files at all. (Same behavior with all the --ignore*space*

"git subtree --squash" interacts poorly with revert, merge, and rebase

I'm the lead developer of a research software application (https://bitb ucket.org/objsheets/objsheets) that uses modified versions of two third-party libraries, which we need to version and distribute along with our application.  For better or for worse, we haven't made it a priority to upstream

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Wed, 2016-10-26 at 19:03 -0700, Stefan Beller wrote: > On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen <m...@mattmccutchen.net> > wrote: > > 4. I pushed several dangling submodule pointers before I learned I > > could set push.recurseSubmodules = check.  This

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

t 4:07 PM, Matt McCutchen <m...@mattmccutchen.net> > wrote: > > - We have to make separate commits and manage corresponding topic > > branches for the superproject and subprojects. > > Well yeah, that is how submodule work on a conceptual level. > While having multip

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Sat, 2016-10-29 at 09:39 -0400, Jeff King wrote: > I'm not sure I understand how connecting to a remote server to fetch is > a big problem. The server may learn about the existence of particular > sha1s in your repository, but cannot get their content. > > It's the subsequent push that is a

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote: > Not sending to the list, where mails from Gmail/phone is known to get > rejected. [I guess I can go ahead and quote this to the list.] > No. I'm saying that the scenario you gave is bad and people should be > taught not to connect to

Fetch/push lets a malicious server steal the targets of "have" lines

I was studying the fetch protocol and I realized that in a scenario in which a client regularly fetches a set of refs from a server and pushes them back without careful scrutiny, the server can steal the targets of unrelated refs from the client repository by fabricating its own refs to the "have"

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote: > Maybe we would never hit any of these problems in practice, but they > give me a bad enough feeling that I'm planning to write my own tool > that tracks the upstream commit ID in a file (like a submodule) and > doesn't genera

Re: [PATCH] fetch/push: document that private data can be leaked

On Sun, 2016-11-13 at 18:57 -0800, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > > >  Documentation/fetch-push-security.txt | 9 + > > A new (consolidated) piece like this that can be included in > multiple places is a goo

[PATCH] doc: mention transfer data leaks in more places

git-pull(1), and git-push(1) man pages. Also add references to this section from the documentation of server configuration options that attempt to control data leakage but may not be fully effective. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- Documentation/config.txt

Re: Protecting old temporary objects being reused from concurrent "git gc"?

On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote: >  - when an object write is optimized out because we already have the >    object, git will update the mtime on the file (loose object or >    packfile) to freshen it FWIW, I am not seeing this happen when I do "git read-tree --prefix" followed

[PATCH] git-gc.txt: expand discussion of races with other processes

runeExpire config variable. Based on a write-up by Jeff King: http://marc.info/?l=git=147922960131779=2 Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- Documentation/config.txt | 4 +++- Documentation/git-gc.txt | 34 ++ 2 files changed, 29 insertions

[PATCH] fetch/push: document that private data can be leaked

and recommend using separate repositories for private data and interaction with untrusted servers. Signed-off-by: Matt McCutchen <m...@mattmccutchen.net> --- And here's a proposed patch. Based on the maint branch, ac84098. Documentation/fetch-push-security.txt | 9 + Documentati

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Sun, 2016-10-30 at 01:03 -0700, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > > > On Fri, 2016-10-28 at 22:31 -0700, Junio C Hamano wrote: > > > > > > Not sending to the list, where mails from Gmail/phone is known to &

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Sun, 2016-10-30 at 01:16 -0700, Junio C Hamano wrote: > Jon Loeliger writes: > > > > > Is there an existing protocol provision, or an extension to > > the protocol that would allow a distrustful client to say to > > the server, "Really, you have Y2?  Prove it." > > There is

Re: Protecting old temporary objects being reused from concurrent "git gc"?

On Tue, 2016-11-15 at 12:40 -0500, Jeff King wrote: > On Tue, Nov 15, 2016 at 12:33:04PM -0500, Matt McCutchen wrote: > > > > > On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote: > > > > > >  - when an object write is optimized out because we already have

Re: [PATCH] fetch/push: document that private data can be leaked

On Mon, 2016-11-14 at 11:00 -0800, Junio C Hamano wrote: > Matt McCutchen <m...@mattmccutchen.net> writes: > > > > > > > > > Yup, and then "do not push to untrustworthy place without > > > checking > > > what you are pushing&qu

Protecting old temporary objects being reused from concurrent "git gc"?

The Braid subproject management tool stores the subproject content in the main tree and is able to switch to a different upstream revision of a subproject by doing the equivalent of "git read-tree -m" on the superproject tree and the two upstream trees.  The tricky part is preparing temporary

Re: "git subtree --squash" interacts poorly with revert, merge, and rebase

On Thu, 2016-11-10 at 16:53 -0500, Matt McCutchen wrote: > On Wed, 2016-10-26 at 19:07 -0400, Matt McCutchen wrote: > > > > Maybe we would never hit any of these problems in practice, but they > > give me a bad enough feeling that I'm planning to write my own tool > &g

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Fri, 2016-10-28 at 15:00 -0700, Junio C Hamano wrote: > Let me see if I understood your scenario correctly. > > Suppose we start from this history where 'O' are common, your victim > has a 'Y' branch with two commits that are private to it, as well as > a 'X' branch on which it has X1 that it

Re: Fetch/push lets a malicious server steal the targets of "have" lines

On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote: > Ah, I see.  My immediate reaction is that you can do worse things in > the reverse direction compared to this, but your scenario does sound > bad already. Are you saying that clients connecting to untrusted servers already face worse

Tools that do an automatic fetch defeat "git push --force-with-lease"

When I'm rewriting history, "git push --force-with-lease" is a nice safeguard compared to "git push --force", but it still assumes the remote-tracking ref gives the old state the user wants to overwrite. Tools that do an implicit fetch, assuming it to be a safe operation, may break this

Re: Duplicate safecrlf warning for racily clean index entry

On Wed, 2018-02-21 at 08:53 +0100, Torsten Bögershausen wrote: > I don't hava a pointer, but what should happen ? > 2 warnings for 2 "git add" should be OK, I think. > > 1 warning is part of the optimization, that Git does to handle > hundrets and thousands of files efficciently. > > Is the 1/2

Re: Duplicate safecrlf warning for racily clean index entry

On Tue, 2018-02-20 at 08:42 -0500, Matt McCutchen wrote: > In either case, if "git update-index --refresh" (or "git status") is > run before "git add", then "git add" does not print the warning. On > the other hand, if line endings in the working

Duplicate safecrlf warning for racily clean index entry

I noticed that if a file subject to a safecrlf warning is added to the index in the same second that it is created, resulting in a "racily clean" index entry, then a subsequent "git add" command prints another safecrlf warning. I reproduced this on the current "next" (499d7c4f91). The procedure: