I want to discuss a very profitable business with you.
Reply for info.
Regards,
Ms. Yu
Sir/madam,I humbly seek your consent for an investment in your
Country.I need your good advice and suggest areas of sustainable and
viable economy that will be of great value to us.More details of this
will be sent following your INVESTMENT suggestions.Regards,
---
Makefile | 1 +
bloom-filter.c | 103 +
bloom-filter.h | 39 +++
3 files changed, 143 insertions(+)
create mode 100644 bloom-filter.c
create mode 100644 bloom-filter.h
diff --git a/Makefile b/Makefile
index 13e1c52478.
On Sat, Sep 22, 2018 at 1:30 AM Ævar Arnfjörð Bjarmason
wrote:
> Duy's
> https://public-inbox.org/git/20180920161928.ga13...@duynguyen.home/ is
> another recent thing that reminded me of this, i.e. that suggested
> "\\|/-" spinner could be made much neater with non-ASCII.
>
> > 1. Add a trace_ke
e made much neater with non-ASCII.
Here is a IMO very large collection of spinner-like unicode animations:
https://asciinema.org/a/ex8z3z6d5m7uv4buww0o2qeq2
This comes from Zsh world, it's a plugin with spinners to use in Zsh scripts.
I've never managed to see even 1/3 of them.
> I
On Sat, Sep 22, 2018 at 01:30:36AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >> This will allow users to free their creativity and provide probably
> >> dozens of custom Git progress bars.
> >
> > I don't personally feel that the existing progress bar is that bad, but
> > if anybody wants to pursue
On Fri, Sep 21 2018, Jeff King wrote:
> On Fri, Sep 21, 2018 at 09:34:14AM -0400, Sebastian Gniazdowski wrote:
>
>> Git default progress indicator for clone is very unattractive, IMO. It
>> does its job in providing all the operation details very well, but I
>> bet most
On Fri, Sep 21, 2018 at 09:34:14AM -0400, Sebastian Gniazdowski wrote:
> Git default progress indicator for clone is very unattractive, IMO. It
> does its job in providing all the operation details very well, but I
> bet most of users strongly dream about a gauge box!
>
> Have a l
Hello!
Git default progress indicator for clone is very unattractive, IMO. It does its
job in providing all the operation details very well, but I bet most of users
strongly dream about a gauge box!
Have a look at my gauge box constructed as git-stderr pipe script:
https://asciinema.org/a
Col. Hussein Kharmusch
Greetings My Dear Friend,
MY name is Mr.Yaya Bambara i am working in ADB bank I have
($16.4million Dollars) to transfer to your country and if you are
interested get back to me immediately for more details.and i we
give you 40% for you and 60% for me ok.
Mr.Yaya Bambara.
Telex Manager
African Dev
Hello Dear,
Please forgive me for stressing you with my predicaments as I know that
this letter may come to you as big surprise.Truly, I came across your E-
mail from my personal search afterward I decided to email you directly
believing that you will be honest to fulfill my final wish before i
Hello Dear,
Compliment of the season, I have an urgent Business Transaction for you kindly
contact me through my Google email: mrsjanezh...@gmail.com
for more details.
Happy New Year
Mrs Lin.
On Tue, Nov 21, 2017 at 4:07 AM, Peter Krefting wrote:
> Elijah Newren:
>
>> Sure, take a look at the big-repo-small-cherry-pick branch of
>> https://github.com/newren/git
>
>
> With those changes, the time usage is the same as if I set
> merge.renameLimit=1 for the repository, and the end result
Elijah Newren:
Sure, take a look at the big-repo-small-cherry-pick branch of
https://github.com/newren/git
With those changes, the time usage is the same as if I set
merge.renameLimit=1 for the repository, and the end result is identical:
$ time /usr/local/stow/git-v2.15.0-323-g31fe956618/b
On Mon, Nov 13, 2017 at 3:22 AM, Peter Krefting wrote:
> Elijah Newren:
>
>> I would be very interested to hear how my rename detection performance
>> patches work for you; this kind of usecase was the exact one it was designed
>> to help the most. See
>>
Elijah Newren:
I would be very interested to hear how my rename detection
performance patches work for you; this kind of usecase was the exact
one it was designed to help the most. See
https://public-inbox.org/git/20171110222156.23221-1-new...@gmail.com/
I'd be happy to try them ou
Kevin Willford:
Since this is happening during a merge, you might need to use merge.renameLimit
or the merge strategy option of -Xno-renames. Although the code does fallback
to use the diff.renameLimit but there is still a lot that is done before even
checking
the rename limit so I would first
ther direction.
>
> However, none of them applies to these particular commits, which only
> touches files that are in the exact same location on both branches.
I would be very interested to hear how my rename detection performance
patches work for you; this kind of usecase was the exact
Interesting timing. I have some performance patches specifically
developed because rename detection during merges made a small
cherry-pick in a large repo rather slow...in my case, I dropped the
time for the cherry pick by a factor of about 30 (no guarantees you'll
see the same; it's ve
renames turned off.
Thanks,
Kevin
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf
> Of Peter Krefting
> Sent: Friday, November 10, 2017 7:05 AM
> To: Derrick Stolee
> Cc: Jeff King ; Git Mailing List
> Subject: Re: che
Derrick Stolee:
Git is spending time detecting renames, which implies you probably
renamed a folder or added and deleted a large number of files. This
rename detection is quadratic (# adds times # deletes).
Yes, a couple of directories with a lot of template files have been
renamed (and some
On 11/10/2017 7:37 AM, Peter Krefting wrote:
Jeff King:
Can you get a backtrace? I'd do something like:
Seems that it spends most time in diffcore_count_changes(), that is
where it hits whenever I hit Ctrl+C (various line numbers 199-207 in
diffcore-delta.c; this is on the v2.15.0 tag).
(
Jeff King:
Can you get a backtrace? I'd do something like:
Seems that it spends most time in diffcore_count_changes(), that is
where it hits whenever I hit Ctrl+C (various line numbers 199-207 in
diffcore-delta.c; this is on the v2.15.0 tag).
(gdb) bt
#0 diffcore_count_changes (src=src@en
On Fri, Nov 10, 2017 at 10:39:39AM +0100, Peter Krefting wrote:
> Running strace, it seems like it is doing lstat(), open(), mmap(), close()
> and munmap() on every single file in the repository, which takes a lot of
> time.
>
> I thought it was just updating the status, but "git status" returns
Hi!
On a big repository (57000 files, 2,5 gigabytes in .git/objects), git
cherry-pick is very slow for me (v2.15.0). This is cherry-picking a
one-file change, where the file is in the same place on both branches,
and which applies cleanly (I am backporting a few fixes to a
maintenance
reading it a few
>times.
Many parts of the man page are written from a very technical perspective. I'm
sure patches to improve this would be welcome by the community. Even just
reading your thoughts here is helpful, though I do not know who may find the
interest and time to produce such.
rints, but the man page doesn't really tell that.
1)I mean, there is a section:
"https://git-scm.com/docs/git-diff#_combined_diff_format";, but at the
very end of the manpage, so presumably, only aimed at advanced users.
And the first thing it says is
"Any diff-generating comman
how fast "git diff-index --cached -r HEAD --", with the
>> same pathspec used for the problematic "git rm", runs in this same
>> 50,000 path project.
>
> I'll let the original poster answer this one as well, but it was very
> fast in my test repo. I&#x
-cached -r HEAD --", with the
> same pathspec used for the problematic "git rm", runs in this same
> 50,000 path project.
I'll let the original poster answer this one as well, but it was very
fast in my test repo. I'm not very familiar with the code path in
question, but
Junio C Hamano writes:
> I wonder how fast "git diff-index --cached -r HEAD --", with the
> same pathspec used for the problematic "git rm", runs in this same
> 50,000 path project.
>
> If it runs in a reasonable time, one easy way out may be to revamp
> the codepath to call check_local_mod() t
"brian m. carlson" writes:
>> Looking at an optimized profile, all the time seems to be spent in
>> “get_tree_entry” — I assume there is some huge object representing the
>> directory which is being re-expanded for each file?
>
> Yes, there's a tree object that represents each directory.
>
>> I
On Sat, Oct 28, 2017 at 05:02:02PM +, Christopher Jefferson wrote:
> I stupidly added a directory with many files ( ~450,000 ) to git, and want to
> delete them — later I plan to rebase/squash various commits to remove the
> files from the history altogether.
>
> However, ‘
I stupidly added a directory with many files ( ~450,000 ) to git, and want to
delete them — later I plan to rebase/squash various commits to remove the files
from the history altogether.
However, ‘git rm’ is VERY slow. For example, in a directory with 10,000 files
(on a Mac), git v2.14.2
Git
gt;
> Indeed. I'll add a --allow-missing-tagger option (suggestions for a
> snappier name accepted!) and pass it unconditionally from the filter-
> branch script.
I think that name is the right amount of snappy. It's not meant to be
used very often. :)
-Peff
Ian Campbell writes:
> Indeed. I'll add a --allow-missing-tagger option (suggestions for a
> snappier name accepted!) and pass it unconditionally from the filter-
> branch script.
Thanks. That's much better.
On Wed, 2017-08-09 at 08:50 -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
> >
> >> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
> >>
> >> Insert a fake tag header, since newer `git mktag` wont accept the
Jeff King writes:
> On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
>
>> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
>>
>> Insert a fake tag header, since newer `git mktag` wont accept the input
>> otherwise:
>
> Hmm. Now your resulting tag will have this cruf
On Tue, Aug 08, 2017 at 09:06:20AM +0100, Ian Campbell wrote:
> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
>
> Insert a fake tag header, since newer `git mktag` wont accept the input
> otherwise:
Hmm. Now your resulting tag will have this crufty "unkn...@example.com"
heade
On Tue, 2017-08-08 at 14:00 -0700, Junio C Hamano wrote:
> > @@ -540,6 +540,9 @@ if [ "$filter_tag_name" ]; then
> > > new_sha1=$( ( printf 'object %s\ntype commit\ntag %s\n'
> > >\
> > > "$new_sha1" "$new_ref"
> > >
Ian Campbell writes:
> Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
>
> Insert a fake tag header, since newer `git mktag` wont accept the input
> otherwise:
>
> $ git cat-file tag v2.6.12-rc2
> object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
> type commit
> ta
Such as v2.6.12-rc2..v2.6.13-rc3 in the Linux kernel source tree.
Insert a fake tag header, since newer `git mktag` wont accept the input
otherwise:
$ git cat-file tag v2.6.12-rc2
object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
type commit
tag v2.6.12-rc2
Linux v2.6.12-rc2 re
Hi Adam,
On Sun, 2 Jul 2017, Adam Dinwoodie wrote:
> I do the builds for the Cygwin distribution on my normal PC (so
> reasonably powerful but definitely not devoted to the purpose), and
> doing the build and running the default tests takes in the region of 8
> hours for the 64-bit build and 12 h
On Tue, Jun 06, 2017 at 05:04:32PM +0200, Lars Schneider wrote:
> > On 06 Jun 2017, at 16:47, Jason Pyeron wrote:
> >
> > Do we have Jenkins (or something else) setup for Git?
> >
> > We would be happy to donate (slave) VMs for cygwin builds og Git.
> >
> > -Jason Pyeron
> >
>
> We use Trav
> On 06 Jun 2017, at 16:47, Jason Pyeron wrote:
>
> Do we have Jenkins (or something else) setup for Git?
>
> We would be happy to donate (slave) VMs for cygwin builds og Git.
>
> -Jason Pyeron
>
We use TravisCI for Linux, Mac, and (in a special way) Windows:
https://travis-ci.org/git/git
Do we have Jenkins (or something else) setup for Git?
We would be happy to donate (slave) VMs for cygwin builds og Git.
-Jason Pyeron
One could have configure ask some existing dependency that has already
determined the byte order. For example:
# perl -e 'use Config; $o=$Config{byteorder}; print(($o=~/^1234/ ?
"little" : ($o=~/4321$/ ? "big" : "weird")), "\n");'
little
Good: less #ifdef soup; bad: not so great for cross-compil
On Tue, Jun 06, 2017 at 08:55:04PM +0900, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
> > Digging briefly into the endianness detection, it appears Cygwin has
> > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by
> > assuming it's in a little endian environment and switc
Adam Dinwoodie writes:
> Digging briefly into the endianness detection, it appears Cygwin has
> both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by
> assuming it's in a little endian environment and switching to big endian
> if it detects any of the defines that indicate such,
On Tue, Jun 06, 2017 at 10:20:45AM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > That looks scary, can you please comment out this:
> >
> > #define SHA1DC_ALLOW_UNALIGNED_ACCESS
> >
> > In sha1dc/sha1.c and see if that helps, alternatively comment out the
> > ifdefs gua
Ævar Arnfjörð Bjarmason writes:
> That looks scary, can you please comment out this:
>
> #define SHA1DC_ALLOW_UNALIGNED_ACCESS
>
> In sha1dc/sha1.c and see if that helps, alternatively comment out the
> ifdefs guarded by "#ifdef _MSC_VER" calls in sha1dc/sha1.c
That is merely a performance (
a1dc: update from upstream", 2017-05-20) is breaking a very
>>> significant number of test cases in both 32-bit and 64-bit Cygwin
>>> builds.
>>>
>>> The first failure is t.46 "validate object ID of a known tree"; output
>>> with
>>
On 05/06/17 22:05, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jun 5, 2017 at 10:34 PM, Adam Dinwoodie wrote:
>> I'm trying to compile Git v2.13.1 to release for Cygwin, but it appears
>> a010391 ("sha1dc: update from upstream", 2017-05-20) is breaking a very
>>
On Mon, Jun 5, 2017 at 10:34 PM, Adam Dinwoodie wrote:
> I'm trying to compile Git v2.13.1 to release for Cygwin, but it appears
> a010391 ("sha1dc: update from upstream", 2017-05-20) is breaking a very
> significant number of test cases in both 32-bit and 64-bit Cygwin
I'm trying to compile Git v2.13.1 to release for Cygwin, but it appears
a010391 ("sha1dc: update from upstream", 2017-05-20) is breaking a very
significant number of test cases in both 32-bit and 64-bit Cygwin
builds.
The first failure is t.46 "validate object ID of a know
- a bit late in providing a comment..
From: "Michael J Gruber"
Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:
On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:
Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason"
:
On Tue, Apr 11, 2017 at 5:13 PM, Enis Bay
sing it for years until this thread, that's bad UX, git's also used
>> by a lot of non-native English speakers who may not at all get the
>> subtle difference between at and from in this context, or if they do
>> think the UI is using that subtlety to tell them somethin
Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:
> On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:
>> Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason"
>> :
>>> On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu
HEAD detached from origin/master 1 commit ag
On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:
> Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason"
> :
>>On Tue, Apr 11, 2017 at 5:13 PM, Enis Bayramoğlu
>>> HEAD detached from origin/master 1 commit ago,
>>
>>In lieu of that, which would need some of the rev-list machin
if (state.detached_at)
>>> on_what = _("HEAD detached at ");
>>>else
>>> - on_what = _("HEAD detached from
>>> &quo
on_what = _("HEAD detached &
>>diverged from ");
>>} else {
>>branch_name = "";
>> on_what = _("Not currently on any branch.&quo
se {
>branch_name = "";
> on_what = _("Not currently on any branch.");
>
>
>
No way. That would reduce the information that we give.
Note that the difference between from and at is also: are there commit
Hi,
Jeff Hostetler wrote:
> Signed-off-by: Jeff Hostetler
Usually the commit message is a place to put some of the motivation
behind the patch or why I should want to apply it. In this example,
everything is answered by the previous patch, which suggests that it
would be easier to understand
on_what = _("HEAD detached from ");
+ on_what = _("HEAD detached &
diverged from ");
} else {
branch_name = "";
on_what = _("Not currently
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
t/perf/p0005-status.sh | 51 ++
1 file changed, 51 insertions(+)
create mode 100755 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100755
i
D detached from origin/master, no longer at the same commit
nothing to commit, working directory clean
or, to be more informative
HEAD detached from origin/master 1 commit ago,
On Tue, Apr 11, 2017 at 5:55 PM, Michael J Gruber wrote:
> Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
&
Enis Bayramoğlu venit, vidit, dixit 11.04.2017 10:57:
> I've encountered a very misleading output from `git status`. Here's a
> sequence of events that demonstrates the issue:
>
> $ git --version
> git version 2.12.0
>
> $ git checkout origin/master
>
> $ g
I've encountered a very misleading output from `git status`. Here's a
sequence of events that demonstrates the issue:
$ git --version
git version 2.12.0
$ git checkout origin/master
$ git status
HEAD detached from origin/master
nothing to commit, working directory clean
$ git
On Thu, Apr 06, 2017 at 09:26:15AM -0400, Jeff Hostetler wrote:
> > > +export depth
> > > +export width
> > > +export files
> >
> > Why are these exported? test_expect_success code (unlike test_per
> > code) runs in the same shell as outside, so it doesn't seem necessary.
>
> I'm still trying t
; >>+
> >>+## (5, 10, 9) will create 999,999 files.
> >>+## (4, 10, 9) will create 99,999 files.
> >>+depth=5
> >>+width=10
> >>+files=9
> >>+
> >>+## Inflate the index with thousands of empty files and commit it.
> >>+##
+ git branch $br_work1 &&
+ git checkout $br_work1 &&
+ fill_index $dir_new $depth $width $files &&
+ git commit -m $br_work1 &&
+ git reset --hard
+'
+
+## The number of files in the branch.
+nr_work1=$(git ls-files | wc -l)
The abo
p;
> + fill_index $dir_new $depth $width $files &&
> + git commit -m $br_work1 &&
> + git reset --hard
> +'
> +
> +## The number of files in the branch.
> +nr_work1=$(git ls-files | wc -l)
The above seems to be repeated (or at least very similar
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
t/perf/p0005-status.sh | 61 ++
1 file changed, 61 insertions(+)
create mode 100755 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100755
i
On 4/5/2017 5:33 PM, Jonathan Nieder wrote:
Hi,
g...@jeffhostetler.com wrote:
+++ b/t/perf/p0005-status.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+
+test_description="Tests performance of read-tree"
+
+. ./perf-lib.sh
+
+test_perf_default_repo
+test_checkout_worktree
+
+## usage: dir depth width files
Hi,
g...@jeffhostetler.com wrote:
> +++ b/t/perf/p0005-status.sh
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +
> +test_description="Tests performance of read-tree"
> +
> +. ./perf-lib.sh
> +
> +test_perf_default_repo
> +test_checkout_worktree
> +
> +## usage: dir depth width files
> +make_paths () {
> +
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
t/perf/p0005-status.sh | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100644
i
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
t/perf/p0005-status.sh | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 t/perf/p0005-status.sh
diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
new file mode 100644
i
Ævar Arnfjörð Bjarmason writes:
> I am very tempted though to support them in parallel, if only for ease
> of performance testing and to be able to roll out support for
> grep.patternType=perl meaning pcre1 for now, but add a
> grep.patternType=pcre2 for testing (and make grep.patte
Jeffrey Walton writes:
>> Just to make sure that we are on the same page. While I do not see
>> the need to link with both variants and allow users to choose
>> between them at runtime, I do not know if the whole world is ready
>> to drop pcre1 and use pcre2 (the latter of which has only been
>>
> Just to make sure that we are on the same page. While I do not see
> the need to link with both variants and allow users to choose
> between them at runtime, I do not know if the whole world is ready
> to drop pcre1 and use pcre2 (the latter of which has only been
> around for a bit over two yea
ing builds are likely to be depending on "is it set to
> anything? then use PCRE1" behaviour, so we unfortunately cannot take
> that route.
We're on the same page, all of this makes sense, there'll be some OS's
/ environments which for years won't be packaging pcre2
Ævar Arnfjörð Bjarmason writes:
> On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> That enables the new JIT support in pcre v2:
>>>
>>> s/iterrx fixed prx
>>> rx 2.19-- -33% -44%
>>> fixed 1.47 49%-- -17%
>>> prx
On Sat, Apr 1, 2017 at 12:48 AM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> That enables the new JIT support in pcre v2:
>>
>> s/iterrx fixed prx
>> rx 2.19-- -33% -44%
>> fixed 1.47 49%-- -17%
>> prx 1.22 79% 20%--
>
> The numbers wit
Ævar Arnfjörð Bjarmason writes:
> That enables the new JIT support in pcre v2:
>
> s/iterrx fixed prx
> rx 2.19-- -33% -44%
> fixed 1.47 49%-- -17%
> prx 1.22 79% 20%--
The numbers with JIT does look "interesting".
I couldn't quite tell if there are
The recent libpcre2 got me interested in seeing what the difference in
v1 and v2 was.
So I hacked up a *very basic* patch for libpcre2 that passes all
tests, but obviously isn't ready for inclusion (I searched/replaced
all the v1 usage with v2). I'm not even bothering sending this t
Hello,
Hello, how are you doing? I want to inform you that, we have an
inheritance of a deceased client with your surname. Reply via email:
andrsi...@yandex.com with your full names for info.
Regards.
Miss. Melissa.
--
Correo Corporativo Hospital Universitar
I have tried all of that.
A colleague looked at it and he reset xrdb with xrdb -remove -all
apparently this works and my issues has been fixed.
Regards,
On Wed, Jul 27, 2016 at 10:21 AM, Trần Ngọc Quân wrote:
> On 27/07/2016 15:05, jessie hernandez wrote:
>> Dear git,
>>
>> I have been dealing
On 27/07/2016 15:05, jessie hernandez wrote:
> Dear git,
>
> I have been dealing with an issue in gitk for a while now. I do not
> know if this is a specific gitk issue or something else. I cannot find
> any information about it online.
>
> When I start gitk in my repository gitk comes up but all t
Dear git,
I have been dealing with an issue in gitk for a while now. I do not
know if this is a specific gitk issue or something else. I cannot find
any information about it online.
When I start gitk in my repository gitk comes up but all the font and
all the menus are Extremly small. (see attach
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
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
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 setting it to any specific
pager) breaks badly: the pager spa
Hi Jeff,
[please note that top-posting is discouraged on this mailing list]
On Tue, 12 Jul 2016, Jeff Hostetler wrote:
> Thanks for the feedback. I like the overall direction of your
> suggestions. Going for a porcelain V2 feels better than piling
> onto verbose. I think that would also give
itfield, like:
N - not a submodule
S[C][M][U] - is a submodule, with one or more of:
- commits (C)
- modifications (M)
- untracked files (U)
@@ -1380,7 +1382,20 @@ int cmd_status(int argc, const char **argv, const char
*prefix)
fd = hold_lock
not a submodule.
So would it be:
XY 100644 ...
with two spaces in that case?
I wonder if it would be less mysterious if the submodule data got its
own bitfield, like:
N - not a submodule
S[C][M][U] - is a submodule, with one or more of:
- commits (C)
- modifications
Hi,
On Thu, 7 Jul 2016, Jeff Hostetler wrote:
> Tools interacting with Git repositories may need to know the complete
> state of the working directory. For efficiency, it would be good to have
> a single command to obtain this information.
>
> We already have a `--porcelain` mode intended for to
een staged (i.e., like the output of `git diff`).
+ When given twice with `--porcelain`, additional output is enabled.
+ See the section entitled "Very Verbose Porcelain Format" for details.
+
-u[]::
--untracked-files[=]::
Show untracked files.
@@ -207,6 +210,86 @@
On Tue, Aug 11, 2015 at 09:34:31AM -0700, Junio C Hamano wrote:
> > As for vwritef, it exists solely to work over write(), _and_ it doesn't
> > get the "one-shot" thing right (which is probably OK, as we use it only
> > when exec fails). But we could probably teach run-command to fdopen(),
> > and
1 - 100 of 184 matches
Mail list logo
