Re: Issue 457 in msysgit: Push over git protocol hangs in msysGit
msy...@googlecode.com
Summary: Push over git protocol hangs in msysGit
Comment #21 on issue 457 by patthoyts: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
(No comment was entered for this change.)
msy...@googlecode.com
Comment #22 on issue 457 by zzffbbpp: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
please done
msy...@googlecode.com
Comment #23 on issue 457 by johannes.schindelin: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
please grammar & remove :-)
msy...@googlecode.com
Comment #24 on issue 457 by alex.blewitt: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Is there any reason we can't implement the suggested workaround as
mentioned in comment 20?
msy...@googlecode.com
Comment #25 on issue 457 by jeroen.wolff: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
same issues here. can it be fixed? thanks
Client git version 1.7.3.1.msysgit.0
Server FreeBsd 1.7.3.2
msy...@googlecode.com
Comment #26 on issue 457 by jeroen.wolff: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Please fix it, we need it in our LAN environment. We don't want to struggle
with ssh keys ;)
msy...@googlecode.com
Comment #27 on issue 457 by johannes.schindelin: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
If you need it fixed badly, why don't you hire somebody to do it?
msy...@googlecode.com
Comment #29 on issue 457 by scott.macintire: Push over git protocol hangs
in msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
I implemented the workaround in #20. It works fine. Technically I didn't
use sed, I just opened the file in notepad and did find and replace (it
only appears in 1 place btw)
After compiling, I took the git.exe produced and copied it over the one in
C:\Program Files\Git\bin. Once I'm at work Monday, I'll try to post the bin
somewhere...
msy...@googlecode.com
Comment #30 on issue 457 by jopie64: Push over git protocol hangs in msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
I also suggest the workaround. Its better that it works most of the times,
then that it doesnt work at all. And it can be reverted when there is a
real fix.
I dare to bet this is not the only workaround. I remember something about
loading a dll on a different address space then the default.
msy...@googlecode.com
Comment #31 on issue 457 by johannes.schindelin: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
It might seem as a good idea to apply the workaround to those who want to
push over git:// protocol (which basically seems to be not the case for
most people who have commits in either git.git or 4msysgit.git). But the
problem is that the problem is not solved that way. We still do not
understand what is going on here, really, and just ignoring this is not
good practice. Besides, there would be bad consequences from just removing
sideband support.
And please, everybody, obey basic netiquette. Ad hominem attacks are a
display of bad character, and "me, too"s make it only hard to extract the
relevant information from the bug tracker. If you are interested in getting
the issue fixed, star it, and then think about what incentives you could
give to those who could fix it. I know that I am stating the obvious here,
but apparently it has to be stated.
msy...@googlecode.com
Comment #33 on issue 457 by kusmabite: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Adrian: No, repeating the same requests over and over again without giving
any incentive is not just rude; it's annoying. Git for Windows isn't
something that anyone is obliged to provide. There is no msysGit-staff that
you have a service agreement with that you get to push around if something
doesn't work. All there is, is a group of people who have taken matters
into their own hands, and made sure we have what we have. People should be
grateful for that, not upset that no one scratched an itch that wasn't
their own.
We know exactly what patch introduced the problem, but no one has been able
to explain WHY it does. We know two work-arounds; pushing over SSH, and
disabling the side-band-64k support. The first work-around is trivial to
implement in most environment. The second requires you to download the
development environment and build the source code yourself. So far no one
has contributed the patches to do so, and I suspect many people with
push-access to 4msysgit.git feels uneasy about such a change and might
object against including it. I know _I_ feel uneasy about it, we'd might
just end up ignoring what could turn out to be the tip of a massive iceberg.
Johannes Schindelin
FYI: I deleted this comment after reading the first word, as it was
obviously in the category of "comments" I told everybody is undesirable.
Ciao,
Dscho
On Sun, 12 Dec 2010, msy...@googlecode.com wrote:
>
> Comment #32 on issue 457 by adrian.m...@gmail.com: Push over git protocol
> hangs in msysGit
> http://code.google.com/p/msysgit/issues/detail?id=457
>
> Johannes, [...]
msy...@googlecode.com
Comment #34 on issue 457 by kusmabite: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Just thought I'd shed a tiny bit of light on the issue: MSVC builds are
also affected. This means that we can *probably* rule out race conditions
in the CRT startup and the likes.
msy...@googlecode.com
Comment #35 on issue 457 by kusmabite: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Debugging this issue with MSVC seems to reveal something else than what GDB
has:
- pack-objects is stuck in write(1, ...) (through flush, sha1flush,
sha1close, write_pack_file)
- The debugger claims that the push process appears to have deadlocked or
isn't running any user-mode code. This goes away if I change the call to
WaitForSingleObject(h, INFINITE) to a while-loop with a cap.
- The main-thread of the push-process is stuck in WaitForSingleObject
(through waitpid, wait_or_whine, finish_command, pack_objects, send_pack,
git_transport_push, transport_push, push_with_options, do_push). This is
when it's waiting for the pack-objects process to finish.
- The push process has a worker-thread thread stuck in read(3, buf, 4),
(through read_in_full, safe_read, packet_read_line, recv_sideband,
sudeband_demux, run_thread, win32_start_routine...)
- The hanging safe_read is the first call to safe_read from the
worker-thread. There are other successful calls to safe_read from the main
thread prior to this.
This is probably unrelated:
- When terminating the push-process, I get a debug-hook for an invalid
parameter error from the pack-objects process. This originates from
_get_osfhandle(1) in mingw_fstat (through run_builtin). The comment on the
call-site says "Somebody closed sdtout?", so that's probably what has
happened. Triggering this hook is annoying when debugging, but probably
harmless. I don't know any other way to validate a file descriptor to avoid
it.
I don't quite know what to read out of all this. Perhaps this rings a bell
for someone else who has debugged the issue?
Johannes Sixt
> Comment #35 on issue 457 by kusmabite: Push over git protocol hangs in
> msysGit
> http://code.google.com/p/msysgit/issues/detail?id=457
>
> Debugging this issue with MSVC seems to reveal something else than what GDB
> has:
> - pack-objects is stuck in write(1, ...) (through flush, sha1flush,
> sha1close, write_pack_file)
Isn't it the case that this pack-objects process writes to a network socket,
but it has never initialized the networking stack using WSAStartup()? How can
this work, I wonder...
> - The debugger claims that the push process appears to have deadlocked or
> isn't running any user-mode code. This goes away if I change the call to
> WaitForSingleObject(h, INFINITE) to a while-loop with a cap.
> - The main-thread of the push-process is stuck in WaitForSingleObject
> (through waitpid, wait_or_whine, finish_command, pack_objects, send_pack,
> git_transport_push, transport_push, push_with_options, do_push). This is
> when it's waiting for the pack-objects process to finish.
> - The push process has a worker-thread thread stuck in read(3, buf, 4),
> (through read_in_full, safe_read, packet_read_line, recv_sideband,
> sudeband_demux, run_thread, win32_start_routine...)
> - The hanging safe_read is the first call to safe_read from the
> worker-thread. There are other successful calls to safe_read from the main
> thread prior to this.
>
> This is probably unrelated:
> - When terminating the push-process, I get a debug-hook for an invalid
> parameter error from the pack-objects process. This originates from
> _get_osfhandle(1) in mingw_fstat (through run_builtin). The comment on the
> call-site says "Somebody closed sdtout?", so that's probably what has
> happened. Triggering this hook is annoying when debugging, but probably
> harmless. I don't know any other way to validate a file descriptor to avoid
> it.
It is not a debug hook, but a "safety feature" that terminates a process under
certain CRT calls that should actually error out with EINVAL. I've a patch
somewhere that works it around by installing a do-nothing
invalid-parameter-hook.
> I don't quite know what to read out of all this. Perhaps this rings a bell
> for someone else who has debugged the issue?
No. But I vaguely recall that your findings match what I found out...
-- Hannes
Erik Faye-Lund
> On Montag, 20. Dezember 2010, msy...@googlecode.com wrote:
>> Comment #35 on issue 457 by kusmabite: Push over git protocol hangs in
>> msysGit
>> http://code.google.com/p/msysgit/issues/detail?id=457
>>
>> Debugging this issue with MSVC seems to reveal something else than what GDB
>> has:
>> - pack-objects is stuck in write(1, ...) (through flush, sha1flush,
>> sha1close, write_pack_file)
>
> Isn't it the case that this pack-objects process writes to a network socket,
> but it has never initialized the networking stack using WSAStartup()? How can
> this work, I wonder...
>
Yes, your hunch might be right. But simply calling
ensure_socket_initialization from the main in mingw.h doesn't resolve
the problem. Neither does calling it from the beginning of
cmd_pack_objects...
According to Microsoft, sockets are inheritable on Windows NT and up:
http://support.microsoft.com/kb/150523
But note that the example code mentions that WSAStartup() should be
called by the child...
What's even more bizarre is that this works when we're not using
side-band-64k. Stdout should still be a socket in that case, no?
>> This is probably unrelated:
>> - When terminating the push-process, I get a debug-hook for an invalid
>> parameter error from the pack-objects process. This originates from
>> _get_osfhandle(1) in mingw_fstat (through run_builtin). The comment on the
>> call-site says "Somebody closed sdtout?", so that's probably what has
>> happened. Triggering this hook is annoying when debugging, but probably
>> harmless. I don't know any other way to validate a file descriptor to avoid
>> it.
>
> It is not a debug hook, but a "safety feature" that terminates a process under
> certain CRT calls that should actually error out with EINVAL. I've a patch
> somewhere that works it around by installing a do-nothing
> invalid-parameter-hook.
>
Nice.
>> I don't quite know what to read out of all this. Perhaps this rings a bell
>> for someone else who has debugged the issue?
>
> No. But I vaguely recall that your findings match what I found out...
Hm, OK. Thanks for taking a look still.
Johannes Schindelin
On Mon, 20 Dec 2010, Erik Faye-Lund wrote:
> But note that the example code mentions that WSAStartup() should be
> called by the child...
Could you test whether the issue457 branch gives you a starting point?
Ciao,
Dscho
Erik Faye-Lund
Thanks for the effort, but I don't think the problem is that each
thread needs initialization. The first line on MSDN about
WSAStartup[1] is "The WSAStartup function initiates use of the Winsock
DLL by a process.". This is a strong indication that we don't need to
do it per thread IMO. And just to be sure, I tested. There's still no
improvement with your patch :(
[1]: http://msdn.microsoft.com/en-us/library/ms742213(v=vs.85).aspx
Johannes Sixt
> On Mon, Dec 20, 2010 at 10:53 PM, Johannes Sixt <j...@kdbg.org> wrote:
> > On Montag, 20. Dezember 2010, msy...@googlecode.com wrote:
> >> Comment #35 on issue 457 by kusmabite: Push over git protocol hangs in
> >> msysGit
> >> http://code.google.com/p/msysgit/issues/detail?id=457
> >>
> >> Debugging this issue with MSVC seems to reveal something else than what
> >> GDB has:
> >> - pack-objects is stuck in write(1, ...) (through flush, sha1flush,
> >> sha1close, write_pack_file)
> >
> > Isn't it the case that this pack-objects process writes to a network
> > socket, but it has never initialized the networking stack using
> > WSAStartup()? How can this work, I wonder...
>
> Yes, your hunch might be right. But simply calling
> ensure_socket_initialization from the main in mingw.h doesn't resolve
> the problem. Neither does calling it from the beginning of
> cmd_pack_objects...
>
> According to Microsoft, sockets are inheritable on Windows NT and up:
> http://support.microsoft.com/kb/150523
>
> But note that the example code mentions that WSAStartup() should be
> called by the child...
>
> What's even more bizarre is that this works when we're not using
> side-band-64k. Stdout should still be a socket in that case, no?
The difference is that the parent process does not have the async thread.
When I debugged the issue using Procmon (i.e., outside the debugger), I found
that the child process hung even before it loaded *any* DLLs. Not that this
would move us forward a bit...
-- Hannes
msy...@googlecode.com
Comment #36 on issue 457 by yervand.aghababyan: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
hey guys. is this going to be fixed some day? :) the issue has been open
for more than half a year already!
msy...@googlecode.com
Comment #37 on issue 457 by johannes.schindelin: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
Running the risk of stating the obvious, I want to point out that the bug
is going to be fixed some day if -- and only if -- some poor soul sits down
to do it.
The likelihood of that to happen is an ill-defined non-linear function
which depends on incentives, and more. One strong incentive would be if a
developer capable of doing it had the problem herself. Another incentive
could be money. Yet another incentive could be a close friend who has the
problem.
But however hard I look at it, I cannot bring myself to believe that pushy
comments displaying unwillingness to scratch one's own itch could ever be a
strong incentive for a capable developer to fix an issue they do not have a
problem with personally.
I definitely do not want to sound condescending, but I have a distinct
feeling that I needed to say this out loud, as I do not have the feeling
that the social aspects are clear to everyone involved in this discussion.
msy...@googlecode.com
Comment #38 on issue 457 by harut.martirosyan: Push over git protocol hangs
in msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Johannes, you sound like Napoleon, you know :-)
msy...@googlecode.com
Comment #39 on issue 457 by khomoutov: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Don't be silly.
If you feel like bugs not being fixed automagically in a F/OSS project
somehow make your life inconvenient, just buy a commercial VCS with a good
support plan.
Also this issue turned out to be quite hard to fix -- see the preceding
comments (in fact you could check out their timestamps before posting
your "me too").
msy...@googlecode.com
Comment #40 on issue 457 by yervand.aghababyan: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
If by asking when a bug i'm interested in is going to be fixed i'm proving
that I'm "silly" then you're twice as silly because of replying to my
comment just to tell me to fuck off if i'm not pleased and taking my
question too personally.
And sorry I didn't read all of the above wall of text about where actually
the bug may be and stuff like that. I didn't even download the ~150Mb dev
package, didn't search for the mentioned code there and didn't do a time
estimation myself which alone would have taken me several hours.
I saw that there has been activity in the thread a couple of days ago and
just preferred to ask if someone's working on it and what the people
actually involved think.
Nor am i complaining of the job you guys are doing. Thank you for your hard
work. If not the existence of this project i wouldn't have moved to git at
all.
It's just not polite to call someone silly if what he's doing is just
asking when the issue is going to be fixed. And regarding the "me too"
style comments being useless. Personally I have worked on some open source
projects and seeing that the stuff i'm doing is actually needed has always
motivated me. Even if it was just a "me too" style comment :)
msy...@googlecode.com
Comment #41 on issue 457 by mcalahan: Push over git protocol hangs in
msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
I played around with this a bit myself and am able to recreate this when
changing the child process (upload-pack) to use pipe for StdOut instead of
the socket to communicate with the parent (send-pack) a little better. The
child actually finishes all its work fine. When I went to write the data
from the child to the socket file descriptor I ended up in a deadlock.
Tracing this into the MS CRT I found that both write() and read() lock the
file handle with _lock_fh().
With the addition of the multiplexing there is a second thread reading from
the socket before the client is spawned and it continues until after all
the data from the child is supposed to be written. This causes a deadlock.
I was able to see similar behaviors when the child process was using the
socket as StdOut but it was a lot harder to actually see this going on.
Short term as mentioned above use_sideband can be set to 0 and the system
will work as all data is written from the child before the send-pack
process even attempts to read from the socket. This is not ideal but it
produces a working system which is much better than a non working system.
There are non locking functions in the CRT (e.g. _write_nolock) but those
might not be a great approach either to get around this.
Fundamentally it appears that a few things will need to change as the code
uses core safe_write/read functions and those all use write/read internally
causing these issues.
Workaround attached.
Attachments:
send-pack.diff 997 bytes
msy...@googlecode.com
Comment #42 on issue 457 by tomlo...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
Can this change (send-pack.diff) be scheduled for the next build? I'm an
embedded developer, and would prefer to use an official build, instead of
installing the necessary build tools and trying to do a custom build of
msysgit. I'm able to use the git from my Cygwin installation, but I have
to use msysgit for the Git Extensions GUI.
I would think the provided workaround is an acceptable fix until the root
cause of the problem can be determined and resolved.
-----
OK, so I went ahead and tried to install the development environment so I
could build a custom installer. Here's my experience with that (I'm sure
this belongs in a new issue, and if someone tells me where I should file it
I will.):
1) I was able to run `make` in the /git directory. I was able to modify
send-pack.c and re-run make. I was able to commit my changes to git and
msysgit.
2) When I tried to run /share/WinGit/release.sh, I first got an error about
non-existent directory /src/git-cheetah/explorer/.
3) After creating that directory, the install script now fails with "make:
*** No targets specified and no makefile found. Stop."
4) The help at
<https://git.wiki.kernel.org/index.php/MSysGit:WorkingOnMsysGit> says there
are "devel" and "master" branches, but I have not been able to checkout the
master branch.
error: Not tracking: ambiguous information for ref
refs/remotes/origin/master
I've given this an hour and a half, and I need to get back to the project
I'm trying to manage.
msy...@googlecode.com
Comment #43 on issue 457 by liorta...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
hi i am using "git version 1.7.6.msysgit.0"
this issue seems to occur here as well. Is this scheduled to be fixed any
time soon in the near future?
msy...@googlecode.com
Comment #44 on issue 457 by kusmab...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
We have no clue what cause this problem to occur, so no. If you have light
to shed on the issue or you want to discuss it further, please send an
e-mail to the mailing list; this issue tracker has been closed.
msy...@googlecode.com
Comment #45 on issue 457 by vkochepa...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
1) A point regarding accepting send-pack.diff.
As per http://git-scm.com/gitserver.txt section =>
* side-band-64k means that server can send, and client understand
multiplexed (muxed) progress reports ..
* The "side-band-64k" capability -> newer clients can handle much larger
packets ..
It sounds like msysgit client _should_ correctly implement "send" part
of "side-band-64k" version of git protocol before fully enable
use_sideband=1. Rather than enable it just because "receive" part
of "side-band-64k" protocol works.
2) Workaround for one who _USE_ msysgit but not a _C_WIN32_ developer.
Install EGit(plugin for Eclipse) on same windows host and push to Linux box
from Eclipse with no problem while keep using your command line tools works
with msysgit.
Yes, same git repository (a folder on windows) is served by msysgit and
EGit with no problem if you do that in one at time manner.
msy...@googlecode.com
Comment #46 on issue 457 by liorta...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
Is there any news on this issue? i have been using Git (msysgit) on a
windows 7 with success, since i was using 1.7.4.msysgit.0 which as i was
told contains some fix for the problem.
Installing this version on a new desktop today is not working (getting
stuck on 100% when pushing).
What can be the problem here? and is there something that can be done to
circumvent this ?
msy...@googlecode.com
Comment #47 on issue 457 by Was...@gmail.com: Push over git protocol hangs
in msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Looks like the solution is to manually patch the source code yourself
http://code.google.com/p/msysgit/issues/attachmentText?id=457&aid=1482886574544170951&name=send-pack.diff&token=yu5_UBA67iUmHvgvNtJoO8JXdmo%3A1323242032592
The only problem is, how do you compile this thing? It looks like no one
is maintaining their web site anymore, so the link to the installation
procedure leads to an error page.
https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit
Does anyone still use msysgit who know how to compile git with the
appropriate patch?
Thanks =)
msy...@googlecode.com
Comment #48 on issue 457 by vkochepa...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
I would recommend you to use Java implementation of GIT on windows
platform. Because it does work!
1) If you need Git for develpment task than choose Net Beans or Eclipse IDE.
2) If you need it to run in CLI mode on build system, look at JGit library
with some CLI and Ant tasks for some common commands.
http://wiki.eclipse.org/JGit/User_Guide
+ JGit is an engine used in both IDE above and quite robust!
- Unfortunately they do not have any reasonable CLI implementation or one
for use with Ant directly.
http://www.jgit.org/ : "... but we are open to anyone wanting to interface
with other tools, Netbeans, Ant, Maven etc.".
You may re-consider to run your build system on Linux with native support
from Git and Ant.
An web search may give you some other ideas. Like jgit-ant project at
https://github.com/smartrics/jgit-ant etc.
Good luck,
Slav.
msy...@googlecode.com
Comment #49 on issue 457 by johannes...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
Re: maintaining websites, seems nobody bothers to search the mailing list
anymore. It was mentioned quite a couple of times that the problem is that
kernel.org was hacked and the Wiki has not come back up, and _nobody_
volunteered to port the msysGit pages to GitHub's Wiki. _Nobody_. Everybody
is satisfied with complaining.
Re: JGit, I have to say that JGit is a rather good reimplementation with C
Git. Unfortunately, it is not fully compatible, so 3rd-party add-ons on top
of Git do not work with JGit. Also, the suggestions how to use JGit seem to
be awfully focused on Java development -- which does not exactly apply to
many Windows users.
In any case, this issue tracker is closed (as you can see when surfing to
http://msysgit.googlecode.com/ -- a little research should have shown that
the best place to discuss things like this is the mailing list,
msy...@googlegroups.com). So please do not reply here.
Thank you for your attention.
Philip Oakley
Sent: Thursday, December 08, 2011 4:13 AM
Comment #49 on issue 457 by johannes...@gmail.com: ....
Re: maintaining websites, seems nobody bothers to search the mailing list
anymore. It was mentioned quite a couple of times that the problem is that
kernel.org was hacked and the Wiki has not come back up, and _nobody_
volunteered to port the msysGit pages to GitHub's Wiki. _Nobody_. Everybody
is satisfied with complaining.
Thank you for your attention.
----
Johannes,
I was checking up on what was needed to help you with this and found that
the git.wiki.kernel.org was already _partially_ restored, including most of
the MSysGit pages (a change from a few weeks ago).
I've seen from the list that we can still get at the old pages using
carefully crafted google searches.
The old web pages are now hidden under a google search of "msysgit
site:kernel.org", which brings up the old web pages but with _new_ URLs.
e.g.
https://git.wiki.kernel.org/articles/i/n/s/MSysGit~InstallMSysGit_1a31.html
https://git.wiki.kernel.org/articles/u/p/d/MSysGit~UpdatingMSysGit_7ab1.html
https://git.wiki.kernel.org/articles/g/i/t/MSysGit~GitCheetah_ddb8.html
https://git.wiki.kernel.org/articles/w/o/r/MSysGit~WorkingOnMsysGit_7b43.html
(i.e. it looks like they appended a hash code.., and used the first three
letters for sub-directories)
These pages properly link between each other. However I can't log in, nor
edit them.
Also, unfortunately, the https://git.wiki.kernel.org/index.html Search box
doesn't work, and neither does the "Category:Msysgit" option used in the
link from your http://code.google.com/p/msysgit/wiki/MovedToGitWiki page.
(Is it your page?)
As an initial work around, would it be reasonable to simple change the above
link on the MovedToGitWiki page to the static
https://git.wiki.kernel.org/articles/m/s/y/Category~MSysGit_ed62.html, or
https://git.wiki.kernel.org/articles/h/o/m/MSysGit~Home_7374.html, or
https://git.wiki.kernel.org/articles/i/n/s/MSysGit~InstallMSysGit_1a31.html
or [your choice]?
This would avoid the need for porting the wiki in the short term.
I also had a look at https://github.com/msysgit/msysgit and
https://github.com/msysgit/git but neither of them have a wiki page yet, and
I couldn't find how to create one on Github, so I wasn't sure what would be
needed for that part of re-creating the wiki.
Is changing the googlecode page an option?
Philip Oakley
Scotland
msy...@googlecode.com
Comment #50 on issue 457 by vkochepa...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
development -- which does not exactly apply to many Windows users.
You misunderstood my advice on JGit. JGit was in part (2) for running build
system - not for use by a developer.
If the problem of windows user is in bucket (1) development and you do
C/C++ on windows, why would not try NB or Eclipse IDE?
The NetBeans IDE is not ideal but does more than just Java. It allows to do
a development in C/C++, PHP and some other fancy languages.
I see an angree in your post regarding no volunteers. That is an ugly fact
of life not someone fault. There is a back side of doing C++ development on
windows without using M$ products. ;) But it is irrelevant to this mail
thread. Hoverer may explain a low popularity of a Git implementation just
for Windows.
msy...@googlecode.com
Comment #51 on issue 457 by johannes...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
I am very sorry, apparently I forgot to say one crucial thing:
This issue tracker is closed. So please, if you want to answer, do it on
the mailing list. In case you did not know the mailing list address (and it
is really very hard to find on the msysGit GoogleCode page):
msy...@googlegroups.com.
msy...@googlecode.com
Comment #52 on issue 457 by I...@excelsiorcarpetone.com: Push over git
http://code.google.com/p/msysgit/issues/detail?id=457
Is it responsible to set up "google traps" like this one and then whine
about people for exchanging support information? I realize now how mute
the issue was since the ssh protocol works fine in msysgit and is actually
easier to setup in order to push to a linux server
http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/#sshserver
but not everyone knows this immediately.
msy...@googlecode.com
Comment #53 on issue 457 by johannes...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
Dear IT@excelsiorcarpetone,com, please direct your complaints to the
mailing list. Its address is msy...@googlegroups.com.
msy...@googlecode.com
Comment #54 on issue 457 by wilson.j...@gmail.com: Push over git protocol
http://code.google.com/p/msysgit/issues/detail?id=457
I'll put a paltry $10 reward into the pot. Contact me to claim once fixed,
documented, verified, and new build is published. (Hacks don't count!)
msy...@googlecode.com
Status: Closed
Comment #55 on issue 457 by johannes...@gmail.com: Push over git protocol
hangs in msysGit
http://code.google.com/p/msysgit/issues/detail?id=457
Please note that this bug tracker is closed. Due to a shortcoming in
GoogleCode's adminstration interface, we cannot block write access, but
that does not mean that you should discuss things here.
So please redirect all your comments and contributions to the mailing list,
msy...@googlegroups.com.