{"thread":{"id":"17462","subject":"[ANNOUNCE] EasyGit (eg) 0.97","startedAt":"2009-01-30T16:42:00Z","lastAt":"2009-01-31T07:25:36Z","messageCount":10,"participants":["Elijah Newren","Mike Ralphson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"102620","messageId":"51419b2c0901300842rb993454u7e8b6d1032c12ac8@mail.gmail.com","threadId":"17462","inReplyTo":null,"subject":"[ANNOUNCE] EasyGit (eg) 0.97","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-01-30T16:42:00Z","receivedAt":"2009-01-30T16:42:00Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"=== What is Easy Git? ===\n\nEasy Git (eg) is an alternative frontend for git, specifically designed for\nformer cvs and svn users in order to provide a lower learning curve and\nprevent common user errors. Since eg largely looks and feels like core\ngit, eg can also serve as a training tool to teach users git (see below for\nsimilarities and how to display git commands that eg uses). There is a\ndetailed side-by-side comparison of svn and eg to help svn users make the\nswitch[1]. eg is trivial to install and try out: simply download a single\nfile and stick it in your PATH[2].\n\n=== How different is eg from git? ===\n\neg is nearly backward-compatible to the core git porcelain, meaning that\nyou can take any git command, replace \"git\" with \"eg\" and run it[3]; I\nbelieve that any behavioral differences between eg and git can be\ndiscovered naturally and innocuously by an existing git user during normal\nuse of eg. Also, you can switch back and forth between git and eg commands\nin the same project. Finally, eg is also somewhat forward-compatible with\nthe git porcelain, by which I mean that new flags to git commands are often\nsupported automatically in eg even if no modifications are made to eg.\n\n=== If eg is so similar, what is the difference between eg and git? ===\n\nDifferences between eg and git[4] basically boil down to:\n* eg has a replacement help system that is tutorial oriented for new users\n (these help pages do refer to the git manpages, for more in-depth details)\n* eg does extra error checking to avoid some common gotchas\n* eg changes some defaults, particularly where git defaults cause\n significant confusion and/or common gotchas for users\n* eg has some (occasionally gratuitous) new svn-compatibility subcommands\n (cat, resolved, switch, update)\n\n=== How far along is eg? ===\n\neg is essentially complete and has been for a while; I've used it daily\nsince last February, and there are multiple other users who do as well.\nI've even benefitted from having some users who barely grasp the basics of\nCVS who have tried eg and provided feedback (\"[utterly broken workflow] is\nwhat I do in CVS! To figure out how to do that in eg I had to go _read_\nsome of the help pages -- why can't you make it easy?\")\n\neg has just one major bug left that I know of[5]; otherwise it's\nessentially 1.0. eg requires fairly minimal maintainance -- most new\ncapabilities in git are automatically accessible through eg due to eg's\ndesign of passing arguments on to git after optionally massaging them or\ndoing extra checks. In fact, this design also means eg users can benefit\nfrom documentation meant for core git, and that eg users should often be\nable to get help from git users without git users really needing to learn a\ndifferent UI. On the downside, this design also means that (a) eg feels\nlike an incomplete solution (\"why does this message suggest running 'git\nrebase --continue' when I'm using eg rather than git?\"), and (b) eg's\ninterface is not simplified as much as it could be by focusing on a\nspecific use-case (e.g. centralized development) or providing a more\northogonal UI[6]. It does, however, ease transition between the two tools\nand potentially provide a testbed for ideas that could be adopted by git\nmore easily.\n\n=== What's the path forward? ===\n\nI have no idea. It turns out that eg allowed me to overcome the concerns\nof others at work that \"git was too difficult to use\", and was an important\npart of convincing them to switch to git instead of svn (we're stuck with\nCVS right now but are working on switching). So eg won't die, unless git\nitself adopts enough of the improvements in eg. And really, some stuff\nfrom eg may just not belong in git, so it may make sense to have an\nindependent script indefinitely (though it could certainly be made much\nsmaller).\n\nWhat makes sense to the community? Some possibilities:\n* Keep working on eg completely independently\n* Propose eg (and perhaps eg-completion.bash) for contrib\n* Start a series of discussions on individual changes from eg and see which\n ones the community thinks make sense in git\n* Have me stop being lazy and create patches for git as a basis of\n discussion\n* Let the crickets chirp (i.e. just ignore this weird Easy Git guy)\n* Some combination of the above, or maybe something else entirely?\n\n\n\nElijah\n\n\n[1] http://www.gnome.org/~newren/eg/git-for-svn-users.html\n[2] http://www.gnome.org/~newren/eg/download, or\n[3] If you're curious if/how/when eg changes arguments before passing them\nto git, you can run \"eg --debug ARGS...\" to see the git commands eg is\nrunning. If you just want to see the git commands that eg would run\nwithout them also being executed, you can run \"eg --translate ARGS...\"\n[4] For detailed differences, see\nhttp://www.gnome.org/~newren/eg/git-eg-differences.html\n[5] The bug I can only occasionally trigger and which I don't know the\ncause of yet: when exiting from eg log the terminal settings sometimes\nare messed up (with echo off and such), requiring a \"reset\" to get the\nterminal back to normal.\n[6] http://marc.info/?l=git&m=122071366316713&w=1\n"},{"id":"102623","messageId":"e2b179460901300859r438a4230hc990305688b4f29e@mail.gmail.com","threadId":"17462","inReplyTo":"51419b2c0901300842rb993454u7e8b6d1032c12ac8@mail.gmail.com","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-01-30T16:59:26Z","receivedAt":"2009-01-30T16:59:26Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/1/30 Elijah Newren :\n> [5] The bug I can only occasionally trigger and which I don't know the\n> cause of yet: when exiting from eg log the terminal settings sometimes\n> are messed up (with echo off and such), requiring a \"reset\" to get the\n> terminal back to normal.\n\nAre you sure that isn't this bug in git.git ?\n\npager: do wait_for_pager on signal death\nhttp://article.gmane.org/gmane.comp.version-control.git/106728\n\nMike\n"},{"id":"102634","messageId":"51419b2c0901301035g6867b9d8l2d4de9590035bd4e@mail.gmail.com","threadId":"17462","inReplyTo":"e2b179460901300859r438a4230hc990305688b4f29e@mail.gmail.com","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-01-30T18:35:50Z","receivedAt":"2009-01-30T18:35:50Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jan 30, 2009 at 9:59 AM, Mike Ralphson wrote:\n> 2009/1/30 Elijah Newren :\n>> [5] The bug I can only occasionally trigger and which I don't know the\n>> cause of yet: when exiting from eg log the terminal settings sometimes\n>> are messed up (with echo off and such), requiring a \"reset\" to get the\n>> terminal back to normal.\n>\n> Are you sure that isn't this bug in git.git ?\n>\n> pager: do wait_for_pager on signal death\n> http://article.gmane.org/gmane.comp.version-control.git/106728\n\nInteresting. I just went and tried out next (git version\n1.6.1.2.418.gd79e6), which I believe has this patch...and after a\nwhile I was still able to duplicate the eg bug on one of my\nmachines[1]. So it doesn't seem to be that particular issue, at\nleast.\n\nThanks for the pointer.\n\nElijah\n\n\n[1] Output of stty after I trigger the eg/git bug:\nspeed 38400 baud; line=0;\nlnext = ; min = 1; time = 0;\n-icrnl\n-icanon -echo\n"},{"id":"102639","messageId":"20090130194727.GA31927@coredump.intra.peff.net","threadId":"17462","inReplyTo":"51419b2c0901301035g6867b9d8l2d4de9590035bd4e@mail.gmail.com","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T19:47:27Z","receivedAt":"2009-01-30T19:47:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 11:35:50AM -0700, Elijah Newren wrote:\n\n> > 2009/1/30 Elijah Newren :\n> >> [5] The bug I can only occasionally trigger and which I don't know the\n> >> cause of yet: when exiting from eg log the terminal settings sometimes\n> >> are messed up (with echo off and such), requiring a \"reset\" to get the\n> >> terminal back to normal.\n> >\n> > Are you sure that isn't this bug in git.git ?\n> >\n> > pager: do wait_for_pager on signal death\n> > http://article.gmane.org/gmane.comp.version-control.git/106728\n> \n> Interesting. I just went and tried out next (git version\n> 1.6.1.2.418.gd79e6), which I believe has this patch...and after a\n> while I was still able to duplicate the eg bug on one of my\n> machines[1]. So it doesn't seem to be that particular issue, at\n> least.\n\nThere is also a related set of fixes for spawning externals via fork,\nwhich fixes a bug with the pager not getting cleaned up. But it looks\nlike it is also in the version you tested.\n\nCan you give a more complete recipe for reproducing? Since I was just\ntouching this area in git, I want to make sure it isn't a git bug you\nare triggering. :)\n\nAs an aside, I found some related weirdness. In my git repo, if I do\nthis:\n\n $ git checkout next\n $ eg log -p\n\nI get log output, but the diff is not colorized (and I have color.diff\nset to \"auto\" in my ~/.gitconfig). But if I detach my HEAD and show the\nlog:\n\n $ git checkout next^0\n $ eg log -p\n\nthen I _do_ get color in the patch. I also get this error:\n\n Use of uninitialized value $branch in concatenation (.) or string at\n /home/peff/eg line 2854.\n eg: command (git rev-parse refs/heads/) failed\n eg: received signal 13\n\nThe error is easy to explain. The offending code is:\n\n my $branch = RepoUtil::current_branch();\n my ($ret, $revision) =\n ExecUtil::execute_captured(\"git rev-parse refs/heads/$branch\");\n\nSo it is clear that you just need to handle the case of there being no\ncurrent branch. But the color thing is certainly exotic. :)\n\n-Peff\n"},{"id":"102640","messageId":"20090130200307.GA3054@coredump.intra.peff.net","threadId":"17462","inReplyTo":"20090130194727.GA31927@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T20:03:07Z","receivedAt":"2009-01-30T20:03:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 02:47:27PM -0500, Jeff King wrote:\n\n> There is also a related set of fixes for spawning externals via fork,\n> which fixes a bug with the pager not getting cleaned up. But it looks\n> like it is also in the version you tested.\n> \n> Can you give a more complete recipe for reproducing? Since I was just\n> touching this area in git, I want to make sure it isn't a git bug you\n> are triggering. :)\n\nAh, OK. I just peeked through the 'eg' source. It looks like you may\nhave replicated the same bug that I just fixed in git. :)\n\nYou want to make sure that \"eg\" is the last process to die (i.e.,\n_after_ the pager). Otherwise after it dies, less has trouble reading\nfrom the terminal (I don't know for sure, but I assume this has to do\nwith the shell making \"eg\" the process group leader and magic about\nprocess groups and controlling terminals).\n\nI think perl may even do the wait() for you under ordinary\ncircumstances. But, for example, if I kill \"eg\" with a signal (say, by\nhitting ^C), then it will die but the pager will live on. In git, we\ncatch the signal and wait() before dying.\n\nSo I don't know for sure that is your problem (it really depends on how\nmuch magic perl is doing behind the scenes with wait()ing on children,\nand I don't recall the exact details of that). But it is something to\nlook into.\n\nI don't think it's a git problem, though. \"eg log\" doesn't spawn a git\npager, since you pipe the output into eg. The paging is all your local\n\"less\" invocation.\n\n-Peff\n"},{"id":"102642","messageId":"51419b2c0901301221n45cde1abw7a57a13bfa74b34@mail.gmail.com","threadId":"17462","inReplyTo":"20090130194727.GA31927@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-01-30T20:21:00Z","receivedAt":"2009-01-30T20:21:00Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jan 30, 2009 at 12:47 PM, Jeff King wrote:\n> As an aside, I found some related weirdness. In my git repo, if I do\n> this:\n>\n> $ git checkout next\n> $ eg log -p\n>\n> I get log output, but the diff is not colorized (and I have color.diff\n> set to \"auto\" in my ~/.gitconfig). But if I detach my HEAD and show the\n> log:\n>\n> $ git checkout next^0\n> $ eg log -p\n>\n> then I _do_ get color in the patch. I also get this error:\n\nHmm, I had never turned color on before; I guess other eg users hadn't\neither. Anyway, the difference can be explained pretty easily: eg\nlog tries to provide user-meaningful names for how commits relate to\nthe active branch (like git-name-rev but implemented internally in eg\nto allow the common case to be fast); if there is no active branch\nthere's no special naming to do so I simply run git log without\nreading and modifying its output.\n\nEssentially, the difference in coloring here is much like the\ndifference you see between\n\n$ git log\n$ git log | less\n\nWhenever I try to load the output in perl, git won't show the\ncolorization. I guess I could manually add it when I am printing the\ninformation, but it'd be nicer to just have git do the colorization\ndespite the fact that its output is not a tty. Is there an easy way\nto do that (without mucking with the user's config file)?\n\n(It looks like eg status is also affected, for similar reasons.)\n\n> Use of uninitialized value $branch in concatenation (.) or string at\n> /home/peff/eg line 2854.\n> eg: command (git rev-parse refs/heads/) failed\n> eg: received signal 13\n>\n> The error is easy to explain. The offending code is:\n>\n> my $branch = RepoUtil::current_branch();\n> my ($ret, $revision) =\n> ExecUtil::execute_captured(\"git rev-parse refs/heads/$branch\");\n\nIndeed, the latter two lines should have been after the if (!$branch) check.\n\n\nThanks,\nElijah\n"},{"id":"102643","messageId":"51419b2c0901301222l2b722714v48db0039180d262b@mail.gmail.com","threadId":"17462","inReplyTo":"20090130200307.GA3054@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-01-30T20:22:36Z","receivedAt":"2009-01-30T20:22:36Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jan 30, 2009 at 1:03 PM, Jeff King wrote:\n> Ah, OK. I just peeked through the 'eg' source. It looks like you may\n> have replicated the same bug that I just fixed in git. :)\n>\n> You want to make sure that \"eg\" is the last process to die (i.e.,\n> _after_ the pager). Otherwise after it dies, less has trouble reading\n> from the terminal (I don't know for sure, but I assume this has to do\n> with the shell making \"eg\" the process group leader and magic about\n> process groups and controlling terminals).\n>\n> I think perl may even do the wait() for you under ordinary\n> circumstances. But, for example, if I kill \"eg\" with a signal (say, by\n> hitting ^C), then it will die but the pager will live on. In git, we\n> catch the signal and wait() before dying.\n>\n> So I don't know for sure that is your problem (it really depends on how\n> much magic perl is doing behind the scenes with wait()ing on children,\n> and I don't recall the exact details of that). But it is something to\n> look into.\n\nThanks for the tips; I'll try to take a look and see what I can figure out.\n\n\nElijah\n"},{"id":"102644","messageId":"20090130202917.GA3370@coredump.intra.peff.net","threadId":"17462","inReplyTo":"51419b2c0901301221n45cde1abw7a57a13bfa74b34@mail.gmail.com","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-30T20:29:17Z","receivedAt":"2009-01-30T20:29:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 01:21:00PM -0700, Elijah Newren wrote:\n\n> Whenever I try to load the output in perl, git won't show the\n> colorization. I guess I could manually add it when I am printing the\n> information, but it'd be nicer to just have git do the colorization\n> despite the fact that its output is not a tty. Is there an easy way\n> to do that (without mucking with the user's config file)?\n> \n> (It looks like eg status is also affected, for similar reasons.)\n\nIf you pass --color on the command line, it is equivalent to \"color =\nalways\" (whereas the default is \"auto\", which turns it on only if output\nis to a tty).\n\nSo you would have to read color.diff yourself and then decide whether to\nadd --color.\n\nNote that in general you are playing things a bit risky with these sorts\nof outputs. You are calling porcelain (like log and status) and piping\nit into your program. There's no guarantee that user config might not be\naffecting the results of those programs.\n\nBut I think that is sort of the nature of \"eg\": to be a thin wrapper\naround git. So maybe it is OK for your use.\n\n-Peff\n"},{"id":"102655","messageId":"51419b2c0901301455h32775947rfc4483fd5a5b6c2a@mail.gmail.com","threadId":"17462","inReplyTo":"20090130202917.GA3370@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-01-30T22:55:28Z","receivedAt":"2009-01-30T22:55:28Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jan 30, 2009 at 1:29 PM, Jeff King wrote:\n> If you pass --color on the command line, it is equivalent to \"color =\n> always\" (whereas the default is \"auto\", which turns it on only if output\n> is to a tty).\n>\n> So you would have to read color.diff yourself and then decide whether to\n> add --color.\n\nIt looks like I can also set the environment variable GIT_PAGER_IN_USE\nto achieve the same effects (and I don't even need to do so for most\ncommands, such as diff, just those whose output I'm parsing and\npossibly tweaking).\n\n> Note that in general you are playing things a bit risky with these sorts\n> of outputs. You are calling porcelain (like log and status) and piping\n> it into your program. There's no guarantee that user config might not be\n> affecting the results of those programs.\n>\n> But I think that is sort of the nature of \"eg\": to be a thin wrapper\n> around git. So maybe it is OK for your use.\n\nRight, I considered switching eg to use git plumbing commands to\ninsulate from issues like this, but the problem is that if git output\nchanges then the eg output really should change too (or else I should\nhave a very specific reason for not changing it). This almost\ncertainly means that I'll have to bump the minimum git version to be\nused with eg at some point, but that seemed the most reasonable path\nfor eg.\n"},{"id":"102685","messageId":"20090131072536.GE3033@coredump.intra.peff.net","threadId":"17462","inReplyTo":"51419b2c0901301455h32775947rfc4483fd5a5b6c2a@mail.gmail.com","subject":"Re: [ANNOUNCE] EasyGit (eg) 0.97","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-31T07:25:36Z","receivedAt":"2009-01-31T07:25:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 30, 2009 at 03:55:28PM -0700, Elijah Newren wrote:\n\n> > So you would have to read color.diff yourself and then decide whether to\n> > add --color.\n> \n> It looks like I can also set the environment variable GIT_PAGER_IN_USE\n> to achieve the same effects (and I don't even need to do so for most\n> commands, such as diff, just those whose output I'm parsing and\n> possibly tweaking).\n\nAh, right. I forgot about that. Yes, setting GIT_PAGER_IN_USE should\nwork, I think.\n\n-Peff\n"}]}