MinGW port updated to GIT 1.5.0

MinGW port updated to GIT 1.5.0

[Johannes Sixt]

I've merged GIT 1.5.0 into the MinGW port. It is available at the usual
location:

pull/clone: git://repo.or.cz/git/mingw.git
gitweb:     http://repo.or.cz/w/git/mingw.git

It contains an important fix (MinGW specific): Earlier versions could
sometimes create temporary files read-only instead of read-writable.


WARNING!

The MinGW port does not support symbolic links, but the git.git itself
now contains a symbolic link (RelNotes). For this reason, you cannot
successfully pull this version's "master" branch to your Windows box and
expect it to work. The "devel" branch has the symbolic link removed, so
it can at least be checked out. For other operations you may enounter an
error like this:

bad tree object: 4571d0d1cfb5a4170dfc80e9654228acae295129

I'm working on a solution. The general idea is to extend the meaning of
`core.filemode = false` to check out symbolic links as plain files. Any
hints about where the source code needs changes are welcome.

-- Hannes

GIT 1.5.0 binary installer available.

[Han-Wen Nienhuys]

Johannes Sixt escreveu:
> I've merged GIT 1.5.0 into the MinGW port. It is available at the usual
> location:
> 
> pull/clone: git://repo.or.cz/git/mingw.git
> gitweb:     http://repo.or.cz/w/git/mingw.git
> 
> It contains an important fix (MinGW specific): Earlier versions could
> sometimes create temporary files read-only instead of read-writable.

I've uploaded a binary installer to

http://lilypond.org/git/binaries/mingw/

(untested, and will need magic to get the bash scripts 
working)




-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: GIT 1.5.0 binary installer available.

[Johannes Schindelin]

Hi,

On Thu, 15 Feb 2007, Han-Wen Nienhuys wrote:

> Johannes Sixt escreveu:
> > I've merged GIT 1.5.0 into the MinGW port. It is available at the usual
> > location:
> > 
> > pull/clone: git://repo.or.cz/git/mingw.git
> > gitweb:     http://repo.or.cz/w/git/mingw.git
> > 
> > It contains an important fix (MinGW specific): Earlier versions could
> > sometimes create temporary files read-only instead of read-writable.
> 
> I've uploaded a binary installer to
> 
> http://lilypond.org/git/binaries/mingw/
> 
> (untested, and will need magic to get the bash scripts 
> working)

Yes, indeed. And not only the bash scripts: AFAICT the command line option 
parsing is borked: whatever I do, a

	sh -c "git-config -l"

from cmd does not pick up the option "-l". Which is funny, since a simple 
test program (outputting just the options passed to it) works. And so does 
"git-config -l" from "cmd".

Could you please try making an installer which includes an exe for this 
simple program?

-- snip --
#include <stdio.h>

int main(int argc, char **argv)
{
        int i;

        for (i = 0; i < argc; i++)
                printf("arg %d: %s\n", i, argv[i]);
        return 0;
}
-- snap --

Other than that, I'd go the git-gui way. For this, not only many of the 
tools in MinGW (such as cat, expr, etc., and maybe even perl) are needed, 
but also a wish. Happily, you can download that just fine:

http://prdownloads.sf.net/mingw/tcltk-8.4.1-1.exe?download

I already made a minimal change to git-gui so you can choose the directory 
to start from.

Ciao,
Dscho

Re: GIT 1.5.0 binary installer available.

[Johannes Schindelin]

Hi,

On Thu, 15 Feb 2007, Johannes Schindelin wrote:

> Yes, indeed. And not only the bash scripts: AFAICT the command line option 
> parsing is borked: whatever I do, a
> 
> 	sh -c "git-config -l"
> 
> from cmd does not pick up the option "-l".

I know now why it does not work. Somehow the PATH gets reset all the time. 
Will investigate further.

Ciao,
Dscho

Re: GIT 1.5.0 binary installer available.

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I already made a minimal change to git-gui so you can choose the directory 
> to start from.

Do post, when ready.  ;-)

-- 
Shawn.

Re: GIT 1.5.0 binary installer available.

[Johannes Schindelin]

Hi,

On Thu, 15 Feb 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I already made a minimal change to git-gui so you can choose the directory 
> > to start from.
> 
> Do post, when ready.  ;-)

ATM it looks like this:

