Should we discuss Windows-related changes on git@vger.kernel.org?

Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

I decided to stop queuing changes in 4msysgit.  Instead I'd like to
bring the diff between Junio's and 4msysgit's master to zero.  This
seems to be achievable after Junio merged Hannes' MinGW changes.

I think all Windows-related changes to the git code base could be
discussed directly on the main git list and the msysgit list would be
reserved for the MinGW/MSYS runtime environment and the installer.  I do
not expect that Windows-related changes would add too much traffic to
the list.  But, even though we have mechanisms to separate the
platform-specific code from the main code base (like git-compat-util.h),
the Windows-related changes eventually need to be integrated with the
mainline, so it might make sense to discuss them on the main list right
away.

What do you think?

         Steffen

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> I decided to stop queuing changes in 4msysgit.  Instead I'd like to
> bring the diff between Junio's and 4msysgit's master to zero.  This
> seems to be achievable after Junio merged Hannes' MinGW changes.
> 
> I think all Windows-related changes to the git code base could be
> discussed directly on the main git list and the msysgit list would be
> reserved for the MinGW/MSYS runtime environment and the installer.

I disagree.  Judging from the mails I read on the git list, Junio gets 
really swamped by patches these days (what with our very productive GSoC 
students).

I really think that we should discuss the patches on the msysGit list 
first, whip them into shape, and then send them off.

Just think of those patches that were sent off, only to realize that they 
were no longer needed.  That should not have happened.

My 2p,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:

> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> I decided to stop queuing changes in 4msysgit.  Instead I'd like to
>> bring the diff between Junio's and 4msysgit's master to zero.  This
>> seems to be achievable after Junio merged Hannes' MinGW changes.
>>
>> I think all Windows-related changes to the git code base could be
>> discussed directly on the main git list and the msysgit list would be
>> reserved for the MinGW/MSYS runtime environment and the installer.
>
> I disagree.  Judging from the mails I read on the git list, Junio gets
> really swamped by patches these days (what with our very productive  
> GSoC
> students).

Sending the patches to the git list does not necessarily mean that
they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,
and git gui patches on the list too.  AFAIK, none of them are applied
by Junio directly but by the respective maintainers.  We could handle
Windows-related patches similarly.


> I really think that we should discuss the patches on the msysGit list
> first, whip them into shape, and then send them off.
>
> Just think of those patches that were sent off, only to realize that  
> they
> were no longer needed.  That should not have happened.


I intentionally sent the patches to show and discuss the differences
between the state of the MinGW port in Junio's master and in 4msysgit.
Some of the patches could be reverted in 4msysgit.  But, at least one
patch was unrelated to MinGW and is now in master.  Some other patches
need more work and are currently improved.  I think this was not a waste
of time.

	Steffen

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
> 
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >I decided to stop queuing changes in 4msysgit.  Instead I'd like to
> > >bring the diff between Junio's and 4msysgit's master to zero.  This
> > >seems to be achievable after Junio merged Hannes' MinGW changes.
> > >
> > >I think all Windows-related changes to the git code base could be
> > >discussed directly on the main git list and the msysgit list would be
> > >reserved for the MinGW/MSYS runtime environment and the installer.
> >
> >I disagree.  Judging from the mails I read on the git list, Junio gets
> >really swamped by patches these days (what with our very productive GSoC
> >students).
> 
> Sending the patches to the git list does not necessarily mean that
> they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,
> and git gui patches on the list too.  AFAIK, none of them are applied
> by Junio directly but by the respective maintainers.  We could handle
> Windows-related patches similarly.

Then what is the msysGit list about?

No, I really disagree.  Windows support is too large a thing, and partly a 
too disgusting one to bother the git list.

> >I really think that we should discuss the patches on the msysGit list 
> >first, whip them into shape, and then send them off.
> >
> >Just think of those patches that were sent off, only to realize that 
> >they were no longer needed.  That should not have happened.
> 
> I intentionally sent the patches to show and discuss the differences 
> between the state of the MinGW port in Junio's master and in 4msysgit. 
> Some of the patches could be reverted in 4msysgit.  But, at least one 
> patch was unrelated to MinGW and is now in master.  Some other patches 
> need more work and are currently improved.  I think this was not a waste 
> of time.

IMO we could have discussed first what is the current state on the msysGit 
list, and I would have commented there already on the patches that I think 
would no longer be needed.

