On FreeBSD 10.3 (but presumably any FreeBSD 8+), /usr/bin/unzip
exists, but is insufficient for t5003 due to its non-standard
handling of the -a option[1]. This version of unzip exits
with "1" when given the "-v" flag.
However, the common Info-ZIP version may be installed at
/usr/local/bin/unzip
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 deletions(-)
diff -
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 conv
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 crashed on my laptop but
> not
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...
> >
> > Still wondering... Checking sys/mman.h in an old Fr
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 objects
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).
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 is
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 comman
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 done set of instru
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 decades.
And having t
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 order),
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 forci
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 SHA-1s
> >> with, say 0xa1, to the
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 padding to
>> distinguish between
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 s
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
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 ou
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.
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 b
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
---
builti
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 insertions(+), 5 deletions(-)
d
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 commits/t
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), for several reasons:
> >
> >
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
> > supposed to be reachable.
> >
>
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
> >
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 rewriti
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 th
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 a
29 matches
Mail list logo
