blog.felipebalbi.com

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.

Read the rest of this entry »

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.

Hello all,

This is really simple to do once you know how git works.
If you managed to follow the previous post, the only thing you have to do is start a sshd in you server machine and add users to it.
Remember to use

git-shell

as the shell to your users

When cloning a repository, you should use:

$ git-clone git+ssh://username@/path/to/project.git/

And that's all. You can pull and push via ssh.

Simple isn't it?

Hi all,

After a while without posting I'm back and we'll see how to serve a git-server through a ssh tunnel.
This is the easiest way to serve git to other users. It'll be quite a few steps, but in the end it'll be just nice to serve git to others.

We're assuming here you have some "untracked" source code and want to serve it through git. So let's start.

First of all, let's create a user to own our sources:

# adduser devel

And now add our own user to devel group:

# adduser username devel

We now create a folder called git inside /home/devel:

$ mkdir git

Obs: we're using user devel here.

Let's say our project name is 'Project', so let's create its gittree:

$ mkdir project.git

Obs: the .git at the end of project is needed

And now we initialize a bare git tree and share it to all group users:

$ cd project.gitproject.git$ git --bare init --shared=group

Now we go back to our user and initialize a git there. We'll also configure a remote called origin which is where we'll push our sources:

$ cd /path/to/our/sources$ git-init$ git-config remote.origin.url /home/devel/git/project.git/

Ok. We now have our local gittree initialized and ready to send patches to our git server but we have no commits in our tree (remember, we're assuming you have an untracked source code tree).
We need to add the files to our local gittree and start commiting them, after that we can push those commits to our local server tree:

$ git-add .$ git-commit -s

Obs: remember to clean-up your tree before git-add'ing the files. Whithout cleaning it up, you'll probably commit some garbage like .o files, ~ files, etc.

We now have an initial commit on the project, which we're gonna push to our server tree:

$ git-push origin master

And it's all done. We can use a gittree through a local server now. Next post we'll see how to serve it through SSH. It's quite simple once you really understand locally serving gittrees.

See y'all

Hello all,

We said we'd take a look at git-config before keep going. So let's go...
This post will be some kind of notes. I won't explain in a detailed way since it's not difficult. You just need to see the commands and you'll be able to understand what's happening:

This will export your name for all git repositories, don't worry when commiting again.

$ git-config --global user.name "My Name"

Same as above, but for email

$ git-config --global user.email mymail@mydomain.com

Use your smtp server when git-send-email'ing

$ git-config --global sendemail.smtpserver smtp.mydomain.com

Stripping whitespaces before commiting

$ git-config --global apply.whitespace strip

Use the .diff extension when git-format-patch'ing

$ git-config --global format.suffix .diff

Hello again everybody,

Now we need to learn how to update our git tree (and of course, all of its branches).

issuing:

$ git-pull

In the master branch will pull and merge every single new commit locally. To update our local branches we just need to issue:

$ git-pull  master

This will get the updates in the master branch and merge them the local_branch.

Now that we have an updated tree, let's check if our patches have been applied, we just issue:

$ git-cherry master 

If is there any un-pushed commit, it will print the commit id.

That's all for today. Next post we're gonna play a bit with git-config before keep going with patch management.

See y'all

Hello everybody,

How to format patches and send them away?
It's just a couple of commands. Let's see how?

First of all you need to commit local changes to your local development branch. So let's do it:

$ git-status$ git-add   ... 

Now, we need to check out the logs:

$ git-log

And get the commit id just before our first commit. And then we type:

$ git-format-patch -o patches_to_send  .. HEAD

This will put all our patch series into patches_to_send/ directory. Now we can send them away.
Just issue:

$ git-send-email --to list@domain.com \--from "My Name " patches_to_send

This will send all the patches in patches_to_send/ directory.

In the next post, we're gonna learn to update our tree (and all our local branches) and track our pending patches.

See y'all