Recent Posts by Travis Swicegood

Topic: Pragmatic Version Control Using Git / git status for remote repos...

Hey Arthur;

Make sure your friend is using the latest version of Git. When I run the git status, I get the following output:

prompt> git status
# On branch master
# Your branch is ahead of 'origin/master' by 3 commits.
#
nothing to commit (working directory clean)

The Your branch is… shows that my current branch has three commits that my origin/master doesn’t have. That data only shows in remote tracking branches, however.

-T

Topic: Pragmatic Version Control Using Git / Structure within the Project

Hey Kris;

Thanks for the comment. I debated on whether to keep that section in there or not, and in the end decided on the current wording. My reasoning was that frameworks, and even languages to a certain extent, have become very opinionated in how a project should be laid out. Rather than promote one particular path, I decided to point readers to their framework/language to follow those practices.

Thanks again for the comment. Hope you’ve enjoyed the book!
-T

Topic: Pragmatic Version Control Using Git / Fixing beta book errata via git

Hey Andrew;

That’s an interesting idea. It would be a piece of cake if we exposed the markup the book is written in, but we don’t currently and I imagine there are a lot of implications that Dave and Andy would have to consider to keep the “mama gerbil” happy…

-T

Topic: Pragmatic Version Control Using Git / moving code between repositories?

Hey Daniel;

That’s a work-flow I haven’t covered in the book yet. It’s kind of specific, but could definitely be useful. Maybe I’ll add it to the Recipes appendix.

You are definitely right, though. Keeping a bunch of different projects in one big Git repository isn’t the best of way to handle this situation. You can do it, but you don’t have as much flexibility as having smaller, more focused repositories.

So here’s what I would do. Create a clone of the repository that has the code you want to extract into its own repository. Let’s call them repo A and repo B, respectively. The cloned copy will become your repo B. Just run git rebase -i and erase all of the commits that you’re not interested in keeping around. When you finish, your repository will have just has the history related to parts of the code you want to keep around. Change the remote repository to the remote you want to use to share this repository with others, and you’re set.

To make your job a bit easier, you can generate the list of commits you want to pull out for your rebase instead of manually going over every commit. To do that, run git log --pretty=format:"pick %h %s" path/to/pull. That assumes all of your files exist in the same path. You could also provide it with a list of all of the individual files you want to keep around. The format that the log output is in is the same format that git rebase -i uses, so just copy-and-paste that into your editor when setting up the rebase and you’re set.

Hope that helps!
-T

Topic: Pragmatic Version Control Using Git / Undoing git actions

Hey Guido;

Was loading this page when I say an email come in. I hope you don’t mind me just responding here – that way everyone can see it.

Yes, the book does deal with undoing changing. In good Git form, it covers a few different methods of undoing and removing changes, including (off of the top of my head):

• git revert
• git reset
• git rebase

I hope that answers your question.

-T

Topic: Pragmatic Version Control Using Git / Gitosis

Morning David,

Thanks for the link. I’ve already written a section in an appendix on setting up and using Gitosis. Like you, I think it’s a great tool. I use it to manage my own private repository.

The appendix with that section should be out soon.

Thanks again,
-Travis

Topic: Pragmatic Version Control Using Git / git pull erin ?

Hey Chris;

Could you do me a favor and add that to the errata page? That way it’ll be a reminder to me to check it before we roll the next beta.

Thanks! I’m glad you’re enjoying the book.
-T

Topic: Pragmatic Version Control Using Git / git stash

Hey Martin;

I sure am. Still working on where to stash it (sorry, couldn’t resist the pun) though. It seems to fit with git branch because that’s when you use it the most, but it feels kind of awkward in that chapter. Any suggestions for where you would put it?

-T

Topic: Pragmatic Version Control Using Git / DVCS, Thank you.

Hey Nick;

Soon… very soon. :-)

-T

Topic: Pragmatic Version Control Using Git / DVCS, Thank you.

Ha!

So that last bullet point should read as two hyphens, followed by squash and shouldn’t be surrounded with strike tags. Oh, the joys of trying to make mark up thats more readable.

-T

Update: I edited this – I’m going to have to submit a patch mapping squashed to squash… :-)

Topic: Pragmatic Version Control Using Git / DVCS, Thank you.

Hi Jeroen;

Let me answer these in backwards order :-)

We are planning on a beta book and want to have it out soon. How soon is soon? Depends on how quickly I can polish up a few chapters. ;-) I’m definitely looking forward to feedback from the community, so I hope you’ll read it and let me know your thoughts.

GitHub and hosting your own repository are both slated be covered in Appendixes. I’m planning on touching on the gitosis server configuration package too which makes hosting your own Git repository a snap. gitosis also showcases Git as a platform too.

Regarding upstream repositories: definitely! :-) The distributed in the DVCS means Git plans on you working with other repositories, so I’ll definitely be covering that. The book starts off working solo and builds from there. I have a chapter devoted to Tags and Branches which will not only cover the mechanics of creating them, but how to utilize them to their fullest. It’s next up on my list to write as I think it’ll be the most fun to write.

A few best practices for you:

• Treat master as something that should be always deployable
• Do all of your development in local branches, then merge back when they’re ready. This was the hardest for me to get used to. Cheap branches, once you’re used to them, are very liberating though.
• -squash is your friend. Most people are just curious that a new feature is implemented, not in the 20 commits it took to get there ;)

-T

Topic: Pragmatic Version Control Using Git / DVCS, Thank you.

Hey Krouper;

I actually would have preferred Mercurial as well. I spent about a week going back and forth between the two when I originally tried to decide which one I was going to use. The decision was sort of made for me though. Git has bi-directional Subversion support, Mercurial doesn’t (yet).

edit: It was brought to my attention that the above paragraph is kind of ambiguous. It’s not that I would have wanted to write a book on Mercurial, but that when I started researching the various DVCS to see what they were capable of I was impressed by Mercurial’s feature set. Git has the killer feature: bi-directional Subversion support. Both are excellent tools, but right now I think Git has the edge.

That was crucial for me, and I think it will be for a lot of people who move to DVCS. It’s hard to get a company to change their VCS server. By treating Subversion as your main upstream repository though, an individual developer or team of developers within the company can make the jump and not require everyone to switch.

Hope the book exceeds your expectations.
-T