On Tue, Apr 29, 2014 at 11:08:29PM -0500, Felipe Contreras wrote:
If we use a different conflict style `git rerere forget` is not able to
find the matching conflict SHA-1 because the diff generated is actually
different from what `git merge` generated.
Can you show an example or test case?
I
Mark Lodato wrote:
Previously, git-completion.zsh redefined complete() to make
__git_complete() a no-op. This broke zsh's built-in bash completion
compatibility layer (bashcompinit), which defines its own complete().
How exactly? I'm testing this and I don't see any problems. I run
'type -f
Phil Pennock wrote:
The bash completion pulled into zsh was being pulled in _as_ zsh, but
used patterns which relied on falling through as unhandled. In zsh
5.0.3 this no longer works, resulting in:
__git_complete_remote_or_refspec:33: bad pattern: +*
Fix by telling zsh to emulate sh
From: Pat Thoyts pattho...@users.sourceforge.net
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
Another one from msysGit project.
Original subject by Pat; I would suggest:
wincred: improve Makefile
Piotr Krukowiecki piotr.krukowie...@gmail.com wrote:
On Mon, Apr 28, 2014 at 9:26 PM, Aaron Laws dartm...@gmail.com wrote:
The way I understand it, when `git svn dcommit` is run, new commits
are created (A' is created from A adding SVN information), then the
current branch is moved to point
Jeff King wrote:
On Tue, Apr 29, 2014 at 11:08:29PM -0500, Felipe Contreras wrote:
If we use a different conflict style `git rerere forget` is not able to
find the matching conflict SHA-1 because the diff generated is actually
different from what `git merge` generated.
Can you show an
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag (chop long lines), on the other hand, is not related
to Git and is a
Am 29.04.2014 11:12, schrieb Marat Radchenko:
On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
Fix `warning: passing argument 2 of 'mingw_main' from incompatible
pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
Would you mind cross checking your changes
On Wed, Apr 30, 2014 at 10:35 AM, Karsten Blees karsten.bl...@gmail.com wrote:
Am 29.04.2014 11:12, schrieb Marat Radchenko:
On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
Fix `warning: passing argument 2 of 'mingw_main' from incompatible
pointer type` in http-fetch.c and
strbuf_trim strips whitespace from the end, then the beginning of a
strbuf. Those operations are duplicated in strbuf_rtrim and
strbuf_ltrim.
Replace strbuf_trim implementation with calls to strbuf_rtrim,
then strbuf_ltrim.
Signed-off-by: Brian Gesiak modoca...@gmail.com
---
This is tangential
API documentation for strbuf does not document strbuf_trim or
strbuf_ltrim. Add documentation for these two functions.
Signed-off-by: Brian Gesiak modoca...@gmail.com
---
Documentation/technical/api-strbuf.txt | 9 +
1 file changed, 9 insertions(+)
diff --git
On Wed, Apr 30, 2014 at 8:46 AM, Stepan Kasal ka...@ucw.cz wrote:
From: Pat Thoyts pattho...@users.sourceforge.net
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
Another one from msysGit project.
On 4/23/2014 11:24 AM, Junio C Hamano wrote:
Ilya Bobyr ilya.bo...@gmail.com writes:
Most arguments that could be provided to a test have short forms.
Unless documented, the only way to learn them is to read the code.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
t/README |8
On 4/23/2014 11:40 AM, Junio C Hamano wrote:
Ilya Bobyr ilya.bo...@gmail.com writes:
@@ -187,10 +192,70 @@ and either can match the t[0-9]{4} part to skip the
whole
test, or t[0-9]{4} followed by .$number to say which
particular test to skip.
-Note that some tests in the existing test
On 4/23/2014 12:51 PM, Eric Sunshine wrote:
On Tue, Apr 22, 2014 at 4:19 AM, Ilya Bobyr ilya.bo...@gmail.com wrote:
Allow better control of the set of tests that will be executed for a
single test suite. Mostly useful while debugging or developing as it
allows to focus on a specific test.
Confirm your Donation of £2,000.000.00 Contact Kindly contact claims office via
Email: neiltro...@qq.com--
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
Allow better control of the set of tests that will be executed for a
single test suite. Mostly useful while debugging or developing as it
allows to focus on a specific test.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
A number of minor changes according to the review comments.
t/README
We used to show (missing ) next to tests skipped because they are
specified in GIT_SKIP_TESTS. Use (GIT_SKIP_TESTS) instead.
Plus tests that check basic GIT_SKIP_TESTS functions.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
No changes.
t/t-basic.sh | 63
Most arguments that could be provided to a test have short forms.
Unless documented, the only way to learn them is to read the code.
Signed-off-by: Ilya Bobyr ilya.bo...@gmail.com
---
Changed to use AsciiDoc format.
t/README |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff
This patches add `--run` option to the test suites to allow one to run
individual tests out of the test suite. Like this:
./t-basic.sh --run='-4,7,9-12,15-'
Previous version:
[RFC/PATCH v3] Better control of the tests run by a test suite
Felipe Contreras wrote:
Phil Pennock wrote:
The bash completion pulled into zsh was being pulled in _as_ zsh, but
used patterns which relied on falling through as unhandled. In zsh
5.0.3 this no longer works, resulting in:
__git_complete_remote_or_refspec:33: bad pattern: +*
Felipe Contreras wrote:
Mark Lodato wrote:
Previously, git-completion.zsh redefined complete() to make
__git_complete() a no-op. This broke zsh's built-in bash completion
compatibility layer (bashcompinit), which defines its own complete().
How exactly? I'm testing this and I don't see
Avoid Yoda conditions, use test, and cleaner statement.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
It has been deprecated for one year and a half. It's time to move on.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 64 --
1 file changed, 64 deletions(-)
diff --git
We don't want to override the 'complete()' function in zsh, which can be
used by bashcomp.
Reported-by: Mark Lodato lod...@google.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 6 --
2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 12
1 file changed, 12 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 9525343..6e331d2 100644
---
We don't need to override IFS, zsh has a native way of splitting by new
lines: the expansion flag (f).
Also, we don't need to split files by ':' or '='; that's only for words.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.zsh | 10 +++---
1
There's no need to hide the fact that we are on zsh any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
A bunch of cleanups and fixes.
Felipe Contreras (6):
completion: bash: remove old wrappers
completion: bash: remove zsh wrapper
completion: zsh: don't hide ourselves
completion: remove zsh hack
completion: zsh: trivial cleanups
completion: bash: cleanup cygwin check
Hello,
On Wed, Apr 30, 2014 at 8:46 AM, Stepan Kasal ka...@ucw.cz wrote:
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
Another one from msysGit project.
Original subject by Pat; I would
Hello,
On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote:
On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI.
Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of
bringing in wingdi.h with weird #define ERROR 0 that conflicts with
internal
On Wed, Apr 30, 2014 at 1:27 PM, Stepan Kasal ka...@ucw.cz wrote:
Hello,
On Wed, Apr 30, 2014 at 8:46 AM, Stepan Kasal ka...@ucw.cz wrote:
Date: Wed, 24 Oct 2012 00:15:29 +0100
Signed-off-by: Pat Thoyts pattho...@users.sourceforge.net
Signed-off-by: Stepan Kasal ka...@ucw.cz
---
Here's a small bugfix release to fix some *blush* last minute changes.
Release notes
-
Bug fixes:
- Fix compilation in watch.c.
- Fix parsing of key bindings mapped to '^' and ''. (GH #280, #282)
Change summary
--
The diffstat and log summary for changes made in this
Hi kusma,
On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
While it's certainly a good point, I think this is *our* fault for not
upstreaming our changes, and the responsibility of cleaning up merges
should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
great job making the
On Mon, Apr 28, 2014 at 11:01 PM, Dave Borowitz dborow...@google.com wrote:
The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed
On Mon, Apr 28, 2014 at 6:29 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
MinGW builds of cURL does not ship with curl-config unless built
with the autoconf based build system, which is not the practice
recommended by the documentation. MsysGit has had issues with
binaries of that sort, so it
Duy Nguyen pclo...@gmail.com writes:
when no entry is reused). I kinda hope to avoid that.
I see.
Speaking about
reusing cache_entry, we won't be able to share cache_entry because
when it's freed in replace_index_entry, or remove_index_entry_at in
the main index, we need to locate the same
Jeff King p...@peff.net writes:
I could not reproduce the problem with a trivial case, and rerere
specifically tries to handle the differences between merge and diff3
styles by throwing away the base content between | and = lines.
However, I wonder if it could still miss a match in some cases
Ilya Bobyr ilya.bo...@gmail.com writes:
The above two illustrate the reason rather well why I said it would
be better to avoid negation because it would complicate the mental
model the user needs to form when using the feature.
I think that you do not have to use it if you do not need it.
On 04/29/2014 08:58 PM, Ronnie Sahlberg wrote:
On Tue, Apr 29, 2014 at 2:25 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
[...]
Unless we want to make ref_transaction objects reusable. [...]
ACK, but I don't think we need reusable transaction yet. Once the API
is cleaned up
it should
On 14-04-28 02:41 PM, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
Problem #1: TortoiseGit GUI windows for common tasks have a heck
lots of controls that a common Git user will never need.
Do people around TortoiseGit lurk on this list? Otherwise this may
not be
Marc Branchaud marcn...@xiplink.com writes:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one
On 29.04.14 20:02, Jeff King wrote:
On Tue, Apr 29, 2014 at 10:12:52AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
This patch just adds a test to demonstrate the breakage.
Some possible fixes are:
1. Tell everyone that NFD in the git repo is wrong, and
they should
Erik Faye-Lund kusmab...@gmail.com writes:
This is wrong, no? With CURL_CONFIG not set, it currently *does* run
curl-config, see below.
...
ifdef CURLDIR
+ CURL_LIBCURL =
+ else
+ CURL_CONFIG = curl-config
+ ifeq $(CURL_CONFIG)
+
Erik Faye-Lund kusmab...@gmail.com writes:
MinGW builds of cURL does not ship with curl-config unless built
with the autoconf based build system, which is not the practice
recommended by the documentation. MsysGit has had issues with
binaries of that sort, so it has switched away from
On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano gits...@pobox.com wrote:
How old/battle tested is this change? My inclination at this point
is to revert the merge of Dave's series from 2.0 (yes, I know we
have been looking at fixing it and I _think_ the issue of unpleasant
error message you
Matthieu Moy matthieu@imag.fr writes:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
output). The S flag (chop long lines), on
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes short output to less, and R because Git pipes colored
On Wed, Apr 30, 2014 at 5:27 PM, Junio C Hamano gits...@pobox.com wrote:
Erik Faye-Lund kusmab...@gmail.com writes:
MinGW builds of cURL does not ship with curl-config unless built
with the autoconf based build system, which is not the practice
recommended by the documentation. MsysGit has
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular,
Patches 1/14 are
Reviewed-by: Matthieu Moy matthieu@imag.fr
On a side note, reviewing patches by batches of 14 patches actually
turns out to be much less convenient for me than reviewing larger
batches.
If I'm counting correctly, there should be around 100 patches remaining.
I'd suggest
Johannes Schindelin wrote:
On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
While it's certainly a good point, I think this is *our* fault for not
upstreaming our changes, and the responsibility of cleaning up merges
should lie on our shoulders. We've diverged a lot. Sure, Dscho does a
great
Hi kusma,
On Wed, 30 Apr 2014, Erik Faye-Lund wrote:
We can keep this patch in the msysGit repo for the 2.0 release.
FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is
not quite clear as of yet how patches will be managed with said
environment.
Ciao,
Johannes
--
To
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one on the mailing list.
Felipe Contreras felipe.contre...@gmail.com writes:
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
On Wed, Apr 30, 2014 at 05:58:06PM +0900, Brian Gesiak wrote:
strbuf_trim strips whitespace from the end, then the beginning of a
strbuf. Those operations are duplicated in strbuf_rtrim and
strbuf_ltrim.
Replace strbuf_trim implementation with calls to strbuf_rtrim,
then strbuf_ltrim.
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
By default, Git used to set $LESS to -FRSX if $LESS was not set by the
user. The FRX flags actually make sense for Git (F and X because Git
sometimes pipes
Felipe Contreras felipe.contre...@gmail.com writes:
These are the steps needed to achieve this:
The overall progression (this comment is only about the design, not
the implementation) looks almost sensible, but I may have missed
some issues because the presentation was done in reverse.
In the
Thanks, pulled.
--
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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Patches 1/14 are
Reviewed-by: Matthieu Moy matthieu@imag.fr
On a side note, reviewing patches by batches of 14 patches actually
turns out to be much less convenient for me than reviewing larger
batches.
If I'm counting correctly,
On Apr 28, 2014, at 02:29, Marat Radchenko ma...@slonopotamus.org wrote:
In short:
1. Hack, hack, hack
2. Commit
3. Push, woops, reject (non-ff)
4. Pull
5. Push
Just do pull --rebase? This is essentially the same as what SVN
used to do in your setup.
-Geert
--
To unsubscribe from this
You should use the latest version of the patch series (v11), because the
blank line is now automatically added.
Yes interpret-trailers add the blank line, but when call `git commit
-m $MSG -e` it isn't displayed.
I think this happens due to the default value of 'cleanup' option of
git-commit
David Turner dtur...@twopensource.com writes:
Sorry about that -- the documentation of RUN_SETUP confused me. So I
have a new patch that edits that as well.
--
RUN_SETUP_GENTLY and improve RUN_SETUP docs
Signed-off-by: David Turner dtur...@twitter.com
---
You do not want to have Sorry
Stepan Kasal ka...@ucw.cz writes:
From: Karsten Blees bl...@dcon.de
Date: Fri, 7 Jan 2011 17:20:21 +0100
Dynamic linking is generally preferred over static linking, and MSVCRT.dll
has been integral part of Windows for a long time.
This also fixes linker warnings for _malloc and _free in
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
These are the steps needed to achieve this:
The overall progression (this comment is only about the design, not
the implementation) looks almost sensible, but I may have missed
some issues because the presentation
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.
You definitely have a strange notion of everyone.
Felipe Contreras felipe.contre...@gmail.com writes:
- With the endgame of out of box Git without any configuration
refuses 'git pull' (without --merge/--rebase) that does not
fast forward in mind, start warning In the future you will
have to either set pull.mode (and/or
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
- With the endgame of out of box Git without any configuration
refuses 'git pull' (without --merge/--rebase) that does not
fast forward in mind, start warning In the future you will
have to
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
...
Until the --merge option is added, pull.mode = merge cannot be
the same as git pull --merge. I think you either need to squash
these two steps into one, or flip the order of them.
Yeah, but the documentation of
On 30.04.2014 20:36, Junio C Hamano wrote:
I am not intimate with the msysgit developer community, and I do not
know if it is appropriate for me to respond with a
Does this look OK with msysgit folks?
This patch has been carried in the msysgit tree since more than 3 years,
although
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.
You definitely have
On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
We can keep this patch in the msysGit repo for the 2.0 release.
FWIW the plan is to switch to mingwGitDevEnv for the 2.0 release. It is
not quite clear as of yet how patches will be managed with said
On 14-04-30 10:55 AM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
This plan, however, fell off the cliff.
Yeah, I see that $gmane/234488 explains why the second step in the
previous one stopped. I guess it was in expecting
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the
Sebastian Schuberth sschube...@gmail.com writes:
On 30.04.2014 20:36, Junio C Hamano wrote:
I am not intimate with the msysgit developer community, and I do not
know if it is appropriate for me to respond with a
Does this look OK with msysgit folks?
This patch has been carried in the
$ git --version
git version 1.8.5.5
git send-email uses Net::SMTP connections that use STARTTLS. Net::SMTP
does not support IPv6. I patched Net:SMTP to use IO::Socket::INET6 and
it worked.
- Matthias-Christian Ott
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Marc Branchaud marcn...@xiplink.com writes:
On 14-04-30 10:55 AM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
...
Anyway, rather than ranting on I'll just suggest that there's not enough
commonality between the ways people use git to make it worthwhile trying to
teach
On 2014-04-30 at 05:00 -0500, Felipe Contreras wrote:
Felipe Contreras wrote:
Phil Pennock wrote:
The bash completion pulled into zsh was being pulled in _as_ zsh, but
used patterns which relied on falling through as unhandled. In zsh
5.0.3 this no longer works, resulting in:
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead me to
start using git pull let alone recommending it to new users.
If git pull starts using --ff-only by default then I might
Hello Junio,
On Wed, Apr 30, 2014 at 11:36:37AM -0700, Junio C Hamano wrote:
like I do not have to ask does this look ok? question when seeing
a patch from Erik or J6t, is it unnecessary for me to do so for a
patch from you?
it _is_ necessary to ask, as I'm just a newcomer who has
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead
me to start using git pull let alone recommending it to new users.
What is wrong when `git pull` merges a fast-forward? The
On 2014-04-29 07:17, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way 'pull.mode' can be set to 'merge', and the default can be
something else.
The old configurations still work, but get deprecated.
Should users be warned if both pull.rebase and
On Mon, Apr 28, 2014 at 6:55 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Make sure entry addition does not lead to unifying the index. We don't
need to explicitly keep track of new entries. If ce-index is zero,
they're new. Otherwise it's unlikely that they are new, but we'll do a
On 2014-04-28 06:55, Nguyễn Thái Ngọc Duy wrote:
From the user point of view, this reduces the writable size of index
down to the number of updated files. For example my webkit index v4 is
14MB. With a fresh split, I only have to update an index of 200KB.
Every file I touch will add about 80
1 - 100 of 125 matches
Mail list logo
