* The 8th airing of the msysGit herald
@ 2008-03-02 23:30 Johannes Schindelin
2008-03-03 0:44 ` Jakub Narebski
0 siblings, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2008-03-02 23:30 UTC (permalink / raw
To: msysgit, git
Good morning git land!
This dark and quiet Sunday night is as good an occasion as any to
offer to you the 8th airing of the msysGit Herald, the
not-quite-biweekly news letter to keep you informed about msysGit, the
effort to bring one of the most powerful Source Code Management
systems to the poor souls stuck with Windows.
These are the covered topics:
We have a working 'git svn'
Interview with Christian Stimming
GPL only needs to be acknowledged
The installer was on diet
core.autocrlf = true
Update to a new ssh, problems with pulling msysGit
Entering Babel: "rebase"
git-cheetah is now a submodule
Maybe I should strike the "not quite biweekly"? But then, it _is_ not
quite biweekly ;-)
Anyway, here it goes, the newest issue of the Herald, subtitle "Yeah,
we have a working git svn!"
We have a working 'git svn'
===========================
Some time ago, we started work on compiling Perl ourselves, in order
to be able to install the Subversion modules which are necessary to
run 'git svn'. In the last issue of the Herald, I wrote something
about our long and rocky road until we had a working 'git svn' (See
the story "We managed to get git-svn to run!").
We played it safe, though, and had some alpha versions of a Git
installer including 'git svn', and with good reason: Some testers came
back and said that it would not work with https repositories, and that
authentication was not supported. We included the necessary libraries
and modules, cut a new Git installer, and the tests show that while it
is slow, it works!
While working on git-svn, we realized that there are a few scripts in
msysGit that cannot possibly work (yet), so we excluded them from the
Git installer. These scripts are: archimport, cvsexportcommit,
cvsimport, cvsserver, filter-branch, instaweb, send-email, and shell.
Interview with Christian Stimming
=================================
Christian put in a big effort to get 'git svn' to work when I got
stuck. He did such a great job, that I decided to interview him for
the Herald, since I could not afford to buy him a house by way of
saying thanks. So here it goes:
> 1) How did you get involved with Git?
Some fellow developer in another Open Source project mentioned it and
was enthusiastic about this new way of working. As my main reason for
being involved in Open Source is learning new things, this got me
curious.
> 2) What were the reasons that you started working on Git?
In one project I had to work with a dead lame CVS server, where each
contact to the repository took way way too long. Discovering that git
would import all of the history and give me access to each and
everything I wanted to know from the history brought back the fun into
the project. From that moment on, I was hooked.
> 3) What do you like most in Git?
Speed. It's so fast, it's marvellous. This doesn't quite hold for the
Windows version, but it is still faster than any other alternatives
that I know of. And the GUI tools gitk and git-gui did a fantastic job
of a low entry barrier - it's now really easy to start branching and
merging a lot.
> 4) What do you hate most in Git?
The command line options. Sometimes it seems to me all the really cool
actions in git can only be invoked by a mysterious collection of weird
option switches which 1. I've never heard of, 2. are hidden deep down
in long manual pages which make it impossible to distinguish important
options from the unimportant ones, and 3. change very frequently in
new versions. For example, "git rebase -i" is a nice feature, but it
is simply a different action than a one-shot "git rebase". Hence, if
it is supposed to be really used, it should rather be a command such
as "git interactive-rebase". The GUI tools go a long way to hide those
mysterious option collections, but some of the daily workflow steps
are still unavailable in the GUI. Rebase being the most prominent, I
guess.
> 5) What was the most surprising moment when working with Git?
Seeing it up and running on Windows just as well as on Linux.
> 6) What was the most frustrating moment when working with Git?
Finding that "git pull" will create many more merge commits than I
wanted, and that there doesn't seem to be an easy way of running "git
fetch; git rebase" in one command. All in all there hasn't been much
frustration potential in git... I guess this is a good thing.
> 7) In what environment do you work?
Desktop machines with Linux or Windows, always using code from a
central SVN repository. Really: I'm switching back and forth between
Linux or Windows, and seeing git available on Windows just as well
makes this fun again.
> 8) What other hobbies do you have?
Programming. Oh, and programming. Well, there's also family: A
wonderful wife and two cute daughters.
> 9) What is your favourite movie?
Schulze gets the Blues.
> 10) What are your visions for Git? (I.e. where do you want it to
go?)
Git will empower the user! (Well, here the user is more the developer,
but this doesn't rhyme as good.) The GUI tools will make it possible
for everyone to use git instead of any of the previously popular
central VCSs, but now with the decentralized features on top. This is
step one in introducing a true decentralized model into the normal
company workflows. Step two is to start using push and pull between
the decentralized repositories, so that developers use the tools to
represent their actual workflow. Step three: World domination!
GPL only needs to be acknowledged
=================================
It is funny how licenses can make people speak up who normally would
keep quiet, and so we got a complaint that we forced the users of our
Git installer to accept the GNU Public License.
Personally, I think it is not nice to demand changes, especially
license changes, or changes in the visibility of the license, when you
get the software for free.
Also, I try to stay on the very safe side of legal issues, in order to
avoid contact with lawyers, especially ones where they demand that I
cross their hands with silver. So I was quite unwilling to change
that.
However, none less than our benevolent dictator, Linus Torvalds spoke
up, pointing out that it is not really a _choice_. You need not accept
the GPL, it is sufficient that you acknowledge that this is the only
license regulating your rights with regard to Git.
Now, that was very reasonable, so we changed it.
Personal sidenote: I would do quite a few things for people whose work
I benefit from every day; it is that fundamental idea of fairness (or
tit for tat) encoded in the GPL which makes me extremely comfortable
with that license, and I think that I am not the only one.
The installer was on diet
=========================
The installer had a diet on Doctor's orders, but no worry, it is not
bulimic. As stated previously, now even 'git svn' was added. How was
that possible?
Pretty easy. We dragged around a lot of garbage in our installer. Some
time ago, it was janitized, and lost a few megabytes already, but this
time, even more effort was put into removing unneeded parts.
Mainly inside the Perl library, files were removed. Since the Git
installer is not meant to be any development environment -- we do not
even ship gcc -- shipping header files and linkable libraries does not
make sense.
Neither is documentation for Perl needed, since nobody is supposed to
develop the Perl scripts of Git without the development environment:
that is what 'msysGit' is for.
So away went the documentation!
A few files have been removed from Tcl, vim, some unneeded Perl
modules, and cvs, too, so we actually ended up with an 8.0 megabyte
installer _with_ 'git svn', whereas the previous installer weighed in
with 8.8 megabyte.
core.autocrlf = true
====================
We finally addressed issue 21. For Windows projects, it seems to be
the safest bet to just set core.autocrlf = true. We did that in the
/etc/gitconfig we ship with msysGit.
There is a subtle problem here, and we will see how to solve it: Git's
source code itself is not supposed to be checked out with
core.autocrlf = true.
For new cloners, this should be easy to address (even if it has not
been done yet): Git is checked out by /etc/profile, and we can set the
config variable there, too.
However, existing users who pull (and do not read the msysGit mailing
list regularly enough to have heard about the problem) will have to
update their setup manually.
Update to a new ssh, problems with pulling msysGit
==================================================
There have been reports about hanging ssh processes, and for a long
time, we had no idea how to solve it.
Until it was reported that an update to a newer MSys helps. So we
updated some of MSys' libraries, and ssh.exe.
Little did we know what this would involve: one peculiarity of the
Windows platform that has never been addressed properly by Git is that
you cannot overwrite files that are in use. The symptoms in Git are
that you check out, or merge, new revisions, but the files-in-use are
not updated, and marked as dirty afterwards.
... such as the MSys libraries, when you are using the bash. While
pulling msysGit, for example.
Now, a workaround is to actually install Git from our installer, then
cd to the msysGit root, and perform the pull. That is a bit involved,
though.
A few ideas arose, such as writing a script, or using git-gui. But a
script does not seem feasible, as it would not be able to close the
bash, perform the pull, and then start the bash again.
Also, "git merge" is still a shell script, so even git-gui (which runs
via Tcl/Tk, and thusly does not use the MSys libraries) cannot perform
the merge -- except when you call the git-gui from the Git installer.
We'll see if we can find an elegant way to tackle that problem.
Entering Babel: "rebase"
========================
What is a "rebase"? For Git users, it means replaying commits on top
of a new branch point.
Not so in Windows Speak: Windows' .dll files have fixed address ranges
assigned to them, and when they overlap, problems occur. The tool
"rebase" is meant to help there, by assigining non-overlapping ranges
to existing .dll files.
Peter Harris -- about whose work you will likely read more in the next
Heralds -- was so kind to diagnose and fix that problem, by running
"rebase" himself.
Unfortunately, this tool is a closed source tool. But happily, Peter
could point me to an Open Source implementation of it, and I succeeded
in compiling it.
As a consequence, we have now a script to fetch, compile and install
that Open Source "rebase" tool in our "full" branch, for the joy and
enlightenement of interested developers.
git-cheetah is now a submodule
==============================
We readded the necessary COM infrastructure, and added git-cheetah
(the hopefully-soon lookalike of TortoiseCVS for Git) as a submodule
in /src/git-cheetah.
It is not checked out by default, so you will have to update the
submodule as usual:
$ cd /
$ git submodule init src/git-cheetah
$ git submodule update src/git-cheetah
$ cd src/git-cheetah
$ make
Speaking of git-cheetah: mailing list member Kirill is working pretty
hard to get a context sensitive menu in place, and on separating the
platform dependent parts out into their own source files.
So my dream about a git-cheetah for Dolphin, Konqueror and Finder has
actually a chance to become reality soon!
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-02 23:30 The 8th airing of the msysGit herald Johannes Schindelin
@ 2008-03-03 0:44 ` Jakub Narebski
2008-03-03 0:54 ` Johannes Schindelin
0 siblings, 1 reply; 23+ messages in thread
From: Jakub Narebski @ 2008-03-03 0:44 UTC (permalink / raw
To: Johannes.Schindelin; +Cc: msysgit, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 4) What do you hate most in Git?
>
> The command line options. Sometimes it seems to me all the really cool
> actions in git can only be invoked by a mysterious collection of weird
> option switches which 1. I've never heard of, 2. are hidden deep down
> in long manual pages which make it impossible to distinguish important
> options from the unimportant ones, and 3. change very frequently in
> new versions. For example, "git rebase -i" is a nice feature, but it
> is simply a different action than a one-shot "git rebase". Hence, if
> it is supposed to be really used, it should rather be a command such
> as "git interactive-rebase". The GUI tools go a long way to hide those
> mysterious option collections, but some of the daily workflow steps
> are still unavailable in the GUI. Rebase being the most prominent, I
> guess.
It is not that much different. The basis operation is the same;
I don't think that "rebase -i" differs from "rebase" more than
"add -i" differs from "add".
> > 6) What was the most frustrating moment when working with Git?
>
> Finding that "git pull" will create many more merge commits than I
> wanted, and that there doesn't seem to be an easy way of running "git
> fetch; git rebase" in one command.
"git pull --rebase", but it is quite new feature.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 0:44 ` Jakub Narebski
@ 2008-03-03 0:54 ` Johannes Schindelin
2008-03-03 1:10 ` Jakub Narebski
0 siblings, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2008-03-03 0:54 UTC (permalink / raw
To: Jakub Narebski; +Cc: msysgit, git
Hi,
On Sun, 2 Mar 2008, Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > > 4) What do you hate most in Git?
> >
> > The command line options. Sometimes it seems to me all the really cool
> > actions in git can only be invoked by a mysterious collection of weird
> > option switches which 1. I've never heard of, 2. are hidden deep down
> > in long manual pages which make it impossible to distinguish important
> > options from the unimportant ones, and 3. change very frequently in
> > new versions. For example, "git rebase -i" is a nice feature, but it
> > is simply a different action than a one-shot "git rebase". Hence, if
> > it is supposed to be really used, it should rather be a command such
> > as "git interactive-rebase". The GUI tools go a long way to hide those
> > mysterious option collections, but some of the daily workflow steps
> > are still unavailable in the GUI. Rebase being the most prominent, I
> > guess.
>
> It is not that much different. The basis operation is the same;
> I don't think that "rebase -i" differs from "rebase" more than
> "add -i" differs from "add".
Well, first of all, this was a personal view.
And then, I think he _has_ a point. Our interfaces are not bad, but they
are not really obvious, either.
If I only were a bit more gifted in interface design...
> > > 6) What was the most frustrating moment when working with Git?
> >
> > Finding that "git pull" will create many more merge commits than I
> > wanted, and that there doesn't seem to be an easy way of running "git
> > fetch; git rebase" in one command.
>
> "git pull --rebase", but it is quite new feature.
Yes, it is. And it is not that easy for our users to find out about what
new features got into Git, since there are _so many_ new features.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 0:54 ` Johannes Schindelin
@ 2008-03-03 1:10 ` Jakub Narebski
2008-03-03 12:00 ` Tilman Schmidt
0 siblings, 1 reply; 23+ messages in thread
From: Jakub Narebski @ 2008-03-03 1:10 UTC (permalink / raw
To: Johannes Schindelin; +Cc: msysgit, git
Johannes Schindelin wrote:
> On Sun, 2 Mar 2008, Jakub Narebski wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>> 6) What was the most frustrating moment when working with Git?
>>>
>>> Finding that "git pull" will create many more merge commits than I
>>> wanted, and that there doesn't seem to be an easy way of running "git
>>> fetch; git rebase" in one command.
>>
>> "git pull --rebase", but it is quite new feature.
>
> Yes, it is. And it is not that easy for our users to find out about what
> new features got into Git, since there are _so many_ new features.
There are always RelNotes ;-))))
For me the sign how incredibly fast the git development is is the fact
that git version from a year ago is considered "ancient".
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 1:10 ` Jakub Narebski
@ 2008-03-03 12:00 ` Tilman Schmidt
2008-03-03 12:05 ` Johannes Schindelin
2008-03-03 17:18 ` Junio C Hamano
0 siblings, 2 replies; 23+ messages in thread
From: Tilman Schmidt @ 2008-03-03 12:00 UTC (permalink / raw
To: Jakub Narebski; +Cc: Johannes Schindelin, msysgit, git
Jakub Narebski schrieb:
>>> "git pull --rebase", but it is quite new feature.
>> Yes, it is. And it is not that easy for our users to find out about what
>> new features got into Git, since there are _so many_ new features.
>
> There are always RelNotes ;-))))
>
> For me the sign how incredibly fast the git development is is the fact
> that git version from a year ago is considered "ancient".
Yes, and that is in itself a problem for people like me who just want to
use git to get some work done. The time I spend installing new git
versions, reading RelNotes and sorting through a rather high-volume
mailing list goes off the time I can spare for working on the Linux
driver I maintain. :-(
Tilman
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 12:00 ` Tilman Schmidt
@ 2008-03-03 12:05 ` Johannes Schindelin
2008-03-03 18:21 ` Tilman Schmidt
2008-03-03 17:18 ` Junio C Hamano
1 sibling, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2008-03-03 12:05 UTC (permalink / raw
To: Tilman Schmidt; +Cc: Jakub Narebski, git
Hi,
On Mon, 3 Mar 2008, Tilman Schmidt wrote:
> Jakub Narebski schrieb:
> >>> "git pull --rebase", but it is quite new feature.
> >> Yes, it is. And it is not that easy for our users to find out about what
> >> new features got into Git, since there are _so many_ new features.
> >
> > There are always RelNotes ;-))))
> >
> > For me the sign how incredibly fast the git development is is the fact
> > that git version from a year ago is considered "ancient".
>
> Yes, and that is in itself a problem for people like me who just want to
> use git to get some work done. The time I spend installing new git
> versions, reading RelNotes and sorting through a rather high-volume
> mailing list goes off the time I can spare for working on the Linux
> driver I maintain. :-(
Well, you do not _have_ to upgrade, if you are comfortable with what you
have...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 12:00 ` Tilman Schmidt
2008-03-03 12:05 ` Johannes Schindelin
@ 2008-03-03 17:18 ` Junio C Hamano
2008-03-03 18:27 ` Tilman Schmidt
1 sibling, 1 reply; 23+ messages in thread
From: Junio C Hamano @ 2008-03-03 17:18 UTC (permalink / raw
To: Tilman Schmidt; +Cc: Jakub Narebski, Johannes Schindelin, msysgit, git
Tilman Schmidt <tilman@imap.cc> writes:
> Jakub Narebski schrieb:
>>>> "git pull --rebase", but it is quite new feature.
>>> Yes, it is. And it is not that easy for our users to find out about what
>>> new features got into Git, since there are _so many_ new features.
>>
>> There are always RelNotes ;-))))
>>
>> For me the sign how incredibly fast the git development is is the fact
>> that git version from a year ago is considered "ancient".
>
> Yes, and that is in itself a problem for people like me who just want to
> use git to get some work done. The time I spend installing new git
> versions, reading RelNotes and sorting through a rather high-volume
> mailing list goes off the time I can spare for working on the Linux
> driver I maintain. :-(
Yeah, we can stop fixing issues and enhancing features. Would that help?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 12:05 ` Johannes Schindelin
@ 2008-03-03 18:21 ` Tilman Schmidt
2008-03-03 18:48 ` Brandon Casey
0 siblings, 1 reply; 23+ messages in thread
From: Tilman Schmidt @ 2008-03-03 18:21 UTC (permalink / raw
To: Johannes Schindelin; +Cc: Jakub Narebski, git
[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]
Am 03.03.2008 13:05 schrieb Johannes Schindelin:
> On Mon, 3 Mar 2008, Tilman Schmidt wrote:
>
>> Jakub Narebski schrieb:
[...]
>>> For me the sign how incredibly fast the git development is is the fact
>>> that git version from a year ago is considered "ancient".
>> Yes, and that is in itself a problem for people like me who just want to
>> use git to get some work done. The time I spend installing new git
>> versions, reading RelNotes and sorting through a rather high-volume
>> mailing list goes off the time I can spare for working on the Linux
>> driver I maintain. :-(
>
> Well, you do not _have_ to upgrade, if you are comfortable with what you
> have...
True as far as it goes, and for appropriate values of "what I have".
Neither do I _have_ to subscribe to the mailing list, or, for that
matter, to read the release notes of a new version I install.
But git is not particularly easy to learn on my own, so I end up
asking for help. (Arguably this qualifies as "not comfortable with
what I have.") And then "ancient version" translates all too easily
into "you should upgrade to a newer one".
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 17:18 ` Junio C Hamano
@ 2008-03-03 18:27 ` Tilman Schmidt
2008-03-03 22:37 ` Junio C Hamano
0 siblings, 1 reply; 23+ messages in thread
From: Tilman Schmidt @ 2008-03-03 18:27 UTC (permalink / raw
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, msysgit, git
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
Am 03.03.2008 18:18 schrieb Junio C Hamano:
> Tilman Schmidt <tilman@imap.cc> writes:
>
>> Yes, and that is in itself a problem for people like me who just want to
>> use git to get some work done. The time I spend installing new git
>> versions, reading RelNotes and sorting through a rather high-volume
>> mailing list goes off the time I can spare for working on the Linux
>> driver I maintain. :-(
>
> Yeah, we can stop fixing issues and enhancing features. Would that help?
Oh dear, I didn't want to offend anyone. Of course fixing issues
and enhancing features is a Good Thing(TM).
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 18:21 ` Tilman Schmidt
@ 2008-03-03 18:48 ` Brandon Casey
2008-03-05 23:12 ` Tilman Schmidt
0 siblings, 1 reply; 23+ messages in thread
From: Brandon Casey @ 2008-03-03 18:48 UTC (permalink / raw
To: Tilman Schmidt; +Cc: Johannes Schindelin, Jakub Narebski, git
Tilman Schmidt wrote:
> Am 03.03.2008 13:05 schrieb Johannes Schindelin:
>> On Mon, 3 Mar 2008, Tilman Schmidt wrote:
>>
>>> Jakub Narebski schrieb:
> [...]
>>>> For me the sign how incredibly fast the git development is is the fact
>>>> that git version from a year ago is considered "ancient".
>>> Yes, and that is in itself a problem for people like me who just want to
>>> use git to get some work done. The time I spend installing new git
>>> versions, reading RelNotes and sorting through a rather high-volume
>>> mailing list goes off the time I can spare for working on the Linux
>>> driver I maintain. :-(
>> Well, you do not _have_ to upgrade, if you are comfortable with what you
>> have...
>
> True as far as it goes, and for appropriate values of "what I have".
> Neither do I _have_ to subscribe to the mailing list, or, for that
> matter, to read the release notes of a new version I install.
>
> But git is not particularly easy to learn on my own, so I end up
> asking for help. (Arguably this qualifies as "not comfortable with
> what I have.") And then "ancient version" translates all too easily
> into "you should upgrade to a newer one".
I think the assumption made was that you were already getting some work
done with the version of git that you had.
If you do not yet have a comfortable grasp of git usage I would suggest
the following steps:
1) Grab "a" version of git (preferably latest stable version)
-If you need to compile it, read the "INSTALL" file.
2) Read intro/tutorials
-tutorial.txt
-everyday.txt
-user-manual.txt (more in-depth)
These three are mentioned in the git man page.
3) Start using it
-refer to man pages to answer questions as you
encounter issues
-ask the mailing list when man pages or other docs
are unable to answer your questions
4) End of story
Upgrading, reading RelNotes, using new features, and reading the high-volume
mailing list are not required, so it is wrong to suggest that they are barriers
to entry for using git.
-brandon
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 18:27 ` Tilman Schmidt
@ 2008-03-03 22:37 ` Junio C Hamano
2008-03-03 22:58 ` Martin Langhoff
0 siblings, 1 reply; 23+ messages in thread
From: Junio C Hamano @ 2008-03-03 22:37 UTC (permalink / raw
To: Tilman Schmidt; +Cc: Jakub Narebski, Johannes Schindelin, msysgit, git
Tilman Schmidt <tilman@imap.cc> writes:
> Am 03.03.2008 18:18 schrieb Junio C Hamano:
>> Tilman Schmidt <tilman@imap.cc> writes:
>>
>>> Yes, and that is in itself a problem for people like me who just want to
>>> use git to get some work done. The time I spend installing new git
>>> versions, reading RelNotes and sorting through a rather high-volume
>>> mailing list goes off the time I can spare for working on the Linux
>>> driver I maintain. :-(
>>
>> Yeah, we can stop fixing issues and enhancing features. Would that help?
>
> Oh dear, I didn't want to offend anyone. Of course fixing issues
> and enhancing features is a Good Thing(TM).
Heh, no offence taken, and sorry I forgot the obligatory smiley ;-)
But if you s/stop/slow down/ what I said, it may start to resemble a more
serious question.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 22:37 ` Junio C Hamano
@ 2008-03-03 22:58 ` Martin Langhoff
2008-03-05 23:40 ` Tilman Schmidt
0 siblings, 1 reply; 23+ messages in thread
From: Martin Langhoff @ 2008-03-03 22:58 UTC (permalink / raw
To: Junio C Hamano
Cc: Tilman Schmidt, Jakub Narebski, Johannes Schindelin, msysgit, git
On Tue, Mar 4, 2008 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> But if you s/stop/slow down/ what I said, it may start to resemble a more
> serious question.
Given that git dev has such a frantic pace... would it make sense to
give way to some "version inflation"?
This would give end users a more clear sense of how much things have
changed -- a 1.4.x to 1.5.x doesn't seem like much. But a 1.5 to 2.0
with a "new features summary" will grab a bit of attention, get its
slashdot article, and be a more frank communication of the work that's
happened, and what the user can expect.
In other words, the 'linux versioning' scheme sucks when dealing with
people who aren't sub'd to the mailing list. Yes, from git v0.99 to
today we haven't broken anything too significant, but from an end user
POV, several of the smaller changes carry enough incompatibility that
v1.4.x and v1.5.x are not actually compatible (all the remote heads
handling changes, for example).
So say rock on, but label the next feature release 2.0 or at least 1.6
and declare it is "mostly compatible, but you'll do well in re-cloning
your projects to keep things simple" -- in practice, I've had to do
that anyway on the 1.3->1.4->1.5 transitions.
cheers,
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 18:48 ` Brandon Casey
@ 2008-03-05 23:12 ` Tilman Schmidt
0 siblings, 0 replies; 23+ messages in thread
From: Tilman Schmidt @ 2008-03-05 23:12 UTC (permalink / raw
To: Brandon Casey; +Cc: Johannes Schindelin, Jakub Narebski, git
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
Am 03.03.2008 19:48 schrieb Brandon Casey:
> I think the assumption made was that you were already getting some work
> done with the version of git that you had.
True.
> If you do not yet have a comfortable grasp of git usage
True, too.
> I would suggest the following steps:
>
> 1) Grab "a" version of git (preferably latest stable version)
> -If you need to compile it, read the "INSTALL" file.
> 2) Read intro/tutorials
> -tutorial.txt
> -everyday.txt
> -user-manual.txt (more in-depth)
> These three are mentioned in the git man page.
> 3) Start using it
> -refer to man pages to answer questions as you
> encounter issues
> -ask the mailing list when man pages or other docs
> are unable to answer your questions
Got as far as that. In fact, I'm talking about one specific aspect
of that last substep. (let's call it 3.2)
> 4) End of story
I can't see that yet.
> Upgrading, reading RelNotes, using new features, and reading the high-volume
> mailing list are not required, so it is wrong to suggest that they are barriers
> to entry for using git.
I never meant to suggest that. They only are barriers for proceeding
to step 3.2 and onwards to step 4.
Hope that clears it up a bit.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-03 22:58 ` Martin Langhoff
@ 2008-03-05 23:40 ` Tilman Schmidt
2008-03-06 0:26 ` Johannes Schindelin
2008-03-06 4:29 ` Jay Soffian
0 siblings, 2 replies; 23+ messages in thread
From: Tilman Schmidt @ 2008-03-05 23:40 UTC (permalink / raw
To: Martin Langhoff, Junio C Hamano
Cc: Jakub Narebski, Johannes Schindelin, msysgit, git
[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]
Am 03.03.2008 23:58 schrieb Martin Langhoff:
> On Tue, Mar 4, 2008 at 11:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> But if you s/stop/slow down/ what I said, it may start to resemble a more
>> serious question.
Well, I seriously wouldn't want you to slow down fixing bugs. :-)
Enhancing features is a slightly different matter, because that
tends to impress upon insiders a feeling of "how could we ever have
done without that?" and onwards from there to "how can anybody
seriously without that?" which then easily creates the impression
that the answer to every other question from simple users like me
is "install the newest version, it has a nifty feature that solves
your problem better than anything already present in the version
you have!"
> Given that git dev has such a frantic pace... would it make sense to
> give way to some "version inflation"?
>
> This would give end users a more clear sense of how much things have
> changed -- a 1.4.x to 1.5.x doesn't seem like much. But a 1.5 to 2.0
> with a "new features summary" will grab a bit of attention, get its
> slashdot article, and be a more frank communication of the work that's
> happened, and what the user can expect.
You've got a point there.
But I'd like to suggest something else still: seeing that my git
mailing list folder has already grown to 363 mails again, of which
probably only a small fraction will concern me as a user - would
it be possible to have separate mailing lists for usage topics and
for discussions of ongoing development? I imagine that might help
those who just want to use git (like me) to find their way around.
Just an idea ...
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-05 23:40 ` Tilman Schmidt
@ 2008-03-06 0:26 ` Johannes Schindelin
2008-03-06 0:41 ` Junio C Hamano
2008-03-06 4:29 ` Jay Soffian
1 sibling, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2008-03-06 0:26 UTC (permalink / raw
To: Tilman Schmidt
Cc: Martin Langhoff, Junio C Hamano, Jakub Narebski, msysgit, git
Hi,
On Thu, 6 Mar 2008, Tilman Schmidt wrote:
> would it be possible to have separate mailing lists for usage topics and
> for discussions of ongoing development? I imagine that might help those
> who just want to use git (like me) to find their way around.
AFAIAC you can have your "users-only" mailing list. Personally, I will
never look at it, though, since all I am interested in is the development
of Git. If that holds true for the majority of Git _developers_, it might
even be a bad idea to have a separate users' list, since then
- no ideas from strictly-users would flow to the developers, and
- new developments would not reach you, and
- you would not get help by the people knowing the internals _deeply_.
FWIW I think what you wish for is already covered -- and in an
instantaneous manner at that -- by the IRC channel.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-06 0:26 ` Johannes Schindelin
@ 2008-03-06 0:41 ` Junio C Hamano
2008-03-06 2:03 ` Jim Raden
0 siblings, 1 reply; 23+ messages in thread
From: Junio C Hamano @ 2008-03-06 0:41 UTC (permalink / raw
To: Johannes Schindelin
Cc: Tilman Schmidt, Martin Langhoff, Jakub Narebski, msysgit, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 6 Mar 2008, Tilman Schmidt wrote:
>
>> would it be possible to have separate mailing lists for usage topics and
>> for discussions of ongoing development? I imagine that might help those
>> who just want to use git (like me) to find their way around.
>
> AFAIAC you can have your "users-only" mailing list. Personally, I will
> never look at it, though, since all I am interested in is the development
> of Git. If that holds true for the majority of Git _developers_, it might
> even be a bad idea to have a separate users' list, since then
>
> - no ideas from strictly-users would flow to the developers, and
>
> - new developments would not reach you, and
>
> - you would not get help by the people knowing the internals _deeply_.
Personally, I suspect I would end up subscribing to both, but
two mailing lists would make it much more cumbersome than
necessary to correlate the original user "itch" request that
triggered an enhancement, the discussion that clarified the
design constraints and requirements, and the patch and the
review comments that lead to the final implementation,
especially if you do not encourage cross posting to both lists.
And of course cross posting will make user-only list more
technical which would defeat the original point of having two
lists.
"users-only" list could probably created by readers' MUA, by
picking emails that do not have "diff --git" in its body; that
would probably be a good enough approximation for people who are
not interested in the technical discussions.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-06 0:41 ` Junio C Hamano
@ 2008-03-06 2:03 ` Jim Raden
2008-03-06 2:29 ` Johannes Schindelin
0 siblings, 1 reply; 23+ messages in thread
From: Jim Raden @ 2008-03-06 2:03 UTC (permalink / raw
To: Junio C Hamano
Cc: Johannes Schindelin, Tilman Schmidt, Martin Langhoff,
Jakub Narebski, msysgit, git
[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]
Perhaps adopting a convention for the subject line, like "Usage question:
xxxxxxxxxxxxxxxxxxxxx"? We're still a small list, so it wouldn't be horribly
cumbersome. If the list grew beyond 150 or
so<http://en.wikipedia.org/wiki/Dunbar%27s_number>active users, or if
the signal:noise ratio grew too low, perhaps then that
would be a good time to readdress the issue.
I confess that I haven't had to deal with such things before, so I'm not
familiar with the practices that may work in other groups faced with a
similar issue.
On Wed, Mar 5, 2008 at 7:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 6 Mar 2008, Tilman Schmidt wrote:
> >
> >> would it be possible to have separate mailing lists for usage topics
> and
> >> for discussions of ongoing development? I imagine that might help those
> >> who just want to use git (like me) to find their way around.
> >
> > AFAIAC you can have your "users-only" mailing list. Personally, I will
> > never look at it, though, since all I am interested in is the
> development
> > of Git. If that holds true for the majority of Git _developers_, it
> might
> > even be a bad idea to have a separate users' list, since then
> >
> > - no ideas from strictly-users would flow to the developers, and
> >
> > - new developments would not reach you, and
> >
> > - you would not get help by the people knowing the internals _deeply_.
>
> Personally, I suspect I would end up subscribing to both, but
> two mailing lists would make it much more cumbersome than
> necessary to correlate the original user "itch" request that
> triggered an enhancement, the discussion that clarified the
> design constraints and requirements, and the patch and the
> review comments that lead to the final implementation,
> especially if you do not encourage cross posting to both lists.
> And of course cross posting will make user-only list more
> technical which would defeat the original point of having two
> lists.
>
> "users-only" list could probably created by readers' MUA, by
> picking emails that do not have "diff --git" in its body; that
> would probably be a good enough approximation for people who are
> not interested in the technical discussions.
>
[-- Attachment #2: Type: text/html, Size: 2827 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-06 2:03 ` Jim Raden
@ 2008-03-06 2:29 ` Johannes Schindelin
2008-03-06 2:42 ` Jim Raden
0 siblings, 1 reply; 23+ messages in thread
From: Johannes Schindelin @ 2008-03-06 2:29 UTC (permalink / raw
To: Jim Raden
Cc: Junio C Hamano, Tilman Schmidt, Martin Langhoff, Jakub Narebski,
msysgit, git
Hi,
On Wed, 5 Mar 2008, Jim Raden wrote:
> Perhaps adopting a convention for the subject line, like "Usage
> question: xxxxxxxxxxxxxxxxxxxxx"? We're still a small list, so it
> wouldn't be horribly cumbersome.
I fail to see how that would accomplish something different from two
mailing list, except the very likely chance that people are unaware of
that convention.
> If the list grew beyond 150 or so
> <http://en.wikipedia.org/wiki/Dunbar%27s_number> active users, or if the
> signal:noise ratio grew too low, perhaps then that would be a good time
> to readdress the issue.
Recently Shawn mentioned that there are 853 members.
> I confess that I haven't had to deal with such things before, so I'm not
> familiar with the practices that may work in other groups faced with a
> similar issue.
<tongue-in-cheek>It is pretty easy to tell that somebody top-posting is
not a regular on this list</tongue-in-cheek>
Don't get me wrong, I'd _love_ to see a proper solution to the problem,
alas, I do not see one yet.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-06 2:29 ` Johannes Schindelin
@ 2008-03-06 2:42 ` Jim Raden
2008-03-06 4:32 ` [msysGit] " Jay Soffian
0 siblings, 1 reply; 23+ messages in thread
From: Jim Raden @ 2008-03-06 2:42 UTC (permalink / raw
To: Johannes Schindelin
Cc: Junio C Hamano, Tilman Schmidt, Martin Langhoff, Jakub Narebski,
msysgit, git
Msysgit has apparently 60 members, at least according to
http://groups.google.com/group/msysgit. It was that number to which I
was referring.
I saw that this message was cross-posted to git@vger.kernel.org, which
no doubt has many, many more than 60. Perhaps this is where the 853
figure comes from?
On Wed, Mar 5, 2008 at 9:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Wed, 5 Mar 2008, Jim Raden wrote:
>
> > Perhaps adopting a convention for the subject line, like "Usage
> > question: xxxxxxxxxxxxxxxxxxxxx"? We're still a small list, so it
> > wouldn't be horribly cumbersome.
>
> I fail to see how that would accomplish something different from two
> mailing list, except the very likely chance that people are unaware of
> that convention.
You're right, many people probably *would* be unaware of the
convention on anything other than a small list, i.e. 60 members. ;)
If the list were bigger, say for instance 853, the solution I proposed
would be too cumbersome.
>
> Recently Shawn mentioned that there are 853 members.
Those 853 members are on msysgit or git@vger.kernel.org?
>
> Don't get me wrong, I'd _love_ to see a proper solution to the problem,
> alas, I do not see one yet.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-05 23:40 ` Tilman Schmidt
2008-03-06 0:26 ` Johannes Schindelin
@ 2008-03-06 4:29 ` Jay Soffian
1 sibling, 0 replies; 23+ messages in thread
From: Jay Soffian @ 2008-03-06 4:29 UTC (permalink / raw
To: Tilman Schmidt
Cc: Martin Langhoff, Junio C Hamano, Jakub Narebski,
Johannes Schindelin, msysgit, git
On Wed, Mar 5, 2008 at 6:40 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>
> But I'd like to suggest something else still: seeing that my git
> mailing list folder has already grown to 363 mails again, of which
> probably only a small fraction will concern me as a user - would
> it be possible to have separate mailing lists for usage topics and
> for discussions of ongoing development? I imagine that might help
> those who just want to use git (like me) to find their way around.
The mercurial lists are split-up this way. I hate it.
As for wanting a git-users list, just try filtering out everything from this
list with PATCH in the subject and you'll have a close-enough proxy, IMO.
j.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [msysGit] Re: The 8th airing of the msysGit herald
2008-03-06 2:42 ` Jim Raden
@ 2008-03-06 4:32 ` Jay Soffian
2008-03-06 4:33 ` Jim Raden
0 siblings, 1 reply; 23+ messages in thread
From: Jay Soffian @ 2008-03-06 4:32 UTC (permalink / raw
To: Jim Raden
Cc: Johannes Schindelin, Junio C Hamano, Tilman Schmidt,
Martin Langhoff, Jakub Narebski, msysgit, git
On Wed, Mar 5, 2008 at 9:42 PM, Jim Raden <james.raden@gmail.com> wrote:
> Those 853 members are on msysgit or git@vger.kernel.org?
http://vger.kernel.org/vger-lists.html#git
Oh no, only 851 members now. They're dropping like flies! :-)
j.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: The 8th airing of the msysGit herald
2008-03-06 4:32 ` [msysGit] " Jay Soffian
@ 2008-03-06 4:33 ` Jim Raden
2008-03-06 11:40 ` [msysGit] " Paul Franz
0 siblings, 1 reply; 23+ messages in thread
From: Jim Raden @ 2008-03-06 4:33 UTC (permalink / raw
To: Jay Soffian
Cc: Johannes Schindelin, Junio C Hamano, Tilman Schmidt,
Martin Langhoff, Jakub Narebski, msysgit, git
Obviously I must have scared them off with my suggestion! ;-)
On Wed, Mar 5, 2008 at 11:32 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Mar 5, 2008 at 9:42 PM, Jim Raden <james.raden@gmail.com> wrote:
>
> > Those 853 members are on msysgit or git@vger.kernel.org?
>
> http://vger.kernel.org/vger-lists.html#git
>
> Oh no, only 851 members now. They're dropping like flies! :-)
>
> j.
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [msysGit] Re: The 8th airing of the msysGit herald
2008-03-06 4:33 ` Jim Raden
@ 2008-03-06 11:40 ` Paul Franz
0 siblings, 0 replies; 23+ messages in thread
From: Paul Franz @ 2008-03-06 11:40 UTC (permalink / raw
To: james.raden
Cc: Jay Soffian, Johannes Schindelin, Junio C Hamano, Tilman Schmidt,
Martin Langhoff, Jakub Narebski, msysgit, git
Jim Raden wrote:
> Obviously I must have scared them off with my suggestion! ;-)
>
> On Wed, Mar 5, 2008 at 11:32 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>
>> On Wed, Mar 5, 2008 at 9:42 PM, Jim Raden <james.raden@gmail.com> wrote:
>>
>> > Those 853 members are on msysgit or git@vger.kernel.org?
>>
>> http://vger.kernel.org/vger-lists.html#git
>>
>> Oh no, only 851 members now. They're dropping like flies! :-)
>>
>> j.
>>
>>
Nah they switched to Mercurial. :-)
Paul Franz
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2008-03-06 11:41 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-02 23:30 The 8th airing of the msysGit herald Johannes Schindelin
2008-03-03 0:44 ` Jakub Narebski
2008-03-03 0:54 ` Johannes Schindelin
2008-03-03 1:10 ` Jakub Narebski
2008-03-03 12:00 ` Tilman Schmidt
2008-03-03 12:05 ` Johannes Schindelin
2008-03-03 18:21 ` Tilman Schmidt
2008-03-03 18:48 ` Brandon Casey
2008-03-05 23:12 ` Tilman Schmidt
2008-03-03 17:18 ` Junio C Hamano
2008-03-03 18:27 ` Tilman Schmidt
2008-03-03 22:37 ` Junio C Hamano
2008-03-03 22:58 ` Martin Langhoff
2008-03-05 23:40 ` Tilman Schmidt
2008-03-06 0:26 ` Johannes Schindelin
2008-03-06 0:41 ` Junio C Hamano
2008-03-06 2:03 ` Jim Raden
2008-03-06 2:29 ` Johannes Schindelin
2008-03-06 2:42 ` Jim Raden
2008-03-06 4:32 ` [msysGit] " Jay Soffian
2008-03-06 4:33 ` Jim Raden
2008-03-06 11:40 ` [msysGit] " Paul Franz
2008-03-06 4:29 ` Jay Soffian
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).