Then the patch would have been sent off, and be in master, too.

The difference: it would have been more efficient.  Those people who can 
test if something is still needed on Windows are on the msysGit list.

We do not really need to clutter git@vger more than necessary.

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

On Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:

> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
>>
>>> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>>>
>>>> I decided to stop queuing changes in 4msysgit.  Instead I'd like to
>>>> bring the diff between Junio's and 4msysgit's master to zero.  This
>>>> seems to be achievable after Junio merged Hannes' MinGW changes.
>>>>
>>>> I think all Windows-related changes to the git code base could be
>>>> discussed directly on the main git list and the msysgit list  
>>>> would be
>>>> reserved for the MinGW/MSYS runtime environment and the installer.
>>>
>>> I disagree.  Judging from the mails I read on the git list, Junio  
>>> gets
>>> really swamped by patches these days (what with our very  
>>> productive GSoC
>>> students).
>>
>> Sending the patches to the git list does not necessarily mean that
>> they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk,
>> and git gui patches on the list too.  AFAIK, none of them are applied
>> by Junio directly but by the respective maintainers.  We could handle
>> Windows-related patches similarly.
>
> Then what is the msysGit list about?

I think the msysGit list could be useful for:

  - Everything that is in the msysgit repo, i.e. the MinGW/MSYS
    runtime environment and the installers.

  - User questions, including the issue tracker.


> No, I really disagree.  Windows support is too large a thing, and  
> partly a
> too disgusting one to bother the git list.

My understanding is that the mainline of git starts supporting the MinGW
port with version 1.6.0.  The MinGW port is merged to Junio's master, so
the remaining differences between Junio's master and 4msysgit's master
should be removed and afterwards new changes should be discussed,  
improved,
and applied to Junio's master anyway.  This would also allow to directly
test Junio's next on Windows.


>>> I really think that we should discuss the patches on the msysGit  
>>> list
>>> first, whip them into shape, and then send them off.
>>>
>>> Just think of those patches that were sent off, only to realize that
>>> they were no longer needed.  That should not have happened.
>>
>> I intentionally sent the patches to show and discuss the differences
>> between the state of the MinGW port in Junio's master and in  
>> 4msysgit.
>> Some of the patches could be reverted in 4msysgit.  But, at least one
>> patch was unrelated to MinGW and is now in master.  Some other  
>> patches
>> need more work and are currently improved.  I think this was not a  
>> waste
>> of time.
>
> IMO we could have discussed first what is the current state on the  
> msysGit
> list, and I would have commented there already on the patches that I  
> think
> would no longer be needed.
>
> Then the patch would have been sent off, and be in master, too.
>
> The difference: it would have been more efficient.  Those people who  
> can
> test if something is still needed on Windows are on the msysGit list.
>
> We do not really need to clutter git@vger more than necessary.

But git 1.6 will contain the MinGW port.  Shouldn't related patches
then be discussed on git@vger?

	Steffen

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> On Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:
> 
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
> > >
> > > >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> > > >
> > > > >I decided to stop queuing changes in 4msysgit.  Instead I'd like 
> > > > >to bring the diff between Junio's and 4msysgit's master to zero.  
> > > > >This seems to be achievable after Junio merged Hannes' MinGW 
> > > > >changes.
> > > > >
> > > > >I think all Windows-related changes to the git code base could be 
> > > > >discussed directly on the main git list and the msysgit list 
> > > > >would be reserved for the MinGW/MSYS runtime environment and the 
> > > > >installer.
> > > >
> > > >I disagree.  Judging from the mails I read on the git list, Junio 
> > > >gets really swamped by patches these days (what with our very 
> > > >productive GSoC students).
> > >
> > >Sending the patches to the git list does not necessarily mean that 
> > >they are directly addressed to Junio.  We discuss JGIT, EGIT, gitk, 
> > >and git gui patches on the list too.  AFAIK, none of them are applied 
> > >by Junio directly but by the respective maintainers.  We could handle 
> > >Windows-related patches similarly.
> >
> >Then what is the msysGit list about?
> 
> I think the msysGit list could be useful for:
> 
> - Everything that is in the msysgit repo, i.e. the MinGW/MSYS
>   runtime environment and the installers.

