I find that preview 1.8 is bluescreening on about 1 of 3 ssh pushes.
1.9 preview 12-17-2014 doesn't even bluescreen, the windows gui locks
until reset.
Sample command:
git push omv master\r
config. =
[core]
repositoryformatversion = 0
filemode = false
bare = false
Can I submit this as a bug report, that sending something from the
gmail client results in this response?
Delivery to the following recipient failed permanently:
git@vger.kernel.org
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
While we are here, remove some boilerplate by using test_commit.
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 27557d6..86ceb38 100755
--- a/t/t7300-clean.sh
+++ b
On Mon, Aug 31, 2015 at 8:54 PM, Jeff King wrote:
> On Sun, Aug 30, 2015 at 11:18:09AM +0200, Erik Elfström wrote:
>
> Unfortunately CHAIN_LINT cannot reach inside a nested subshell. I cannot
> think of a way to make it do so, and besides, that is also the way to
> overri
first version.
(Forgot to include the list in my first reply, sorry... And forgot to
turn off HTML in the second... sigh, sorry for the spam)
/Erik
--
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 http://vger.kernel.org/majordomo-info.html
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
cache.h | 11 -
setup.c | 84 ++---
2 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/cache.h b/cache.h
index 571c98f..25578cb 100644
--- a/cache.h
+++ b/cache.h
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 142 +++
1 file changed, 142 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..fbfdf2d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,148
fficiently unreasonable size that should never be exceeded by a
genuine .git file.
Signed-off-by: Erik Elfström
---
cache.h | 1 +
setup.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/cache.h b/cache.h
index 25578cb..858d9b3 100644
--- a/cache.h
+++ b/cache.h
@@ -454,6 +454,7 @@ ex
.
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file size in read_gitfile_gently
t7300: add tests to document behavior of clean and nested git
p7300: add performance tests for clean
clean: improve performance when removing lots of directories
builtin
1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 30 ++
t/t7300-clean.sh | 10 --
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 6dcb72e..df53def 100644
On Sun, Jun 14, 2015 at 5:42 AM, Eric Sunshine wrote:
>
> This variable name doesn't convey much about its purpose, and
> introduces a bit of maintenance burden if the limit is some day
> changed. Perhaps "sane_size_limit" or something even more descriptive
> (and/or terse) would be better.
>
Wou
fficiently unreasonable size that should never be exceeded by a
genuine .git file.
Signed-off-by: Erik Elfström
---
cache.h | 1 +
setup.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/cache.h b/cache.h
index 25578cb..858d9b3 100644
--- a/cache.h
+++ b/cache.h
@@ -454,6 +454,7 @@ ex
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
cache.h | 11 -
setup.c | 84 ++---
2 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/cache.h b/cache.h
index 571c98f..25578cb 100644
--- a/cache.h
+++ b/cache.h
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 142 +++
1 file changed, 142 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..fbfdf2d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,148
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
This is v8 of this series. v7 can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/271220
Changes in v8:
* change name and type of file size limit variable in read_git_file_gently
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file
1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 30 ++
t/t7300-clean.sh | 10 --
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 6dcb72e..df53def 100644
On Fri, Jun 26, 2015 at 11:03 AM, Jeff King wrote:
> I happened to be playing with clang's static analyzer today, and it
> noticed that there is a subtle use-after-free here.
Doh, sorry about that. Thanks for fixing my bug.
/Erik
--
To unsubscribe from this list: send the line "
% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/archive-extracted-xz || echo "directory doesn't
exist"
directory doesn't ex
On Thu, Jul 07, 2016 at 04:39:26PM -0700, Jacob Keller wrote:
On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson wrote:
% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d
On Fri, Jul 08, 2016 at 05:41:17PM -0700, Jacob Keller wrote:
On Thu, Jul 7, 2016 at 5:36 PM, Erik Johnson wrote:
I'm not expecting _any_ git branch command to prune worktrees, but a
branch _deletion_ shouldn't fail because git thinks the branch is
checked out in a worktree that doe
On Fri, Jul 08, 2016 at 09:58:26PM -0700, Jacob Keller wrote:
On Fri, Jul 8, 2016 at 7:22 PM, Erik Johnson wrote:
On Fri, Jul 08, 2016 at 05:41:17PM -0700, Jacob Keller wrote:
It is possible we should update "git branch -d" should perform a
worktree prune first, since that would en
*/
Technically we don't have a valid .git file here but we have something
that really tries to be. I guess it is debatable what the correct
conservative choice is here and if it is the same for all callers.
/Erik
--
To unsubscribe from this list: send the line "unsubscribe git" i
s an invalid reflog entry. Why should 0 be treated as an
invalid timestamp (even if it's unlikely outside of corner cases)?
Thanks,
Erik
--
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 http://vger.kernel.org/majordomo-info.html
age) which would indicate
that strtoul failed, but checking for errno==ERANGE sounds good. +1
on the patch modulo setting errno = 0 first.
Thanks,
Erik
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
When creating shortcuts for git bash on Windows machines, the "Target"
contains the command "C:\PF\Git\git-bash.exe --cd-to-home" and the
"Start In" field contains %HOMEDRIVE%%HOMEPATH%.
This is redundant, and makes it harder to modify the shortcut to start
bash in the user's directory of choice.
When pushing an existing local repo to a new remote repo, git 2.6.3
misidentifies the user's home directory on a domain-connected Windows
machine. My machine is running Win7-64 and I have tried both the 32-bit
and 64-bit version of git.
For example, the following sequence fails on the last command
but
instead just run any of them.
Thank you for Git. Maybe I'll see this feature in the future!
Best,
Erik
Getting the following error for a submodule when using git/ssh:
$ git clone --recursive ssh://incense:/home/erik/git/nacl.git
Cloning into 'nacl'...
remote: Counting objects: 32, done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 32 (delta 5), reused 0 (delta 0)
Ah. I was able to get it to work with the ssh protocol and a relative
path. Thank you for your help.
On Fri, Apr 28, 2017 at 8:45 AM, Chris Packham wrote:
> Hi Erik,
>
> On Fri, Apr 28, 2017 at 11:25 AM, Erik Haller wrote:
>> Getting the following error for a submodule whe
I hunted around for the bugreport email on mysgit but couldn't seem to
find it. It seems in the foggy recesses I remember reading about an
ssh issue with windows, but can't find it now.
On Wed, Feb 11, 2015 at 3:56 AM, Chris Packham wrote:
> Hi Erik,
>
> On Tue, Feb 10, 2015
Thu, Feb 12, 2015 at 4:33 AM, Chris Packham wrote:
> On Thu, Feb 12, 2015 at 1:33 AM, Erik Friesen wrote:
>> Pushing over http and https are unaffected.. My linux nas died, so on
>> rebuild I tried to do the ssh thing, and realized quite soon that
>> things weren't right.
r, I'd say it will have issues.
>
> At minimum, this should be on the list for others to view. I have run
> across problems from others, but I don't think they realized it could
> be an ssh problem.
>
> On Thu, Feb 12, 2015 at 4:33 AM, Chris Packham
> wrote:
>&g
The nature of a bluescreen doesn't make debugging and reproduction
real easy. If it helps, I can get the dumps from those crashes. To
move on, I moved back to local http pushes.
On Thu, Feb 12, 2015 at 7:42 AM, Thomas Braun
wrote:
> Am Donnerstag, den 12.02.2015, 07:21 -0500 schrieb Erik Frie
le to bypass it, maybe by calling
resolve_gitlink_ref_recursive directly or by using some other way of
checking for the presence of a git repo in clean.c:remove_dirs?
/Erik
--
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 http://vger.kernel.org/majordomo-info.html
That looks like the same issue. The "use is_git_directory" approach
sounds good to me, is that the direction you would prefer? I can try
to cobble something together although I must warn you I have zero
previous experience with this code base so a few iterations will
probably be needed.
when
reviewing.
Jeff King also expressed concerns that we may have similar performance
issues in other commands and that it could be good to unify these "is
this a repo?"-checks. This series only attempts to solve the git-clean
case.
Erik Elfström (3):
t7300: add tests to document behavi
1.7s after this change.
Signed-off-by: Erik Elfström
Helped-by: Jeff King
---
builtin/clean.c | 23 +++
t/t7300-clean.sh | 4 ++--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 98c103f..e951bd9 100644
--- a/builtin/cl
Signed-off-by: Erik Elfström
---
These tests were added so that I could understand the corner case
behaviors of clean and nested repositories and document the changes in
behavior that this series will cause. The ones marked as expect
failure will be changed to expect success later in the series
Signed-off-by: Erik Elfström
---
t/perf/p7300-clean.sh | 37 +
1 file changed, 37 insertions(+)
create mode 100755 t/perf/p7300-clean.sh
diff --git a/t/perf/p7300-clean.sh b/t/perf/p7300-clean.sh
new file mode 100755
index 000..3f56fb2
--- /dev/null
will fix!
On Tue, Apr 7, 2015 at 12:06 AM, Eric Sunshine wrote:
> On Mon, Apr 6, 2015 at 7:48 AM, Erik Elfström wrote:
>> Signed-off-by: Erik Elfström
>> ---
>> diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
>> index 99be5d9..cfdf6d4 100755
>> --- a/t/t7300-c
p" option to be called be before each
iteration.
On Tue, Apr 7, 2015 at 12:09 AM, Eric Sunshine wrote:
> On Mon, Apr 6, 2015 at 4:40 PM, Torsten Bögershausen wrote:
>> On 2015-04-06 13.48, Erik Elfström wrote:
>>> Signed-off-by: Erik Elfström
>>> ---
>&g
On Tue, Apr 7, 2015 at 12:10 AM, Eric Sunshine wrote:
> On Mon, Apr 6, 2015 at 7:48 AM, Erik Elfström wrote:
>> Before this change, clean used resolve_gitlink_ref to check for the
>> presence of nested git repositories. This had the drawback of creating
>> a ref_cache entr
ray index
* use size_t instead of int for strbuf->len
fixes held back for cleanup patches:
* fixed existing broken && chains
* added assert in existing code to guard against
negative array index
Thanks to Eric Sunshine and Torsten Bögershausen for the very helpful
review!
Erik Elf
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 72
1 file changed, 72 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..58e6b4a 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,78
ray index
* use size_t instead of int for strbuf->len
fixes held back for cleanup patches:
* fixed existing broken && chains
* added assert in existing code to guard gainst
negative array index
Thanks to Eric Sunshine and Torsten Bögershausen for the very helpful
review!
Erik Elfströ
1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 24
t/t7300-clean.sh | 4 ++--
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 98c103f..b679913 100644
--- a/builtin/cl
Signed-off-by: Erik Elfström
---
t/perf/p7300-clean.sh | 37 +
1 file changed, 37 insertions(+)
create mode 100755 t/perf/p7300-clean.sh
diff --git a/t/perf/p7300-clean.sh b/t/perf/p7300-clean.sh
new file mode 100755
index 000..af50d5d
--- /dev/null
On Sat, Apr 11, 2015 at 7:59 PM, Thomas Gummerer wrote:
> On 04/11, Erik Elfström wrote:
>> Signed-off-by: Erik Elfström
>> ---
>> t/perf/p7300-clean.sh | 37 +
>> 1 file changed, 37 insertions(+)
>> create mode 100755 t/per
On Wed, Apr 15, 2015 at 7:56 PM, Junio C Hamano wrote:
> Erik Elfström writes:
>
>> Before this change, clean used resolve_gitlink_ref to check for the
>> presence of nested git repositories. This had the drawback of creating
>> a ref_cache entry for every directory th
we won't clean either. How serious is this? Is there
an easy fix (preferebly to clean all bare repositories)?
* Still have issues in the performance tests, see comments
from Thomas Gummerer on v2
Thanks to Junio C Hamano and Jeff King for spotting fundamental
problems in v2 and suggesti
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
If this is going to be used for speculative probing should there
be a sanity check before:
buf = xmalloc(st.st_size + 1);
len = read_in_full(fd, buf, st.st_size);
Something like:
if (st.st_size > PATH_MA
Signed-off-by: Erik Elfström
---
t/perf/p7300-clean.sh | 37 +
1 file changed, 37 insertions(+)
create mode 100755 t/perf/p7300-clean.sh
diff --git a/t/perf/p7300-clean.sh b/t/perf/p7300-clean.sh
new file mode 100755
index 000..af50d5d
--- /dev/null
00 sub
directories went from 61s to 1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 25 +
t/t7300-clean.sh | 8 +++-
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 127 +++
1 file changed, 127 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..4b9a72a 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,133
On Sun, Apr 19, 2015 at 3:14 AM, Junio C Hamano wrote:
> Erik Elfström writes:
>
>> Known Problems:
>> * Unsure about the setup.c:read_gitfile refactor, feels a bit
>> messy?
>
> The interface indeed feels somewhat messy. I suspect that a better
tests, either directly in this series or as a follow
up if that is preferred.
/Erik
On Tue, Apr 21, 2015 at 12:14 AM, Thomas Gummerer wrote:
> On 04/18, Erik Elfström wrote:
>> * Still have issues in the performance tests, see comments
>> from Thomas Gummerer on v2
>
&g
eneral performance test if
we only do "half" the clean? Admittedly we clearly lose some value in
the current state as well due to the copying taking more time than the
cleaning. I could go either way here.
/Erik
--
To unsubscribe from this list: send the line "unsubscribe git" in
the b
On Wed, Apr 22, 2015 at 9:46 PM, Jeff King wrote:
> On Wed, Apr 22, 2015 at 09:30:20PM +0200, erik elfström wrote:
>>
>> Yes, that is the problem. A dry run will spot this particular performance
>> issue but maybe we lose some value as a general performance test if
>>
message in [5/5] to more clearly motivate
remaining behavioral changes of git clean.
Thanks to Junio C Hamano and Jeff King for comments and help on v3.
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file size in read_gitfile_gently
t7300: add tests to
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
cache.h | 3 ++-
setup.c | 82 +++--
2 files changed, 67 insertions(+), 18 deletions(-)
diff --git a/cache.h b/cache.h
index 3d3244b..6e29068 100644
--- a/cache.h
+++ b/cache.h
tracked directory containing 10 sub
directories went from 61s to 1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 26 ++
t/t7300-clean.sh | 8 +++-
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/buil
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
fficiently unreasonable size that should never be exceeded by a
genuine .git file.
Signed-off-by: Erik Elfström
---
I'm not sure about this one but it felt like the safe thing to do.
This patch can be dropped if it is not desired.
I considered testing it using
"mkdir foo &&am
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 128 +++
1 file changed, 128 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..11f3a6d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,134
On Sat, Apr 25, 2015 at 6:47 PM, Junio C Hamano wrote:
> I do not think it is wrong per-se, but the changes in this patch
> shows why hardcoded values assigned to error_code without #define is
> not a good idea, as these values are now exposed to the callers of
> the new function. After we gain a
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
cache.h | 11 -
setup.c | 82 +++--
2 files changed, 75 insertions(+), 18 deletions(-)
diff --git a/cache.h b/cache.h
index 3d3244b..868e4d3 100644
--- a/cache.h
+++ b/cache.h
Changes in v5:
* Added defines for read_gitfile_gently error codes.
This was a silly mistake, sorry about that.
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file size in read_gitfile_gently
t7300: add tests to document behavior of clean and nested git
fficiently unreasonable size that should never be exceeded by a
genuine .git file.
Signed-off-by: Erik Elfström
---
cache.h | 1 +
setup.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/cache.h b/cache.h
index 868e4d3..c9f1f8e 100644
--- a/cache.h
+++ b/cache.h
@@ -439,6 +439,7 @@ ex
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 128 +++
1 file changed, 128 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..11f3a6d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,134
tracked directory containing 10 sub
directories went from 61s to 1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 26 ++
t/t7300-clean.sh | 8 +++-
2 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/buil
le the paths
in the tree then there seem to be little point in trying to go on (as
opposed to when
some string in a file is too large for a path)
Thoughts?
/Erik
--
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 http://vger.kernel.org/majordomo-info.html
On Tue, Apr 28, 2015 at 8:33 AM, Jeff King wrote:
>
> Do we actually need a large repo here? The real cost is coming from the
> directories we create. We could actually start with a totally empty
> repository if we wanted (though I don't think the t/perf system handles
> that right now). But if th
ce.
Overall it seems like a less attractive solution to me but I can be
persuaded if there is more support expressed for the strbuf direction.
/Erik
--
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 http://vger.kernel.org/majordomo-info.html
be best to leave the generalization and making it public
for future work.
/Erik
--
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 http://vger.kernel.org/majordomo-info.html
1.7s after this change.
Helped-by: Jeff King
Signed-off-by: Erik Elfström
---
builtin/clean.c | 31 +++
t/t7300-clean.sh | 10 --
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 98c103f..d739dcf
er and consider that
string the file name, drop the idea of trees at all and add the
information that is traditionally stored in tree objects directly in a
commit object. Wouldn't that be much simpler and still accomplish the
same? I think the idea of keeping information in separate small files
On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano wrote:
> While the last statement applies to other parts of the system, it is
> not true for the in-core index design. We always had a flat index,
> and it is not cheating at all. The original "tree" was also a flat
> representation of everything u
to object store recursively bottom-up,
tracking the sha1 of child trees for parent trees
4. add root-sha1 and commit-msg to memory commit object (author,
committer and so on can be added later)
5. write commit object to object store
6. update HEAD (branches will be added later)
7. clean i
make sense. What is your opinion?
[1]
https://github.com/git/git/blob/master/Documentation/technical/index-format.txt
Cheers
Erik
--
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 http://vger.
once
you modify a cow-linked file, the file contents are copied, the file is
unlinked and you can safely work on the new file. It has some horrible
semantics in that the inode number of the opened file changes, I don't
know if applications are or should be aware of that.
Erik
--
+-- Erik Mouw -
On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin
wrote:
> Hi Johannes,
>
> On 2015-08-11 22:51, Johannes Sixt wrote:
>> Invoking plink requires special treatment, and we have support and even
>> test cases for the commands 'plink' and 'tortoiseplink'. We also support
>> .exe variants for these
On Thu, Aug 13, 2015 at 10:37 AM, Johannes Schindelin
wrote:
> Hi kusma,
>
> On 2015-08-12 13:58, Erik Faye-Lund wrote:
>> On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin
>> wrote:
>>>
>>> On 2015-08-11 22:51, Johannes Sixt wrote:
>>>> Inv
ort for
this for a while now.
I imagine other large code hosts could benefit from this as well and
I'd love to gauge the group's interest for this. Could this make sense
for Git? Would it have a chance of landing?
Our spike implements it as an optional capability during ref
advertisement. What are your thoughts on this?
Cheers,
Erik
credential.c, run_credential_helper(): now ignores SIGPIPE
when writing to credential helper. Avoids problem with race
where cred helper exits very quickly and, after, git tries
to write to it, generating SIGPIPE and crashing git. To
reproduce this the cred helper must not read from STDIN.
This
reasonable for it to take down the parent Git
process with SIGPIPE.
Even with such a helper, seeing this problem should be rare. Getting
SIGPIPE requires the helper racily exiting before we've written the
fairly small credential output.
Signed-off-by: Erik E Brady
---
credential.c | 3
I.e. "Squash 'somedir' changes" and not "Squashed ..."
See
https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L463
s.
2. If not "used on the Git project itself" (I assume it will always be
used on A Git project), changing the commit title to be in line with
the rest would not hurt anyone.
Bjørn Erik
2017-08-04 23:21 GMT+02:00 Junio C Hamano :
> Bjørn Erik Pedersen writes:
>
>> I.
On Tue, Feb 18, 2014 at 3:33 AM, Mike Hommey wrote:
> On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote:
>> Hopefully the Postfix Greylisting Policy Server will not try again to
>> greylist me, as it might however do without violating the RFC.
>>
>> -- Forwarded message -
On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
> diff --git a/Makefile b/Makefile
> index dddaf4f..0334806 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -316,6 +321,7 @@ endif
> ifeq ($(uname_S),Windows)
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> + HAVE_ALL
On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote:
> On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
>> diff --git a/Makefile b/Makefile
>> index dddaf4f..0334806 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -316,6 +321,7 @@ e
On Fri, Feb 28, 2014 at 6:00 PM, Kirill Smelkov wrote:
> On Fri, Feb 28, 2014 at 02:50:04PM +0100, Erik Faye-Lund wrote:
>> On Fri, Feb 28, 2014 at 2:44 PM, Erik Faye-Lund wrote:
>> > On Mon, Feb 24, 2014 at 5:21 PM, Kirill Smelkov wrote:
>> >> diff --git a/M
On Fri, Feb 28, 2014 at 11:38 PM, Robert Dailey
wrote:
> Is there a way to change color scheme in msysgit without going through
> the Properties >> Colors settings?
>
> Reason I ask is because I share the same HOME directory and .bashrc
> file between msysgit and cygwin, and it'd be nice to use th
On Wed, Apr 9, 2014 at 2:48 PM, Kirill Smelkov wrote:
> On Thu, Mar 27, 2014 at 06:22:50PM +0400, Kirill Smelkov wrote:
>> On Mon, Mar 24, 2014 at 02:47:24PM -0700, Junio C Hamano wrote:
>> > Kirill Smelkov writes:
>> >
>> > > On Fri, Feb 28, 2014 at
On Fri, Apr 11, 2014 at 9:25 PM, Junio C Hamano wrote:
> The motion is about this:
>
> Outside people, like the party who approached us about putting
> our logo on their trinket, seem to associate that logo we see on
> git-scm.com today with our project, but we never officially said
>
On Mon, Apr 14, 2014 at 5:14 PM, Johannes Schindelin
wrote:
> Dear friends of Git for Windows,
>
> it was very delightful to be on the show, hosted by Thomas Ferris
> Nicolaisen:
>
> http://episodes.gitminutes.com/2014/04/gitminutes-28-johannes-schindelin-on.html
Really enjoyable, thanks!
--
To u
From: Erik Faye-Lund
On Windows, absolute paths might start with a DOS drive prefix,
which this check fails to recognize.
Unfortunately, we cannot simply use the file_name_is_absolute
helper in File::Spec::Functions, because Git for Windows has an
MSYS-based Perl, where this helper doesn't
On Tue, Apr 15, 2014 at 12:32 PM, Johannes Sixt wrote:
> Am 4/15/2014 10:44, schrieb Erik Faye-Lund:
>> From: Erik Faye-Lund
>>
>> On Windows, absolute paths might start with a DOS drive prefix,
>> which this check fails to recognize.
>>
>>
1 - 100 of 422 matches
Mail list logo
