[PATCH] daemon: ignore ENOTSOCK from setsockopt

In inetd mode, we are not guaranteed stdin or stdout is a socket; callers could filter the data through a pipe or be testing with regular files. This prevents t5802 from polluting syslog. Signed-off-by: Eric Wong --- daemon.c | 8 +--- 1 file changed, 5 insertions(+), 3

Fwd: Git and SHA-1 security (again)

Do you think the multi-hash approach worth the added complexity? It'll break a lot of things. I mean almost everything. All git algorithms rely on the "same hash => same content" "same content => same hash" statements. I think converting is a much better option. Use a single-hash storage, and

Re: git-svn dies all the time

Alexandre Bique wrote: > Hi, > > I did by mistake report the bug here: > > https://github.com/git/git-scm.com/issues/807#issuecomment-233200404 > > In short this is a backtrace of git svn rebase crashing in perl, and > likely because of an out of memory issue. It

Re: [PATCH] list: avoid incompatibility with *BSD sys/queue.h

Eric Sunshine wrote: > On Sat, Jul 16, 2016 at 8:25 PM, Eric Wong wrote: > > Eric Wong wrote: > >> I also wonder where we use sys/queue.h, since I use > >> LIST_HEAD from ccan/list/list.h in a different project > >> without conflicts... >

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 12:23:49PM -0400, Theodore Ts'o wrote: > On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote: > > As I said, I'm not planning on multiple hash support at first, but it > > doesn't appear impossible if we go this route. We might still have to > > rewrite

git-svn dies all the time

Hi, I did by mistake report the bug here: https://github.com/git/git-scm.com/issues/807#issuecomment-233200404 In short this is a backtrace of git svn rebase crashing in perl, and likely because of an out of memory issue. It crashed on my laptop but not on my desktop (4G of RAM vs 16G of RAM).

Draft of Git Rev News edition 17

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-17.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub

Re: format-patch with pager.format-patch=true gets very confused

On Sun, Jul 17, 2016 at 02:41:48PM +0200, Johannes Schindelin wrote: > Hi Josh, > > On Sat, 16 Jul 2016, Josh Triplett wrote: > > > git-config(1) documents the ability to enable or disable the pager (or > > set a command-specific pager) for any command by setting > > pager.=true. For most

Re: proposal: allow git clone for http-hosted bundles

Jeff King writes: > You might do better to stick a shim script in your $PATH to just > intercept the calls to git. Hacky, but it would probably solve your > problem with a minimal amount of code. I recently learned about http://repo.or.cz/git.git/bundles which is a very nicely

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

writes: > >The other replies covered how to use the system's own diff instead. >Just curious: What makes using git diff difficult and its output hard to >deal with for you? In decreasing importance order: I am 84 years old. I have been using /usr/bin/diff for more than four

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

