Posts tagged with “”

Git Tip: Ignore Changes to Tracked Files

Every once in a while, I find myself working on a project that forces me to modify key files—often config files—in order to get it running locally. In those cases, the last thing I want to do, for a number of reasons, is to commit those changes. That’s hard to do, though, since I regularly use git add . and/or git ci -a to commit everything I’ve changed. Make enough changes in enough files that you don’t want to commit and these changes begin to cause as many problems as they solve.

As is so often the case, it seems, Git comes to the rescue with its update-index command. Reading the documentation, it’s not really intended for this purpose, but its effectiveness as a “coarse file-level mechanism to ignore uncommitted changes in tracked files” is recognized. To apply it, simply make a change to a committed file, say, database.yml and execute git status. Git should report the modified file. Since we don’t want to commit, we don’t want to see this listed as a modified file until the end of time and we can’t ignore it (because it’s already being tracked), we need to tell Git to assume the file is not changed.

git update-index --assume-unchanged path/to/database.yml

I’ve been using this command since I learned of it a few weeks ago and it works perfectly for this use case. Inevitably, though, a question will arise:

What files have I marked this way?

Since those files will no longer appear in the modified list, can’t be easily found in a .gitignore file or exposed by removing a .gitignore file, there will eventually be a need to know this. Maybe you’re trying to get another instance running or maybe you’re just the curious sort and you’ve forgotten. Like many things in Git-land, the functionality exists, but is far from obvious. I asked on StackOverflow and Andrew Aylett provided the answer I was looking for.

If you ever find yourself needing to know, this command will display the files that have been marked as —assumed-unchanged.

git ls-files -v | grep -e "^[hsmrck]"

Thinking in Subversion

I just spent more time than I should have needed to spend learning that svn revert is so not the same thing as git revert.

I had modified a page in my working copy while trying to track down and understand the nature of an error. Once I figured out what I needed, I wanted to get my working copy of that file back to where I started. Having been a Subversion user for so long, I immediately tried to revert those changes. Wrong. Then I tried git reset only to find that while it works on entire repositories, it doesn’t work on individual file paths. At a loss, I turned to Twitter and, once again, Twitter delivered.

Thanks to Ben Kutil and Brad Greenlee, I learned that git checkout is what I needed. That never even occurred to me and, honestly, I doubt I would have tried it even if it had occurred to me. I’d have assumed it would throw an error. In the git paradigm, of course, it makes perfect sense that no error is thrown, but I’m still ascending that learning curve. I’m still thinking in Subversion.

Ignore Git's Suspicious Patch Lines

Those who follow me on Twitter have recently been forced to endure a steady stream of rants directed at Git, the DCVS I’ve been trying out while working on the new theme for this site (one really is coming). I’ve only tweeted a fraction of my frustration, but this tweet sums it up nicely:

What the fuck is up with git and its need for precisely zero trailing whitespace?! Suspicious patch lines my ass.

It seems that Git is a finicky little bastard and it pays obscenely close attention to whitespace. If there is a line, any line, with whitespace at the end of it Git decides that something must be fishy. I mean, it’s whitespace. Horror. Everyone knows whitespace is the very spawn of Satan, right? Er, no. Nonetheless, if there’s any trailing whitespace to be found in content that’s being committed, Git balks:

*
* You have some suspicious patch lines:
*

The message then proceeds to itemize its suspicions for my viewing pleasure. Tonight I’d finally had enough. I can’t figure out how to make Git force the commit or at least stop it from worrying its pretty little head over a little empty space, so I took drastic measures:

$ sudo chmod a-x /path/to/my/repository/.git/hooks/pre-commit

That’ll teach it to mess with me.

Source Control Strategies for Frameworks

I’m starting to get my hands dirty with CakePHP and as I’m getting started, I find myself pondering the use of source control. Not whether to use source control, mind you (because, well, duh), but how to use it optimally in the context of a framework or even a product that can be extended with custom code. Ideally, I’d like to version any and all code that I write or modify, but none of the framework code that is left unmodified. I’m not sure that I’ve ever spent much time on that question. As best I can remember, I’ve always just committed everything.

I’m wondering what strategies others employ with respect to source control when custom code is mixed with product or framework code. Are there any best practices?

How I Use Subversion

Last night I gave a Subversion presentation for the Refresh Baltimore group. The presentation ended up being a bit more of an informal dialog due to time constraints, but that was actually great. I rather enjoy talking with people rather than at them, when appropriate. The audience seemed to be largely front end developers, but many were very new to source control in general and, of course, Subversion in particular.

After the meeting, I thought I’d write a bit about how I use source control within my workflow. It’s the personal experience that folks in the group – myself included – seemed most interested in. The terminology I’ll use will be Subversion-centric since that’s my tool of choice (for the moment), but the philosophies, methodologies and processes should be comfortably analogous to other versioning tools.

Read More »

← Earlier Posts Page 1 of 2