Git

Working Copy makes my heart throbb

by

Working Copy is one freaking impressive feat of work.

One of my early bits of research into apps to solve less popular problems, was searching the app store for a Git client. Because I’m really more of a git and vim kind of guy than a cloud thing and browser based word processor kind of guy. On my old Tab S3 and on my Chromebook, it was easy enough to combine a git client and an editor to manage some repos, even keep a backup of some software projects for reference. Priorities being as they are, I started with iVim because muscle memory and most likely to freak out the fruity operating system. Combined with Pretext it gives me an editor I’m very familiar with, and a simple editor that matches what I’d want out of something neither vi nor emacs like.
After reading around Mac Stories, I decided to finally give Working Copy a whurl. I’m impressed, and I’m happy. Hell, judging by its user guide I could probably manage a nice local edit + git → remote build life cycle if I really wanted to.
For the most part, the software I use tends to be cross platform. E.g. developed on Linux, also available on Windows, cie; Android and iOS. And mostly the apps I use that are on both, are mostly the same on both. Except for the habit of iOS apps to use a scrunched landscape in portrait rather than going to a full screen view. Which is fine by me ‘cuz I’m a lazy git and have more than a few platforms to deal with.
Working Copy manages to be pretty native and runs with it all the way. You wanna know what my definition of professional grade, well made software for doing real shit would look like on an iPad? Well pal, Working Copy is now that definition, and what a damned stunning example it is!!!
Even more so, it appears to be feature complete enough that I don’t have to worry much. You see, I’m weird. I tend to like doing my work from the git command line client, and if I’m going to suffer a GUI then it’ll probably be git gui + gitk. And if Working Copy can’t do what I need to do, odds are I’d be running command line git regardless of the operating system, and probably quite out of my routine.
Something that makes me kind of happy about how native it is, is the file sync.
The way {App}/Documents is exported into the On My iPad provider as {App} is pretty nice. But doesn’t seem like the iOS Files stuff really has a concept of Unix style hidden files, so getting to .vim is a bit of a pickle.
Thus, I had Working Copy’s sync feature use On My iPad/iVim/vimfiles. Which for iVim, maps to ~/vimfiles. A quick :e ~/.vimrc and it only took a moment to get my stuff in order.
" For iVim on iOS.
" Working copy can sync my terryp/vim to ~/ or a subdir but not ~/.vim because iOS file goodies don't like dot files
" So let's use terryp/vim -> ~/vimfiles ala wintel.

set runtimepath+=~/vimfiles/
set runtimepath+=~/vimfiles/after
source ~/vimfiles/vimrc

Since Working Copy is trivially able to handle the submodules in my repo, which anger some GUI clients I’ve tried on PC and Android, all my stuff pretty much just works. Because my .vim/bundle gets synced to vimfiles/bundle like the rest of my stuff.

When someone makes an application as good as Working Copy,  we should all applaud. I know that I’m sure freaking happy! It takes a lot of work to make an application that great, and all to often when you find an application to scratch such a less popular itch, it can be hard to find a really great solution. Working Copy is one of those rare, great solutions.

Sometimes Linus is a genius

by

When you begin to do more advanced things with subversion (not my idea, trust me), I would have to conclude using tarballs and larger hard drives is more useful than subversion.

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company [Transmeta[11]] and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was “CVS done right”, or something like that, and if you start with that kind of slogan, there’s nowhere you can go. There is no way to do CVS right.[12]

source: Wikipedia on Git.

Please, for the love of sanity (and science), do not use Subversion…..you have been warned!

+1 for git in my book

by

Parsing this old blog post by Keith Packard, somehow makes me happy that I opted to follow the Git path rather than the Mercurial (hg) path when I left CVS behind. I also like the trailing comment xD.

That being said, git and hg are the only version control systems I really respect, above tar. Perforce and Darcs, I at least consider worth a closer look someday. Just haven’t had any excuse to leave Git on my own projects since the first date.

Yeah, I’m a lazy git alright.

github and filter-branch fun

by

In between being driven crackers, I’ve been *attacking* just about every TODO and item in my backlog. Staying insanely busy has the benefit that there’s minimal time to feel or think, until passing out cold >_>.

