On Wed, Jun 26, 2013 at 11:06:41PM +0300, Kevin Bracey wrote:
> git am was previously modified to provide --continue for consistency
> with rebase, merge etc, and the documentation changed to showing
> --continue as the primary form.
>
> Complete the work by replacing remaining uses of --resolved
I just ran into a funny edge-case when doing a long rebase: one of
the rewritten commits got a sha1 starting with one of the abbreviated
sha1's of a commit still to be applied.
As a result, the rebase stopped with a funny-looking "short SHA1 ... was
ambiguous", which would not have occured if the
On 27 June 2013 18:55, Yann Dirson wrote:
> I just ran into a funny edge-case when doing a long rebase: one of
> the rewritten commits got a sha1 starting with one of the abbreviated
> sha1's of a commit still to be applied.
>
> As a result, the rebase stopped with a funny-looking "short SHA1 ...
I wanted to look at some OpenWRT bits this morning and ran into an
issue cloning the packages repository when setting up the package
feed. The feeds script executes this under the hood:
git clone --depth 1 git://nbd.name/packages.git feeds/packages
When trying to run the command directly on O
David writes:
> I'm not sure that rebase could predict the new hashes without actually
> creating
> the prior commits? So maybe the "short" SHA1 is "too short"?
It's OK to show the short sha1 to the user, but "git rebase" could and
should expand these to complete sha1 right after the editor is
On 27 June 2013 21:04, Matthieu Moy wrote:
> David writes:
>
>> I'm not sure that rebase could predict the new hashes without actually
>> creating
>> the prior commits? So maybe the "short" SHA1 is "too short"?
>
> It's OK to show the short sha1 to the user, but "git rebase" could and
> should e
Hi,
I have a colleague who has to left our office for three month, but still
need to work on the project which is hosted on our in-office git
repository. Problem is that our company has firewall, it's not possible
or not allowed to access the company LAN outside the building. So I
want to ask you
Call built-in commands via the main executable (non-dashed form) without
relying on the aliases (dashed form) to be present. On some platforms,
e.g. those that do not properly support file system links, it is
inconvenient to ship the built-in aliases, so do not depend on their
presence.
Signed-off
On Thu, Jun 27, 2013 at 08:46:56PM +0800, Woody Wu wrote:
> Hi,
>
> I have a colleague who has to left our office for three month, but still
> need to work on the project which is hosted on our in-office git
> repository. Problem is that our company has firewall, it's not possible
> or not allowed
On Wed, Jun 26, 2013 at 08:27:56PM -0700, Perry Wagle wrote:
> Hi --
>
> I have a disk image of a small embedded device whose root file system I'd
> like to check-in to git as a means of distributing its GPL'd software. In
> that disk image are device files, which GIT studiously ignores. If sy
On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu wrote:
> I have a colleague who has to left our office for three month, but still
> need to work on the project which is hosted on our in-office git
> repository. Problem is that our company has firewall, it's not possible
> or not allowed to access the co
On Thu, Jun 27, 2013 at 3:08 PM, Fredrik Gustafsson wrote:
> On Wed, Jun 26, 2013 at 08:27:56PM -0700, Perry Wagle wrote:
>> Is there a reason not to handle device files other than "its not
>> traditional"? That's the only reason given in google or the IRC channel.
>
> In linux you can't create
On Thu, Jun 27, 2013 at 08:06:05AM -0500, Tim Chase wrote:
> On 2013-06-27 20:46, Woody Wu wrote:
> > I have a colleague who has to left our office for three month, but
> > still need to work on the project which is hosted on our in-office
> > git repository. Problem is that our company has firewal
On Thu, Jun 27, 2013 at 03:14:05PM +0200, Johan Herland wrote:
> On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu wrote:
> > I have a colleague who has to left our office for three month, but still
> > need to work on the project which is hosted on our in-office git
> > repository. Problem is that our co
On Thu, Jun 27, 2013 at 3:41 PM, Woody Wu wrote:
> On Thu, Jun 27, 2013 at 03:14:05PM +0200, Johan Herland wrote:
>> On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu wrote:
>> > I have a colleague who has to left our office for three month, but still
>> > need to work on the project which is hosted on o
On Thu, Jun 27, 2013 at 03:43:51PM +0200, Jean-No?l Avila wrote:
> Le 27/06/2013 14:46, Woody Wu a écrit :
> >Hi,
> >
> >I have a colleague who has to left our office for three month, but still
> >need to work on the project which is hosted on our in-office git
> >repository. Problem is that our co
On 2013-06-27 20:46, Woody Wu wrote:
> I have a colleague who has to left our office for three month, but
> still need to work on the project which is hosted on our in-office
> git repository. Problem is that our company has firewall, it's not
> possible or not allowed to access the company LAN out
Le 27/06/2013 14:46, Woody Wu a écrit :
Hi,
I have a colleague who has to left our office for three month, but still
need to work on the project which is hosted on our in-office git
repository. Problem is that our company has firewall, it's not possible
or not allowed to access the company LAN o
Am 26.06.2013 23:03, schrieb Junio C Hamano:
> Fredrik Gustafsson writes:
>
>> On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
>>> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
Used only when a clone is initialized. This is useful when the submodule(s)
On 2013-06-26 23.54, Ramsay Jones wrote:
> Torsten Bögershausen wrote:
>> On 2013-06-25 23.18, Junio C Hamano wrote:
>>> Johannes Sixt writes:
>>>
Some context: This is about a patch by Ramsay that removes the
"schizophrenic lstat" hack for Cygwin. Junio, can you please queue that
p
Queued, and merged to 'pu' without the previous merge with the older
iteration. If you two can double check the merged result, it would
be very much appreciated.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
Matthieu Moy writes:
> benoit.per...@ensimag.fr writes:
>
>> +do you want ? Use the -r option to specify the remote.
>
> Not that it really matters, but there should be no space before ? in
> English (although there is in French).
>
> (Shouldn't prevent merging)
>
> Other than that, the series lo
I just discovered a major problem for
Mac OS and Windows people:
In contrib/mw-to-git/ there is a file called "git".
And there is a directory called "Git".
This does not work very well on case insensitive file systems.
When the file "git" is created, we can not create a directory
called "Git", a
Sebastian Schuberth writes:
> Call built-in commands via the main executable (non-dashed form) without
> relying on the aliases (dashed form) to be present. On some platforms,
> e.g. those that do not properly support file system links, it is
> inconvenient to ship the built-in aliases, so do not
On Wed, Jun 26, 2013 at 7:45 PM, Jeff King wrote:
>
> In particular, it seems like the slowness we saw with the v1 bitmap
> format is not what Shawn and Colby have experienced. So it's possible
> that our test setup is bad or different. Or maybe the C v1 reading
> implementation had some problems
Work around issues that git hangs when doing fetch or pull under
various protocols under CYGWIN.
Replace pipe() with a socket connection using a TCP/IP.
Introduce a new function socket_pipe() in compat/socket_pipe.c
Re-define the pipe() function into socket_pipe() for CYGWIN.
(This redefinition
John Keeping writes:
>> @@ -176,7 +176,7 @@ aborts in the middle. You can recover from this in one
>> of two ways:
>>
>> . hand resolve the conflict in the working directory, and update
>>the index file to bring it into a state that the patch should
>> - have produced. Then run the com
Benoît Person writes:
> Junio, Matthieu : should I resend a new version of my serie which
> renames the 'git' (lowercase) file into something like 'git-dev' ?
I'd call it bin-wrapper/git, so that people can put bin-wrapper/ in
their $PATH if needed, and by analogy with ../../bin-wrapper. If you
On Thu, Jun 27, 2013 at 6:11 PM, Junio C Hamano wrote:
>> Call built-in commands via the main executable (non-dashed form) without
>> relying on the aliases (dashed form) to be present. On some platforms,
>> e.g. those that do not properly support file system links, it is
>> inconvenient to ship
Oops, so sorry :/
It's defintely doable since the lowercase 'git' is only a bin-wrapper
for git to ease development in contrib/mw-to-git/ .
Junio, Matthieu : should I resend a new version of my serie which
renames the 'git' (lowercase) file into something like 'git-dev' ?
(some comments directly
Matthieu Moy writes:
> David writes:
>
>> I'm not sure that rebase could predict the new hashes without actually
>> creating
>> the prior commits? So maybe the "short" SHA1 is "too short"?
>
> It's OK to show the short sha1 to the user, but "git rebase" could and
> should expand these to comple
Junio C Hamano writes:
> It could be something as simple like this (not tested).
>
> git-rebase--interactive.sh | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f953d8d..6766b44 100644
> --- a/git-rebase
On Thu, Jun 27, 2013 at 09:07:38AM -0700, Shawn O. Pearce wrote:
> > And the pack-order versus idx-order for the bitmaps is still up in the
> > air. Do we have numbers on the on-disk sizes of the resulting EWAHs?
>
> I did not see any presented in this thread, and I am very interested
> in this a
Jean-Noël Avila writes:
> For a short time, I had the same issue. We came up using "git bundle"
> to bundle changes and exchange them via email.
>
> The setup was to work in two separate branches. The roaming developper
> started a new branch when leaving. After some work, she sent the
> commits
Sebastian Schuberth writes:
> On Thu, Jun 27, 2013 at 6:11 PM, Junio C Hamano wrote:
>
>> I vaguely recall that some people may have argued that git-foo is
>> one less exec(2) when we left these in our scripted Porcelains,
>> though, so on a platform with poorly performing fork/exec, this
>> cha
Benoît Person writes:
> Oops, so sorry :/
>
> It's defintely doable since the lowercase 'git' is only a bin-wrapper
> for git to ease development in contrib/mw-to-git/ .
Hmph. Does it even need to be in-tree then? Is it insufficient to
run ../../git from that directory instead?
> Junio, Matth
Matthieu Moy writes:
> Benoît Person writes:
>
>> Junio, Matthieu : should I resend a new version of my serie which
>> renames the 'git' (lowercase) file into something like 'git-dev' ?
>
> I'd call it bin-wrapper/git, so that people can put bin-wrapper/ in
> their $PATH if needed, and by analog
From: Benoit Person
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed
From: Benoit Person
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be created. To achieve this goal, the project needs a way to
share code b
From: Benoit Person
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypas
From: Benoit Person
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implem
From: Benoit Person
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v5:
- Move git bin-wrapper 'git' into bin-wrapper/
- Updates its GIT_ROOT_DIR accordingly
- Updates the Makefile to u
From: Benoit Person
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any
Torsten Bögershausen writes:
> Work around issues that git hangs when doing fetch or pull under
> various protocols under CYGWIN.
>
> Replace pipe() with a socket connection using a TCP/IP.
> Introduce a new function socket_pipe() in compat/socket_pipe.c
Sounds like sweeping the real problem, wh
> Hmph. Does it even need to be in-tree then? Is it insufficient to
> run ../../git from that directory instead?
Well, the fact is we use Perl packages now (Git.pm and
Git::Mediawiki.pm in contrib/mw-to-git/Git/). The way we build perl
scripts in the toplevel's Makefile makes those packages acces
benoit.per...@ensimag.fr writes:
> diff --git a/contrib/mw-to-git/bin-wrapper/git
> b/contrib/mw-to-git/bin-wrapper/git
> new file mode 100755
> index 000..aa714a5
> --- /dev/null
> +++ b/contrib/mw-to-git/bin-wrapper/git
> @@ -0,0 +1,27 @@
> +#!/bin/sh
> +
> +# git executable wrapper script
On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano wrote:
[snip]
>> diff --git a/git-am.sh b/git-am.sh
>> index 9f44509..ad67194 100755
>> --- a/git-am.sh
>> +++ b/git-am.sh
>> @@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit
>> message
>> u,utf8 recode into utf8 (d
John Szakmeister writes:
> On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano wrote:
> [snip]
>>> diff --git a/git-am.sh b/git-am.sh
>>> index 9f44509..ad67194 100755
>>> --- a/git-am.sh
>>> +++ b/git-am.sh
>>> @@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit
>>> message
>>
Benoît Person writes:
>> I just noticed that the script is not strictly a text file, ending
>> with an incomplete line, by the way.
> an incomplete line ?
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_194
--
To unsubscribe from this list: send the line "unsubscr
Junio C Hamano writes:
> John Szakmeister writes:
>
>> On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano wrote:
>> [snip]
diff --git a/git-am.sh b/git-am.sh
index 9f44509..ad67194 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,8 +16,8 @@ s,signoff add a Signed-off-by
On Thu, Jun 27, 2013 at 11:05:09AM -0700, Junio C Hamano wrote:
> John Szakmeister writes:
>
> > On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano wrote:
> > [snip]
> >>> diff --git a/git-am.sh b/git-am.sh
> >>> index 9f44509..ad67194 100755
> >>> --- a/git-am.sh
> >>> +++ b/git-am.sh
> >>> @@ -16
Signed-off-by: Andrew Pimlott
---
t/lib-rebase.sh |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 0b41155..7b42199 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -24,8 +24,7 @@
# ">" -- Add a blank line.
set_fake_edit
Andrew Pimlott writes:
> Signed-off-by: Andrew Pimlott
> ---
> t/lib-rebase.sh |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
> index 0b41155..7b42199 100644
> --- a/t/lib-rebase.sh
> +++ b/t/lib-rebase.sh
> @@ -24,8 +24,7 @@
>
Junio C Hamano writes:
> As far as I can tell, the only real reason why you need this and
> cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
> it gives you only points at ../../perl/blib/lib and not this
> directory.
Not only. You also need to have contrib/mw-to-git/ in the $
Hi Sebastian,
On Thu, 27 Jun 2013, Sebastian Schuberth wrote:
> Call built-in commands via the main executable (non-dashed form) without
> relying on the aliases (dashed form) to be present. On some platforms,
> e.g. those that do not properly support file system links, it is
> inconvenient to sh
> As far as I can tell, the only real reason why you need this and
> cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
> it gives you only points at ../../perl/blib/lib and not this
> directory.
Plus (forgot to mention it in the other mail :/ ) it enables us to not
"copy" git-mw
Excerpts from Junio C Hamano's message of Thu Jun 27 11:37:31 -0700 2013:
> Thanks, but it should probably be
>
> write_script fake-editor.sh <<-\EOF
> case "$1" in
> ...
> EOF
>
> test_set_editor ...
>
> if the aim is to modernize this part.
Yes, the goal is
ACHTUNG
Ich habe ein lukratives Geschäft Vorschlag von gemeinsamem Interesse mit
Ihnen zu teilen, sondern die Übertragung von einer großen Geld von meiner
Bank hier in Hongkong. Ich habe deinen Hinweis in meiner Suche nach
jemandem, passend zu meinervorgeschlagenen Geschäftsbeziehung. Wenn Sie
Excerpts from Andrew Pimlott's message of Wed Jun 26 17:20:32 -0700 2013:
> Excerpts from Junio C Hamano's message of Wed Jun 26 16:48:57 -0700 2013:
> > Andrew Pimlott writes:
> > > In order to test this, I wrote a helper function to dump the rebase -i
> > > todo list. Would you like this introd
Because letting a trivial merge automatically handled by Git is so
easy with "git pull", a person who is new to Git may not realize
that the project s/he is interacting with may prefer "rebase"
workflow. Add a safety valve to fail "git pull" that is not a
fast-forward until/unless the user express
On Thu, Jun 27, 2013 at 07:51:57AM +0200, Michael Haggerty wrote:
> > In theory we can drop the safety valve; it should never actually happen.
> > But I'd like to keep it there for working systems. Perhaps it is worth
> > doing something like this:
> >
> > [...#ifdef out consistency check on cygw
Am 27.06.2013 14:47, schrieb Sebastian Schuberth:
> diff --git a/git-archimport.perl b/git-archimport.perl
> index 9cb123a..ed2c741 100755
> --- a/git-archimport.perl
> +++ b/git-archimport.perl
...
> @@ -477,8 +477,8 @@ sub process_patchset_fast {
> unlink @$del;
> while (@$del)
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> +# See if we are configured to rebase by default.
> +# The value $rebase is, throughout the main part of the code:
> +#(empty) - the user did not have any preference
> +#true- the user told us to integrate by rebasing
>
Assorted minor edits:
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
Maybe:
Because letting Git handle a trivial merge automatically is so…
> that the project s/he is interacting with may prefer "rebase"
> w
Fredrik Gustafsson writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>
>> +# See if we are configured to rebase by default.
>> +# The value $rebase is, throughout the main part of the code:
>> +#(empty) - the user did not have any preference
>> +#true- the use
Andrew Pimlott writes:
> I should update the function I introduced first. I will re-submit
> the rebase -i --autosquash patch and wait for acceptance before
> trying to fix other things.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
Andrew Pimlott writes:
> Updated for recommended here-doc style.
Thanks.
> +test_auto_fixup_fixup () {
> + git reset --hard base &&
> + echo 1 >file1 &&
> + git add -u &&
> + test_tick &&
> + git commit -m "$1! first" &&
> + echo 2 >file1 &&
> + git add -u &&
> +
"W. Trevor King" writes:
> Assorted minor edits:
>
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>
> Maybe:
>
> Because letting Git handle a trivial merge automatically is so…
>
>> that the project s/he is
WE OFFER LOANS @3% INTEREST RATE FOR BUSINESS AND PRIVATE PURPOSES.APPLY NOW
WITH:
FILL AND RETURN
Name: ===
Amount needed: ===
Duration: ==
Sex ===
Purpose: ===
Mobile number: ==
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
Jeff King writes:
>> But, taking a step back, I think it is a bad idea to have an unreliable
>> stat() masquerading as a real stat(). If we want to allow the use of an
>> unreliable stat for certain purposes, let's have two stat() interfaces:
>>
>> * the true stat() (in this case I guess cygwin
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow.
Or they may not even r
"W. Trevor King" writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>>
Junio C Hamano writes:
> Because letting a trivial merge automatically handled by Git is so
> easy with "git pull", a person who is new to Git may not realize
> that the project s/he is interacting with may prefer "rebase"
> workflow. Add a safety valve to fail "git pull" that is not a
> fast-fo
Benoît Person writes:
>> Two possible alternatives:
>>
>> - Is there a reason you would not want to "install" whatever Perl
>>modules you want to "use" via GITPERLLIB mechanism to
>>../../perl/blib/lib?
> If we are making modifications to Git/Mediawiki.pm or even git-mw.perl
> / git-remo
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
There are quite a few fixes already on 'master' that needed merging
down to 'maint'; I'll be tagging 1.8.3.2 shortly.
You can find the changes
Jeff King wrote:
> On Wed, Jun 26, 2013 at 10:45:48PM +0100, Ramsay Jones wrote:
[ ... ]
> I think Michael's assessment above is missing one thing. It is true that
> a false positive is just a performance problem in most cases, as we
> unnecessarily reload the file, thinking it has changed.
>
> Ho
Michael Haggerty wrote:
> On 06/27/2013 12:35 AM, Jeff King wrote:
[ ... ]
>> I think Michael's assessment above is missing one thing.
>
> Peff is absolutely right; for some unknown reason I was thinking of the
> consistency check as having been already fixed.
Well, the "cygwin: Remove the Win32
Torsten Bögershausen wrote:
[ ... ]
>>> (And have a look how to improve the core.filemode)
>>
>> I don't understand this (parenthetical) comment; could you
>> elaborate on this.
>>
> This is probably wrong information:
> I had in mind that cygwin sets core.filemode=false,
It does, see commit c86
Jeff King wrote:
> On Wed, Jun 26, 2013 at 06:35:52PM -0400, Jeff King wrote:
>
>> I am curious how often Cygwin gives us the false positive. If it is
>> every time, then the check is not doing much good at all. Is it possible
>> for you to instrument stat_validity_check to report how often it doe
On Thu, Jun 27, 2013 at 02:20:42PM -0700, Junio C Hamano wrote:
> Your "accident user" could have just been on a 'maint' branch,
> [snip]
By the time I talk people into using a 'maint' branch, we'll probably
have already passed the 'accidental pull and push' stage ;). This
will certainly reduce t
On Fri, Jun 28, 2013 at 12:16:53AM +0200, Matthieu Moy wrote:
> IMHO, that would be terrible for beginners.
>
> My experience with many beginners/students is: they run "git pull" to
> get changes from their co-workers, don't read the messages.
I admit that I'd be happy with a config option that j
Hi Junio,
The merged result is ok!
Thanks,
Eduardo
--
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 Mon, Jun 24, 2013 at 11:16:56AM -0700, Junio C Hamano wrote:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 0da944f..a535eb2 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -111,12 +111,14 @@ static int show_ignored_in_status;
> static const char *only_include_assumed
On 06/27/2013 06:58 PM, Ramsay Jones wrote:
This is why I tried the "cygwin: Remove the Win32 l/stat()
functions" patch first; I think this is the correct approach
to fixing this problem (and similar *future* problems).
I adamantly agree.
However, since that is no longer an option, on performa
On 06/27/2013 01:38 PM, Junio C Hamano wrote:
Torsten Bögershausen writes:
Work around issues that git hangs when doing fetch or pull under
various protocols under CYGWIN.
Replace pipe() with a socket connection using a TCP/IP.
Introduce a new function socket_pipe() in compat/socket_pipe.c
S
Jeff King writes:
> You lose the assertion that finalize_deferred_config has been called,
> but I think the resulting code would be simpler, as it drops this
> die("BUG") state entirely. Am I missing something?
Probably not. Depending on "-z", NONE is sometimes converted to
PORCELAIN and someti
"W. Trevor King" writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>>
On Thu, Jun 27, 2013 at 04:54:45PM +0200, Jens Lehmann wrote:
> Am 26.06.2013 23:03, schrieb Junio C Hamano:
> > Fredrik Gustafsson writes:
> >
> >> On Wed, Jun 26, 2013 at 12:11:32AM +0200, Heiko Voigt wrote:
> >>> On Tue, Jun 25, 2013 at 12:49:25AM +0200, Fredrik Gustafsson wrote:
> Used o
88 matches
Mail list logo
