Hi,
Nathan Collins wrote:
> Patches created with 'diff.noprefix=true' don't 'git apply' without
> specifying '-p0'.
>
> I'm not sure this is a bug -- the 'man git-apply' just says "Reads the
> supplied diff output (i.e. "a patch") and applies it to files" -- but
> I would expect patches I create
Bug?
Patches created with 'diff.noprefix=true' don't 'git apply' without
specifying '-p0'.
I'm not sure this is a bug -- the 'man git-apply' just says "Reads the
supplied diff output (i.e. "a patch") and applies it to files" -- but
I would expect patches I create locally to apply cleanly loc
On Thu, May 1, 2014 at 6:44 AM, Ramsay Jones wrote:
> Hi Duy,
>
> I haven't looked at your split-index series at all. However, sparse has
> nagged me to take a quick squint at the result of the series as it
> appears in the 'pu' branch.
>
> In particular, sparse complains thus:
>
> SP sequen
On Wed, Apr 30, 2014 at 04:48:05PM -0400, Richard Hansen wrote:
> I played around with these changes a bit and have some questions:
>
> * These changes should only affect performance when the index is
> updated, right? In other words, if I do "git status; git status"
> the second "git s
Hi Duy,
I haven't looked at your split-index series at all. However, sparse has
nagged me to take a quick squint at the result of the series as it
appears in the 'pu' branch.
In particular, sparse complains thus:
SP sequencer.c
sequencer.c:690:49: error: incompatible types for operation
Marc Branchaud wrote:
> On 14-04-30 04:14 PM, Felipe Contreras wrote:
> > 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 recommen
From: Karsten Blees
Date: Fri, 7 Jan 2011 19:47:23 +0100
The code in the MinGW main macro is getting more and more complex,
move to a separate initialization function for readabiliy and
extensibility.
Signed-off-by: Karsten Blees
Signed-off-by: Erik Faye-Lund
Signed-off-by: Pat Thoyts
Signed-
Hello,
On Wed, Apr 30, 2014 at 10:35:56AM +0200, Karsten Blees wrote:
> Would you mind cross checking your changes with the msysgit fork?
> [...]
> See https://github.com/msysgit/git/commit/9206e7fd (squashed from
> https://github.com/msysgit/git/commit/0115ef83 and
> https://github.com/msysgit/gi
Signed-off-by: Junio C Hamano
---
* Instead of using trailing "# correct" comment on each of the
one-liners, group the good ones and the bad ones into two groups
and give (incorrect)/(correct) header like the other patches as
suggested. How does this look?
The only reason I origin
On 14-04-30 04:14 PM, Felipe Contreras wrote:
> 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
Stefan Beller writes:
> On 30.04.2014 23:45, Junio C Hamano wrote:
>> Signed-off-by: Junio C Hamano
>> ---
>> Documentation/CodingGuidelines | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
>> index 1e0c4cf
On 30.04.2014 23:45, Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> Documentation/CodingGuidelines | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 1e0c4cf..d72e912 100644
> --- a/Document
On 14-04-30 04:01 PM, Junio C Hamano wrote:
>
> Maybe I was unclear.
>
> I didn't mean "replace 'pull' with 'update' everywhere". I meant
> "Introduce 'update' that lets integrate your history into that from
> the remote, which is to integrate in a direction opposite from how
> 'pull' does".
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 21e427
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 86fb9f6..759003e 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1e0c4cf..d72e912 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index fdf6269..9b103cb 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/
The sentence lacked the necessary verb.
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index f424dbd..fdf6269 100644
--- a/Documentation/CodingGui
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index d72e912..1b0cd2b 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentati
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 9b103cb..1e0c4cf 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -53
The point immediately before it is about having SP after the control
keyword. Follow it.
Signed-off-by: Junio C Hamano
---
Documentation/CodingGuidelines | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 1b0
After seeing a large torrent of patches from Elia, I was re-reading
the CodingGuidelines to see if our preference of $( ... ) over `...`
was properly described, and then I spotted a typo and also lack of
examples on a few points that I recall pointing out during recent
reviews, which grew to this s
Hi Pavel,
Pasha Bolokhov wrote:
> It turns out Git treats the directory '.git' differently enough
> from everything else. That may be ok,
Yeah, it's intended.
[...]
> if you supply a different repository base name, say, '.git_new',
> by either setting GIT_DIR or using the '--git-dir' op
Linus Torvalds writes:
> I just got a comment saying that
>
> git commit --amend --date=now
>
> doesn't work. I replied that you can use
>
>--date="$(date)"
Offhand without double-checking the actual codepath I do not have
objection against approxidate-careful.
But why does the workflow
Hi
It turns out Git treats the directory '.git' differently enough
from everything else. That may be ok, but here's one place where I
encountered an unpleasant (and imho unexpected) behaviour:
if you supply a different repository base name, say, '.git_new',
by either setting GIT_D
I just got a comment saying that
git commit --amend --date=now
doesn't work. I replied that you can use
--date="$(date)"
but I do wonder if we should accept the approxidate format - we do in
other equivalent places. Hmm?
The code uses fmt_ident(), which uses parse_date(), which in turn
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 8
On Mon, Apr 28, 2014 at 6:55 AM, Nguyễn Thái Ngọc Duy 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
> through check later
On 2014-04-29 07:17, Felipe Contreras wrote:
> Also 'branch..rebase' to 'branch..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 pull.mode
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 pro
Junio C Hamano wrote:
> Felipe Contreras writes:
> > Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >> > Matthieu Moy wrote:
> >> >> Felipe Contreras writes:
> >> >> ...
> >> >> > Yes, this has been discussed many times in the past, and everyone
> >> >> > agrees
> >> >> > the default beh
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 (fortun
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 migh
Marc Branchaud writes:
> On 14-04-30 10:55 AM, Junio C Hamano wrote:
>> Marc Branchaud 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 pull how to deal with a sign
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 i
$ 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
Sebastian Schuberth 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 msysgit
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>> > Matthieu Moy wrote:
>> >> Felipe Contreras writes:
>> >> ...
>> >> > Yes, this has been discussed many times in the past, and everyone agrees
>> >> > the default behavior is not correct.
>> >>
>> >> You definitel
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras 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 a reroll state,
>> waiting for that oth
On 14-04-30 10:55 AM, Junio C Hamano wrote:
> Marc Branchaud 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 u
On Wed, Apr 30, 2014 at 6:52 PM, Johannes Schindelin
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.
The environm
Junio C Hamano wrote:
> Felipe Contreras writes:
> > Matthieu Moy wrote:
> >> Felipe Contreras 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"
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 s
Felipe Contreras 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 --merge sho
Junio C Hamano wrote:
> Felipe Contreras 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
Felipe Contreras 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 its friends) or
Felipe Contreras writes:
> Matthieu Moy wrote:
>> Felipe Contreras 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".
>
> Do I? Let's look at some of the
Junio C Hamano wrote:
> Felipe Contreras 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
Matthieu Moy wrote:
> Felipe Contreras 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 a
Stepan Kasal writes:
> From: Karsten Blees
> 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 zlib.lib, which
> see
David Turner 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
> ---
You do not want to have "Sorry about that..." in your final commit
> 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
On Apr 28, 2014, at 02:29, Marat Radchenko 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 list: send the li
Matthieu Moy writes:
> Patches 1/14 are
>
> Reviewed-by: Matthieu Moy
>
> 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
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
Felipe Contreras 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 following comment, I'll fl
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy 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 colore
Erik Faye-Lund writes:
> On Wed, Apr 30, 2014 at 5:13 PM, Junio C Hamano wrote:
>> I think something along the lines of
>>
>> ifdef CURLDIR
>> CURL_LIBCURL =
>> else
>> CURL_CONFIG = curl-config
>> CURL_LIBCURL := $(shell sh -c '$(C
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.
Felipe Contreras 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
>> starting threads
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
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 unsubs
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
>
Patches 1/14 are
Reviewed-by: Matthieu Moy
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 that the next batch cont
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
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, em
Hello Marat,
On Mon, Apr 28, 2014 at 10:29:07AM +0400, Marat Radchenko wrote:
> Setup:
> 20 people (programmers, artists, designers) with prior SVN
I was in a similar situation: 10 people, mostly mathematicians,
previous experience with Tortoise SVN.
I wanted to move to Git with centralized mode
On Wed, Apr 30, 2014 at 5:13 PM, Junio C Hamano wrote:
> I think something along the lines of
>
> ifdef CURLDIR
> CURL_LIBCURL =
> else
> CURL_CONFIG = curl-config
> CURL_LIBCURL := $(shell sh -c '$(CURL_CONFIG) --libs'
> 2>/dev/null
On Wed, Apr 30, 2014 at 5:27 PM, Junio C Hamano wrote:
> Erik Faye-Lund 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
Junio C Hamano writes:
> Matthieu Moy 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
Matthieu Moy 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 the other hand,
On Wed, Apr 30, 2014 at 8:27 AM, Junio C Hamano 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 reported can be
Erik Faye-Lund 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 autoconf-based
> cURL-b
Erik Faye-Lund 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)" ""
>> +
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 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
Marc Branchaud 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 the mailing li
On 14-04-28 02:41 PM, Junio C Hamano wrote:
> Marat Radchenko 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 something we ca
On 04/29/2014 08:58 PM, Ronnie Sahlberg wrote:
> On Tue, Apr 29, 2014 at 2:25 AM, Michael Haggerty
> 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 be reasonably
Ilya Bobyr 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.
> It adds some
Jeff King 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 b
Duy Nguyen 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 entry in the
On Mon, Apr 28, 2014 at 6:29 PM, Erik Faye-Lund 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 has switched aw
On Mon, Apr 28, 2014 at 11:01 PM, Dave Borowitz 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 along system libra
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 dive
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 r
On Wed, Apr 30, 2014 at 1:27 PM, Stepan Kasal wrote:
> Hello,
>
>> On Wed, Apr 30, 2014 at 8:46 AM, Stepan Kasal wrote:
>> > Date: Wed, 24 Oct 2012 00:15:29 +0100
>> >
>> > Signed-off-by: Pat Thoyts
>> > Signed-off-by: Stepan Kasal
>> > ---
>> > Another one from msysGit project.
>> > Original s
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
> interna
Hello,
> On Wed, Apr 30, 2014 at 8:46 AM, Stepan Kasal wrote:
> > Date: Wed, 24 Oct 2012 00:15:29 +0100
> >
> > Signed-off-by: Pat Thoyts
> > Signed-off-by: Stepan Kasal
> > ---
> > Another one from msysGit project.
> > Original subject by Pat; I would suggest:
> > wincred: improve Makefile
1 - 100 of 125 matches
Mail list logo
