Vim & Vision

You searched for articles tagged with Git.

[ #231 ] Git - fixing commit user Permalink

Git Added about a month ago

If you just committed a change as the incorrect user, as long as you haven't pushed your branch you can do this:

$ git config user.name "Correct name here"
$ git config user.email "Correct email here"
$ git commit --amend --reset-user

[ #222 ] Git - Which commits are in your branch only? Permalink

Git Added about two months ago

If you created branch AAA from master, have committed to AAA but also done some rebasing or merging from master into AAA, git log will not tell you which commits belong only to your branch. You can uncover them like so:

$ git cherry master AAA

[ #209 ] Speed of git clone Permalink

Git Added less than a year ago

Git clone is fast locally because it uses hardlinks.

If you compare it to a:

$ mkdir repo && cd repo
$ git init
$ git remote add origin /path/to/local/repo
$ git pull origin master

... then you will see how much faster the hardlinks make it. On a repo of about 600MB checked out, the git clone will finish in < 5 seconds while the init/remote/pull will finish in ~ 1.5 mins. You can make the init/remote/pull use hardlinks by supplying an alternates file, and this will take the operation down to the same time as a git clone.

If the reason for replacing a git clone with the complex steps above does not seem obvious to you, ... I don't blame you. I'm doing some complex wrappers of git that intercept certain commands and locally cache all downloaded repos then fetch from that instead of going over the network all the time. So... don't worry about it :-)

[ #200 ] Git's Index Permalink

Git Added less than a year ago

Plasmasturm has some excellent things to say about git's index, including:

So what is the index good for? The key to understanding it is how it interacts with git diff. Once you add something to the index (also referred to as staging it), it disappears off the diff. You can pass --cached to see what changes you have staged, but by default, it doesn’t show you the changes that you have asserted are ready for commit. When I first read about this, it sounded outright stupid to me. Why would anyone want that? Turns out: because it is hugely helpful. Consider: when a merge fails, the successfully merged diff hunks are staged, but conflicted hunks are not – which means that git diff will show only conflicts, and the successfully performed part of the merge doesn’t cloud the diff. Furthermore, the way to mark files with conflicts as merged is to stage them after manual resolution, which makes them too disappear from the diff. Maybe this is why Linus introduced the concept in the first place, being that the main part of his job is to perform merges all day long. But that’s far from the only circumstance in which the index has been useful to me.

[ #196 ] Git GUI Permalink

Git Added less than a year ago

The GUI you get from:

$ git gui

... is a good way to look at all your changes (with diffs), selectively stage them, commit and push. This is mostly just an easy shortcut but I find it easier to compose a commit message this way, while you can see the diffs for changed files.

[ #168 ] Git Squashing Permalink

Git Added less than a year ago and last edited about a fortnight ago

If you decide to choose a development workflow where you are working on lots of branches (perhaps a branch per feature), then you will want to merge branches back to master regularly - like when you've finished your feature. If you have branches for smallish items then you might only want the whole feature to appear under one commit in your master branch - even though your feature branch has many commits.

This is when you should use git's commit squash.

$ git branch
* master
$ git checkout -b feature-01
$ # EDIT A FILE
$ git add .
$ git commit -m "Edit 01"
$ # EDIT ANOTHER FILE
$ git add .
$ git commit -m "Edit 02"
$ git log
 ... output here lists Edit 01, Edit 02 and all previous log messages ...
$ git checkout master
$ git merge --squash feature-01
$ git commit -m "Feature 01"
$ git log
... output here lists Feature 01 and all previous log messages ...

So Edit 01 and Edit 02 now appear in your log the one Feature 01 commit.

If you don't use squash then all the commits from your branch will also individually appear in the commit log for master.

A squash acts like a regular merge in svn.

[ #123 ] Git Push Error Permalink

Git Added a year and a bit ago

After rearranging my remote repos I received this error locally after trying to push upstream (from local to the new remote repo):

! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'ssh://myserver/myproject.git'

... make sure the hooks in your hooks/ directory are all chmod -x (unless of course you have purposely enabled one.) This folder is full of default/example hooks that should be only enabled/modified if you require them. If they are executable they are enabled.

[ #114 ] Using Git for Server Configs Permalink

Git, Shell, Apache Added a year and a bit ago and last edited a year and a bit ago

I dev on a VM that has at least two projects running with incompatible apache httpd.conf files. The differences include User/Group, Location etc, so I switch between the configs and then restart apache httpd when I want to work on a particular project.

Firstly, I understand that some or all of my different settings could be merged into one conf file and made to work on different virtual hosts etc, but in some situations you can't do this because: you only want one project running off your dev server at a time due to performance/load issues; or you have a specific file you need to use as a httpd conf file from your codebase etc.

So - I used git to help me switch between configs.

# cd /etc/apache2
# git add apache2.conf
# git commit
# git tag projA
# vim apache2.conf # or cp your apache2.conf for projB into place
# git add apache2.conf
# git commit
# git tag projB
# echo "/etc/init.d/apache2 restart" > .git/hooks/post-checkout
# chmod a+x .git/hooks/post-checkout

... now you are setup! So when you want to switch to projA you do this:

# cd /etc/apache2 && git checkout projA

... and to switch back to projB use:

# cd /etc/apache2 && git checkout projB

... and your apache will automatically restart after each checkout.

Yes you could do this just by copying your files into place but I think this is a neat use of git and one that will scale over many projects and many revisions of the conf files.

UPDATE

Instead of using tags, use branches! That way you can update the conf files, commit, and then continue using the projA and projB identifiers.

[ #85 ] Modern Software Development Permalink

Subversion, Best-Practice, Agile, Testing, Git Added a year and a bit ago and last edited about two months ago

Modern Software Development is an article I wrote with a concise list of technical points for a software house to implement. It has a basis in Agile methodologies but doesn't preach a certain one. It is aimed at the small software house or the beginner.

Modern is being proactive and efficient. It is being prepared, having backups, examining information, deploying with minimal mistakes and being able to recover and review when mistakes are made. Modern is being well-tested and writing maintainable code. Modern is being able to release regularly and easily.

[ #71 ] Using Git to Rollback Bad Deployments Permalink

Git, ThisBlog, Apache Added a year and a bit ago and last edited a year and a bit ago

Git just keeps rocking my world.

OK, here is how I deploy my blog and here is how git saved me last night when the deployment went bad:

I git-pull into a webroot directory (well, the directory that is setup to serve my python) from my main git repo (which is also hosted on the same machine.)

When I updated the blog software last night I did a git-pull, restarted apache and saw the error (yes I should've caught it in dev, shoulda-coulda-woulda but-but-but.)

So, error noted. What do I do to rollback to the last working version?

$ git log

... and I copy the SHA hex-string of the last working commit. Then we rollback with:

$ git checkout <copied_hex_string>

... and restart apache. Ta-da! Now the blog is still up while I do the bug fix.

OK so what happens when I've commited the fix and I want to make the blog update?

$ git pull

... puts all the new changes in the git repo but doesn't fast-forward it to the HEAD of master automatically. Why? Because you aren't in master anymore - you've checked out a previous commit. So all you need to do now is:

$ git checkout master

... restart apache and you're set.

EDIT: Here is some info to rollback to the previous commit in a more general way:

$ git checkout HEAD~1
...  # you are now at the previous version
$ git checkout master
... # you are now back to the latest version

Older Posts ... (Nothing Newer)

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

This is the blog of Brad Willis, a software engineer living in Brisbane.

Links

ChoppingBoard, DaveMisc, Project365, RageQuit

Vim & Vision

[ #231 ] Git - fixing commit user Permalink

[ #222 ] Git - Which commits are in your branch only? Permalink

[ #209 ] Speed of git clone Permalink

[ #200 ] Git's Index Permalink

[ #196 ] Git GUI Permalink

[ #168 ] Git Squashing Permalink

[ #123 ] Git Push Error Permalink

[ #114 ] Using Git for Server Configs Permalink

[ #85 ] Modern Software Development Permalink

[ #71 ] Using Git to Rollback Bad Deployments Permalink

Colophon

The Author

Meta

Recent Entries

Links