Which very much includes brushing up the patches in 4msysgit, which are 
invariably of lower quality than git.git's, because we lack a brilliant 
maintainer like Junio.

Come to think of it, we do not have a maintainer at all.  Many people can 
commit and push into 4msysgit, and I am debating with myself for a long 
time already if that was a sensible thing to do.  Just think of that C# 
desaster.

> >No, I really disagree.  Windows support is too large a thing, and 
> >partly a too disgusting one to bother the git list.
> 
> My understanding is that the mainline of git starts supporting the MinGW 
> port with version 1.6.0.  The MinGW port is merged to Junio's master, so 
> the remaining differences between Junio's master and 4msysgit's master 
> should be removed and afterwards new changes should be discussed, 
> improved, and applied to Junio's master anyway.  This would also allow 
> to directly test Junio's next on Windows.

Junio expressed several times that he is uncomfortable that he cannot 
easily test Windows support himself.

I strongly doubt that discussing things on git@vger that are not even 
half-cooked would help that impression.

Also, there are a lot of people on git@vger who could not care _less_ 
about Windows.

And there are a few on the list who could not care less about those 
Windows users who seem to be content to let others work for them, but 
comment at every _possible_ occasion, on what should, and what should not 
be done.  Let's keep them on the msysGit list, for the benefit of the 
saner half of git@vger.

> > > >I really think that we should discuss the patches on the msysGit 
> > > >list first, whip them into shape, and then send them off.
> > > >
> > > >Just think of those patches that were sent off, only to realize 
> > > >that they were no longer needed.  That should not have happened.
> > >
> > >I intentionally sent the patches to show and discuss the differences 
> > >between the state of the MinGW port in Junio's master and in 
> > >4msysgit. Some of the patches could be reverted in 4msysgit.  But, at 
> > >least one patch was unrelated to MinGW and is now in master.  Some 
> > >other patches need more work and are currently improved.  I think 
> > >this was not a waste of time.
> >
> >IMO we could have discussed first what is the current state on the 
> >msysGit list, and I would have commented there already on the patches 
> >that I think would no longer be needed.
> >
> >Then the patch would have been sent off, and be in master, too.
> >
> >The difference: it would have been more efficient.  Those people who 
> >can test if something is still needed on Windows are on the msysGit 
> >list.
> >
> >We do not really need to clutter git@vger more than necessary.
> 
> But git 1.6 will contain the MinGW port.  Shouldn't related patches then 
> be discussed on git@vger?

See above.  There will be a rudimentary support for MinGW, yes, but that's 
for hardcore people like Hannes.

For those who just want to use Git on Windows, there is msysGit.  And 
for them, we have the msysGit list.

Let's not confuse things, let's not upset git@vger with too many less 
clueful users who should rather post to msysgit@googlegroups.com.

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Linus Torvalds]

On Fri, 11 Jul 2008, Johannes Schindelin wrote:
> 
> Which very much includes brushing up the patches in 4msysgit, which are 
> invariably of lower quality than git.git's, because we lack a brilliant 
> maintainer like Junio.

Umm. The other side of the coin is:

 - a lot of people with good taste won't _be_ on the windows lists, 
   because there is likely a high correlation with "good taste in 
   development" and "try to avoid using windows"

 - a lot of Junio's maintenance is likely helped by the fact that (a) he 
   sees the features being discussed and the reason for them and (b) the 
   patches have in general seen comments from other people.

 - 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.

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.

		Linus

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

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.

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.

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

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

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> 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",

Maybe I am overly cautious, but you remember what drove me away from 
msysGit?  Exactly, people, and issues, took out all the fun.

Let's not inflict upon git@vger what they did not deserve to suffer.

And if the separation is not always that clear, why not discuss those 
things on msysGit first, and then come to git@vger with our minds (and 
possibly our patches) made up?

> Another example is the discussion about GIT_EXEC_PATH, see
> 
> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633

This is a particularly good example that does not matter for Linux, 
MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.

And once this patch hits git@vger, it is still visible to other platforms.

> 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

So?  If it did not hit other platforms, it is the duty of that guy to find 
out what it is.  And if it _does_ turn out to be a Windows-specific bug, 
which might very well be the case, we do not need to add to the volume of 
git@vger.

> >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.

Sure the benefit is undisputed.

Now let's look at the downsides: we take away time, and possibly fun, from 
many more people than one or two persons.

