More incomplete thoughts on Git

 books, git  2 Responses »
Jun 032012
 

I’m working through Chapter 6 and things are starting to go off the rails for me. Here are my current thoughts…

  • The git diff --stat <branch|tag> command is nifty. Even more nifty: referring to tags and branches by name rather than full path (svn).
  • I’m gratified to see that EGit displays annotations (blame) similarly to Subclipse.
  • Countless times I’ve committed code to a Subversion repository only to find I’ve broken the build by leaving out a file or lib. The Subversion-way is to either make a follow-up commit with whatever was missing or to reverse-merge the commit and re-commit with everything. The former is undesirable because it spreads the single change across more than one commit; the latter is preferred but is more complicated. Git’s amended commit gives you the convenience of the former with the pedantic correctness of the latter.
  • Yeah… git revert != svn revert … this is going bite me constantly. It already has.
  • I’m totally confused by git reset. I have no idea what this means: “git reset updates the repository and stages the changes for you to commit.” Maybe if I knew what was being “updated” or what was being “staged,” it would make sense! Also, the book says “[git reset] is useful when you notice an error in your previous commit and want to fix it.” What…? I thought that’s what amend was for…? Apparently, if I’m going to understand reset, I’ll have to find another reference.
  • My single experiment with git rebase -i wherein I attempted to squash two commits together and then break them back out did not work as expected. The book said the second execution of rebase would show my squashed commit starting with “edit” but it still says “pick”; not sure what I did wrong.
  • Using hashes as revision numbers makes it impossible to glance at a list of commits and determine what’s newer, older, or (dis)ordered. I ran into this when playing with git rebase -i. Unquestionably, rebase has a set order but it’s not self-obvious.

Incomplete thoughts on Git

 books, git, subversion  1 Response »
May 302012
 


For the last week or so I’ve worked my way through about half of Pragmatic Version Control using Git with a mixture of excitement and terror. In random order, as it comes from my mind, are some thoughts:

  • Git treats branches and tags as first-class citizens. They are attributes of the repository. Git can easily give you a list of branches in one single git branch command. Coming from the world of Subversion, where branches and tags are tenuously related to trunk, I have to say this is refreshing. I almost said “Of course! It should be this way!”
  • Subversion makes you organize your branches and tags by paths. Git, following from the above, does not. I’ve never much liked having to babysit the Subversion repository hierarchy, even though it is extremely malleable.
  • Going in, I was not aware who authored Git. After I typed out a few commands, I joked to myself that it seemed made for Linux command-line lovers. Spot on.
  • Git operates on file contents rather than files. It knows when code moves from one file to another. It knows when code is duplicated. It doesn’t balk at files being renamed or moved. If you frequently refactor your code, this should produce at least one little tear of joy in your eyes.
  • I wonder how well Redmine, Jenkins, and other heavily-VCS based systems work with Git. I’ll have to find out.
  • Perhaps it’s just this book, but I think I’m seeing inconsistencies in naming. For example: staging, cache, and index. Are they the same? Are they different? How do they relate? I’m not satisfied the book isn’t confusing me. It could be my fault, though.
  • Those familiar with Subversion may see the .git directory as an analogue to .svn. It’s not; the .git directory is the repository.

SVN repository moved

 subversion  No Responses »
Sep 082009
 

If you use Subversion via Apache/WebDAV and get a message like “Repository moved permanently” or “301 Moved Permanently” you should definitely read the Subversion FAQ on the 301 issue.

But, don’t take its advice too literally… you may indeed have a configuration issue, but not with DocumentRoot. Be sure to check your Apache configuration for any overlapping/conflicting SVNParentPath and Alias entries!