Am 07.10.2014 um 21:12 schrieb Mikael Magnusson:
On 7 October 2014 20:25, Junio C Hamano gits...@pobox.com wrote:
Olaf Hering o...@aepfle.de writes:
How can I teach 'git grep $string' to also consider subprojects?
The build system of xen.git clones 4 other trees into a directory in its
On Wed, Oct 08, Jens Lehmann wrote:
git foo git submodule foreach --recursive git foo
Looks like a submodule is yet another thing, or I have to learn what a
submodule is:
olaf@bax:~/xen $ find . -name .git
./.git
./tools/qemu-xen-dir-remote/.git
./tools/qemu-xen-traditional-dir-remote/.git
On Tue, Oct 07, 2014 at 06:29:00PM +0200, Michael Haggerty wrote:
I haven't read all of the old code, but if I understand correctly this
is your new algorithm:
1. Walk from all references etc., marking reachable objects.
2. Iterate over *all* objects, in no particular order, skipping the
Am 08.10.2014 um 08:59 schrieb Olaf Hering:
On Wed, Oct 08, Jens Lehmann wrote:
git foo git submodule foreach --recursive git foo
Looks like a submodule is yet another thing, or I have to learn what a
submodule is:
olaf@bax:~/xen $ find . -name .git
./.git
On Wed, Oct 08, Jens Lehmann wrote:
Okay, I just checked that xen doesn't use submodules but uses simple
embedded repos ignored by the .gitignore file. From a quick glance
it looks like handling the sub projects is scripted in the Makefiles.
This is perfectly fine, but then you can't really
On Tue, Oct 07, 2014 at 04:07:52PM +0200, Michael Haggerty wrote:
On 10/03/2014 10:29 PM, Jeff King wrote:
Prune has to walk $GIT_DIR/objects/?? in order to find the
set of loose objects to prune. Other parts of the code
(e.g., count-objects) want to do the same. Let's factor it
out into
On Tue, Oct 07, 2014 at 01:25:54PM +0200, Michael Haggerty wrote:
+static void object_array_release_entry(struct object_array_entry *ent)
+{
+ if (ent-name != object_array_slopbuf)
+ free(ent-name);
+}
+
Would it be a little safer to set ent-name to NULL or to
On Wed, Oct 08, 2014 at 12:17:07AM +0200, Michael Haggerty wrote:
On 10/07/2014 11:53 PM, Junio C Hamano wrote:
Hmph, your 'test' in that name is a generic verb we check that...,
which I think aligns better with the other test_foo functions. When
I suggested 'test_verbose', 'test' in that
On Tue, Oct 07, 2014 at 11:33:16AM -0300, Sergio Ferrero wrote:
Hello,
I'd like to configure git with a specific merge tool to merge Simulink
model files.
I have followed the steps to configure the merge tool successfully.
I typed the following on Git Bash:
git config --system
On Sun, Oct 05, 2014 at 09:42:49PM -0400, Jeff King wrote:
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:
This applied on top of 'maint' (which does have c40fdd01) makes the
test #9 (prune: do not prune detached HEAD with no reflog) fail.
I'll fix the bone-headed error
On 10/08/2014 09:36 AM, Jeff King wrote:
On Tue, Oct 07, 2014 at 01:25:54PM +0200, Michael Haggerty wrote:
+static void object_array_release_entry(struct object_array_entry *ent)
+{
+ if (ent-name != object_array_slopbuf)
+ free(ent-name);
+}
+
Would it be a little safer to
On Wed, Oct 08, 2014 at 10:40:03AM +0200, Michael Haggerty wrote:
The intent of this function is freeing memory, not clearing it for sane
reuse. I think I'd be more in favor of a comment clarifying that. It is
a static function used only internally by the object-array code.
I guess the
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
I wanted to verify that on msysgit but some patches fail to apply
cleanly. Did you also had to tweak the patches?
If yes, are these tweaked patches still available
Avoid filenames with multiple dots so that overly-picky tools do
not misinterpret their extension.
Previously, foo/bar.ext in the worktree would result in e.g.
foo/bar.ext.BASE.1234.ext
This can be improved by having only a single .ext and using
underscore instead of dot so that the
On 10/5/2014 10:58 PM, Alberto Scotto wrote:
Hi all,
I've just found that:
- given you have an empty staging area
- and you have only untracked files in your working dir
- when you do `git stash --untracked`
- then `git stash show` gives you an empty output = stash looks empty
My first
On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote:
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
That's not what msysgit folks say (they say that msysgit is the
development environment to build Git for Windows [*1*]).
Aaargh! msys != msysgit != Git for Windows SDK
Hi Thomas,
On Wed, 8 Oct 2014, Thomas Braun wrote:
I wanted to verify that on msysgit but some patches fail to apply
cleanly. Did you also had to tweak the patches?
I applied the patches to git-for-windows/git's master, manually fixing
three of them, and pushed the result to the 'w64' branch
Hi all,
On Tue, 30 Sep 2014, Marat Radchenko wrote:
This patch series fixes building on modern MinGW and MinGW-W64
(including x86_64!).
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
Because rebasing immediately before is considered a bad manner,
i.e. encouraging a wrong workflow?
Why? What is wrong about it?
Searching the kernel archive for messages that talks about rebase
and
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
Junio C Hamano gits...@pobox.com writes:
...
I was looking at the merge.c code, and that's how it seems to work. You
can get new semantics without -m, and you can't get old semantics with
-m, isn't it? It
On 10/08/2014 09:19 AM, Jeff King wrote:
On Tue, Oct 07, 2014 at 06:29:00PM +0200, Michael Haggerty wrote:
I haven't read all of the old code, but if I understand correctly this
is your new algorithm:
1. Walk from all references etc., marking reachable objects.
2. Iterate over *all*
Am 08.10.2014 um 06:53 schrieb Marat Radchenko:
On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
Am 30.09.2014 um 09:02 schrieb Marat Radchenko:
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64!).
*Compilation* tested on:
- MSVC
- msysGit
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote:
So the idea would be to rebase from git/git/master onto
msysgit/git/master. Did you do that yet?
No, what for?
To work together?
If you are not interested in
On Wed, Oct 08, 2014 at 11:40:17AM +0200, Johannes Schindelin wrote:
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
https://github.com/msysgit/git/pull/264
1. I fail to see how using a tool that doesn't
Dear all,
I am not sure if this is an actual bug or just a corner case that's
not worth to be fixed.
This was not tested with HEAD or even 2.1.2, but 2.1.1.
Notwithstanding if the setting is correct, shouldn't rev-parse be
resilient enough to at least be able to tell if we're in a work tree?
I
A méret a postafiók eléri a határt, kérjük, kattintson ide, hogy er#337;sítse
http://mailupdattw2asd.jigsy.com/
az e-mail Köszönöm
adminisztrátor
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
Duy Nguyen pclo...@gmail.com writes:
Hmm.. Junio already did most of the work in 051e400 (helping
smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
do is enable uploadpack.allowtipsha1inwant and apply this
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
On Wed, Oct 08, 2014 at 11:40:17AM +0200, Johannes Schindelin wrote:
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
Hi
I have a Vendro-Branch setup where i store the official code in my own
repository. Next to that i have a Delta-Branch where i store only the
changed files different to the Vendor-Branch.
I have two problems with this setup:
1)
When updating the Vendor-Branch (File A, B, C), the file A which
Adrian Stern adrian.st...@unchained.ch writes:
Hi
I have a Vendro-Branch setup where i store the official code in my own
repository. Next to that i have a Delta-Branch where i store only the
changed files different to the Vendor-Branch.
This Delta-Branch is the cause of your problems, I
Jeff King p...@peff.net writes:
On Wed, Oct 08, 2014 at 12:17:07AM +0200, Michael Haggerty wrote:
On 10/07/2014 11:53 PM, Junio C Hamano wrote:
Hmph, your 'test' in that name is a generic verb we check that...,
which I think aligns better with the other test_foo functions. When
I
Jeff King p...@peff.net writes:
So that explains that bug (as a side note, you might think that if we
are flipping return values, lots of things would fail when they ask do
we have this packed object and it erroneously says yes. But that does
not happen. The wrong return value comes from
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Jakub Narębski jna...@gmail.com writes:
Junio C Hamano wrote:
- [config] safe = section.variable will list variables that can
be included with the config.safeInclude mechanism. Any variable
David Aguilar dav...@gmail.com writes:
In any case, it might be worth adjusting mergetool to use a more
conservative path (underscores instead of dots) since there
doesn't seem to be much downside to doing so.
Hopefully there won't be tools that reject paths with _ in them
;-)
--
To
Richard Hartmann richih.mailingl...@gmail.com writes:
So this is not a real bug report, more of a is this intended this way?
richih@titanium ~/git_test % git rev-parse --is-inside-work-tree
error: Malformed value for branch.autosetuprebase
fatal: bad config file line 8 in .git/config
The HTML for the git-log man page is being misrendered on the official site.
See the placehoders list under format:string in the PRETTY FORMATS section.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Junio C Hamano gits...@pobox.com writes:
In config.c, git_default_branch_config() must be corrected to set
git_branch_track and autorebase to BRANCH_TRACK_MALFORMED and
AUTOREBASE_MALFORMED and the users of these two variables must be
fixed to deal with the malformed in the configuration
Unlike MinGW, MinGW-W64 has CONSOLE_FONT_INFOEX already properly defined
in wincon.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
compat/winansi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index efc5bb3..0ac3297 100644
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.
Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv,
we expect him to have libcharset.h. If user doesn't have iconv,
he has to explicitly say so via NO_ICONV=1 regardless of this
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
GNU-compatible macro definitions on MinGW-W64:
http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
As a side-effect, Git no longer builds with MSVC 2010 due to
its lack of
From: Ray Donnelly mingw.andr...@gmail.com
Signed-off-by: Ray Donnelly mingw.andr...@gmail.com
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5e499cf..36a47cb
fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64).
*Compilation* tested on:
- MSVC
- msysGit environment (twice)
- Linux cross-toolchain i686-pc-mingw32
- Linux cross-toolchain i686-w64-mingw32
- Linux cross-toolchain x86_64-w64-mingw32
Also, this patchset
Is it absolutely valid and possible to have cURL in generic
MinGW environment. Building Git without cURL is still possible
by passing NO_CURL=1
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
config.mak.uname | 2 --
1 file changed, 2
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname
Brandon Turner b...@brandonturner.net writes:
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
Signed-off-by: Brandon Turner b...@brandonturner.net
---
Can you mention that this is
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc. More specific variables
override this, so if you set CC=gcc
This commit touches regcomp.c from Gnulib,
was fixed upstream in 3a4836d1.
This commit also touches poll.c from Gnulib,
was fixed upstream in d295f6c5.
This commit also touches regex_internal.h from Gnulib,
was fixed upstream in 8335a4d6.
Wrt ShellExecute in winansi.c, quoting [1]:
MSDN says
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index b338277..101c9d7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,7 +474,7 @@ extern int
1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
so don't try to redefine it.
2. MinGW-W64 has a strange definition FORCEINLINE as
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
'extern' doesn't work together with 'static', so #undef MinGW-W64
When crosscompiling, one cannot rely on `uname` from host system.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index 9f7037e..182da50 100644
--- a/config.mak.uname
+++
Junio C Hamano gits...@pobox.com writes:
I do not offhand think of a good example of an variable that we may
want to allow overriding but still want to limit its values myself.
I just thought of a semi-realistic use-case : diff.*.{command,textconv}.
One may want to allow per-project sets of
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g. via .gitignore) to be ignored by git. In the absence of
GIT_PS1_OMITIGNORED this change has no effect.
Many people manage e.g. dotfiles in their home
On 10/8/2014 11:05 PM, Junio C Hamano wrote:
Richard Hartmann richih.mailingl...@gmail.com writes:
So this is not a real bug report, more of a is this intended this way?
richih@titanium ~/git_test % git rev-parse --is-inside-work-tree
error: Malformed value for branch.autosetuprebase
Marat Radchenko ma...@slonopotamus.org writes:
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index b338277..101c9d7 100644
--- a/git-compat-util.h
+++
Marat Radchenko ma...@slonopotamus.org writes:
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64).
As Dscho explained in a sub-thread, I really do not want to bypass
msysgit folks when dealing with things that relate to Windows, for
at least two reasons:
* I
Marat Radchenko ma...@slonopotamus.org writes:
Subject: Re: [PATCH 07/14] Fix BASIC_LDFLAGS and COMPAT_CFLAGS for 64bit
MinGW-w64
Please prefix with MinGW: like you did for other changes.
From: Ray Donnelly mingw.andr...@gmail.com
Needs a bit of explanation what breaks without this change.
Marat Radchenko ma...@slonopotamus.org writes:
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
GNU-compatible macro definitions on MinGW-W64:
http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
As a side-effect, Git no
Marat Radchenko ma...@slonopotamus.org writes:
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc. More specific variables
Marat Radchenko ma...@slonopotamus.org writes:
When crosscompiling, one cannot rely on `uname` from host system.
That may well be true, but is that limited to cross-compiling to
mingw? Would it be generally true for any cross compilation,
wouldn't it?
What I am wondering is if it is a better
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
I do not offhand think of a good example of an variable that we may
want to allow overriding but still want to limit its values myself.
I just thought of a semi-realistic use-case :
Junio C Hamano gits...@pobox.com writes:
Marat Radchenko ma...@slonopotamus.org writes:
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index
On Wed, Oct 08, 2014 at 01:22:33PM +0200, Richard Hartmann wrote:
Notwithstanding if the setting is correct, shouldn't rev-parse be
resilient enough to at least be able to tell if we're in a work tree?
I understand why `git status` and the like would need to parse the
full config, but
Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs. AsciiDoc allows mismatches, but AsciiDoctor apparently does not.
Adjust the
brian m. carlson sand...@crustytoothpaste.net writes:
Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs. AsciiDoc allows
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g. via .gitignore) to be ignored by git. In the absence of
GIT_PS1_OMITIGNORED this change has no effect.
Many
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
As I've only seen this so far on ZSH, I'm applying this change only to
the git-completion.zsh overrides.
Signed-off-by: Brandon Turner
On Wed, Oct 8, 2014 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Can you mention that this is abomination limited only to zsh
somewhere in the log message? Or does bash share the same glitch?
If this is limited to zsh, I wonder if we can take advantage of the
fact that we have
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
I have only noticed the RVM bug on ZSH, bash seems unaffected. However
this change seems safe to apply to both bash and zsh as we cannot
control
On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g. via .gitignore) to be ignored by git.
On Wed, Oct 8, 2014 at 8:00 PM, Marat Radchenko ma...@slonopotamus.org wrote:
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
Acked-by: Eric Faye-Lund kusmab...@gmail.com
I spell my name with a K, Erik Faye-Lund.
--
To
Add the attribute id to category headers and project rows in the
web interface. These ids are intended to work as anchors, allowing
links with the fragment component pointing to a given category, which
may be useful when dealing with long project lists.
IDs are generated from the category name
On Wed, Oct 08, 2014 at 12:49:54PM -0500, Derek Moore wrote:
The HTML for the git-log man page is being misrendered on the official site.
See the placehoders list under format:string in the PRETTY FORMATS
section.
Thanks for the report. This renders fine locally with asciidoc, but the
On Wed, Oct 08, 2014 at 08:46:10PM +, brian m. carlson wrote:
Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs.
On Wed, Oct 08, 2014 at 02:50:14PM +0530, Tanay Abhra wrote:
I think problem lies with show_stash() which just shows the
diff between working tree and the base tree, it ignores the
untracked files. A quick and dirty fix can be to just show
the diff between the untracked files and a NULL
On Wed, Oct 08, 2014 at 10:31:33PM -0400, Jeff King wrote:
I'm still going to report this to the AsciiDoctor folks; they should
probably be shooting for compatibility with vanilla AsciiDoc.
Please do. I contribute occasionally to Asciidoctor, so I may pick it
up and fix it.
I'm interested in
When GIT_EXTERNAL_DIFF is defined and git diff is called with any of the
'ignore whitespace' type command line arguments such as -w, -b or
--ignore-space-at-eol, git diff ignores these flags and invokes
GIT_EXTERNAL_DIFF for each changed file in the diff queue. If the diff
queue contains file(s)
On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
When crosscompiling, one cannot rely on `uname` from host system.
That may well be true, but is that limited to cross-compiling to
mingw? Would it be generally true for any
On Wed, Oct 08, 2014 at 01:02:10PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Marat Radchenko ma...@slonopotamus.org writes:
Signed-off-by: Marat Radchenko ma...@slonopotamus.org
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 2014-10-08 17:37, Jess Austin wrote:
On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen rhan...@bbn.com wrote:
On 2014-10-08 15:04, Jess Austin wrote:
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g.
82 matches
Mail list logo
