How will we approach a stable release?
Steffen Prohaska
Last October we agreed on a versioning scheme for msysgit and a
few criteria when to go stable [1].
[1] http://article.gmane.org/gmane.comp.version-control.msysgit/899
Today, I updated share/WinGit/HowToRelease.txt to reflect the
current status. Here is the relevant section:
> We use the following criteria to decide if we go stable.
> * features equivalent to official git-#-#-# are available in
> Git Bash.
> * [DONE] git-gui works if run from Git Bash.
> * [DONE] git-gui works if run from Start Menu.
> * [DONE] git and git-gui available from Windows Command Prompt
> (cmd shell).
> * server functionality (git-daemon, git-shell, ...) _not_
> necessarily
> supported.
> * git-cheetah _not_ needed.
Now that we have resolved the most urgent issues, I think it's
time to further discuss what "feature equivalent" means.
In a mail related to the Git User's Survey 2007 I proposed to
group git's commands into several categories [2]. My idea is
that these groups should reflect typical workflows. This would
make it easier to discuss the high level tasks git is used for.
[2] http://article.gmane.org/gmane.comp.version-control.git/61815
For msysgit, these grouping could help to make a decision where
to focus our efforts, and how to decide when we'd declare a
msysgit release stable.
Personally, I am only interested in the groups I denoted
"plumbing" and "core porcelain" and would focus exclusively on
commands in these groups (a comprehensive list is not yet
available). I could imagine having a stable release *without*
mail porcelain, import/export or admin tools. Users who want
to use commands from these groups would need to work on Unix.
I'd declare a release as stable if all "plumbing" and "core
procelain" commands were supported with features equivalent to
official git (a detailed list needs yet to be defined). I'd
certainly not exclude a command that is not included in these two
groups if the command works. However, missing commands would not
be accepted as bugs and the release notes would explicitly state
that only a subset of the official commands is supported by
msysgit.
I believe we should not only focus on the features visible by the
user but also make sure these features are implemented in C.
Migrating stable commands from shell code to C code is accepted
as a good way to ensure interoperability with Windows.
Eventually, we could get rid of all the Unix emulation tools and
I believe this would be a good thing. So maybe, we should add a
criteria that states that "plumbing" and "core porcelain" should
be implemented in C.
The criteria would be changed as follows:
--- snip ---
We release a stable version if:
* commands from "plumbing" and "core porcelain" equivalent to
official git are available in Git Bash and implemented in C.
(A list of commands would be added here.)
* [DONE] git-gui works if run from Git Bash.
* [DONE] git-gui works if run from Start Menu.
* [DONE] git and git-gui available from Windows Command
Prompt (cmd shell).
* other command, such as "mail porcelain", "import/export",
"admin", "server" are *not* required, though commands from
these groups may be included.
* git-cheetah is *not* required.
--- snip ---
What do you think?
[ Side note: it is unlikely that you can talk me into supporting
more than the core porcelain on Windows; *except* that someone
pledges to support the msysgit effort by taking responsibility
for commands that do not belong to the core porcelain. ]
Steffen
Johannes Schindelin
On Sun, 13 Jan 2008, Steffen Prohaska wrote:
> The criteria would be changed as follows:
>
> --- snip ---
> We release a stable version if:
> * commands from "plumbing" and "core porcelain" equivalent to
> official git are available in Git Bash and implemented in C.
> (A list of commands would be added here.)
That would take too long. IMHO having the whole merge stuff ported to C
will need at least another 6 months.
> * [DONE] git-gui works if run from Git Bash.
> * [DONE] git-gui works if run from Start Menu.
> * [DONE] git and git-gui available from Windows Command
> Prompt (cmd shell).
> * other command, such as "mail porcelain", "import/export",
> "admin", "server" are *not* required, though commands from
> these groups may be included.
IMHO git-svn is a _must_. (Although I can be talked out of it.)
My status so far: I got perl-5.8.8 compiled, subversion, too, but the perl
bindings are a bit strange. For one, the Makefiles are written to
somewhere completely bogus, and then they do not work properly.
> * git-cheetah is *not* required.
Yes, git-cheetah is nowhere near the state I would like to see it.
Unfortunately, the only developer I could get interested so far seems to
have lost interest, and I do not have enough time to take care of it.
FWIW I think that we are stable enough already to have better-than-preview
releases (although, like I said, lack of git-svn is a reason for me not to
declare non-beta status yet).
Ciao,
Dscho
Pēteris Kļaviņš
wrote in message news:alpine.DEB.1.00.0801141231500.23987@eeepc-johanness...
> IMHO git-svn is a _must_. (Although I can be talked out of it.)
Are you saying you would like to import from a svn repository hosted on
Windows, or one on another platform? If on another platform, couldn't you
git-svn on that platform, therefore obviating the need for git-svn on
Windows itself?
--
------------------------------------------------------------------------
Peter Klavins
Johannes Schindelin
On Mon, 14 Jan 2008, Pēteris Kļaviņš wrote:
> "Johannes Schindelin" <Johannes....@gmx.de> wrote in message
> news:alpine.DEB.1.00.0801141231500.23987@eeepc-johanness...
> > IMHO git-svn is a _must_. (Although I can be talked out of it.)
>
> Are you saying you would like to import from a svn repository hosted on
> Windows, or one on another platform? If on another platform, couldn't
> you git-svn on that platform, therefore obviating the need for git-svn
> on Windows itself?
Well, _I_ have no problem cloning via git-svn, since I am a very happy
Linux user, thankyouverymuch.
But for a proper Windows Git, I think it is wrong to ask people to do the
import/export on a different OS, or with cygwin...
Ciao,
Dscho
Pēteris Kļaviņš
wrote in message news:alpine.DEB.1.00.0801141300380.23987@eeepc-johanness...
> But for a proper Windows Git, I think it is wrong to ask people to do the
> import/export on a different OS, or with cygwin...
I think it's not so important for the first version of git on Windows to
target those developers that need to import/export to svn. If svn, why not
also cvs? I would be interested in statistics of the mix of cvs/svn/.../git
in the installed base of scm repositories, if anyone knows how to get that
sort of information.
For a first Windows version of git, I think it would be perfectly sufficient
to support pull/push to only git remote repositories.
Once we got 'em hooked on git for Windows, _then_ we could make it even more
enticing to never turn back by adding support for the additional cvs/svn/...
import/export sugar in a subsequent version. :-)
------------------------------------------------------------------------
Peter Klavins
Juanma Barranquero
> But for a proper Windows Git, I think it is wrong to ask people to do the
> import/export on a different OS, or with cygwin...
As a git newbie, I'd like to agree.
I have a tiny (about 400 revisions) Subversion repo I'd like to
convert to git, and currently I'm going the "funny" process of setting
up a virtual machine to run Kubuntu on my Windows XP to be able do the
conversion... "git svn" working on msysGit would definitely be a big
improvement.
Juanma
Johannes Schindelin
On Mon, 14 Jan 2008, Pēteris Kļaviņš wrote:
> "Johannes Schindelin" <Johannes....@gmx.de> wrote in message
> news:alpine.DEB.1.00.0801141300380.23987@eeepc-johanness...
> > But for a proper Windows Git, I think it is wrong to ask people to do
> > the import/export on a different OS, or with cygwin...
>
> I think it's not so important for the first version of git on Windows to
> target those developers that need to import/export to svn. If svn, why
> not also cvs? I would be interested in statistics of the mix of
> cvs/svn/.../git in the installed base of scm repositories, if anyone
> knows how to get that sort of information.
From a purely selfish viewpoint: Just look at how many people contributed
issues (more than one...) complaining that git-svn does not work.
Ciao,
Dscho
Johannes Schindelin
On Mon, 14 Jan 2008, Juanma Barranquero wrote:
> "git svn" working on msysGit would definitely be a big improvement.
The real question now: will you help?
Ciao,
Dscho
Juanma Barranquero
> The real question now: will you help?
I'd like to, and I'm willing. But I have no experiencie whatsoever
with the git source code.
Juanma
Johannes Schindelin
On Mon, 14 Jan 2008, Juanma Barranquero wrote:
Git experience is not required. Windows experience is, and how to compile
Perl modules for Windows.
Ciao,
Dscho
Juanma Barranquero
> Windows experience is, and how to compile
> Perl modules for Windows.
Not much experience compiling Perl modules (outside of "perl
Makefile.PL; make; make test; make install"), but I have experience as
a C and Perl programmer on Windows. I can try. Where to start from?
Juanma
Johannes Schindelin
On Mon, 14 Jan 2008, Juanma Barranquero wrote:
First, get a full clone of msysgit.git (or update it if you have a partial
one).
I uploaded an intermediate state (not to be integrated as-is) to tmp/msys.
But beware: you have to start msys.bat again after checking out tmp/msys,
otherwise you will still be in a MinGW system, not an MSys one.
After that, you can go to /src/perl and fetch&make&install perl 5.8.8 (For
some strange reason, perl < 5.8 is not good enough for subversion).
The next steps are to fetch&make&install expat, get subversion and
subversion-deps, adjust subversion so it compiles with MSys (not MinGW),
then make it, make "swig-pl-lib", "install-swig-pl-lib", and then the fun
starts:
In subversion/bindings/swig/perl/native, run "perl Makefile.PL". Find out
why it creates the Makefiles in ../libswig_perl_lib/.libs/, or move them
to the correct directory, and adjust them, because libsvn_* was not built
shared, but static.
Or find out how to build libsvn_* shared, not static, and then build the
module.
If you succeed building the module, write /src/subversion/release.sh a la
/src/perl/release.sh to fetch&build&install it automatically.
Be a hero.
Ciao,
Dscho
Steffen Prohaska
On Jan 14, 2008, at 1:37 PM, Johannes Schindelin wrote:
> On Sun, 13 Jan 2008, Steffen Prohaska wrote:
>
>> The criteria would be changed as follows:
>>
>> --- snip ---
>> We release a stable version if:
>> * commands from "plumbing" and "core porcelain" equivalent to
>> official git are available in Git Bash and implemented in C.
>> (A list of commands would be added here.)
>
> That would take too long. IMHO having the whole merge stuff ported
> to C
> will need at least another 6 months.
So you propose to release a stable version based on shell
scripts? Maybe we should be patient until we have a stable
msysgit release and push harder to have the C port done ASAP?
>> * [DONE] git-gui works if run from Git Bash.
>> * [DONE] git-gui works if run from Start Menu.
>> * [DONE] git and git-gui available from Windows Command
>> Prompt (cmd shell).
>> * other command, such as "mail porcelain", "import/export",
>> "admin", "server" are *not* required, though commands from
>> these groups may be included.
>
> IMHO git-svn is a _must_. (Although I can be talked out of it.)
>
> My status so far: I got perl-5.8.8 compiled, subversion, too, but
> the perl
> bindings are a bit strange. For one, the Makefiles are written to
> somewhere completely bogus, and then they do not work properly.
I can't say anything about this. I never used git-svn and I do
not plan to use it. Basically, I skipped svn. I tried it for
some time and wasn't really convinced by its advantages over CVS.
So I hibernated using CVS until eventually I found git.
>> * git-cheetah is *not* required.
>
> Yes, git-cheetah is nowhere near the state I would like to see it.
> Unfortunately, the only developer I could get interested so far
> seems to
> have lost interest, and I do not have enough time to take care of it.
>
> FWIW I think that we are stable enough already to have better-than-
> preview
> releases (although, like I said, lack of git-svn is a reason for me
> not to
> declare non-beta status yet).
Currently, we install git-svn even that we know it won't work.
This is certainly not the type of installer I'd like to declare
beta.
Maybe we could clearly state what we have and exclude all
commands that do not work from the installer. If we only
installed stable commands and give a clear indication on the
perspective for the missing commands, maybe we could do a beta
release for plumbing and core porcelain. The commands that
are not ready would still be included in msysgit. So it would
be easy for developers to get and improve what we already have.
But end users would not see commands that do not work.
From my perspective, more important than getting git-svn is to
merge the core porcelain back to official git. I'd like to be
able to build the msysgit release from official git ASAP. After
the 1.5.4 release, there's hopefully a time window to make some
progress on this. Explicitly excluding commands from the msysgit
end user release could also be a way to approach this goal more
quickly.
Steffen
Johannes Schindelin
On Mon, 14 Jan 2008, Steffen Prohaska wrote:
> On Jan 14, 2008, at 1:37 PM, Johannes Schindelin wrote:
>
> > On Sun, 13 Jan 2008, Steffen Prohaska wrote:
> >
> > > The criteria would be changed as follows:
> > >
> > > --- snip ---
> > > We release a stable version if:
> > > * commands from "plumbing" and "core porcelain" equivalent to
> > > official git are available in Git Bash and implemented in C.
> > > (A list of commands would be added here.)
> >
> > That would take too long. IMHO having the whole merge stuff ported to
> > C will need at least another 6 months.
>
> So you propose to release a stable version based on shell scripts?
> Maybe we should be patient until we have a stable msysgit release and
> push harder to have the C port done ASAP?
Unless more people are participating in the effort, this will not be
faster than 6 months; I even fully expect it to be slower.
So yes, I would say we release a version with shell scripts.
> > > * [DONE] git-gui works if run from Git Bash.
> > > * [DONE] git-gui works if run from Start Menu.
> > > * [DONE] git and git-gui available from Windows Command
> > > Prompt (cmd shell).
> > > * other command, such as "mail porcelain", "import/export",
> > > "admin", "server" are *not* required, though commands from
> > > these groups may be included.
> >
> > IMHO git-svn is a _must_. (Although I can be talked out of it.)
> >
> > My status so far: I got perl-5.8.8 compiled, subversion, too, but the
> > perl bindings are a bit strange. For one, the Makefiles are written
> > to somewhere completely bogus, and then they do not work properly.
>
> I can't say anything about this. I never used git-svn and I do not plan
> to use it. Basically, I skipped svn. I tried it for some time and
> wasn't really convinced by its advantages over CVS. So I hibernated
> using CVS until eventually I found git.
Yes, I did almost the same.
But plenty of otherwise interesting projects did not. That's why I
personally need svn.
I even would need it for work right now, if I weren't so paranoid as to
avoid typing a strong password into Windows.
> > > * git-cheetah is *not* required.
> >
> > Yes, git-cheetah is nowhere near the state I would like to see it.
> > Unfortunately, the only developer I could get interested so far seems
> > to have lost interest, and I do not have enough time to take care of
> > it.
> >
> > FWIW I think that we are stable enough already to have
> > better-than-preview releases (although, like I said, lack of git-svn
> > is a reason for me not to declare non-beta status yet).
>
> Currently, we install git-svn even that we know it won't work.
> This is certainly not the type of installer I'd like to declare
> beta.
>
> Maybe we could clearly state what we have and exclude all commands that
> do not work from the installer. If we only installed stable commands
> and give a clear indication on the perspective for the missing commands,
> maybe we could do a beta release for plumbing and core porcelain. The
> commands that are not ready would still be included in msysgit. So it
> would be easy for developers to get and improve what we already have.
> But end users would not see commands that do not work.
That sounds good.
These are the programs that do not work, AFAICT:
- cvsexportcommit
- cvsimport
- send-email
- svn
> From my perspective, more important than getting git-svn is to merge the
> core porcelain back to official git. I'd like to be able to build the
> msysgit release from official git ASAP. After the 1.5.4 release,
> there's hopefully a time window to make some progress on this.
> Explicitly excluding commands from the msysgit end user release could
> also be a way to approach this goal more quickly.
It would be a good thing to get closer to official git.git. But I have no
say in this, as I have not enough time to care about that.
Ciao,
Dscho
Johannes Sixt
> On Mon, 14 Jan 2008, Steffen Prohaska wrote:
> > So you propose to release a stable version based on shell scripts?
> > Maybe we should be patient until we have a stable msysgit release and
> > push harder to have the C port done ASAP?
>
> Unless more people are participating in the effort, this will not be
> faster than 6 months; I even fully expect it to be slower.
>
> So yes, I would say we release a version with shell scripts.
Side note: Quite a few spots in git code spawn
"sh", "-c", some_command
so it's not that we can get rid of bash once all scripts are ported to C.
-- Hannes
Johannes Schindelin
On Mon, 14 Jan 2008, Johannes Schindelin wrote:
> On Mon, 14 Jan 2008, Juanma Barranquero wrote:
>
> > On Jan 14, 2008 4:51 PM, Johannes Schindelin
> > <Johannes....@gmx.de> wrote:
> >
> > > Windows experience is, and how to compile Perl modules for Windows.
> >
> > Not much experience compiling Perl modules (outside of "perl
> > Makefile.PL; make; make test; make install"), but I have experience as
> > a C and Perl programmer on Windows. I can try. Where to start from?
>
> [... a really complex recipe to get subversion almost to compile ...]
I have a better method now.
Please fetch the current "temp/msys" branch of msysgit.git, and check it
out.
Then, cd to /src/subversion and execute release.sh therein.
The problem is that "git svn clone" segfaults for me.
I did not even test svn.exe itself, since everything takes such a _long_,
_looooong_ time on Windows.
If you could help me with that, it would be much appreciated (hint: I
_think_ libsvn_* should be compiled _dynamically_ instead of statically,
but I have nothing to back that hunch).
Thanks,
Dscho
Juanma Barranquero
> I have a better method now.
Great :)
> If you could help me with that, it would be much appreciated (hint: I
> _think_ libsvn_* should be compiled _dynamically_ instead of statically,
> but I have nothing to back that hunch).
I'll try to find some time during the weekend.
Juanma
Steffen Prohaska
On Jan 14, 2008, at 10:40 PM, Johannes Schindelin wrote:
>>> FWIW I think that we are stable enough already to have
>>> better-than-preview releases (although, like I said, lack of git-svn
>>> is a reason for me not to declare non-beta status yet).
>>
>> Currently, we install git-svn even that we know it won't work.
>> This is certainly not the type of installer I'd like to declare
>> beta.
>>
>> Maybe we could clearly state what we have and exclude all commands
>> that
>> do not work from the installer. If we only installed stable commands
>> and give a clear indication on the perspective for the missing
>> commands,
>> maybe we could do a beta release for plumbing and core porcelain.
>> The
>> commands that are not ready would still be included in msysgit.
>> So it
>> would be easy for developers to get and improve what we already have.
>> But end users would not see commands that do not work.
>
> That sounds good.
>
> These are the programs that do not work, AFAICT:
>
> - cvsexportcommit
> - cvsimport
> - send-email
> - svn
I pushed work/install-fewer to msysgit, which excludes the
following commands:
git-cvsexportcommit
git-cvsimport
git-cvsserver
git-send-email
git-shell.exe
git-svn
The next list contains commands that I am not sure about.
Should we install these?
git-archimport
git-help--browse
git-instaweb
git-mailinfo.exe
git-mailsplit.exe
git-quiltimport
git-relink
The last list contains commands that I think should be installed:
git-add--interactive
git-add.exe
git-am
git-annotate.exe
git-apply.exe
git-archive.exe
git-bisect
git-blame.exe
git-branch.exe
git-bundle.exe
git-cat-file.exe
git-check-attr.exe
git-check-ref-format.exe
git-checkout
git-checkout-index.exe
git-cherry-pick.exe
git-cherry.exe
git-citool
git-clean.exe
git-clone
git-commit-tree.exe
git-commit.exe
git-config.exe
git-count-objects.exe
git-describe.exe
git-diff-files.exe
git-diff-index.exe
git-diff-tree.exe
git-diff.exe
git-fast-export.exe
git-fast-import.exe
git-fetch--tool.exe
git-fetch-pack.exe
git-fetch.exe
git-filter-branch
git-fmt-merge-msg.exe
git-for-each-ref.exe
git-format-patch.exe
git-fsck-objects.exe
git-fsck.exe
git-gc.exe
git-get-tar-commit-id.exe
git-grep.exe
git-gui
git-gui.tcl
git-hash-object.exe
git-http-fetch.exe
git-http-push.exe
git-index-pack.exe
git-init-db.exe
git-init.exe
git-log.exe
git-lost-found
git-ls-files.exe
git-ls-remote.exe
git-ls-tree.exe
git-merge
git-merge-base.exe
git-merge-file.exe
git-merge-index.exe
git-merge-octopus
git-merge-one-file
git-merge-ours.exe
git-merge-recursive.exe
git-merge-resolve
git-merge-stupid
git-merge-subtree.exe
git-merge-tree.exe
git-mergetool
git-mktag.exe
git-mktree.exe
git-mv.exe
git-name-rev.exe
git-pack-objects.exe
git-pack-redundant.exe
git-pack-refs.exe
git-parse-remote
git-patch-id.exe
git-peek-remote.exe
git-prune-packed.exe
git-prune.exe
git-pull
git-push.exe
git-read-tree.exe
git-rebase
git-rebase--interactive
git-receive-pack.exe
git-reflog.exe
git-remote
git-repack
git-repo-config.exe
git-request-pull
git-rerere.exe
git-reset.exe
git-rev-list.exe
git-rev-parse.exe
git-revert.exe
git-rm.exe
git-send-pack.exe
git-sh-setup
git-shortlog.exe
git-show-branch.exe
git-show-index.exe
git-show-ref.exe
git-show.exe
git-stash
git-status.exe
git-stripspace.exe
git-submodule
git-symbolic-ref.exe
git-tag.exe
git-tar-tree.exe
git-unpack-file.exe
git-unpack-objects.exe
git-update-index.exe
git-update-ref.exe
git-update-ref.exe.manifest
git-update-server-info.exe
git-upload-archive.exe
git-upload-pack.exe
git-var.exe
git-verify-pack.exe
git-verify-tag.exe
git-whatchanged.exe
git-write-tree.exe
git.exe
gitk
Steffen
Johannes Schindelin
This patch looks good, except that it calls "egrep", which is a simple
script to call "grep -E", so I would like the patch to be more explicit
and call "grep -E" right away. Or even better: "grep", since it does not
even start to begin using extended regular expressions.
> The next list contains commands that I am not sure about.
> Should we install these?
>
> git-archimport
Agree; we do not ship tla.
> git-help--browse
AFAICT we need it, and probably need to adjust it to msysGit (although
that might not be necessary; I have no time to look into it).
> git-instaweb
Agree; we do not ship apache or lighttp.
> git-mailinfo.exe
> git-mailsplit.exe
AFAIR these are needed for git-am.
> git-quiltimport
Even if we do not ship quilt, this script might be useful; it does not use
quilt itself.
> git-relink
This is not really useful, I think, but it _should_ work on Filesystems
that support hard links, so IMHO we sould ship it.
> The last list contains commands that I think should be installed:
>
> git-citool
AFAICT this is not built anymore by git.git.
> git-filter-branch
I recently tried to use filter-branch on Windows, but it did not work, so
I resorted to Linux, where the same command line worked.
So I vote to exclude it until it starts to work properly (although I think
that the tests pass).
Or maybe somebody else should confirm that it actually works with a simple
msg-filter to transform msysgit's "devel" branch (which was my non-working
test case).
> git-gui
> git-gui.tcl
Do we really need both? Or is the second just a left-over from an old
install?
> git-mergetool
I think we need to include a tool like tkdiff for this to become actually
useful, or exclude it from the distribution.
Ciao,
Dscho
Steffen Prohaska
I'll check this. My first "grep" didn't work. Maybe I need
'\|' instead of a simple '|'. I'll find out.
>
>> The next list contains commands that I am not sure about.
>> Should we install these?
>>
>> git-archimport
>
> Agree; we do not ship tla.
>
>> git-help--browse
>
> AFAICT we need it, and probably need to adjust it to msysGit (although
> that might not be necessary; I have no time to look into it).
Do you mean it is needed for "git help"? I don't think so.
We launch the HTML browser directly using the Windows API
and do not support man.
>> git-instaweb
>
> Agree; we do not ship apache or lighttp.
>
>> git-mailinfo.exe
>> git-mailsplit.exe
>
> AFAIR these are needed for git-am.
I'll check.
>
>> git-quiltimport
>
> Even if we do not ship quilt, this script might be useful; it does
> not use
> quilt itself.
Will include it.
>> git-relink
>
> This is not really useful, I think, but it _should_ work on
> Filesystems
> that support hard links, so IMHO we sould ship it.
ditto.
>> The last list contains commands that I think should be installed:
>>
>> git-citool
>
> AFAICT this is not built anymore by git.git.
I ran "rm /bin/git*" and did a fresh install. I'll check
again.
If it is still built, I'll exclude it from the installer.
>> git-filter-branch
>
> I recently tried to use filter-branch on Windows, but it did not
> work, so
> I resorted to Linux, where the same command line worked.
>
> So I vote to exclude it until it starts to work properly (although
> I think
> that the tests pass).
>
> Or maybe somebody else should confirm that it actually works with a
> simple
> msg-filter to transform msysgit's "devel" branch (which was my non-
> working
> test case).
I'll exclude it.
>> git-gui
>> git-gui.tcl
>
> Do we really need both? Or is the second just a left-over from an old
> install?
dunno, will check.
>> git-mergetool
>
> I think we need to include a tool like tkdiff for this to become
> actually
> useful, or exclude it from the distribution.
This is pretty useful. I use it regularly. You can point
mergetool.<tool>.path to the tool of your choice (e.g.
kdiff3 or ecmerge) and use git-mergetool right away.
Steffen
Johannes Schindelin
On Sat, 19 Jan 2008, Steffen Prohaska wrote:
> On Jan 19, 2008, at 11:42 PM, Johannes Schindelin wrote:
>
> > On Sat, 19 Jan 2008, Steffen Prohaska wrote:
> >
> > > git-help--browse
> >
> > AFAICT we need it, and probably need to adjust it to msysGit (although
> > that might not be necessary; I have no time to look into it).
>
> Do you mean it is needed for "git help"? I don't think so. We launch
> the HTML browser directly using the Windows API and do not support man.
Maybe we should consolidate that so that "man" _could_ be launched, but
the default is to do HTML help via git-help--browse?
Dunno, as I said: time is lacking to look into that.
> > > git-mergetool
> >
> > I think we need to include a tool like tkdiff for this to become
> > actually useful, or exclude it from the distribution.
>
> This is pretty useful. I use it regularly. You can point
> mergetool.<tool>.path to the tool of your choice (e.g. kdiff3 or
> ecmerge) and use git-mergetool right away.
That reason to include it is good enough for me!
Thanks,
Dscho
Steffen Prohaska
On Jan 20, 2008, at 12:22 AM, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 19 Jan 2008, Steffen Prohaska wrote:
>
>> On Jan 19, 2008, at 11:42 PM, Johannes Schindelin wrote:
>>
>>> On Sat, 19 Jan 2008, Steffen Prohaska wrote:
>>>
>>>> git-help--browse
>>>
>>> AFAICT we need it, and probably need to adjust it to msysGit
>>> (although
>>> that might not be necessary; I have no time to look into it).
>>
>> Do you mean it is needed for "git help"? I don't think so. We launch
>> the HTML browser directly using the Windows API and do not support
>> man.
>
> Maybe we should consolidate that so that "man" _could_ be launched,
We would need to add the command "man" to msysgit and the
installer; and also checkout Junio's man branch somewhere and add
it to the installer, too.
I'll not look into that because I'm not interested in the
man pages. The HTML help works perfectly for me. However,
I'm not against it. If someone sent a clean patch, I'd
certainly include it.
> but
> the default is to do HTML help via git-help--browse?
I'm against this. The current solution directly uses a C-API to
tell Windows to display the HTML page. Let's keep it this way.
git-help--browse is yet another shell script; but we want to get
rid of the shell scripts.
Steffen
Steffen Prohaska
BTW,
"git diff --text" works pretty well to review changes in
ReleaseNotes.rtf.
On Jan 19, 2008, at 11:57 PM, Steffen Prohaska wrote:
> On Jan 19, 2008, at 11:42 PM, Johannes Schindelin wrote:
>
>> This patch looks good, except that it calls "egrep", which is a
>> simple
>> script to call "grep -E", so I would like the patch to be more
>> explicit
>> and call "grep -E" right away. Or even better: "grep", since it
>> does not
>> even start to begin using extended regular expressions.
>
> I'll check this. My first "grep" didn't work. Maybe I need
> '\|' instead of a simple '|'. I'll find out.
grep '\|' works.
>>> git-mailinfo.exe
>>> git-mailsplit.exe
>>
>> AFAIR these are needed for git-am.
>
> I'll check.
They are needed.
>>
>>> The last list contains commands that I think should be installed:
>>>
>>> git-citool
>>
>> AFAICT this is not built anymore by git.git.
>
> I ran "rm /bin/git*" and did a fresh install. I'll check
> again.
>
> If it is still built, I'll exclude it from the installer.
It is built by git.git. It's listed in git-gui/Makefile as
GITGUI_BUILT_INS = git-citool
I see two options
- exclude it from msysgit's Git-installer.
- propose upstream to remove it and wait.
git-citool works and therefore I tend to leave it in the
installer.
>>> git-gui
>>> git-gui.tcl
>>
>> Do we really need both? Or is the second just a left-over from an old
>> install?
>
> dunno, will check.
The current implementation needs both. I propose to leave this
until 1.5.4 is released. Maybe we should cleanup afterwards?
Steffen
Johannes Schindelin
On Sun, 20 Jan 2008, Steffen Prohaska wrote:
>
> On Jan 20, 2008, at 12:22 AM, Johannes Schindelin wrote:
>
> > On Sat, 19 Jan 2008, Steffen Prohaska wrote:
> >
> > > On Jan 19, 2008, at 11:42 PM, Johannes Schindelin wrote:
> > >
> > > > On Sat, 19 Jan 2008, Steffen Prohaska wrote:
> > > >
> > > > > git-help--browse
> > > >
> > > > AFAICT we need it, and probably need to adjust it to msysGit
> > > > (although that might not be necessary; I have no time to look into
> > > > it).
> > >
> > > Do you mean it is needed for "git help"? I don't think so. We
> > > launch the HTML browser directly using the Windows API and do not
> > > support man.
> >
> > Maybe we should consolidate that so that "man" _could_ be launched,
>
> We would need to add the command "man" to msysgit and the installer; and
> also checkout Junio's man branch somewhere and add it to the installer,
> too.
What I meant was: if the user _asks_ for "man", it is the _user's_
obligation to provide a working "man" and "man pages".
> > but the default is to do HTML help via git-help--browse?
>
> I'm against this. The current solution directly uses a C-API to tell
> Windows to display the HTML page. Let's keep it this way.
> git-help--browse is yet another shell script; but we want to get rid of
> the shell scripts.
Hmm. I want to get rid of shell scripts, too, but rather not deviate from
git.git in that...
I'll think about it.
Ciao,
Dscho
Johannes Schindelin
On Sun, 20 Jan 2008, Steffen Prohaska wrote:
> I pushed an updated patch to work/install-fewer.
Thanks.
> BTW, "git diff --text" works pretty well to review changes in
> ReleaseNotes.rtf.
I used "git diff -a" ;-)
> On Jan 19, 2008, at 11:57 PM, Steffen Prohaska wrote:
>
> > On Jan 19, 2008, at 11:42 PM, Johannes Schindelin wrote:
> >
> > > > The last list contains commands that I think should be installed:
> > > >
> > > > git-citool
> > >
> > > AFAICT this is not built anymore by git.git.
> >
> > I ran "rm /bin/git*" and did a fresh install. I'll check
> > again.
> >
> > If it is still built, I'll exclude it from the installer.
>
> It is built by git.git. It's listed in git-gui/Makefile as
>
> GITGUI_BUILT_INS = git-citool
>
> I see two options
> - exclude it from msysgit's Git-installer.
> - propose upstream to remove it and wait.
>
> git-citool works and therefore I tend to leave it in the
> installer.
Let's leave it, and not care about it being the same as git-gui.
> > > > git-gui
> > > > git-gui.tcl
> > >
> > > Do we really need both? Or is the second just a left-over from an old
> > > install?
> >
> > dunno, will check.
>
> The current implementation needs both. I propose to leave this
> until 1.5.4 is released. Maybe we should cleanup afterwards?
Maybe.
Thanks,
Dscho
Dan Nicholson
On Jan 14, 12:40 pm, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
>
> On Mon, 14 Jan 2008, Juanma Barranquero wrote:
>
> > > Windows experience is, and how to compile Perl modules for Windows.
>
> > Not much experience compiling Perl modules (outside of "perl
> > Makefile.PL; make; make test; make install"), but I have experience as a
> > C and Perl programmer on Windows. I can try. Where to start from?
>
> First, get a full clone of msysgit.git (or update it if you have a partial
> one).
>
> I uploaded an intermediate state (not to be integrated as-is) to tmp/msys.
> But beware: you have to start msys.bat again after checking out tmp/msys,
> otherwise you will still be in a MinGW system, not an MSys one.
>
> After that, you can go to /src/perl and fetch&make&install perl 5.8.8 (For
> some strange reason, perl < 5.8 is not good enough for subversion).
>
> The next steps are to fetch&make&install expat, get subversion and
> subversion-deps, adjust subversion so it compiles with MSys (not MinGW),
> then make it, make "swig-pl-lib", "install-swig-pl-lib", and then the fun
> starts:
>
> In subversion/bindings/swig/perl/native, run "perl Makefile.PL". Find out
> why it creates the Makefiles in ../libswig_perl_lib/.libs/, or move them
> to the correct directory, and adjust them, because libsvn_* was not built
> shared, but static.
bindings many times with "make swig-pl && make install-swig-pl". No
extra steps should be required. I.e., you shouldn't have to run "perl
Makefile.PL" because the make target does that for you.
However, I do happen to know that the build is broken in that it
relies on macros defined by `perl -V:cflags' to set what is needed by
`apr-1-config --cppflags'.
If you can show more of an error, I might be able to suggest a fix. I
don't really have a Windows development machine, but I might be able
to figure something out and take a look.
--
Dan
Johannes Schindelin
As I described, it does not work. First, "install-swig-pl" does not fail
(but does not install the modules either". Second, "perl Makefile.PL"
creates the Makefiles in the _wrong_ directory, and I am not quite certain
that the Makefiles are correct, either.
> However, I do happen to know that the build is broken in that it relies
> on macros defined by `perl -V:cflags' to set what is needed by
> `apr-1-config --cppflags'.
>
> If you can show more of an error, I might be able to suggest a fix. I
> don't really have a Windows development machine, but I might be able to
> figure something out and take a look.
The easiest way would be to try for yourself. As you are on the msysgit
list, I assume you have a clone of msysgit.git (probably by running the
msysGit-netinstaller).
Just do a "cd / && git fetch", then. This should bring you all the
current branches, and "temp/msys" is what you want.
Check this branch out by "cd / && git checkout temp/msys". Now you need
to run msys.bat again, or manually set "export MSYSTEM=MSYS", since Perl
(and thus, the Perl bindings) need to be aware of MSys, not just MinGW32.
Now you can run "/src/subversion/release.sh". Be sure to report any
errors that you cannot fix, or to provide fixes for any errors you could
fix (this is what Open Source is about; I worked _long_ and _hard_ to get
it at the stage where it is, if other people bring it to perfection, I am
just glad).
Anybody who can fix it will be interviewed for the next Herald (this is
not a threat, but a bonus ;-)
Ciao,
Dscho
P.S.: Seems like my last P.S. on this list is unmerited... or _are_ you
from central Europe?
Dan Nicholson
I guess I'll have to go see for myself.
> > However, I do happen to know that the build is broken in that it relies
> > on macros defined by `perl -V:cflags' to set what is needed by
> > `apr-1-config --cppflags'.
> >
> > If you can show more of an error, I might be able to suggest a fix. I
> > don't really have a Windows development machine, but I might be able to
> > figure something out and take a look.
>
> The easiest way would be to try for yourself. As you are on the msysgit
> list, I assume you have a clone of msysgit.git (probably by running the
> msysGit-netinstaller).
No, I just cloned on a Linux machine and had a look around. But I've
got a windows partition on my laptop, so I'll try it from there.
> Just do a "cd / && git fetch", then. This should bring you all the
> current branches, and "temp/msys" is what you want.
>
> Check this branch out by "cd / && git checkout temp/msys". Now you need
> to run msys.bat again, or manually set "export MSYSTEM=MSYS", since Perl
> (and thus, the Perl bindings) need to be aware of MSys, not just MinGW32.
>
> Now you can run "/src/subversion/release.sh". Be sure to report any
> errors that you cannot fix, or to provide fixes for any errors you could
> fix (this is what Open Source is about; I worked _long_ and _hard_ to get
> it at the stage where it is, if other people bring it to perfection, I am
> just glad).
>
> Anybody who can fix it will be interviewed for the next Herald (this is
> not a threat, but a bonus ;-)
I've fixed many build errors on Linux, but this would be my first
attempt on Windows. Thanks for the instructions.
> P.S.: Seems like my last P.S. on this list is unmerited... or _are_ you
> from central Europe?
I'm not sure what your last P.S. was about. Possibly the time on my
mail? I'm not subscribed, so I just threw in a reply from Google
Groups. And I'm not from central Europe.
--
Dan
Johannes Schindelin
I'm sorry... I should have been more verbose (but got distracted by this
darned Ballard).
The issue I see is that
- the build process says that it would prefer dynamic libraries, but will
go ahead and try static ones (for libsvn_*),
- when I run "git svn", it works,
- when I run "git svn clone <url>", it crashes, and the crashdump shows
only _one_ hexadecimal address in the stackdump. No function name, no
function name_s_.
> > > However, I do happen to know that the build is broken in that it
> > > relies on macros defined by `perl -V:cflags' to set what is needed
> > > by `apr-1-config --cppflags'.
> > >
> > > If you can show more of an error, I might be able to suggest a fix.
> > > I don't really have a Windows development machine, but I might be
> > > able to figure something out and take a look.
> >
> > The easiest way would be to try for yourself. As you are on the
> > msysgit list, I assume you have a clone of msysgit.git (probably by
> > running the msysGit-netinstaller).
>
> No, I just cloned on a Linux machine and had a look around. But I've got
> a windows partition on my laptop, so I'll try it from there.
Wow, another Linux developer providing development assistance ;-)
> > Just do a "cd / && git fetch", then. This should bring you all the
> > current branches, and "temp/msys" is what you want.
> >
> > Check this branch out by "cd / && git checkout temp/msys". Now you
> > need to run msys.bat again, or manually set "export MSYSTEM=MSYS",
> > since Perl (and thus, the Perl bindings) need to be aware of MSys, not
> > just MinGW32.
> >
> > Now you can run "/src/subversion/release.sh". Be sure to report any
> > errors that you cannot fix, or to provide fixes for any errors you
> > could fix (this is what Open Source is about; I worked _long_ and
> > _hard_ to get it at the stage where it is, if other people bring it to
> > perfection, I am just glad).
> >
> > Anybody who can fix it will be interviewed for the next Herald (this
> > is not a threat, but a bonus ;-)
>
> I've fixed many build errors on Linux, but this would be my first
> attempt on Windows. Thanks for the instructions.
Thanks for your help! I really appreciate it!
> > P.S.: Seems like my last P.S. on this list is unmerited... or _are_
> > you from central Europe?
>
> I'm not sure what your last P.S. was about. Possibly the time on my
> mail? I'm not subscribed, so I just threw in a reply from Google Groups.
> And I'm not from central Europe.
California? (Just a guess from the timezone.)
Ciao,
Dscho
Dan Nicholson
Do you know why dynamic libraries aren't being created? I like to
think I have a pretty decent understanding of how libtool works, but
then I actually have no idea what it does in a Windows context.
> - when I run "git svn", it works,
>
> - when I run "git svn clone <url>", it crashes, and the crashdump shows
> only _one_ hexadecimal address in the stackdump. No function name, no
> function name_s_.
Ouch. Out of curiosity, what kind of urls have you tried? Depending on
if it's http:// or svn://, different libraries will be used (neon for
http://, I believe).
> > No, I just cloned on a Linux machine and had a look around. But I've got
> > a windows partition on my laptop, so I'll try it from there.
>
> Wow, another Linux developer providing development assistance ;-)
Even though I've purged Windows from nearly all my computers, I still
have a soft spot in my heart that wants git to work right there. My
knowledge of C is pretty weak, but I'd like to think I can at least
hack up some build fixes.
> > I'm not sure what your last P.S. was about. Possibly the time on my
> > mail? I'm not subscribed, so I just threw in a reply from Google Groups.
> > And I'm not from central Europe.
>
> California? (Just a guess from the timezone.)
Seattle, WA.
--
Dan
Johannes Schindelin
On Mon, 21 Jan 2008, Dan Nicholson wrote:
> > - the build process says that it would prefer dynamic libraries, but
> > will go ahead and try static ones (for libsvn_*),
>
> Do you know why dynamic libraries aren't being created? I like to think
> I have a pretty decent understanding of how libtool works, but then I
> actually have no idea what it does in a Windows context.
I have no idea (yet). But as Christian pointed out, it could be a
peculiarity in the Win32 handling of libtool/autoconf.
> > - when I run "git svn", it works,
> >
> > - when I run "git svn clone <url>", it crashes, and the crashdump shows
> > only _one_ hexadecimal address in the stackdump. No function name, no
> > function name_s_.
>
> Ouch. Out of curiosity, what kind of urls have you tried? Depending on
> if it's http:// or svn://, different libraries will be used (neon for
> http://, I believe).
http://
> > > No, I just cloned on a Linux machine and had a look around. But I've got
> > > a windows partition on my laptop, so I'll try it from there.
> >
> > Wow, another Linux developer providing development assistance ;-)
>
> Even though I've purged Windows from nearly all my computers, I still
> have a soft spot in my heart that wants git to work right there. My
> knowledge of C is pretty weak, but I'd like to think I can at least hack
> up some build fixes.
;-)
I know your feeling.
I live without Windows since 1994. It has not always been easy, but
always pleasing. Especially the lack of a need to install an antivirus
(although I _got_ a virus _once_ on Linux; a server connected to the
internet 24/7, with a user "ron" with password "ron"... go figure).
> > > I'm not sure what your last P.S. was about. Possibly the time on my
> > > mail? I'm not subscribed, so I just threw in a reply from Google
> > > Groups. And I'm not from central Europe.
> >
> > California? (Just a guess from the timezone.)
>
> Seattle, WA.
Ah, closer to Linus than I am. Ah!
;-)
Ciao,
Dscho