blog.felipebalbi.com

Housekeeping a git repository is useful to make it smaller and faster. Git has a lot of tools to allow you optimizing your git repository. Let's take a look on a few of them and see what they do.

(more...)

Hi all,

This will only be possible on git 1.5.3 and later versions (1.5.3 is the most recent at the time of this posting). With interactive rebase you can reorder your commits, meld them together, discard some commits, etc...

Let's see how to do it.

(more...)

Hello all,

The title of this post came from git-cvsimport's man page. Let's try to use it??

NOTE: We're gonna need cvsps 2.1 or higher in order to split cvs log into patch sets.

Once you have the address of the cvs project you wanna import, you just issue:

$ git-cvsimport -d "CVSROOT" "CVS_module"

Example:

$ git-cvsimport -d \

   ":pserver:anonymous@linux-usb.cvs.sourceforge.net:/cvsroot/linux-usb" usbutils

And that's all, you just have to wait now

See y'all

Hello all,

After a lot of branching, merging, pulling, rebasing, etc we'll probably see some conflicts on the source code.
With this post we're gonna learn what's a conflicted merge and how to solve it.

Let's take a look:

Sometimes the merge can't be automatically resolved. When this happens, git leaves the index and working tree in such a state that gives you some information to help resolving the merge.

(more...)

Hello all,

Yes, this post doesn't have a nice name... but let's go anyway:

1st tip: Using git-checkout to produce clean patches.

Assumptions: using that same 'exp' branch

Story: Let's say we're implementing a new driver in our 'exp' branch and we're committing even unbuildable code, of course, git lets us do it. But you won't send the whole change history to any public list. Once you finish the driver you send only one patch with the finished driver. So, how to do it??

We can change to a new branch, let's say 'new-drivers', and commit the finished file there.

$ git-checkout master
$ git-checkout -b new-drivers
$ git-checkout exp path/to/our/driver.c
$ git-commit -s

2nd tip: Tracking remote branches

Assumptions: you're working on a public tree with at least two branches (master and fix - for example)

Story: Let's say you're working on project.git and that tree has two branches: master (of course) and fix. You wanna track what's happening on branch fix. So you'd run:

$ git-clone http://project.org/project.git
$ cd project$ git-checkout --track -b fix
$ git-pull

From now on, when you run:

$ git-pull

It'll fetch differences for both branches.

3rd tip: Switching a file n-commits back

Assumptions: none

Story: Let's say you wanna switch-back a file N-commits earlier. You'd issue:

$ git-checkout branch
$ git-checkout branch~n path/to/file.c
$ git-diff path/to/file.c

That's all for now...

See y'all

Hi all,

we all know when we're working on public projects we'll always get our patches commented; so how to apply those comments and even though keep the patch-series order??

That's what we're learning today. Let's start?

NOTE: I'm assuming we're using the same 'exp' branch as on previous posts.

First of all we need to create a tag to that bad commit. So:

$ git-tag bad COMMIT_ID

Then we should checkout to that tag:

$ git-checkout bad

Edit that bad file to apply the comments and after that:

$ git-add /path/to/modified/file.c$ git-commit --amend$ git-rebase --onto HEAD bad exp

This will left you with exp checked out and with that bad commit corrected. After testing and reviewing our new changes we can delete that bad tag:

$ git-tag -d bad

That's all.

See y'all

Hi all,

It's getting harder and harder, isn't it?
Not at all

Let's say we have an 'exp' branch where we're implementing a new feature for our project and, of course, committing there. Also, during our development, some interesting work has been done to branch origin (the remote master branch) of our project and we wanna get this interesting work back to our feature. So we would:

$ git-checkout master$ git-pull$ git-checkout exp$ git-rebase master

This will update our exp branch but keep our patch-series as top-most patches. If, during this process, we have a conflict we should solve it by editing the conflicted and run:

$ git-add /path/to/conflicted/file.c$ git-rebase --continue

NOTE: Do not use git-commit during this process.

After this, run:

$ git-log

To see your patch-series updated and still as top-most patches

That's easy

See y'all

Hello all,

after a long, long time I'm back to show you how to modify the top-most commit.
Let's try it?

First of all, you just edit the file:

$ vim file.c-- Save and quit

$ git-add file.c$ git-commit --amend

And that's all. You're gonna commit the changes on the same commit you were.

Easy, isn't it?

On later post we'll see how to use git-rebase.