On Wed, Jul 13, 2016 at 01:52:16PM +0300, Kirill Smelkov wrote: > On Wed, Jul 13, 2016 at 04:26:53AM -0400, Jeff King wrote: > > On Fri, Jul 08, 2016 at 01:38:55PM +0300, Kirill Smelkov wrote: > > > > > > - we will not compute the same write order (which is based on > > > > traversal

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote: > As I said, I'm not planning on multiple hash support at first, but it > doesn't appear impossible if we go this route. We might still have to > rewrite objects, but we can verify signatures over the legacy SHA-1 > objects by

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 05:19:02PM +0200, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: > > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > >> Out of curiosity: have you considered something like padding the

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: >> Out of curiosity: have you considered something like padding the SHA-1s >> with, say 0xa1, to the size of the new hash and using that

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > Out of curiosity: have you considered something like padding the SHA-1s > with, say 0xa1, to the size of the new hash and using that padding to > distinguish between old vs new hash? I'm going to end up having to do something

Re: format-patch with pager.format-patch=true gets very confused

Hi Josh, On Sat, 16 Jul 2016, Josh Triplett wrote: > git-config(1) documents the ability to enable or disable the pager (or > set a command-specific pager) for any command by setting > pager.=true. For most commands, this seems to work as expected. > However, setting pager.format-patch=true (or

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

Am 16.07.2016 um 21:12 schrieb n...@dad.org: I am trying to learn how to use git, and am having difficulty using 'git diff'. I can't deal with its output very well. The other replies covered how to use the system's own diff instead. Just curious: What makes using git diff difficult and its

[PATCH v2 4/4] fsck: optionally show more helpful info for broken links

When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable.

[PATCH v2 2/4] fsck_walk(): optionally name objects on the go

If fsck_options->name_objects is initialized, and if it already has name(s) for the object(s) that are to be the starting point(s) for fsck_walk(), then that function will now add names for the objects that were walked. This will be highly useful for teaching git-fsck to identify root causes for

[PATCH v2 1/4] fsck: refactor how to describe objects

In many places, we refer to objects via their SHA-1s. Let's abstract that into a function. For the moment, it does nothing else than what we did previously: print out the 40-digit hex string. But that will change over the course of the next patches. Signed-off-by: Johannes Schindelin

[PATCH v2 3/4] fsck: give the error function a chance to see the fsck_options

We will need this in the next commit, where fsck will be taught to optionally name the objects when reporting issues about them. Signed-off-by: Johannes Schindelin --- builtin/fsck.c | 3 ++- fsck.c | 5 +++-- fsck.h | 6 -- 3 files changed, 9

[PATCH v2 0/4] Teach `git fsck` a new option: `--name-objects`

When using experimental features (such as worktrees), it is quite possible to end up with a repository that is a little bit corrupted. In this developer's case, the auto gc run during interactive rebases in worktrees completely messed up the reflogs. The symptoms are broken links between

Re: [PATCH 2/3] fsck_walk(): optionally name objects on the go

Hi Junio, On Thu, 14 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Note that this patch opts for decorating the objects with plain strings > > instead of full-blown structs (à la `struct rev_name` in the code of > > the `git name-rev` command),

Re: [PATCH 3/3] fsck: optionally show more helpful info for broken links

Hi Eric, On Fri, 15 Jul 2016, Eric Sunshine wrote: > On Thu, Jul 14, 2016 at 11:30 AM, Johannes Schindelin > wrote: > > When reporting broken links between commits/trees/blobs, it would be > > quite helpful at times if the user would be told how the object is > >

Re: [PATCH v4] config: add conditional include

Hi Peff, On Sat, 16 Jul 2016, Jeff King wrote: > On Sat, Jul 16, 2016 at 06:36:03PM +0200, Johannes Schindelin wrote: > > > > On Sat, Jul 16, 2016 at 03:30:45PM +0200, Johannes Schindelin wrote: > > > > > > > As an alternative solution to your problem, you could of course avoid > > > > all >

Re: Git and SHA-1 security (again)

Hi Brian, On Sat, 16 Jul 2016, brian m. carlson wrote: > My current plan is not to implement side-by-side data, for a couple > reasons. I am as guilty as the next person to have use the "deafbee(This is my commit, 2007-08-21)" format to refer to older commits. So I do have concerns about

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

Hi, [Perry, my mailer could not find your MX record, so I am sorry I had to drop you from the explicit To:...] On Sat, 16 Jul 2016, Perry Hutchison wrote: > n...@dad.org wrote: > > > Would some kind soul be willing to tell me if there is a way to > > do that, short of making a backup copy of

Re: proposal: allow git clone for http-hosted bundles

Ho mappu, On Sun, 17 Jul 2016, mappu wrote: > Right now it's possible to git clone a repository over http, and git > clone a bundle from the local filesystem, but it's not possible to git > clone a bundle hosted on http. > > Would it be possible to allow this in the future? Hopefully it's only

Re: proposal: allow git clone for http-hosted bundles

On Sun, Jul 17, 2016 at 04:41:54PM +1200, mappu wrote: > Right now it's possible to git clone a repository over http, and git clone a > bundle from the local filesystem, but it's not possible to git clone a > bundle hosted on http. > > Would it be possible to allow this in the future? Hopefully