It's like spam.  Asking somebody to "just hit the delete button" stops 
being funny very quickly.

> 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.

I am not so sure.

Your experience should match mine, that the patches coming in through 
msysGit are of a substantial lower quality than what we are used to on 
git@vger.

If you want to force those patches unfiltered onto the readers of 
git@vger, it would only be fair that you have to clean the readers' latest 
lunch out of their keyboards.

Ciao,
Dscho "who has a fata morgana of windmills"

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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.

It is not being masochist, but being practical by trying to know what to
avoid in advance.

>> 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.  

Hannes did a great job with help from msysGit people to contain platform
specific stuff in compat/ layer.  A good rule of thumb to decide what not
to talk about here is:

 - If it is purely about implementation inside compat/ layer, such as
   creating spawn() using Windows specific API, it is probably better done
   on the msysGit list, where presumably more people whose has expertise
   on the particular platform would hang around;

 - If it is about "I downloaded msysgit prepackaged binary and this and
   that does not work as I expect, I haven't bothered trying to build it
   from source on POSIX systems and see if it is broken in the upstream",
   the RFH does not belong here but platform specific forum.  This applies
   not just to Windows but to various distro binary distributions on Linux
   as well.

On the other hand, even if it is related to porting to Windows, discussing
what the compat/ abstraction should look like is very relevant to this
list.

For example, I like is_absolute_path() abstraction you and Hannes pushed
for, but I have a slight distaste against has_dos_drive_prefix().  Some
uses of that macro is about telling if a string is a local file pathname
(e.g. connect()), and some other uses of that macro is about the fact that
on Windows you cannot necessarily make one path relative to another but
our code largely assume that any path can be made relative to any other
path (i.e. on traditional UNIX without "//", you can always make a path
relative by prefixing enough number of "../" to go up, even to root if
needed, but you cannot make C:\foo relative to D:\bar).  We may be able to
find a better abstraction than what has_dos_drive_prefix() offers, and I
think that discussion belongs to here.

Another example that has already happened was our move away from direct
use of fork/exec but abstracting it out to run_command() layer.  This
would not have settled in a shape usable by both Windows and POSIX if
people from both camps did not participate in the design and review.

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> And if the separation is not always that clear, why not discuss those 
> things on msysGit first, and then come to git@vger with our minds (and 
> possibly our patches) made up?

I know you mean well, but my impression from reading the kernel list is
that often a message that says "we already debated this issue on our list
to death and here is our conclusion, take it or leave it" to the audience
is not accepted warmly, and more central kernel people may even say "do
not hide the discussion in the subsystem list, do it in the open,
discussion on the subsystem list does not matter".

Taking that lesson from the other community, I'd suggest that it is
probably a good idea to start discussion on your list, but once (some)
people in the discussion think the topic is releavant here, move it here
sooner rather than later.

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Junio C Hamano wrote:

> Another example that has already happened was our move away from direct 
> use of fork/exec but abstracting it out to run_command() layer.  This 
> would not have settled in a shape usable by both Windows and POSIX if 
> people from both camps did not participate in the design and review.

I think that is a perfect example, since Hannes worked on it in mingw.git.  
AFAIR a few comments came through msysGit, and were incorporated.  When 
everything was good for a first go at git@vger, it was sent, and the 
interface finalized.

And I agree that it is a pretty beautiful interface.

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > And if the separation is not always that clear, why not discuss those 
> > things on msysGit first, and then come to git@vger with our minds (and 
> > possibly our patches) made up?
> 
> I know you mean well, but my impression from reading the kernel list is 
> that often a message that says "we already debated this issue on our 
> list to death and here is our conclusion, take it or leave it" to the 
> audience is not accepted warmly, and more central kernel people may even 
> say "do not hide the discussion in the subsystem list, do it in the 
> open, discussion on the subsystem list does not matter".

I never meant on insisting that we find the final solution on the msysGit 
list, and I would _never_ suggest that anything sent to git@vger is final.  
It is always subject to discussion.

Anyway, enough said (since I think that you and me are in agreement here),
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Linus Torvalds]

On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> 
> I think that is a perfect example, since Hannes worked on it in mingw.git.  
> AFAIR a few comments came through msysGit, and were incorporated.  When 
> everything was good for a first go at git@vger, it was sent, and the 
> interface finalized.

