{"thread":{"id":"9981","subject":"The msysGit Herald, issue 2","startedAt":"2007-09-23T20:54:42Z","lastAt":"2007-09-24T16:49:03Z","messageCount":6,"participants":["Johannes Schindelin","Shawn O. Pearce","Linus Torvalds","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53855","messageId":"Pine.LNX.4.64.0709232153230.28395@racer.site","threadId":"9981","inReplyTo":null,"subject":"The msysGit Herald, issue 2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-23T20:54:42Z","receivedAt":"2007-09-23T20:54:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Good morning git land!\n\nThis lovely afternoon in St Andrews is as good an occasion as any to issue\na new incarnation of the msysGit Herald, the not-quite-biweekly news letter\nto keep you informed about msysGit, the effort to bring one of the most\npowerful Source Code Management systems to the poor souls stuck with\nWindows.\n\nThese are the covered topics:\n\n\tWinGit 0.2\n\n\tWhat will be in WinGit 0.3?\n\n\tWe're getting famous in China\n\n\tCompiling Perl from scratch\n\n\tTime for a new console?\n\n\tInterview with Johannes \"Mr mingw.git\" Sixt\n\n\tStill no concrete mingw/git.git merge plans yet\n\n\nWinGit 0.2\n==========\n\nBy mistake, Perl was not properly installed with version 0.1 of WinGit.\nThis is the most visible part that was fixed in 0.2.\n\nHowever, in the meantime we got our \"Issue\" list (see home page) cut\nalmost in half.  Which means that we are mostly stuck with the hard\nproblems ;-)\n\nWhat will be in WinGit 0.3\n=========================\n\nWhat will be in 0.3?  We have a proper uninstaller now.  Yes, that means\nthat \"Git\" will be in the \"Add/Remove Software\" list.\n\nAlso, curl, termcap, the completions, sh-add, and git-gui are actually\ninstalled.\n\nMaybe we'll get to the state where a link to git gui is installed in\naddition to the \"Git Shell\", maybe we'll succeed in merging 1.5.3.2?\n\nWho knows... ;-)\n\n\nWe're getting famous in China\n=============================\n\nApparently, there is a blog talking (amongst other things, like the\nunfamous language flame war) about \"Git on Windows\" in China:\n\nhttp://blog.csdn.net/turingbook/archive/2007/09/07/1775488.aspx\n\nI am dyslexic when it comes to Chinese, but we got some hits from\nthere...\n\n\nCompiling Perl from scratch\n===========================\n\nWe have an open issue called \"Install scripts do not install perl modules\nfor git-svn\" (Issue 42).  Unfortunately, it is not really as easy as\nthat...\n\nThe Perl version we have does not come with valid MakeMaker information,\nand we are therefore unable to compile modules for Perl (even something\nas dirt-simple as Digest::MD5 does not work).\n\nSo we tried to compile Perl from scratch -- which opened another can of\nworms.  It was not a problem at all to compile Perl for _MinGW_.  Which\nmeans that the resulting binary does not have any clue about the MSys\nenvironment (think Unix style paths, and (worse!) no shell scripts).\n\nAn option would be to not care, and decouple Perl from MSys.  Another\noption would be to get Perl compiled & linked to msys-1.0.dll.\n\nThis issue is not resolved yet.\n\n\nTime for a new console?\n=======================\n\nThe first publically available version of msysGit recommended Rxvt, until\nI realised that there were strange stderr/stdout issues, which prevented\n-- among other things -- the pager and ssh transport from working.\n\nSo we reverted back to cmd as the Terminal, which has its own set of\nshortcomings (does not do ANSI well, has Control-C issues, and the\nmulti-line selection being a rectangular box is outright annoying, as\nwell as the missing Shift+Insert binding to paste the clipboard).\n\nNow, compiling (and possibly fixing) Rxvt seems to be out of reach for the\nmoment, but Marius Storm-Olsen found the \"Console\" project:\n\n\thttp://sourceforge.net/projects/console\n\nUnfortunately, this project does not work on Windows 95/98/ME, and I would\nhave liked to retain backwards compatibility (some developers, yours\ntruly included, do not have Windows boxen to develop, so they have to\nresort to emulated ones -- and 2k is a real hog there, opposed to 95).\n\nHowever, since we already rely on the NT based family for our installer,\nthat reason not to use Console seems to fall on the floor.\n\nWe would need to work on it, though: ATM it has problems with selections,\nand recompiling is made difficult by the ATL dependency.\n\n\nInterview with Johannes \"Mr mingw.git\" Sixt\n===========================================\n\nHannes announced an initial official version of the MinGW port of git on\nJanuary 19th, 2007:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/37202\n\nFor quite some time, he was the only one working on this port.  Most of\nthe smoothness of the msysGit effort is his fault.\n\nSo here, without further ado, the interview:\n\n> 1) How did you get involved with Git?\n\nIn our shop, CVS was used for years. I have been working with patch sets \nbecause it did not allow the workflow that I wanted - namely to construct\na series of changes before making them public.\n\nWhen the news came out that Linus was working on a new VCS, I was\nfollowing its development closely. From the discussions I discovered that\ngit would be the tool that allowed my desired workflow.\n\nIn order to get acquainted with git, I used it on my Linux projects\n(KDbg, Cinelerra).\n\n> 2) What were the reasons that you started working on Git?\n\nIn our shop, which develops software for Windows, the requirement arouse\nto have several different, but related versions of the same product -\nwhich is  a setup that we would not be able to solve with CVS, but it\nwould be a breeze with git.\n\nBut we needed git on Windows. And since I dislike cygwin (for no good\nreason actually), I decided to start the native port of git to Windows\nusing MSYS ang MinGW.\n\n> 3) What do you like most in Git?\n\n- Easy merging with real merge history\n- Massage a series of changes into proper shape before making it public\n\n> 4) What do you hate most in Git?\n\nYou're kiddin'!\n\n> 5) What was the most surprising moment when working with Git?\n\nIt merged a change I made in an old branch in a file that was moved in\nthe new branch to a new location. IOW, merge across renames. Really, I\nwas so surprised - I wanted to start the manual merge when I discovered\nthat git had done all the work for me.\n\n> 6) What was the most frustrating moment when working with Git?\n\nJust the other day, I wanted to fetch a set of changes from a public\nrepo into my test repo in order to cherry-pick from them - and it\nautomatically fetched all the tags. But, the heck, I don't want them tags\nhere, just the commits. I just can't figure out how to avoid the automatic\nfetching of tags.\n\n> 7) In what environment do you work?\n\nLinux (SUSE); Windows 2000, XP.\n\n> 8) What other hobbies do you have?\n\nCuddling the brats and changing nappies - does that count as a hobby?\n\n> 9) What is your favourite movie?\n\nYou think I have time to watch movies?\n\n> 10) What are your visions for Git? (I.e. where do you want it to go?)\n\nSeriously, I'm not a visionair.\n\nOn *nix, git will be perfect when it is able to seamlessly serve the KDE \nsource.\n\nOn Windows, git still has too many problems that we don't need a vision, yet.\n\n-- Hannes\n\n\nStill no concrete mingw/git.git merge plans yet\n===============================================\n\nAs mentioned in the first issue of this news letter, I sent a rather long\nlist of relatively small and well contained projects, that in total would\nmean a complete merge of the mingw/4msysgit port back into git.git:\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/57163\n\nUnfortunately, there have not been any takers (just a few \"would it not\nbe better to have this in git.git\" sayers).\n\nIn related news, it seems to be awfully more common for Windows users than\nfor other people to have the attitude \"I am the user.  You _have_ to help\nme.\"  (Remember that in our case, the users are developers, too, so they\nshould be able to help themselves.)\n\nDo not let yourself fool into thinking that _all_ Windows users are like\nthat.  Just enough to annoy.\n\nHowever, nobody stops changing until eaten by the bugs, so all of those who\nthink \"well, I might be able to do a small thing, just to prove that\nbastard wrong\": follow the above link, read the mail (you can even just\nrandomly jump around, and only read parts of it), pick a target, and say so\non the msysGit mailing list (msysgit@googlegroups.com).\n"},{"id":"53885","messageId":"20070924024828.GE3099@spearce.org","threadId":"9981","inReplyTo":"Pine.LNX.4.64.0709232153230.28395@racer.site","subject":"Re: The msysGit Herald, issue 2","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-24T02:48:28Z","receivedAt":"2007-09-24T02:48:28Z","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> \n> Maybe we'll get to the state where a link to git gui is installed in\n> addition to the \"Git Shell\"\n\nI'm hoping that becomes possible as part of the 0.9.x series of\ngit-gui.  My latest master branch in git-gui.git contains a new\nstartup wizard that can be used to do one of three common actions:\n\n  - Clone a repository\n  - Create a new repository\n  - Open an existing repository\n\nDscho has already seen this wizard.  Its certainly meant to help\nwith linking to git-gui from \"Begin\" menus on systems that probably\nshould have been called \"Wide Open Doors\" (given their security\ntrack record).  Currently the only way to get the wizard to launch\nis to run `git gui` from a pwd that isn't contained within a Git\nrepository.\n \n> > 5) What was the most surprising moment when working with Git?\n> \n> It merged a change I made in an old branch in a file that was moved in\n> the new branch to a new location. IOW, merge across renames. Really, I\n> was so surprised - I wanted to start the manual merge when I discovered\n> that git had done all the work for me.\n\nHeh.  That always gets me too.  Especially when applying git-gui\npatches made against git.git, but to my git-gui tree.  `git-am -3`\nJust Does The Right Thing(tm).  I can't ask for more from a source\ncode control system.\n \n> > 6) What was the most frustrating moment when working with Git?\n> \n> Just the other day, I wanted to fetch a set of changes from a public\n> repo into my test repo in order to cherry-pick from them - and it\n> automatically fetched all the tags. But, the heck, I don't want them tags\n> here, just the commits. I just can't figure out how to avoid the automatic\n> fetching of tags.\n\nIts called `git fetch --no-tags`.  You can also setup a config\noption of \"remote.$name.tagopt = --no-tags\" to tell git-fetch to\nnot fetch tags when fetching from that remote.\n\nBut yea, I too hate the fact that Git cannot read my mind and realize\nthat although I usually do want to fetch tags, right now I don't,\neven though I forgot to tell it that with --no-tags.  :)\n\nSo my most frustrating moment when working with Git was realizing\nthat Linus didn't supply `git-read-users-mind`.  Sadly it only\ncomes with `git-read-tree`.  Ah, well, at least my maple and pine\nare understood.\n \n-- \nShawn.\n"},{"id":"53926","messageId":"alpine.LFD.0.999.0709240840310.3579@woody.linux-foundation.org","threadId":"9981","inReplyTo":"Pine.LNX.4.64.0709232153230.28395@racer.site","subject":"Re: The msysGit Herald, issue 2","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-09-24T15:44:49Z","receivedAt":"2007-09-24T15:44:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 23 Sep 2007, Johannes Schindelin wrote:\n>\n> > 6) What was the most frustrating moment when working with Git?\n> \n> Just the other day, I wanted to fetch a set of changes from a public\n> repo into my test repo in order to cherry-pick from them - and it\n> automatically fetched all the tags. But, the heck, I don't want them tags\n> here, just the commits. I just can't figure out how to avoid the automatic\n> fetching of tags.\n\nThe way this was *supposed* to work is that if you are not fetching a \n\"tracking branch\", it should not fetch any tags.\n\nMaybe this got broken lately?\n\nOr maybe you did fetch a tracking branch?\n\nAnyway, I fetch stuff all the time, and if git were to fetch the tags too, \nI'd be *really* unhappy. So either the people I work with are just good \npeople, or more likely it still works the way it's supposed to work: if \nyou just fetch into FETCH_HEAD (by explicitly giving the remote repository \nname, and not using tracking branches), it should not fetch tags for you.\n\n\t\t\tLinus\n"},{"id":"53927","messageId":"46F7E2A5.6030202@eudaptics.com","threadId":"9981","inReplyTo":"alpine.LFD.0.999.0709240840310.3579@woody.linux-foundation.org","subject":"Re: The msysGit Herald, issue 2","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-09-24T16:15:33Z","receivedAt":"2007-09-24T16:15:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Linus Torvalds schrieb:\n> \n> On Sun, 23 Sep 2007, Johannes Schindelin wrote:\n>>> 6) What was the most frustrating moment when working with Git?\n>> Just the other day, I wanted to fetch a set of changes from a public\n>> repo into my test repo in order to cherry-pick from them - and it\n>> automatically fetched all the tags. But, the heck, I don't want them tags\n>> here, just the commits. I just can't figure out how to avoid the automatic\n>> fetching of tags.\n> \n> The way this was *supposed* to work is that if you are not fetching a \n> \"tracking branch\", it should not fetch any tags.\n> \n> Maybe this got broken lately?\n> \n> Or maybe you did fetch a tracking branch?\n\nI don't think I fetched a tracking branch. If I do:\n\n    $ mkdir foo && cd foo && git init\n    $ git fetch ../git master:refs/heads/master\n\n(where ../git is a clone of git.git with a few local changes), I get all the \ntags. Good or bad?\n\n-- Hannes\n"},{"id":"53929","messageId":"Pine.LNX.4.64.0709241731510.28395@racer.site","threadId":"9981","inReplyTo":"46F7E2A5.6030202@eudaptics.com","subject":"Re: The msysGit Herald, issue 2","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-24T16:32:12Z","receivedAt":"2007-09-24T16:32:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 24 Sep 2007, Johannes Sixt wrote:\n\n> Linus Torvalds schrieb:\n> > \n> > On Sun, 23 Sep 2007, Johannes Schindelin wrote:\n> > > > 6) What was the most frustrating moment when working with Git?\n> > > Just the other day, I wanted to fetch a set of changes from a public\n> > > repo into my test repo in order to cherry-pick from them - and it\n> > > automatically fetched all the tags. But, the heck, I don't want them tags\n> > > here, just the commits. I just can't figure out how to avoid the\n> > > automatic\n> > > fetching of tags.\n> > \n> > The way this was *supposed* to work is that if you are not fetching a\n> > \"tracking branch\", it should not fetch any tags.\n> > \n> > Maybe this got broken lately?\n> > \n> > Or maybe you did fetch a tracking branch?\n> \n> I don't think I fetched a tracking branch. If I do:\n> \n>    $ mkdir foo && cd foo && git init\n>    $ git fetch ../git master:refs/heads/master\n> \n> (where ../git is a clone of git.git with a few local changes), I get all the\n> tags. Good or bad?\n\nThe \":refs/heads/master\" part says that you fetch into a tracking branch.\n\nCiao,\nDscho\n"},{"id":"53932","messageId":"7v1wcoau0w.fsf@gitster.siamese.dyndns.org","threadId":"9981","inReplyTo":"46F7E2A5.6030202@eudaptics.com","subject":"Re: The msysGit Herald, issue 2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-24T16:49:03Z","receivedAt":"2007-09-24T16:49:03Z","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> Linus Torvalds schrieb:\n>\n>> ...\n>> Or maybe you did fetch a tracking branch?\n>\n> I don't think I fetched a tracking branch. If I do:\n>\n>    $ mkdir foo && cd foo && git init\n>    $ git fetch ../git master:refs/heads/master\n>\n> (where ../git is a clone of git.git with a few local changes), I get\n> all the tags. Good or bad?\n\nThat's exactly Linus meant \"fetching a tracking branch\".  Your\nrefspec has non-empty string on the RHS of the colon.\n\n\t$ git fetch ../git master\n\nis the form without tracking.  IOW, not storing into your refs\nnamespace.\n"}]}