{"thread":{"id":"6832","subject":"MinGW port updated to GIT 1.5.0","startedAt":"2007-02-15T12:19:33Z","lastAt":"2007-02-16T19:10:16Z","messageCount":12,"participants":["Johannes Sixt","Han-Wen Nienhuys","Junio C Hamano","Johannes Schindelin","Robin Rosenberg","Shawn O. Pearce","Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34706","messageId":"45D44FD5.72299A3A@eudaptics.com","threadId":"6832","inReplyTo":null,"subject":"MinGW port updated to GIT 1.5.0","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-02-15T12:19:33Z","receivedAt":"2007-02-15T12:19:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"I've merged GIT 1.5.0 into the MinGW port. It is available at the usual\nlocation:\n\npull/clone: git://repo.or.cz/git/mingw.git\ngitweb:     http://repo.or.cz/w/git/mingw.git\n\nIt contains an important fix (MinGW specific): Earlier versions could\nsometimes create temporary files read-only instead of read-writable.\n\n\nWARNING!\n\nThe MinGW port does not support symbolic links, but the git.git itself\nnow contains a symbolic link (RelNotes). For this reason, you cannot\nsuccessfully pull this version's \"master\" branch to your Windows box and\nexpect it to work. The \"devel\" branch has the symbolic link removed, so\nit can at least be checked out. For other operations you may enounter an\nerror like this:\n\nbad tree object: 4571d0d1cfb5a4170dfc80e9654228acae295129\n\nI'm working on a solution. The general idea is to extend the meaning of\n`core.filemode = false` to check out symbolic links as plain files. Any\nhints about where the source code needs changes are welcome.\n\n-- Hannes\n"},{"id":"34717","messageId":"45D48FF5.2060800@xs4all.nl","threadId":"6832","inReplyTo":"45D44FD5.72299A3A@eudaptics.com","subject":"GIT 1.5.0 binary installer available.","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-02-15T16:53:09Z","receivedAt":"2007-02-15T16:53:09Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Sixt escreveu:\n> I've merged GIT 1.5.0 into the MinGW port. It is available at the usual\n> location:\n> \n> pull/clone: git://repo.or.cz/git/mingw.git\n> gitweb:     http://repo.or.cz/w/git/mingw.git\n> \n> It contains an important fix (MinGW specific): Earlier versions could\n> sometimes create temporary files read-only instead of read-writable.\n\nI've uploaded a binary installer to\n\nhttp://lilypond.org/git/binaries/mingw/\n\n(untested, and will need magic to get the bash scripts \nworking)\n\n\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"34721","messageId":"7vire3co5s.fsf@assigned-by-dhcp.cox.net","threadId":"6832","inReplyTo":"45D44FD5.72299A3A@eudaptics.com","subject":"Re: MinGW port updated to GIT 1.5.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-15T17:43:11Z","receivedAt":"2007-02-15T17:43:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <J.Sixt@eudaptics.com> writes:\n\n> .... The general idea is to extend the meaning of\n> `core.filemode = false` to check out symbolic links as plain files. Any\n> hints about where the source code needs changes are welcome.\n\ngrep for \"if (S_ISLNK(mode))\", see if it talks about the mode we\nput (either in tree object or index) and if so they are the\nplaces you want them to pretend that you got a regular file.\n\nFor example, builtin-apply.c::try_create_file() is one.  This\nwrites out \"git apply\" result (so \"am\" and \"rebase\" are affected\nwith this).  entry.c::write_entry() is another.  This writes\nthings out of the index and used by \"checkout-index\" and\n\"read-tree -u\".\n"},{"id":"34722","messageId":"7v7iujckmv.fsf@assigned-by-dhcp.cox.net","threadId":"6832","inReplyTo":"7vire3co5s.fsf@assigned-by-dhcp.cox.net","subject":"Re: MinGW port updated to GIT 1.5.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-15T18:59:20Z","receivedAt":"2007-02-15T18:59:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Johannes Sixt <J.Sixt@eudaptics.com> writes:\n>\n>> .... The general idea is to extend the meaning of\n>> `core.filemode = false` to check out symbolic links as plain files. Any\n>> hints about where the source code needs changes are welcome.\n\nI might have misread the above but I do not think linking\ncore.filemode and the symlink munging is the right way.  Another\nper-repository core.symlink = yes/no (which defaults to yes for\nothers and no on filesystems without symlinks) would be more\nappropriate, as it allows Cygwin to continue using symlinks\nwhere it can, and UNIX folks to try it out.\n\nI take by \"checking out as plain files\" you mean instead of\ncalling symlink(2) you would write(2) it out.\n\nI think that would be Ok from git's side.  Just like we use\nexecutable bit from the index to \"fix\" what we read from the\nfilesystem (e.g. look for trust_executable_bit in diff-lib.c)\nwhen core.filemode is set, you would munge st.st_mode and\npretend as if your lstat() said \"RelNotes\", which should be a\nsymlink but you checked out as a regular file, said it is a\nsymlink, using what is in the index.\n\nHowever, I am not so sure if we can do better to help Windows\npeople.  They have what they call \"ShortCut\", which to me feels\nlike what they use for what symlinks are used for.  I do not\nknow if it is possible (I do not even know doing so would make\nlife easier for Windows people) but perhaps a symlink can be\n\"checked out\" as a ShortCut?\n\nI suspect reading side would become too complex and slow if the\nshortcut needs to be named differently from the real name\n(e.g. \"RelNotes\" needs to be checked out as \"RelNotes.lnk\" or\nsomething silly like that), so if that is the case, please\nforget about this useless suggestion.\n"},{"id":"34724","messageId":"Pine.LNX.4.63.0702151954480.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6832","inReplyTo":"45D48FF5.2060800@xs4all.nl","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T19:11:19Z","receivedAt":"2007-02-15T19:11:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Sixt escreveu:\n> > I've merged GIT 1.5.0 into the MinGW port. It is available at the usual\n> > location:\n> > \n> > pull/clone: git://repo.or.cz/git/mingw.git\n> > gitweb:     http://repo.or.cz/w/git/mingw.git\n> > \n> > It contains an important fix (MinGW specific): Earlier versions could\n> > sometimes create temporary files read-only instead of read-writable.\n> \n> I've uploaded a binary installer to\n> \n> http://lilypond.org/git/binaries/mingw/\n> \n> (untested, and will need magic to get the bash scripts \n> working)\n\nYes, indeed. And not only the bash scripts: AFAICT the command line option \nparsing is borked: whatever I do, a\n\n\tsh -c \"git-config -l\"\n\nfrom cmd does not pick up the option \"-l\". Which is funny, since a simple \ntest program (outputting just the options passed to it) works. And so does \n\"git-config -l\" from \"cmd\".\n\nCould you please try making an installer which includes an exe for this \nsimple program?\n\n-- snip --\n#include <stdio.h>\n\nint main(int argc, char **argv)\n{\n        int i;\n\n        for (i = 0; i < argc; i++)\n                printf(\"arg %d: %s\\n\", i, argv[i]);\n        return 0;\n}\n-- snap --\n\nOther than that, I'd go the git-gui way. For this, not only many of the \ntools in MinGW (such as cat, expr, etc., and maybe even perl) are needed, \nbut also a wish. Happily, you can download that just fine:\n\nhttp://prdownloads.sf.net/mingw/tcltk-8.4.1-1.exe?download\n\nI already made a minimal change to git-gui so you can choose the directory \nto start from.\n\nCiao,\nDscho\n"},{"id":"34725","messageId":"Pine.LNX.4.63.0702152012490.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6832","inReplyTo":"7v7iujckmv.fsf@assigned-by-dhcp.cox.net","subject":"Re: MinGW port updated to GIT 1.5.0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T19:14:17Z","receivedAt":"2007-02-15T19:14:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Junio C Hamano wrote:\n\n> However, I am not so sure if we can do better to help Windows people.  \n> They have what they call \"ShortCut\", which to me feels like what they \n> use for what symlinks are used for.  I do not know if it is possible (I \n> do not even know doing so would make life easier for Windows people) but \n> perhaps a symlink can be \"checked out\" as a ShortCut?\n\nThis is exactly what Cygwin does. They revers-engineered the format of \n.lnk files.\n\nI am not so sure if it is worth the effort, though, since .lnk files are \nhandled as files even from Windows. At some point we have to admit that \nWindows does not love symlinks, and we don't love Windows.\n\nCiao,\nDscho\n"},{"id":"34726","messageId":"200702152041.31220.robin.rosenberg.lists@dewire.com","threadId":"6832","inReplyTo":"7v7iujckmv.fsf@assigned-by-dhcp.cox.net","subject":"Re: MinGW port updated to GIT 1.5.0","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-02-15T19:41:31Z","receivedAt":"2007-02-15T19:41:31Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 15 februari 2007 19:59 skrev Junio C Hamano:\n> Junio C Hamano <junkio@cox.net> writes:\n> \n> > Johannes Sixt <J.Sixt@eudaptics.com> writes:\n> >\n> >> .... The general idea is to extend the meaning of\n> >> `core.filemode = false` to check out symbolic links as plain files. Any\n> >> hints about where the source code needs changes are welcome.\n> \n> I might have misread the above but I do not think linking\n> core.filemode and the symlink munging is the right way.  Another\n> per-repository core.symlink = yes/no (which defaults to yes for\n> others and no on filesystems without symlinks) would be more\n> appropriate, as it allows Cygwin to continue using symlinks\n> where it can, and UNIX folks to try it out.\n> \n> I take by \"checking out as plain files\" you mean instead of\n> calling symlink(2) you would write(2) it out.\n> \n> I think that would be Ok from git's side.  Just like we use\n> executable bit from the index to \"fix\" what we read from the\n> filesystem (e.g. look for trust_executable_bit in diff-lib.c)\n> when core.filemode is set, you would munge st.st_mode and\n> pretend as if your lstat() said \"RelNotes\", which should be a\n> symlink but you checked out as a regular file, said it is a\n> symlink, using what is in the index.\n> \n> However, I am not so sure if we can do better to help Windows\n> people.  They have what they call \"ShortCut\", which to me feels\n> like what they use for what symlinks are used for.  I do not\n> know if it is possible (I do not even know doing so would make\n> life easier for Windows people) but perhaps a symlink can be\n> \"checked out\" as a ShortCut?\n\nSince cygwin used shortcuts for exactly this purpose, why not (in principle). \nIn practice it is  not the same however, since shortcuts aren't transparent to \napplications. Only apps that explicitly understand shortcuts can make any use \nof the, like the Explorer, and cygwin application since cygwin hide the \nthings. The (presumed) lack of support in Win32 for these makes it harder to \nsupport them. \n\nA little feared commercial Git \"alternative\" uses copies and. You \ncannot \"check out\" a symbolic link, only the \"real\" file. Depending on how \nyou access the repository the copies get updated automatically (virtual file \nsystem) or through an explicit update command. This is more compatible with\nnative applications since alla apps can then \"read\" the symbolic links just as \nif they are normal files. Checking in could be interesting since one has to \ndecide which copy to consider, or only consider the one that is checked in as \na non-link.\n\nSome extra commands like git-ln and git-chmod could help in overcoming some of \nthe cross platform obstacles.\n\n-- robin\n"},{"id":"34727","messageId":"Pine.LNX.4.63.0702152034300.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6832","inReplyTo":"Pine.LNX.4.63.0702151954480.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-15T19:52:34Z","receivedAt":"2007-02-15T19:52:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Johannes Schindelin wrote:\n\n> Yes, indeed. And not only the bash scripts: AFAICT the command line option \n> parsing is borked: whatever I do, a\n> \n> \tsh -c \"git-config -l\"\n> \n> from cmd does not pick up the option \"-l\".\n\nI know now why it does not work. Somehow the PATH gets reset all the time. \nWill investigate further.\n\nCiao,\nDscho\n"},{"id":"34728","messageId":"20070215201249.GA27526@spearce.org","threadId":"6832","inReplyTo":"Pine.LNX.4.63.0702151954480.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-15T20:12:49Z","receivedAt":"2007-02-15T20:12:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> I already made a minimal change to git-gui so you can choose the directory \n> to start from.\n\nDo post, when ready.  ;-)\n\n-- \nShawn.\n"},{"id":"34765","messageId":"Pine.LNX.4.63.0702160517390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6832","inReplyTo":"20070215201249.GA27526@spearce.org","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-16T04:23:35Z","receivedAt":"2007-02-16T04:23:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Feb 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > I already made a minimal change to git-gui so you can choose the directory \n> > to start from.\n> \n> Do post, when ready.  ;-)\n\nATM it looks like this:\n\n-- snip --\n git-gui/git-gui.sh |    5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh\nindex f5010dd..ed5cd82 100755\n--- a/git-gui/git-gui.sh\n+++ b/git-gui/git-gui.sh\n@@ -291,6 +291,11 @@ proc ask_popup {msg} {\n ##\n ## repository setup\n \n+if { [is_Windows] && ![is_Cygwin] } {\n+\tset repo_dir [tk_chooseDirectory -title \"Choose a Git repository\" -mustexist 1]\n+\tcd $repo_dir\n+}\n+\n if {   [catch {set _gitdir $env(GIT_DIR)}]\n \t&& [catch {set _gitdir [exec git rev-parse --git-dir]} err]} {\n \tcatch {wm withdraw .}\n-- snap --\n\nHowever, I am still wondering what to make of the silly behaviour I \nobserved earlier: the PATH was forgotten either by \"sh\" being called from \n\"cmd\", or by \"wish84\" being called from \"sh\".\n\nBut the strangest part about it: if I replaced the program names with \ntheir absolute path, then the command line options would _not_ be ignored. \nStrange.\n\nIf I get that fsck up fixed, I'd like to work with Han-Wen on enhancing \nhis installer (which is nice!) with wish, bash, perl, and a shortcut to \ngit-gui in Start Menu/Git/Git GUI.\n\nBTW any news on the integration of gitk in git-gui?\n\nCiao,\nDscho\n"},{"id":"34768","messageId":"20070216050615.GC28894@spearce.org","threadId":"6832","inReplyTo":"Pine.LNX.4.63.0702160517390.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-16T05:06:15Z","receivedAt":"2007-02-16T05:06:15Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> On Thu, 15 Feb 2007, Shawn O. Pearce wrote:\n> > Do post, when ready.  ;-)\n> \n> @@ -291,6 +291,11 @@ proc ask_popup {msg} {\n>  ##\n>  ## repository setup\n>  \n> +if { [is_Windows] && ![is_Cygwin] } {\n> +\tset repo_dir [tk_chooseDirectory -title \"Choose a Git repository\" -mustexist 1]\n> +\tcd $repo_dir\n> +}\n> +\n>  if {   [catch {set _gitdir $env(GIT_DIR)}]\n>  \t&& [catch {set _gitdir [exec git rev-parse --git-dir]} err]} {\n>  \tcatch {wm withdraw .}\n> -- snap --\n\nOK.  I'm thinking though that this should go below the context that\nappears below it.  The reason is, a \"Desktop Icon\" for git-gui embeds\nthe repository path in it by setting up GIT_DIR, so that the user\nreturns to the same repository when launching through that icon.\nIn other words, maybe only prompt the user to select the directory\nif $env(GIT_DIR) was not set?\n \n> However, I am still wondering what to make of the silly behaviour I \n> observed earlier: the PATH was forgotten either by \"sh\" being called from \n> \"cmd\", or by \"wish84\" being called from \"sh\".\n\nI think I can answer this: Tcl (and thus wish too) on Windows does\nnot pass its environment onto its children.  If you poke around\ngit-gui some and look for is_Cygwin you will find some of the places\nwhere we exec something like git-fetch we actually wrap it up in\na login shell, so the user's environment can be correctly loaded\nbefore git-fetch starts.\n\nI think I have also noticed that setting env(PATH) has no effect\non how Tcl searches for an executable when it tries to exec it.\nThe search path appears to only be settable *before* Tcl begins.\n\nUnfortunately these quirks are also in the Cygwin version of\nTcl, as apparently on Windows even the Cygwin version of Tcl uses\nCreateProcess to execute children, rather than the POSIX fork/exec\nthat comes with Cygwin.\n\n> But the strangest part about it: if I replaced the program names with \n> their absolute path, then the command line options would _not_ be ignored. \n> Strange.\n\nReally strange that command line options get ignored, but the\ncommand still runs?  What's up with that?  Ohhhhhh, its one of\nthose new-fangled operating systems that's based on New Technology\nTechnology, isn't it?[*1*].\n\n> If I get that fsck up fixed, I'd like to work with Han-Wen on enhancing \n> his installer (which is nice!) with wish, bash, perl, and a shortcut to \n> git-gui in Start Menu/Git/Git GUI.\n\nThat will really shine when git-gui learns how to do the magic of\ngit-clone.  Maybe in a week or two (basically when I get to it),\nor sooner if someone is interested in doing that themselves.\n \n> BTW any news on the integration of gitk in git-gui?\n\nNone to report.  I've talked with Paul about it by email only\nslightly, but he has reportedly been busy with other tasks and\nhas not had any time lately for gitk, so the conversation wasn't\nvery detailed.\n\nThere's some complicating factors to embedding git-gui into gitk,\nand vice-versa.  I haven't dug into gitk's UI code but I suspect\nit assumes the main graph window is \".\", and that the repository\nhas commits to display.  So I'm not sure how it would react on an\nempty repository (initial commit case), nor do I want gitk's UI to\nstartup when running git-citool.\n\nLikewise git-gui currently assumes the main commit window is \".\"\n(except in the case of \"git gui blame\").\n\nBoth programs assume a lot of globals.  We probably have some\nduplicate names for different variables.\n\nOver the next month or two one goal for me with git-gui is to\nrefactor some of it into multiple files, and to use namespaces\nto seperate the different modules from each other.  This way the\nbranch control UI's globals aren't in the same namespace as the\ncommit window's UI globals.  That would help with embedding git-gui\ninto gitk.\n\nBut from a user interface perspective I'm not sure that's the best\nthing to do.  I cannot quite wrap my head around what a melded\ngit-gui and gitk would look like.  git-gui's primary focus is\nviewing the status of the working directory, switching branches,\nmerging, transport (fetch/push) and making commits.  gitk's primary\nfocus is looking at history.  I don't know about you, but I commit,\npush, fetch and merge a hellva lot more than I look at history.\n\nOne problem that I had with the last version of qgit that I looked at\nwas creating commits was sort of a secondary operation in the UI.\nIt very much felt like that feature was bolted onto the side,\nand was a second class citizen.  The primary focus of the UI was\nshowing the graphical history.  Which is fine if that's what your\nprimary task is.  But its not for everyone I know.\n\n\n[*1*] If you didn't get that joke, you must not have had enough\nchances to poke fun at Microsoft's marketing materials for Windows\n2000, which the company claimed is based on \"Windows NT technology\".\nOr you did not know that the NT used to stand for \"New Technology\".\nYea, it was a lame joke.  ;-)\n\n-- \nShawn.\n"},{"id":"34822","messageId":"e5bfff550702161110x3507da82v1820bca9d4e37bc1@mail.gmail.com","threadId":"6832","inReplyTo":"20070216050615.GC28894@spearce.org","subject":"Re: GIT 1.5.0 binary installer available.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-16T19:10:16Z","receivedAt":"2007-02-16T19:10:16Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/16/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n>\n> One problem that I had with the last version of qgit that I looked at\n> was creating commits was sort of a secondary operation in the UI.\n> It very much felt like that feature was bolted onto the side,\n> and was a second class citizen.  The primary focus of the UI was\n> showing the graphical history.  Which is fine if that's what your\n> primary task is.  But its not for everyone I know.\n>\n\nYes commit in qgit is very simple: check files you want to commit,\nwrite commit message and press a button. That's all. In case you are\non a StGIT repo it will create a patch / push on top of current patch\ninstead.\n\nqgit commit is definitely not for hardcore use but for a developer\nthat just want to save and document his job. For anything outside the\n*main path* you need something else [1]. qgit is not THE git GUI\ninterface and IMHO it is good like this. Why?\n\n- Easy to use for first time user approaching git (Linux and Windows)\n\n- Easy and quick for the most common browsing/committing/ patch\nexport-import tasks.\n\n- No git 'slang/glossary' required\n\n- No deeply understanding of git main concepts required (index-merging-etc...)\n\nSo in the conquer of the SCM world by git, I see qgit as a 'git\nadvertising tool', it is instrumental in spreading git use among the\nbig part of developers that never tried/know our wonderful 'stupid\ncontent tracker' and could be potentially scared by a frontal approach\nto 'git help --all' output.\n\nI imagine qgit at the 'entry level' of the long, and at times steep,\ngit learning curve.\n\n\nMarco\n\n\n[1] BTW for any command not supported you could use the IMHO powerful\nand flexible 'custom action' paradigm, where you can associate a\ncustom menu entry to *any* kind of command/script you can imagine\n(also with parameter passing!). As an example, in my private branch I\nhave created custom actions like:\n\n- make\n- make install\n- git pull\n- merge <branch name>\n\nAnd few scripts too.\n\nThis lets qgit interface to stay simple, and on the other side allows\nthe user to quickly run also very complex or very uncommon git\ncommands. Given the sheer number of git commands times git commands\noptions (and counting ;-) I had no better idea then 'custom actions'\nto keep it simple and at the same time potentially command complete\nfor any git user.\n"}]}