Umm. Dscho - that was before the thing was merged.

Now that the basic mingw support is part of standard git, the situation 
has changed.

That's the main issue here - if mingw support is in standard git (and it 
is), then mingw issues that touch any non-mingw code should be discussed 
where all the git developers are.

Can't you see the difference between the pre-merge and the post-merge 
situation?

		Linus

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Linus Torvalds wrote:

> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> > 
> > I think that is a perfect example, since Hannes worked on it in 
> > mingw.git.  AFAIR a few comments came through msysGit, and were 
> > incorporated.  When everything was good for a first go at git@vger, it 
> > was sent, and the interface finalized.
> 
> Umm. Dscho - that was before the thing was merged.
> 
> Now that the basic mingw support is part of standard git, the situation 
> has changed.
> 
> That's the main issue here - if mingw support is in standard git (and it 
> is), then mingw issues that touch any non-mingw code should be discussed 
> where all the git developers are.
> 
> Can't you see the difference between the pre-merge and the post-merge 
> situation?

Sure I can.

But we are talking about 4msysgit.git, no?

At least the patches that Steffen sent were all from 4msysgit.git, and for 
some reason or other not necessary for Hannes' mingw.git.

We are talking about stuff like that putty thing, where people feel it 
would be a better idea to avoid scripts, at the cost of a higher 
maintenance burden.

We are talking about patches that were necessary a long time ago, but are 
no longer, and we should have that sorted out on the msysGit list before 
sending them to a list where many people could not care less for Windows, 
and are probably annoyed to even read as much as _this_ thread about it, 
let alone be bothered by patches that turn out to be stale in the first 
place.

_That_ is what I am arguing should be sorted out, at least the early 
stages, on msysGit.  As we did in the past.

And that worked out rather well so far, do you disagree?

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Linus Torvalds]

On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> 
> But we are talking about 4msysgit.git, no?

I'm not. I'm just talking about Windows-related changes in git in 
general, that are expected to be merged into regular git one way or 
another.

If it's something that should be merged, and if it concerns code that I'm 
interested in, I want to know about it. It's that simple.

The fact that _all_ windows discussion used to be in a different area and 
not on the -git list is past. It was definitely the case that it didn't 
affect any normal git code, since it was all maintained in a separate tree 
and the normal git tree was simply not even _relevant_, and didn't even 
try to be.

But that's changed. I think the windows support merge was really quite 
well done, and was a rather clean series, and no, I don't think the unix 
people cared about it when there was so much fundamental stuff needed to 
be done - we didn't have any relevant input.

But I'd certainly _hope_ that future windows work is incremental, and at 
that point it's no longer a "drop the end result on people" situation.

		Linus

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Linus Torvalds wrote:

> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
> > 
> > But we are talking about 4msysgit.git, no?
> 
> I'm not. I'm just talking about Windows-related changes in git in 
> general, that are expected to be merged into regular git one way or 
> another.
>
> [...]
> 
> But I'd certainly _hope_ that future windows work is incremental, and at 
> that point it's no longer a "drop the end result on people" situation.

Fair enough.  You'll get all the crap now, I expect.

Seriously again, I really hope that things do not change very much.  Even 
if the occasional patch will now come in directly to git@vger.

Ciao,
Dscho

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Linus Torvalds]

On Fri, 11 Jul 2008, Linus Torvalds wrote:
> 
> If it's something that should be merged, and if it concerns code that I'm 
> interested in, I want to know about it. It's that simple.

Btw, an example of where I think we need to look at both windows and unix 
behavior and not try to make them two different camps is in that
"start_command()" thing.

It was changed to have a totally separate __MINGW32__ part, but the thing 
is, the unix side could really be improved - and actually made more like 
the MINGW32 code at the same time!

For example, on many systems it is rather noticeably faster to use 
"vfork+execve" than it is to do "fork+execve", because you avoid a whole 
"duplicate and tear down page tables" sequence. So the UNIX code would 
actually be better off using "vfork()" instead of "fork()" there.

But it can't right now - because if "cmd->env" changes the environment, it 
would change it both in the caller and in the result.

It turns out that Windows has the exact same issue (because it uses a 
spawn thing), and already does a "copy_env() + change-in-copy + free" 
model for that reason.