-- snip --
 git-gui/git-gui.sh |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index f5010dd..ed5cd82 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -291,6 +291,11 @@ proc ask_popup {msg} {
 ##
 ## repository setup
 
+if { [is_Windows] && ![is_Cygwin] } {
+	set repo_dir [tk_chooseDirectory -title "Choose a Git repository" -mustexist 1]
+	cd $repo_dir
+}
+
 if {   [catch {set _gitdir $env(GIT_DIR)}]
 	&& [catch {set _gitdir [exec git rev-parse --git-dir]} err]} {
 	catch {wm withdraw .}
-- snap --

However, I am still wondering what to make of the silly behaviour I 
observed earlier: the PATH was forgotten either by "sh" being called from 
"cmd", or by "wish84" being called from "sh".

But the strangest part about it: if I replaced the program names with 
their absolute path, then the command line options would _not_ be ignored. 
Strange.

If I get that fsck up fixed, I'd like to work with Han-Wen on enhancing 
his installer (which is nice!) with wish, bash, perl, and a shortcut to 
git-gui in Start Menu/Git/Git GUI.

BTW any news on the integration of gitk in git-gui?

Ciao,
Dscho

Re: GIT 1.5.0 binary installer available.

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 15 Feb 2007, Shawn O. Pearce wrote:
> > Do post, when ready.  ;-)
> 
> @@ -291,6 +291,11 @@ proc ask_popup {msg} {
>  ##
>  ## repository setup
>  
> +if { [is_Windows] && ![is_Cygwin] } {
> +	set repo_dir [tk_chooseDirectory -title "Choose a Git repository" -mustexist 1]
> +	cd $repo_dir
> +}
> +
>  if {   [catch {set _gitdir $env(GIT_DIR)}]
>  	&& [catch {set _gitdir [exec git rev-parse --git-dir]} err]} {
>  	catch {wm withdraw .}
> -- snap --

OK.  I'm thinking though that this should go below the context that
appears below it.  The reason is, a "Desktop Icon" for git-gui embeds
the repository path in it by setting up GIT_DIR, so that the user
returns to the same repository when launching through that icon.
In other words, maybe only prompt the user to select the directory
if $env(GIT_DIR) was not set?
 
> However, I am still wondering what to make of the silly behaviour I 
> observed earlier: the PATH was forgotten either by "sh" being called from 
> "cmd", or by "wish84" being called from "sh".

I think I can answer this: Tcl (and thus wish too) on Windows does
not pass its environment onto its children.  If you poke around
git-gui some and look for is_Cygwin you will find some of the places
where we exec something like git-fetch we actually wrap it up in
a login shell, so the user's environment can be correctly loaded
before git-fetch starts.

I think I have also noticed that setting env(PATH) has no effect
on how Tcl searches for an executable when it tries to exec it.
The search path appears to only be settable *before* Tcl begins.

Unfortunately these quirks are also in the Cygwin version of
Tcl, as apparently on Windows even the Cygwin version of Tcl uses
CreateProcess to execute children, rather than the POSIX fork/exec
that comes with Cygwin.

> But the strangest part about it: if I replaced the program names with 
> their absolute path, then the command line options would _not_ be ignored. 
> Strange.

Really strange that command line options get ignored, but the
command still runs?  What's up with that?  Ohhhhhh, its one of
those new-fangled operating systems that's based on New Technology
Technology, isn't it?[*1*].

> If I get that fsck up fixed, I'd like to work with Han-Wen on enhancing 
> his installer (which is nice!) with wish, bash, perl, and a shortcut to 
> git-gui in Start Menu/Git/Git GUI.

That will really shine when git-gui learns how to do the magic of
git-clone.  Maybe in a week or two (basically when I get to it),
or sooner if someone is interested in doing that themselves.
 
> BTW any news on the integration of gitk in git-gui?

None to report.  I've talked with Paul about it by email only
slightly, but he has reportedly been busy with other tasks and
has not had any time lately for gitk, so the conversation wasn't
very detailed.

There's some complicating factors to embedding git-gui into gitk,
and vice-versa.  I haven't dug into gitk's UI code but I suspect
it assumes the main graph window is ".", and that the repository
has commits to display.  So I'm not sure how it would react on an
empty repository (initial commit case), nor do I want gitk's UI to
startup when running git-citool.

Likewise git-gui currently assumes the main commit window is "."
(except in the case of "git gui blame").

Both programs assume a lot of globals.  We probably have some
duplicate names for different variables.

Over the next month or two one goal for me with git-gui is to
refactor some of it into multiple files, and to use namespaces
to seperate the different modules from each other.  This way the
branch control UI's globals aren't in the same namespace as the
commit window's UI globals.  That would help with embedding git-gui
into gitk.

But from a user interface perspective I'm not sure that's the best
thing to do.  I cannot quite wrap my head around what a melded
git-gui and gitk would look like.  git-gui's primary focus is
viewing the status of the working directory, switching branches,
merging, transport (fetch/push) and making commits.  gitk's primary
focus is looking at history.  I don't know about you, but I commit,
push, fetch and merge a hellva lot more than I look at history.

One problem that I had with the last version of qgit that I looked at
was creating commits was sort of a secondary operation in the UI.
It very much felt like that feature was bolted onto the side,
and was a second class citizen.  The primary focus of the UI was
showing the graphical history.  Which is fine if that's what your
primary task is.  But its not for everyone I know.


[*1*] If you didn't get that joke, you must not have had enough
chances to poke fun at Microsoft's marketing materials for Windows
2000, which the company claimed is based on "Windows NT technology".
Or you did not know that the NT used to stand for "New Technology".
Yea, it was a lame joke.  ;-)

-- 
Shawn.

Re: GIT 1.5.0 binary installer available.

[Marco Costalba]

On 2/16/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> One problem that I had with the last version of qgit that I looked at
> was creating commits was sort of a secondary operation in the UI.
> It very much felt like that feature was bolted onto the side,
> and was a second class citizen.  The primary focus of the UI was
> showing the graphical history.  Which is fine if that's what your
> primary task is.  But its not for everyone I know.
>

Yes commit in qgit is very simple: check files you want to commit,
write commit message and press a button. That's all. In case you are
on a StGIT repo it will create a patch / push on top of current patch
instead.

qgit commit is definitely not for hardcore use but for a developer
that just want to save and document his job. For anything outside the
*main path* you need something else [1]. qgit is not THE git GUI
interface and IMHO it is good like this. Why?

- Easy to use for first time user approaching git (Linux and Windows)

- Easy and quick for the most common browsing/committing/ patch
export-import tasks.

- No git 'slang/glossary' required

- No deeply understanding of git main concepts required (index-merging-etc...)

So in the conquer of the SCM world by git, I see qgit as a 'git
advertising tool', it is instrumental in spreading git use among the
big part of developers that never tried/know our wonderful 'stupid
content tracker' and could be potentially scared by a frontal approach
to 'git help --all' output.

I imagine qgit at the 'entry level' of the long, and at times steep,
git learning curve.


Marco


[1] BTW for any command not supported you could use the IMHO powerful
and flexible 'custom action' paradigm, where you can associate a
custom menu entry to *any* kind of command/script you can imagine
(also with parameter passing!). As an example, in my private branch I
have created custom actions like:

- make
- make install
- git pull
- merge <branch name>

And few scripts too.

This lets qgit interface to stay simple, and on the other side allows
the user to quickly run also very complex or very uncommon git
commands. Given the sheer number of git commands times git commands
options (and counting ;-) I had no better idea then 'custom actions'
to keep it simple and at the same time potentially command complete
for any git user.

Re: MinGW port updated to GIT 1.5.0

[Junio C Hamano]

Johannes Sixt <J.Sixt@eudaptics.com> writes:

> .... The general idea is to extend the meaning of
> `core.filemode = false` to check out symbolic links as plain files. Any
> hints about where the source code needs changes are welcome.

grep for "if (S_ISLNK(mode))", see if it talks about the mode we
put (either in tree object or index) and if so they are the
places you want them to pretend that you got a regular file.

For example, builtin-apply.c::try_create_file() is one.  This
writes out "git apply" result (so "am" and "rebase" are affected
with this).  entry.c::write_entry() is another.  This writes
things out of the index and used by "checkout-index" and
"read-tree -u".

Re: MinGW port updated to GIT 1.5.0

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Johannes Sixt <J.Sixt@eudaptics.com> writes:
>
>> .... The general idea is to extend the meaning of
>> `core.filemode = false` to check out symbolic links as plain files. Any
>> hints about where the source code needs changes are welcome.

I might have misread the above but I do not think linking
core.filemode and the symlink munging is the right way.  Another
per-repository core.symlink = yes/no (which defaults to yes for
others and no on filesystems without symlinks) would be more
appropriate, as it allows Cygwin to continue using symlinks
where it can, and UNIX folks to try it out.

I take by "checking out as plain files" you mean instead of
calling symlink(2) you would write(2) it out.

I think that would be Ok from git's side.  Just like we use
executable bit from the index to "fix" what we read from the
filesystem (e.g. look for trust_executable_bit in diff-lib.c)
when core.filemode is set, you would munge st.st_mode and
pretend as if your lstat() said "RelNotes", which should be a
symlink but you checked out as a regular file, said it is a
symlink, using what is in the index.

However, I am not so sure if we can do better to help Windows
people.  They have what they call "ShortCut", which to me feels
like what they use for what symlinks are used for.  I do not
know if it is possible (I do not even know doing so would make
life easier for Windows people) but perhaps a symlink can be
"checked out" as a ShortCut?

I suspect reading side would become too complex and slow if the
shortcut needs to be named differently from the real name
(e.g. "RelNotes" needs to be checked out as "RelNotes.lnk" or
something silly like that), so if that is the case, please
forget about this useless suggestion.

Re: MinGW port updated to GIT 1.5.0

[Johannes Schindelin]

Hi,

On Thu, 15 Feb 2007, Junio C Hamano wrote:

> However, I am not so sure if we can do better to help Windows people.  
> They have what they call "ShortCut", which to me feels like what they 
> use for what symlinks are used for.  I do not know if it is possible (I 
> do not even know doing so would make life easier for Windows people) but 
> perhaps a symlink can be "checked out" as a ShortCut?

This is exactly what Cygwin does. They revers-engineered the format of 
.lnk files.

I am not so sure if it is worth the effort, though, since .lnk files are 
handled as files even from Windows. At some point we have to admit that 
Windows does not love symlinks, and we don't love Windows.

Ciao,
Dscho

Re: MinGW port updated to GIT 1.5.0

[Robin Rosenberg]

torsdag 15 februari 2007 19:59 skrev Junio C Hamano:
> Junio C Hamano <junkio@cox.net> writes:
> 
> > Johannes Sixt <J.Sixt@eudaptics.com> writes:
> >
> >> .... The general idea is to extend the meaning of
> >> `core.filemode = false` to check out symbolic links as plain files. Any
> >> hints about where the source code needs changes are welcome.
> 
> I might have misread the above but I do not think linking
> core.filemode and the symlink munging is the right way.  Another
> per-repository core.symlink = yes/no (which defaults to yes for
> others and no on filesystems without symlinks) would be more
> appropriate, as it allows Cygwin to continue using symlinks
> where it can, and UNIX folks to try it out.
> 
> I take by "checking out as plain files" you mean instead of
> calling symlink(2) you would write(2) it out.
> 
> I think that would be Ok from git's side.  Just like we use
> executable bit from the index to "fix" what we read from the
> filesystem (e.g. look for trust_executable_bit in diff-lib.c)
> when core.filemode is set, you would munge st.st_mode and
> pretend as if your lstat() said "RelNotes", which should be a
> symlink but you checked out as a regular file, said it is a
> symlink, using what is in the index.
> 
> However, I am not so sure if we can do better to help Windows
> people.  They have what they call "ShortCut", which to me feels
> like what they use for what symlinks are used for.  I do not
> know if it is possible (I do not even know doing so would make
> life easier for Windows people) but perhaps a symlink can be
> "checked out" as a ShortCut?

Since cygwin used shortcuts for exactly this purpose, why not (in principle). 
In practice it is  not the same however, since shortcuts aren't transparent to 
applications. Only apps that explicitly understand shortcuts can make any use 
of the, like the Explorer, and cygwin application since cygwin hide the 
things. The (presumed) lack of support in Win32 for these makes it harder to 
support them. 

A little feared commercial Git "alternative" uses copies and. You 
cannot "check out" a symbolic link, only the "real" file. Depending on how 
you access the repository the copies get updated automatically (virtual file 
system) or through an explicit update command. This is more compatible with
native applications since alla apps can then "read" the symbolic links just as 
if they are normal files. Checking in could be interesting since one has to 
decide which copy to consider, or only consider the one that is checked in as 
a non-link.

Some extra commands like git-ln and git-chmod could help in overcoming some of 
the cross platform obstacles.

-- robin