From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:49
"Alex Riesen" [off-list ref] writes:
I'd like to see ".patch" there, but...
I have to mention, though, that the majority of the editing
programs is used on that stupid thing called windows ...
Even if majority of git target audience were on Windows, I
thought majority of Windows users are on either VFAT or NTFS and
not DOS 8.3 filesystems these days.
Also, how many mail clients know that .patch is actually
a text and not application/binary? It'll make patch
reviewing harder for some (not sure if I'd like a review
of such a person, though).
Is it common for popular MUAs to have a single command that lets
you specify a file and depending on its suffix paste it inline
or make it an attachment? I had an impression that most have
separate commands for "read text from file (as opposed to
typing)" and "attach a file (of random type, not necessarily and
more often than not text)".
The output of format-patch is not meant to be used as an
attachment (it is "read text from file" kind), so I do not think
your worry applies here. Maybe something I am missing?
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Junio C Hamano [off-list ref] wrote:
quoted
I'd like to see ".patch" there, but...
I have to mention, though, that the majority of the editing
programs is used on that stupid thing called windows ...
Even if majority of git target audience were on Windows, I
thought majority of Windows users are on either VFAT or NTFS and
not DOS 8.3 filesystems these days.
The filesystems are not 8.3, the programs are.
quoted
Also, how many mail clients know that .patch is actually
a text and not application/binary? It'll make patch
reviewing harder for some (not sure if I'd like a review
of such a person, though).
Is it common for popular MUAs to have a single command that lets
you specify a file and depending on its suffix paste it inline
or make it an attachment? I had an impression that most have
separate commands for "read text from file (as opposed to
typing)" and "attach a file (of random type, not necessarily and
more often than not text)".
No, they don't :) They only have "attach" and drag-drop (which does the same).
The output of format-patch is not meant to be used as an
attachment (it is "read text from file" kind), so I do not think
your worry applies here. Maybe something I am missing?
Yes, the experience being a damned corporate windows user
in a novell netware network with 50-year old admin fixated on
microsoft exchange, not to mention Outlook Express users...
I think we'd raising the entry barrier with choosing the defaults
being so convenient for us. Well, the real-life programmers
are less of Unix-liking kind. They are more lazy and demotivated
kind, and Git will be _forced_ on them. It almost certainly
will not be their choice. Not always, some'll like it (heck, I know
people who swear by Perforce!), but most have a job, source
of income, and not the profession (like in professional pride).
As much as like Unix and everything related, I think it is
not reasonable to try to change the majority. Not unless
we have something earth-shattering. Well, git is, but
0001-fix....patch in email attachment probably not.
I think we'd raising the entry barrier with choosing the defaults
being so convenient for us. Well, the real-life programmers
are less of Unix-liking kind. They are more lazy and demotivated
kind, and Git will be _forced_ on them. It almost certainly
will not be their choice. Not always, some'll like it (heck, I know
people who swear by Perforce!), but most have a job, source
of income, and not the profession (like in professional pride).
As much as like Unix and everything related, I think it is
not reasonable to try to change the majority. Not unless
we have something earth-shattering. Well, git is, but
0001-fix....patch in email attachment probably not.
I would venture to say that the _majority_ of git users are not using
Windows. In this enviroment, Linux is likely the dominant OS,
followed by other *nix. So changing the extention to benefit the
majorit of _git's_ users is a good thing.
josh
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:49
Junio C Hamano wrote:
Is it common for popular MUAs to have a single command that lets
you specify a file and depending on its suffix paste it inline
or make it an attachment? I had an impression that most have
separate commands for "read text from file (as opposed to
typing)" and "attach a file (of random type, not necessarily and
more often than not text)".
Most have only "attach" through various means of point-and-click and
drag-and-drop. Thunderbird too lacks the very basic ability of "include
this file as part of the message". I still haven't been able to find an
addon for it that does just that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Josh Boyer [off-list ref] wrote:
quoted
I think we'd raising the entry barrier with choosing the defaults
being so convenient for us. Well, the real-life programmers
are less of Unix-liking kind. They are more lazy and demotivated
kind, and Git will be _forced_ on them. It almost certainly
will not be their choice. Not always, some'll like it (heck, I know
people who swear by Perforce!), but most have a job, source
of income, and not the profession (like in professional pride).
Just because you are not able to realize that the count of
windows-based projects is still superior to that of say...
"likable" systems, they wont magically disappear.
If that is the case, I think I do some more insulting
and say that they are not only real-life but also will never
accept the statement of their ways being wrong, however
stupid they may appear. That's just how it is, count them if
you don't believe me.
quoted
As much as like Unix and everything related, I think it is
not reasonable to try to change the majority. Not unless
we have something earth-shattering. Well, git is, but
0001-fix....patch in email attachment probably not.
I would venture to say that the _majority_ of git users are not using
Windows.
The _real_ majority of the programmers desperately need a better
VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
In this enviroment, Linux is likely the dominant OS,
followed by other *nix. So changing the extention to benefit the
majorit of _git's_ users is a good thing.
Yes. For me and you. One of my coworkers knows nothing about patches,
but wants (and perfectly able to) review my code. He has usable brains
and is able to figure out what "+" and "-" is (he has, by now). He hasn't
even realized that it was an automatically generated information, as
I sent a patch to him first time, thought it was just a funny way to
document changes (and was surprised when I told him a patch can be
applied automatically, even if the original file is not exactly the same).
But he is a typical windows-trained programmer. Lazy, unmotivated and
happily married. He does programming by accident (was smart enough
to learn the basics of the trade). Why would he want to take the an
extra step of figuring out what that strange "0001-...patch" means?
Now, I know him, would never think about sending him a real patch.
I'm kinda grown and tired, and need the bastard, too. Someone younger
will just call him idiot and "improve" the situation by telling him about
"stupid windows" and "he should the right ways". Just to be answered
"it worked for some millions programmers before you" and "I told your
manager you making problems and are hard to communicate with".
People often understand "funny ways" the others may have. They
don't like been told they are wrong or stupid (especially when they
actually are stupid).
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:49
Alex Riesen wrote:
On 1/18/07, Josh Boyer [off-list ref] wrote:
quoted
quoted
As much as like Unix and everything related, I think it is
not reasonable to try to change the majority. Not unless
we have something earth-shattering. Well, git is, but
0001-fix....patch in email attachment probably not.
I would venture to say that the _majority_ of git users are not using
Windows.
The _real_ majority of the programmers desperately need a better
VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
They're free to use git ofcourse, provided they install cygwin or help
migrate it to run natively on windows. I don't think anyone would cry if
a competent cross-platform programmer stepped up and started submitting
patches to get git working on windows without having to resort to the
cygwin emulation layer.
The thing is, no-one's getting paid for it, so until someone *does* step
up, it won't happen, as 95% of the *current* git users are still running
what we on this list will indefinitely refer to as "a sane OS".
quoted
In this enviroment, Linux is likely the dominant OS,
followed by other *nix. So changing the extention to benefit the
majorit of _git's_ users is a good thing.
Yes. For me and you. One of my coworkers knows nothing about patches,
but wants (and perfectly able to) review my code. He has usable brains
and is able to figure out what "+" and "-" is (he has, by now). He hasn't
even realized that it was an automatically generated information, as
I sent a patch to him first time, thought it was just a funny way to
document changes (and was surprised when I told him a patch can be
applied automatically, even if the original file is not exactly the same).
But he is a typical windows-trained programmer. Lazy, unmotivated and
happily married. He does programming by accident (was smart enough
to learn the basics of the trade). Why would he want to take the an
extra step of figuring out what that strange "0001-...patch" means?
Now, I know him, would never think about sending him a real patch.
I'm kinda grown and tired, and need the bastard, too. Someone younger
will just call him idiot and "improve" the situation by telling him about
"stupid windows" and "he should the right ways". Just to be answered
"it worked for some millions programmers before you" and "I told your
manager you making problems and are hard to communicate with".
People often understand "funny ways" the others may have. They
don't like been told they are wrong or stupid (especially when they
actually are stupid).
I still don't see the problem. When he understands (and uses) git, the
name and look of the patch will become blindingly clear to him, and then
it doesn't matter if it's called .txt or .patch. He might even have some
tool by then that displays patches color-coded and what-not (there are a
plethora of such tools for Windows already, most of which register
.patch and .diff as file-types they handle).
Otoh, *until* he uses git, the change doesn't affect him, so why bother
catering for his needs?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:49
Hi,
On Thu, 18 Jan 2007, Andreas Ericsson wrote:
I still don't see the problem. When he understands (and uses) git, the
name and look of the patch will become blindingly clear to him,
Not so. Never underestimate mental inertia.
Recently, a co-worker (in a database-backed webapplication project!) asked
what an SQL injection might be.
Of 5 developers, only 2 were able to answer!
Face it, there are a lot of incompetent programmers out there. And I am
very happy you put up with me on this list.
Ciao,
Dscho
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Andreas Ericsson [off-list ref] wrote:
Alex Riesen wrote:
quoted
On 1/18/07, Josh Boyer [off-list ref] wrote:
quoted
quoted
As much as like Unix and everything related, I think it is
not reasonable to try to change the majority. Not unless
we have something earth-shattering. Well, git is, but
0001-fix....patch in email attachment probably not.
I would venture to say that the _majority_ of git users are not using
Windows.
The _real_ majority of the programmers desperately need a better
VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
They're free to use git ofcourse, provided they install cygwin or help
migrate it to run natively on windows. I don't think anyone would cry if
My example had cygwin installed for him. Is it too unusual?
a competent cross-platform programmer stepped up and started submitting
patches to get git working on windows without having to resort to the
cygwin emulation layer.
don't think so. I _would_ cry seeing how fork(2) gets ported to Windows,
and you will, probably... after seeing how it is done in cygwin.
The thing is, no-one's getting paid for it, so until someone *does* step
up, it won't happen, as 95% of the *current* git users are still running
what we on this list will indefinitely refer to as "a sane OS".
95% of the current users probably is not even 1% of all programmers
who would gladly use it and maybe less than a fraction of percent of
the ones who need it.
quoted
People often understand "funny ways" the others may have. They
don't like been told they are wrong or stupid (especially when they
actually are stupid).
I still don't see the problem. When he understands (and uses) git, the
he does not use git. He knows what the patch is (now I have explained
it to him), I suppose he would still be mildly surprised seeing a file.patch,
but he'll probably recover.
name and look of the patch will become blindingly clear to him, and then
it doesn't matter if it's called .txt or .patch. He might even have some
tool by then that displays patches color-coded and what-not (there are a
plethora of such tools for Windows already, most of which register
.patch and .diff as file-types they handle).
That wont happen until windows registers it for them. And that, again,
wont ever happen. Every user will register .patch to notepad, visual
studio or ultraedit or something else for himself.
Otoh, *until* he uses git, the change doesn't affect him,
actually, patch works for git patches, so format-patch produces
files useful output for anyone.
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:49
Hi,
On Thu, 18 Jan 2007, Alex Riesen wrote:
[discussion about suffix being "patch" or "txt" per default]
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Johannes Schindelin [off-list ref] wrote:
quoted
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
Better control that with templates.
Do we have a template for config already? I thought they were only for hooks...
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:49
Hi,
On Thu, 18 Jan 2007, Alex Riesen wrote:
On 1/18/07, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
Better control that with templates.
Do we have a template for config already? I thought they were only for
hooks...
The template mechanism can handle _all_ files in GIT_DIR. Just drop a
"config" into the templates directory, and you're settled.
Ciao,
Dscho
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:49
Alex Riesen [off-list ref] wrote:
don't think so. I _would_ cry seeing how fork(2) gets ported to Windows,
and you will, probably... after seeing how it is done in cygwin.
AFAIK there's not a strong reason to keep fork() in Git.
Currently anytime we fork a process its to perform a small amount
of file descriptor redirection and then immediately exec some other
executable, or a hook script. In other words we probably could
convert all current uses of fork to something like in run-command.c,
which a Windows port could then easily replace using CreateProcess().
But removing fork isn't worth doing until someone is seriously
trying to port Git onto Windows without Cygwin. The current code
works on sane OSes and isn't broken, so why fix it?
--
Shawn.
From: Brian Gernhardt <hidden> Date: 2016-06-15 22:42:49
On Jan 18, 2007, at 7:40 AM, Andreas Ericsson wrote:
Junio C Hamano wrote:
quoted
Is it common for popular MUAs to have a single command that lets
you specify a file and depending on its suffix paste it inline
or make it an attachment? I had an impression that most have
separate commands for "read text from file (as opposed to
typing)" and "attach a file (of random type, not necessarily and
more often than not text)".
Most have only "attach" through various means of point-and-click
and drag-and-drop. Thunderbird too lacks the very basic ability of
"include this file as part of the message". I still haven't been
able to find an addon for it that does just that.
The "easiest" way is to open it in an editor and Copy'n'Paste it into
the message. Unfortunately, not all clipboards or applications can
be trusted not to mangle whitespace. I learned that the hard way
trying to use Mail.app to send out patches. I ended up just
installing Mutt. Perhaps I should figure out how this "git-send-
email" works, although it doesn't appear to support authentication...
~~ Brian
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
quoted
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
Better control that with templates.
Do we have a template for config already? I thought they were only for
hooks...
The template mechanism can handle _all_ files in GIT_DIR. Just drop a
"config" into the templates directory, and you're settled.
I'm settled! From now on I will never have any objections regarding
any defaults as long as they have a config option :)
Most have only "attach" through various means of point-and-click and
drag-and-drop. Thunderbird too lacks the very basic ability of "include
this file as part of the message". I still haven't been able to find an
addon for it that does just that.
I use the External Editor extension with Thunderbird (it's mentioned in SubmittingPatches).
The script below is used as the external editor, which gives me an easy way to send patches
inline with Thunderbird.
/Lukas
#!/bin/bash
CONFFILE=~/.appprc
if [ -e "$CONFFILE" ] ; then
LAST_DIR=`grep "^LAST_DIR=" $CONFFILE|sed -e 's/^LAST_DIR=//'`
cd $LAST_DIR
else
cd > /dev/null
fi
PATCH=$(zenity --file-selection)
if [ "$?" != "0" ] ; then
#zenity --error --text "No patchfile given."
exit 1
fi
cd - > /dev/null
SUBJECT=`sed -n -e '/^Subject: /p' $PATCH`
HEADERS=`sed -e '/^Subject: /d' $1`
echo "$SUBJECT" > $1
echo "$HEADERS" >> $1
sed -e '1,/^$/d' $PATCH >> $1
LAST_DIR=`dirname $PATCH`
sed -e 's@^LAST_DIR=.*@LAST_DIR='$LAST_DIR'@' $CONFFILE > $CONFFILE"_"
mv $CONFFILE"_" $CONFFILE
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:49
Alex Riesen [off-list ref] wrote:
The _real_ majority of the programmers desperately need a better
VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
Yes. But...
Yesterday I had a conversation with the software configuration
management guy at my day-time-pays-the-bills organization.
They are seriously looking at Perforce and ClearCase, as these are
lightyears ahead of what we have already (PVCS Version Manager).
They also have 1-800-my-vendor telephone numbers which you can
call and scream at someone when the tool corrupts its internal
database[*1*], or when you cannot figure out what the "Checkout"
action in the context menu does[*2*].
However my fellow developers and I use Git. We export our changes
out to PVCS Version Manager via an *ugly* Perl script that I would
never actually wish on anyone (which is one reason why its not
contributed as git-pvcsexport). Configuration management guy won't
even look at Git's real strengths as it lacks the all-important
1-800-git-help[*3*] phone number.
Yesterday we spent 4 half-man-days (4 developers working together
all morning) trying to get a configuration of random files from
PVCS Version Manager which compiled. In Git this would have been as
simple as merging the two topics that management wanted moved to the
next level of testing. But since our organization doesn't actually
use Git and multiple topics affected the same files, well, yea, it
was a mess. Unfortunately calling 1-800-my-vendor yields a "don't do
that" from our vendor and nothing more in support. I'm very glad
we pay them for the privilege of having a 1-800-my-vendor phone
number in our rolodex. Yesterday it cost us over $1600 in labor.
Yes. For me and you. One of my coworkers knows nothing about patches,
but wants (and perfectly able to) review my code. He has usable brains
and is able to figure out what "+" and "-" is (he has, by now). He hasn't
even realized that it was an automatically generated information, as
I sent a patch to him first time, thought it was just a funny way to
document changes (and was surprised when I told him a patch can be
applied automatically, even if the original file is not exactly the same).
But he is a typical windows-trained programmer.
I work with a few people who would rather copy and paste their
changed parts into an email, then color them with pretty colors
like red, green, blue, black, orange in Outlook (and all in the
same email too). These then get sent to me for code review.
Prior to us using Git it may make some sense, as we did not have
a diff tool available. Now that everyone is using Git and working
in isolated topic branches (and doing very well with that concept)
I still get these emails. People seem to have an easy time grasping
the idea that Git is tracking their changes and when combined with
my git-pvcsexport (see above) it just Does The Right Thing(tm)
later on. But they have a hard time grasping the idea that Git can
export these as a diff, or that they could just push their topic
branch to me so I can pop it open in gitk. *sigh*
[*1*] This has happened to me with Perforce more than once. Not a
happy thought. Never with Git.
[*2*] Yes, really, some of our version control users have difficulty
grasping a concept like "checkout". They *definately* have
an issue with Git's "checkout -b" concept.
[*3*] Already taken. Oddly enough by a company that could almost
be considered to be a competiter to my day-time-pays-the-bills
organization.
--
Shawn.
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Shawn O. Pearce [off-list ref] wrote:
quoted
don't think so. I _would_ cry seeing how fork(2) gets ported to Windows,
and you will, probably... after seeing how it is done in cygwin.
AFAIK there's not a strong reason to keep fork() in Git.
Currently anytime we fork a process its to perform a small amount
of file descriptor redirection and then immediately exec some other
executable, or a hook script. In other words we probably could
convert all current uses of fork to something like in run-command.c,
which a Windows port could then easily replace using CreateProcess().
I count 17 instances (excluding run_command). At least fetch-pack
is not trivial (the sideband code. Could be done in a thread, which
is not portable just as well).
But removing fork isn't worth doing until someone is seriously
trying to port Git onto Windows without Cygwin. The current code
works on sane OSes and isn't broken, so why fix it?
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:49
On 1/18/07, Shawn O. Pearce [off-list ref] wrote:
quoted
The _real_ majority of the programmers desperately need a better
VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
Yes. But...
Yesterday I had a conversation with the software configuration
management guy at my day-time-pays-the-bills organization.
They are seriously looking at Perforce and ClearCase, as these are
lightyears ahead of what we have already (PVCS Version Manager).
They also have 1-800-my-vendor telephone numbers which you can
call and scream at someone when the tool corrupts its internal
database[*1*], or when you cannot figure out what the "Checkout"
action in the context menu does[*2*].
However my fellow developers and I use Git. We export our changes
out to PVCS Version Manager via an *ugly* Perl script that I would
never actually wish on anyone (which is one reason why its not
contributed as git-pvcsexport). Configuration management guy won't
even look at Git's real strengths as it lacks the all-important
1-800-git-help[*3*] phone number.
Of course, he is the who'll do the yelling. It's you who'll need support.
Standard Perforce replies: "it is not supported" (if you need branches
as in Git), or "we will probably look into it" (if you point them to a bug.
They never really do). Worst performance in the industry, too.
ClearCase had a sleep(6 /*sec*/) before writing a file in local checkouts
on linux, for whatever reason :) It at least knows about oriented graphs.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:42:49
"Shawn O. Pearce" wrote:
AFAIK there's not a strong reason to keep fork() in Git.
Currently anytime we fork a process its to perform a small amount
of file descriptor redirection and then immediately exec some other
executable, or a hook script. In other words we probably could
convert all current uses of fork to something like in run-command.c,
which a Windows port could then easily replace using CreateProcess().
But removing fork isn't worth doing until someone is seriously
trying to port Git onto Windows without Cygwin. The current code
works on sane OSes and isn't broken, so why fix it?
I'm doing just that (MinGW port).
I've come up with a function spawnvpe_pipe(), which hides all the scary
details of fork+exec with dup2's and close's. It could probably easily
be merged into run_command(), but I haven't tried that, yet.
I'll try to push out what I have to repo.or.cz over the weekend.
-- Hannes
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:49
Shawn O. Pearce wrote:
Alex Riesen [off-list ref] wrote:
However my fellow developers and I use Git. We export our changes
out to PVCS Version Manager via an *ugly* Perl script that I would
never actually wish on anyone (which is one reason why its not
contributed as git-pvcsexport). Configuration management guy won't
even look at Git's real strengths as it lacks the all-important
1-800-git-help[*3*] phone number.
Would a +46-31 number work? If so, you could give me a call when you're
having trouble. I'd probably end up asking the list, or bribing Junio
with beer to answer for me, but the fee would be low (how much is a
dozen beers in Japan?), so perhaps it'd be worth it ;-)
On a serious note, it's probably about time the world saw its first
commercial git support company. It's legal to package and sell GPL'd
code. Many companies have already proven that it can be a very
lucrative business.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:49
Andreas Ericsson [off-list ref] wrote:
Would a +46-31 number work? If so, you could give me a call when you're
having trouble. I'd probably end up asking the list, or bribing Junio
with beer to answer for me, but the fee would be low (how much is a
dozen beers in Japan?), so perhaps it'd be worth it ;-)
Heh. The thing is, with me "on staff" I doubt you can get much
better support. I know Git very well, almost as well as Linus,
Junio, Nico, and Johannes (sorry, no particular order there).
What I don't know off the top of my head, I know where the source
code for it is, and I can read and understand it rather quickly.
When something breaks, I can usually fix it myself, and that usually
results in a patch to Junio just hours after I discover the problem.
Most of the time the patch is worthy of inclusion and Junio picks
it up. You can't get that kind of response from a commerical vendor,
at least not without forking over bucket loads of cash first.
The problem is, the organization has strict rules about recommending
yourself as a vendor. But recommending a guy half way around the
world who works for beer is probably in compliance. :-)
On a serious note, it's probably about time the world saw its first
commercial git support company. It's legal to package and sell GPL'd
code. Many companies have already proven that it can be a very
lucrative business.
I've thought about doing this myself. I'm just so short on time
that developing a business providing support would probably push me
way over the edge. Ideally I'd love to have such a venture make its
money off support contracts and a small markup on dead-tree forms of
open-source Git documentation. I'd also love to see such a venture
be able to support a Git developer or two full-time, making sure that
all of their work is getting folded back into the main git.git tree.
Which of course implies they can't be heading off in directions
that the rest of the group finds useless/pointless/stupid/etc.
Wishful thinking. Back to reality.
--
Shawn.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:49
Shawn O. Pearce wrote:
Andreas Ericsson [off-list ref] wrote:
quoted
Would a +46-31 number work? If so, you could give me a call when you're
having trouble. I'd probably end up asking the list, or bribing Junio
with beer to answer for me, but the fee would be low (how much is a
dozen beers in Japan?), so perhaps it'd be worth it ;-)
Heh. The thing is, with me "on staff" I doubt you can get much
better support. I know Git very well, almost as well as Linus,
Junio, Nico, and Johannes (sorry, no particular order there).
What I don't know off the top of my head, I know where the source
code for it is, and I can read and understand it rather quickly.
Ya, I knows. :)
When something breaks, I can usually fix it myself, and that usually
results in a patch to Junio just hours after I discover the problem.
Most of the time the patch is worthy of inclusion and Junio picks
it up. You can't get that kind of response from a commerical vendor,
at least not without forking over bucket loads of cash first.
The problem is, the organization has strict rules about recommending
yourself as a vendor. But recommending a guy half way around the
world who works for beer is probably in compliance. :-)
That was my devilishly clever plan; To provide support to someone who
knows the thing I'm supposed to support a lot better than myself, while
getting some free beer in the process ;-)
quoted
On a serious note, it's probably about time the world saw its first
commercial git support company. It's legal to package and sell GPL'd
code. Many companies have already proven that it can be a very
lucrative business.
I've thought about doing this myself. I'm just so short on time
that developing a business providing support would probably push me
way over the edge. Ideally I'd love to have such a venture make its
money off support contracts and a small markup on dead-tree forms of
open-source Git documentation. I'd also love to see such a venture
be able to support a Git developer or two full-time, making sure that
all of their work is getting folded back into the main git.git tree.
Which of course implies they can't be heading off in directions
that the rest of the group finds useless/pointless/stupid/etc.
Wishful thinking. Back to reality.
This is a case where "Think Big" isn't enough, and you need to "Think
Bigger". Don't settle for shipping help-docs on git and answering the
phone. Sell pre-packaged versions of git, with a pre-installed Linux
server with raided disks and a nifty backup-solution (just sell a second
server and use an update-hook to replicate everything to that one, then
you're done). You could easily charge up to $2,500 / user for providing
"A fully integrated VCS / backup solution, with full failover to ensure
100% efficiency in your day-to-day job". Tack on another 10k for the
two servers and another 1k / dev to go to a training seminar and you're
good to go.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:49
On 1/19/07, Andreas Ericsson [off-list ref] wrote:
On a serious note, it's probably about time the world saw its first
commercial git support company. It's legal to package and sell GPL'd
code. Many companies have already proven that it can be a very
lucrative business.
<spam, but on topic >
At Catalyst (~70 perl/java/php/c/c++ developers, mostly foss
development) we have switched internally to git for 80% of our active
projects and we do offer commercial support for a couple of clients.
It's not the only thing we do for those clients, but if an
organisation needed specifically support for git, we can help.
We aren't pushing/packaging/selling it because it doesn't work well
that way (for us at least). When it's about new tools, we prefer to
work with people who already know what they want ;-)
cheers,
martin
From: Steven Grimm <hidden> Date: 2016-06-15 22:42:49
Alex Riesen wrote:
I count 17 instances (excluding run_command). At least fetch-pack
is not trivial (the sideband code. Could be done in a thread, which
is not portable just as well).
I looked at that briefly a while ago -- at the prompting of a Windows
developer friend of mine who has some interest in git -- and it seemed
like the best thing for portability to non-fork()ing systems would
probably be a refactor. It looked to me like it'd be possible to
reorganize the code such that it'd work all in one process with no
threads or forking or anything. Not *trivial*, mind you, but possible.
There's nothing in the code path that I saw (I didn't analyze it
super-thoroughly) that looked like it actually needed to run in parallel.
IMO it's worth doing at some point post-1.5.0 simply because it means
one less hurdle for someone who's looking to port Git to Windows. Plus
it'll probably make the code slightly more efficient even on Linux and
friends; there'd be less context-switching latency.
From my brief look, that was the only nontrivial use of fork(). Almost
all of the rest are simple fork/exec pairs.
Of course, the bigger hurdle for a native Windows port is all the shell
scripts. Mercurial solves that by using Python for all its scripts,
which at least has a native Windows version that can be installed. I
wonder if git will/should eventually move its remaining shell scripts to
Perl for that reason, Perl being git's de facto non-shell scripting
language of choice.
-Steve
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:49
On 1/19/07, Shawn O. Pearce [off-list ref] wrote:
Wishful thinking. Back to reality.
Not necessarily ;-) but I'm not sure if the time is right for an
independend services company doing _only_ git.
However, git is the kind of SCM that a big distro needs to keep track
of all their "vendor branches" or "patches against upstream". Ubuntu
pays at least one full-time SCM developer, Martin Pool, to maintain
Bazaar NG and accesory tools.
IIRC MySQL was looking quite seriously to drop BK and with the savings
in licenses, can surely affort to hire a GIT guru to "train the
trainer", solve problems/bugs and write internal support tools. Others
will follow. It shouldn't be too hard to find the right place.
Or a large FOSS services focused company (like Catalyst) that uses git
and offers support as part of a larger bundle. (<spam>we're hiring,
and putting git hackery in your cv is a winner</spam>). There are
plenty of gaps and places for git hackers.
cheers
martin
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:49
Hi,
On Thu, 18 Jan 2007, Steven Grimm wrote:
I looked at that briefly a while ago -- at the prompting of a Windows
developer friend of mine who has some interest in git -- and it seemed
like the best thing for portability to non-fork()ing systems would
probably be a refactor. It looked to me like it'd be possible to
reorganize the code such that it'd work all in one process with no
threads or forking or anything. Not *trivial*, mind you, but possible.
There's nothing in the code path that I saw (I didn't analyze it
super-thoroughly) that looked like it actually needed to run in
parallel.
ssh transport comes to mind, as well as paging functionality. Sometimes we
fork() to catch out-of-memory errors more gracefully.
Of course, the bigger hurdle for a native Windows port is all the shell
scripts. Mercurial solves that by using Python for all its scripts,
which at least has a native Windows version that can be installed. I
wonder if git will/should eventually move its remaining shell scripts to
Perl for that reason, Perl being git's de facto non-shell scripting
language of choice.
Yeah, sure. We had no problems with Perl ;-)
Seriously, IMHO bash is a smaller dependency: here you can at least rely
on which extensions are present (none), and which path-name munging is
present on Windows (/c/windows).
No, the best is not to migrate shell scripts to Perl, but to C.
Ciao,
Dscho
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:49
Alex Riesen wrote:
BTW, Junio, how about making the _default_ settable at compile time?
It'd be reasonable to allow local installations choose to default to what
they find the most paranoid?
You can always modify templates.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git