Except for a minor issue with power save, and tools for a couple programming languages to be installed, work on my laptop is virtually complete.
One thing I have finally accomplished is preparing my personal git repository for the hub. For almost two years now, I’ve kept the important stuff in my home directory under revision control. Now I at long last have an off-site backup of it, reduce need for pastebins, and I could care less if anyone finds the repo helpful 8=). I’m more concerned about freak system failure here… lol.  Somethings, like my vim files represent like 4 years of work so there is a wee bit of life/time investment here.
Projects get their own repositories as needed but top level stuff in $HOME shares one. Originally I used CVS, since my file server only came with that and RCS, and I didn’t want to bloat it with Subversion. About five months later, I switched to git ;).
Here things are still very simple. The file server has a mirror of any important data, plus it has bare git repositories for various projects: backed up independently of my personal data. Plus project repos on several hosting sites.  It’s good insurance: now my most important files have the same.
And of course being me, it’s obvious that I generated a patch set and skimmed through the 17,000-18,000 some lines of data representing over 200 commits, before I would allow the repo to get pushed into a public place.  I tend to be cautious in what I commit, to much so in fact. This repo however was always meant to be “Private”, and programs sometime become probmatic. I only found one instance where this was a concern, minor but still rather something that should be compromised.
The solution of course is to just rewrite history:




$ git filter-branch –tree-filter ‘git ls-files -z “filename glob” |xargs -0 perl -p -i -e “s/secret stuff/Censored By The Git History Cops!/g”‘ — –all




$ git gc –aggressive –prune




$ git push –force origin




$ git remote add github git@github.com:Spidey01/Terry.git


$ git push github master








Also being myself, I made sure to first test the filter-branch in a fresh clone into /tmp, back up my .git directory, as well as verifying the log and format-patch output that it worked. Plus since I made a tag of a commit before updating master to reflect it’s current machine: I also made sure to check that the tag remained unchanged from the filter-branch.








and now… I’m to darn tired to do more than pass out.

			


					
			





	

					

						

			 by  		

					

			
			

				
To say that I love using git for managing source code, would be the understatement of the year.


The first tool I used was Subversion (around late v1.4/early v1.5), and I rarely had any trouble using CVS either. I can basically pick up and figure out any tool given a decent manual or enough kick around time.


It’s like having a freaking swiss army knife of managing changesets, having git in hand :-S

			


					
			





	

					

						

			 by  		

					

			
			

				
Today I’ve had to get used to living with Subversion again, as much as I simply love git, setting up a repository is easier with svn then git-svn :-S. Aside from the obvious problems that chop up from their different mental models it’s not that bad.


The lights flickering as the thunder blares outside on the other hand, tell me that I should probably *WAIT* to merge this vendor branch into the trunk – and go look up how atomic svn copy src-url … dst-url actually is in terms of network and power failures! If I was using git I would just say screw it and do the merge, because I know already that git doesn’t phone home to the repository, because the working copy is a repository.


Oh well, to the manuals!

			


					
			





	

					

				
merging the new code into master
		

			 by  		

					

			
			

				
After 3~4 days of coding, I’ve just merged the parserlexer branch back into master; I love coding 🙂


 commit 9857e5e9556f31543075fb4a74350dbda97a42e5
 Merge: c9a8ae4... bb425eb...
 Author: Terry ....snip...
 Date:   Wed Apr 8 07:23:19 2009 +0000
 
     Merge branch 'parserlexer'
     
     The new parser, lexer, and quote expansion code (+ a few bugfixes) has
     finally been merged into the mainline of development (branch 'master').
     This marks the new sh_eval(), tpsh_parse(), expand_quotes, tpsh_lex()
     functions in such a way that they should be considered 'stable' for
     general usage.
 


some nice things that come with this:


a sane way of quoting stuff; but not sh compatible (”’ = ‘, not an error), more then one set of quotes on the line; and things like `cd /foo; vi bar` finally work xD. In the course of the necessary bug smashin’ for the merge, I’ve also cleaned out a few pains in the todo file, that have been there since last month++ lol.


things that remain to be done: pluggable completion; make completion play nicer with perl/gnu readline backends; restore support for pipes (critical); handling of keybinding (likely painful across perl/gnu/zoid Term::ReadLine backends; but at least zoid is nice…). In the more long term: control flow, (subshells), better `handling`, {anonymous macro/grouping}, more advanced I/O redirections (i.e. only >, >>, and < currently work lol); making `fc -l` and `history list` use a format for display rather then print(); make &do_getopt able to be configured by callers (so fc can accept negative indexes, etc); give a way to turn off shell options (set - and set + currently turn on, only lol); and who knows what else that I can't remember atm.


