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[
{
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.
Signed-off-by:
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 45c849d8c..1efdda804 100644
--
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 na
> On Sat, 3 Jun 2017, René Scharfe wrote:
> + case 'Z':
> + strbuf_addstr(&munged_fmt, tz_name);
Is it guaranteed that tz_name cannot contain a percent sign itself?
Ulrich
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 r
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
+++ b/git-p4.py
@@ -8,10 +8,6
Am 03.06.2017 um 15:13 schrieb Ulrich Mueller:
On Sat, 3 Jun 2017, René Scharfe wrote:
+ case 'Z':
+ strbuf_addstr(&munged_fmt, tz_name);
Is it guaranteed that tz_name cannot contain a percent sign itself?
Currently yes, because the only
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 blind copy of the filesystem
>> content
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:
File "git-p4.p
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
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 download that since
yesterday, sti
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
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
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 nee
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 e
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
What
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, but
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"
> git_format_patch_opt="$git_form
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 blobs at all, a
Æ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 "not suitable" was
Æ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 t3404-rebase-interact
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
fsck may add meaningful
Æ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 merged into the master
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.
>
> Should we find and
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 .git/o
27 matches
Mail list logo
