Here is a new release of YummyYummySourceControl, a shallow porcelain script around common git(7) command variants: yyhelp (v0.8)
This version supports a new command to grep and match an extended regular expression on the full project history by invoking git-grep(1) on all existing commits, displaying matches by commit hash and file name. Also, a CVS/SVN/Cogito style version of yycommit has now been implemented on top of git-commit(1). So YummyYummySourceControl-0.8 finally gets rid of the last remaining cogito dependency, making it a free standing Git Porcelain Suite. ;-) Of course there have also been some other miscellaneous changes and docu updates.
-
removed cogito(7) dependency.
-
made yyview start gitk in the background.
-
suppress yydiff outputs of non-checked-out files (ignored by yycommit).
-
implemented yycommit SVN/CVS/CG-alike on top of git-commit.
-
added '-s' option to yyChangeLog to skip SVN revisions.
-
implemented yyHistoryGrep.
I have been asked some of the purpose of YummyYummySourceControl, so i will extend a bit on that here:
-
On some occasions i had to dig quite deeply into the nitty-gritty details of git (and cogito). However i can simply not be bothered to deal with the complexity of its command set for everyday use. I need my source control interface to be really simple when i concentrate on the various projects i’m involved in.
-
I refuse to bother with the state (or existence) of git’s index file for anything but the correct implementation of yyhelp. SVN and CVS don’t force me to deal with an intermediate cache state between repository and working tree, YummyYummySourceControl keeps me from seeing it in git.
-
I might be using yydiff and yyview up to a dozen or so times per hour while working. Passing options along here or piping the output to a pager or starting stuff in the background really becomes unaffordable at that rate. These commands do all the necessary stuff out of the box, all i have to type is "yyd"+Tab+Return and "yyv"+Tab+Return for each of them now.
-
I’m too old and stupid to remember to pull after i’ve pushed and what the git-svn(1) command variants look like. yypull and yypushpull handle that for me.
-
Personally, i find ChangeLog style logs much more parsable than git-log(1) output. yyChangeLog gives me that for the git commit history.
-
To allow proper git merging, cherry picking, rebasing, etc, i’ve switched to commit my ChangeLog entries as commit message only (with introductionary one-liner instead of the date + email header) and for Rapicorn auto-generate the project ChangeLog for tarballs. Even if the ChangeLog is not auto generated as with Beast or Gtk+, i can still use this commit message scheme for git-svn checkouts, as long as i update the project’s SVN ChangeLog before yypushpull-ing the changes from my local tree to SVN. yyChangeLog -s will generate the remaining ChangeLog portion missing from SVN.
-
To help my utter laziness, yystatus -c can preformat file name change lists for my ChangeLog-style commit messages, i’ve always missed that with CVS and SVN.
-
To help against sudden confusion and lengthy URL searches, yyinfo tells me all i want to know about a repository (git URL + revision, SVN URL + revision, etc).
And i love to have grep-able access to all the data involved in my day to day activities, yyHistoryGrep now gives me that for my project histories.
Given git’s speed, the possibility for light-weight local repositories, and using yyhelp’s ease, revision control has become so available for me, that i could very comfortably apply it to portions of my home directory and /etc/ on a remote server (e.g. i’ve created a ~/.git/ a couple months ago where i checked in a handful selected files like TODO, my blog diary, .emacs and a few other frequently changing TODO-style files and i’m happily committing to it multiple times a day).
I’m not claiming that yyhelp solves anyone else’s problems, but it certainly has helped my SCM usage a great deal, and for me serves as a key to make a frequently used subset of the git machinery accessible at very few finger tips.