Re: Should we discuss Windows-related changes on git@xxxxxxxxxxxxxxx?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:

On Fri, 11 Jul 2008, Linus Torvalds wrote:

- It may well be good to explain to the _real_ git people (eg me) what
  the problems in Windows land are, so that we get a first-hand view
  into hell, and can maybe take it into account when we make changes
  for other things.

Wow.  I did not think that you were a masochist.

IOW, I think that since 1.6.0 is supposed to have native support for
windows, we should have patches discussed on the regular git list. The ghetto that is windows can be useful for _user_ discussions, where a lot
of the core git people simply cannot help. But having development
discussions there is bad, I think.

We do have development discussions there that do not belong to git@vger.
For example, when Hannes reimplemented the utterly broken spawn()
implementation of Microsoft's "Run" time library.

That is not something you need to see, want to see, or can help with.

The separation is not always that clear.  For example, the discussion
of issue 130 might benefit from "a first-hand view into hell", see

http://thread.gmane.org/gmane.comp.version-control.msysgit/2653/focus=2682


Another example is the discussion about GIT_EXEC_PATH, see

http://thread.gmane.org/gmane.comp.version-control.msysgit/2633

It might be triggered by msysGit's need to freely move a git installation in the filesystem. The resulting feature might however be interesting on
other platforms, too.


A last example is the crash of gitk that was observed on Windows and is
now buried in the msysGit issue tracker, although I am pretty sure that
is it not windows-specific, see

http://code.google.com/p/msysgit/issues/detail?id=125



Likewise, I think it has nothing to do with the git@vger list when we add work-arounds until some better solution is found, and then discuss whether
the workaround is still needed.

I cannot help to see the benefit, at least.

Once things are sorted out, I agree, it has to be sent to the git list.

Before that, however, allow us to work on another list.

Personally, I'd find it easier to work on a single list.  MinGW support
is mature enough and workarounds should now be avoid.  If we tested git
during the official release cycle, we would have sufficient time to find
and solve problems on Windows and prepare patches that have sufficient
quality to be discuss on git@vger.

	Steffen


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux