Git Error Message

Hello, I have installed the Git software and upon trying to update a repository by the "open recent repository" link and am unable to access the menu-or anything-from there. Instead a window pops up with the following error message: "\usage C:\Program Files\Git\mingw64/libexec/git-core\git-GUI[

[PATCH 1/2] add setup step to filter-branch

A specific `--setup` step in `git filter-branch` makes it much easier to define the initial values of variables used in the real filters. Also sourcing/defining utility functions here instead of `--env-filter` improves performance and minimizes clogging the output in case of errors.

[PATCH 2/2] add [--] to usage of filter-branch

Signed-off-by: Andreas Heiduk --- Documentation/git-filter-branch.txt | 3 ++- git-filter-branch.sh| 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index

[PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

There is no portable way to pass timezone information to strftime. Add parameters for timezone offset and name to strbuf_addftime and let it handle the timezone-related format specifiers %z and %Z internally. Callers can opt out by passing NULL as timezone name. Use an empty string as timezone

Re: [PATCH] git-p4: remove obsolete version check

On Sat, Jun 3, 2017 at 3:31 PM, Jakub Wilk wrote: > The file is syntactically correct only in Python >= 2.6, so the > version check never does anything. [CC-ing Eric who added that check] Your commit message doesn't give an example of this, but with e.g. python 2.0 you get:

Re: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor

On Fri, Jun 2, 2017 at 11:44 PM, David Turner wrote: > BTW, a medium-sized (~250k files across 40k dirs) synthetic repo is available > over bittorrent at: > http://bitmover.com/2015-04-03-1M-git-bare.tar.bz2.torrent Can you seed this please? I've been trying to

Re: [PATCH] submodule foreach: correct $sm_path in nested submodules from a dir

On 03/06/17 01:37, Stefan Beller wrote: > When running 'git submodule foreach' from a subdirectory of your > repository, nested submodules get a bogus value for $sm_path: > For a submodule 'sub' that contains a nested submodule 'nested', > running 'git -C dir submodule foreach echo $path' would

[PATCH] git-p4: remove obsolete version check

The file is syntactically correct only in Python >= 2.6, so the version check never does anything. Signed-off-by: Jakub Wilk --- git-p4.py | 4 1 file changed, 4 deletions(-) diff --git a/git-p4.py b/git-p4.py index 8d151da91..4278cd9d4 100755 --- a/git-p4.py +++

Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

> On Sat, 3 Jun 2017, René Scharfe wrote: > + case 'Z': > + strbuf_addstr(_fmt, tz_name); Is it guaranteed that tz_name cannot contain a percent sign itself? Ulrich

Re: [PATCH] perf: work around the tested repo having an index.lock

On Sat, Jun 3, 2017 at 1:52 AM, Junio C Hamano wrote: > Jeff King writes: > >> But I think a more compelling case is that there may be an ongoing >> operation in the original repo (e.g., say you are in the middle of >> writing a commit message) when we do a

Re: [PATCH] strbuf: let strbuf_addftime handle %z and %Z itself

Am 03.06.2017 um 15:13 schrieb Ulrich Mueller: On Sat, 3 Jun 2017, René Scharfe wrote: + case 'Z': + strbuf_addstr(_fmt, tz_name); Is it guaranteed that tz_name cannot contain a percent sign itself? Currently yes, because the only caller

Fast Approval in 1-2 Hours.

We provide PERSONAL and BUSINESS assistance No Deposit when you apply Loan with us!! , To Ease Your Financial Burden. -Easy Apply -Flexible Package -Fast Approval in 1-2 Hours. Email: quickfinac...@qq.com

Re: [PATCH 2/2] rebase: turn on progress option by default for format-patch

Jeff King writes: > ... > That explains why you want to pass "-q" in the other hunk; to > countermand the explicit --progress here. But if we separate the two as > I mentioned above, you'd want logic more like: > > if test -t 2 && test "$GIT_QUIET" != "t" >

Re: [PATCH] perf: work around the tested repo having an index.lock

Junio C Hamano writes: > Perhaps run "fsck" and "status" immediately after copying to make > sure they succeed, or something like that? Hmph, this is me half-being silly, as this "copying an existing one" is meant for testing Git with a large repository, and having to run

Fast Approval in 1-2 Hours.

We provide PERSONAL and BUSINESS assistance No Deposit when you apply Loan with us!! , To Ease Your Financial Burden. -Easy Apply -Flexible Package -Fast Approval in 1-2 Hours. Email: quickfinac...@qq.com

How do I regularly clean up .git/objects/pack/tmp_* files?

Hi there, I try to follow the best practice of regular repo maintenance, which afaik consists of running `git gc` every week or so. So I thought I had a well-maintained repository, and was quite surprised to discover some very large .git/objects/pack/tmp_* files, which apparently are entirely

Re: [WIP/PATCH 7/6] perf: add a performance test for core.fsmonitor

Ævar Arnfjörð Bjarmason writes: > This is WIP code for the reasons explained in the setup comments, > unfortunately the perf code doesn't easily allow you to run different > setup code for different versions you're testing. This test will stop > working if the fsmonitor is

issue: "git subtree split" vs "git svn fetch" consequences

Hi, git folks! I think i've found something about inconsistency between "git subtree split" and "git svn fetch". First of all, "git subtree split" ignores commits with 0 changed files, when the "git svn fetch" is not. For example, it could be an svn commit where only properties has changed,

Re: [PATCH] perf: work around the tested repo having an index.lock

Ævar Arnfjörð Bjarmason writes: >> My feeling exactly. Diagnosing and failing upfront saying "well you >> made a copy but it is not suitable for testing" sounds more sensible >> at lesat to me. > > This change makes the repo suitable for testing when it wasn't before. Perhaps

Fast Approval in 1-2 Hours.

We provide PERSONAL and BUSINESS assistance No Deposit when you apply Loan with us!! , To Ease Your Financial Burden. -Easy Apply -Flexible Package -Fast Approval in 1-2 Hours. Email: quickfinac...@qq.com

Re: [WIP v2 2/2] pack-objects: support --blob-max-bytes

Jeff King writes: > I do also wonder if the two features would need to be separated for a > GVFS-style solution. If you're not just avoiding large blobs but trying > to get a narrow clone, you don't want the .git files from the > uninteresting parts of the tree. You want to get no

[ANNOUNCE] git-cinnabar 0.5.0b1

Hi, Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Code on https://github.com/glandium/git-cinnabar This release on https://github.com/glandium/git-cinnabar/releases/tag/0.5.0b1

Re: [PATCH] test-lib: add ability to cap the runtime of tests

Ævar Arnfjörð Bjarmason writes: > Speeding up the test suite by simply cataloging and skipping tests > that take longer than N seconds is a hassle to maintain, and entirely > skips some tests which would be nice to at least partially run, > e.g. instead of entirely skipping

Investment Interest & Offer

Re: How do I regularly clean up .git/objects/pack/tmp_* files?

On Sat, Jun 03, 2017 at 04:53:20PM -0400, Dun Peal wrote: > I try to follow the best practice of regular repo maintenance, which > afaik consists of running `git gc` every week or so. > > So I thought I had a well-maintained repository, and was quite > surprised to discover some very large

[PATCH] test-lib: add ability to cap the runtime of tests

Add a GIT_TEST_TIMEOUT environment variable which optimistically sets an approximate upper limit on how long any one test is allowed to run. Once the timeout is exceeded all remaining tests are skipped, no attempt is made to stop a long running test in-progress, or deal with the edge case of the

Re: [PATCH] perf: work around the tested repo having an index.lock

Jeff King writes: > But I think a more compelling case is that there may be an ongoing > operation in the original repo (e.g., say you are in the middle of > writing a commit message) when we do a blind copy of the filesystem > contents. You might racily pick up a lockfile. > >