If that was shared, the UNIX side could just use vfork, I believe. In 
fact, the following trivial - but horribly ugly - patch passes all the 
tests, by doing the vfork() in all cases except when the environment 
changes. But I don't know what coverage that has, though (maybe env is 
effectively always set?).

And I suspect there are other cases where we'd actually be better off 
trying to share things than having all the differences hidden away in 
compat layers.

			Linus

---
 builtin-grep.c |    2 +-
 run-command.c  |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin-grep.c b/builtin-grep.c
index ef29910..5d3053a 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -168,7 +168,7 @@ static int exec_grep(int argc, const char **argv)
 	int status;
 
 	argv[argc] = NULL;
-	pid = fork();
+	pid = vfork();
 	if (pid < 0)
 		return pid;
 	if (!pid) {
diff --git a/run-command.c b/run-command.c
index 6e29fdf..200ba7b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -68,7 +68,7 @@ int start_command(struct child_process *cmd)
 	trace_argv_printf(cmd->argv, "trace: run_command:");
 
 #ifndef __MINGW32__
-	cmd->pid = fork();
+	cmd->pid = cmd->env ? fork() : vfork();
 	if (!cmd->pid) {
 		if (cmd->no_stdin)
 			dup_devnull(0);

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

On Jul 12, 2008, at 1:58 AM, Linus Torvalds wrote:

> On Sat, 12 Jul 2008, Johannes Schindelin wrote:
>>
>> But we are talking about 4msysgit.git, no?
>
> I'm not. I'm just talking about Windows-related changes in git in
> general, that are expected to be merged into regular git one way or
> another.

The discussion is not about 4msysgit, because 4msysgit will no longer
be needed after we cleaned up all differences between Junio's master
and 4msysgit's master.

I propose the following steps:

  - We review the differences and either prepare patches for official  
git
    or revert commits in 4msysgit.
    -> It will no longer matter if we build the msysgit release from
    Junio's master or from 4msysgit's master.

  - We change the /git submodule in msysgit to point to Junio's repo.
    -> Every developer on Windows will work with the official code base.

  - Windows-users can (and should) participate in the official release
    cycle.  They should test the next branch and the master branch after
    the merge window closed.  We can easily create installers for  
Junio's
    release candidates (I will do this).

We should provide a guideline how developers and users should send
comments and improvements related to Windows.  Such a guideline could be
included in Junio's "A note from the maintainer" mail.  The section on
Windows needs to be changed anyway.  Currently it says:

'''
- Johannes Schindelin and Johannes Sixt for their effort to
   move things forward on the Windows front.  Although my
   repository does not have much from the effort of MinGW team,
   I expect a merge into mainline will happen so that everybody
   can work from the same codebase.
'''

[ Note that the last sentence will become true if we do what I propose
   above. ]

We could send more detailed guidelines to the msysgit list and/or modify
the homepage of the msysgit project.  I think Junio's rule of thumb in

   http://article.gmane.org/gmane.comp.version-control.git/88191

is a good starting point.

It would be good to achieve all this during the 1.6 cycle, because
MinGW is officially part of 1.6.  I am however not sure if it is
practical.  We have some changes in 4msysgit that might need more
discussion and we did not even start discussing the tests.  So maybe
1.6.1 is more realistic.

	Steffen

Re: Should we discuss Windows-related changes on git@vger.kernel.org?

[Steffen Prohaska]

On Jul 11, 2008, at 11:38 PM, Johannes Schindelin wrote:

>> Another example is the discussion about GIT_EXEC_PATH, see
>>
>> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
>
> This is a particularly good example that does not matter for Linux,
> MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.
>
> And once this patch hits git@vger, it is still visible to other  
> platforms.

Hmm... on Mac OS X, applications can typically be moved freely in the
filesystem.  Installing such an application means no more than mounting
a disk image that contains a directory that you can drag and drop to any
location in the filesystem.  You do not need administrative rights to do
this.

For command line programs, like git, moving the installation freely is
less common.  Installers often place everything in /usr/local/ (they
need administrative rights to do so).  But there are other examples too.
For example, I have other vims installed in addition to the system's  
vim:

   /Applications/vim70/Vim.app
   /Applications/MacVim-snapshot-24/mvim

that I can freely move around.

The result of our discussion on GIT_EXEC_PATH might be useful to achieve
something similar for git -- although I think that it is not an  
essential
feature.

	Steffen