and to abuse {erls idea of objects and verbs: eval { $spidey sleep $now };

			


					
			





	

					

						

			 by  		

					

			
			

				
Using git for all my scm/vcs needs, I’m starting to wonder how the hell I ever lived with CVS lol. (The documentation for git isn’t to bad these days either)

			


					
			





	

					

				
git rules, cvs drools
		

			 by  		

					

			
			

				
Hmm, after a using git for all of my stuffs these past few days…..


CVS can go rot in hell, someone actually wrote a real system 😉


As much as I try to keep my OpenBSD box lean & mean, git is fairly light on runtime dependencies: 


Terry@vectra$ cat /var/db/pkg/git-1.5.6.4/+REQUIRING                            
libiconv-1.12
p5-Error-0.17009
curl-7.18.2
rsync-3.0.3


libiconv is required by other things I use, and I believe gettext depends on it, and a lot of stuff uses gettext lol (uh, almost everything). curl and rsync are also useful to have around, and rsync I actually would want installed anyway (just in case I need it someday). So really, there is no serious dependency issue from it, since OpenBSDs standard git package doesn’t include the TK gui tools like FreeBSDs does. TBH, although I usually keep tcl/tk on my development systems, I never use tcl or tk-bindings. And I really have no desire to use any git front ends, nor gitk/git-gui for that matter.


Using git after getting used to living with CVS for so long, I can’t help but wonder….. why the **** anyone uses CVS anymore. Even Subversion is easier to live with then CVS, but not always a fun thing to install/manage at times, ‘least it is well documented (and tirival for cvs users to pick up hehe).


git… simple, effective, fast, and not brain damaged.

			


					
			





	

					

				
A quick conversion from cvs to git
		

			 by  		

					

			
			

				
notes:


    

  • I store all files related to services under /srv, or provide symbolic links.
    • 

  • Personal files are stored in a CVSROOT of  :ext:Terry@vectra:/srv/cvs/ and are filed under module ‘Terry’, for lack of a better name lol.
    • 

  • server is vectra, workstation is dixie; communication done via the Secure SHell protocol.
    • 

  • I don’t use graphical software for these kind of tasks. GUIs are available, but I don’t want them wasting my time
    • 

  • The contents of my personal CVS module will be stored in it’s own spot as ‘cvs-head’ for backup purposes: I have no plans of committing to CVS or merging stuff back into it.
    • 

  • Access git is more or less just me and occasionally root@hostname, but may be expanded later
    • 



OpenBSD server:
 # su - root
  ...
 # pkg_add git cvsps
  ...
 # groupadd -g 2005 git
 # cd /srv/
 # mkdir git
 # chmod 7755 git
   if you want to lock down the CVS, go to the CVSROOT
   and revoke write access on your modules files
   e.g. chmod -R ugo-w fooproject
 # cd git
 # git cvsimport -ikv -d /srv/cvs -C cvs-head Terry
  ...
 # mkdir Terry
 # chmod 0750 Terry; chown Terry:git Terry
 # su - Terry
 $ cd /srv/git/Terry
 $ git init
  ...
FreeBSD workstation:

 $ su - root
 # pkg_add -r git
 # pw groupadd -n git -g 2005 -M Terry
 # exit
 $ git clone vectra:/srv/git/cvs-head /tmp/Terry
 $ cd /tmp/Terry; mv * .* ~/
 $ cd ~
 $ git remote add origin vectra:/srv/git/Terry 
 $ git push origin master
  ...


In a little while, I’ll probably refine things. Originally, I used the old mv file.ext file.c-vN.M and (cd ..; tar cf – project | gzip -c > /tmp/project-N.M.tar && mv /tmp/project-N-M.tar ./project/backups/) style approaches to my stuffs. The first time I went into using a source code management / version control system for a project, I selected Subversion (also known as svn) and enjoyed it quite a lot. Later on, when I decided to start checking in my configuration files, well… I like to keep my OpenBSD box pretty lean & mean; thus I used what came in the base, which was cvs (concurrent versions system). Subversion and CVS are so much alike, that I could live with CVS very easily (after all, it’s just my config files and an occasional project). I prefer svn to cvs, but hey, I’m a cheap bastard!


I’ve been thinking over the merits of Subversion, Bazaar (bzr), and git for various projects. I generally ruled out Monotone on inputs from another programmer, and having a general lack of interest in it myself. I also considered Mercurial (also known as hg), but I’m more familiar with git then hg. One of my friends uses hg for submitting patches to Mozilla and what not, and there is a project I’m involved with that I feel would benefit from using bzr; but either of those would mean a dependency on Python. Despite my levels of fluency in Python, my file server doesn’t have need of a scripting language like Ruby or Python; because OpenBSD provides Perl, SED, and AWK. So for me, git is a smaller package and it is just as easy to choose to pickup git as it is bzr. My workstation will always have Python, but that’s because I write python code lol.


Several of my various micro-projects use git on my work station, because there is no real need to stick them in the CVS server – and I don’t like CVS or rcs enough to employ them for the task lol. I’ve also considered replacing cvs with git on my laptop, and using it to fire off final commits to the CVS server, but eh… fuck CVS.