Use environment variable to know where the config file is

[drimer]

This branch adds an interesting option which will allow us, as developers have our own configuration file in a different directory than the project.

We really need this, particularly because the changes we make on this file always get in the middle of our work and commits, and we end up running git stash and git stash pop between checkouts and pulls.

Not only this branch is useful because of that, but also it has been a good chance to introduce an important new bit of the test infrastructure.

[drimer]

This is what I was talking about two days ago. I hope you like it. Any improvement, suggestion or issue is very welcome.

As I said, there are some other ways to sort this out... But this is your best bet to tackle it. I've dealt with this same problem reg. configurations before and this is the most comfortable thing to do.

[plutec]

All ok, ready to merge! :)

[drimer]

Here's the little trick I said I wanted to show you. Well... First, as an intro, just to say that, because I work in a team of developers and we use a peer-code reviews process, one of our beliefs is that the git history should be as neat as possible. That's a very important fact that not only has an influence on how I write code, but also on how I organise my work in very simple commits trying to keep a neat commits history.

Without going into detail on any of those things, I just wanted to note a few very simple rules of thumb that can be used: 1) Use branches for any different aspect you're working on (remember: branches are free, and help you organise your work). 2) When merging, first rebase on target branch.

So... basically, that little trick, which is what I always do (and what I'm gonna do now), in order to merge overwrite-settings:

$ git checkout master
$ git pull  # probably, since you started working on something, there have
            # been additions in master
$ git checkout overwrite-settings
$ git rebase master  # To avoid fuzzy branch-merging "from the past"
$ resolve-conflicts-if-there-is-any
$ ./tests/run-test-suite.sh  # For sanity check
$ git checkout master
$ git merge --no--ff overwrite-settings

Note the --no-ff option. GitHub, by default uses this flag, but it doesn't rebase your branch on top of master (which is veeeery bad, so avoid using the Merge button in the web, and do this in your terminal).

By using --no-ff, in the future when you open gitk to review your code, you'll see what bulks of commits used to comprise a branch on their own. A good point of this is that, in case you need to revert some changes, you'll see instantly how many commits you should revert if you don't want to leave your code in a bad state.

This gives you to some felixibility and lets you add antoher rule: 3) Every commit in master must pass the test suite. HOWEVER, if a commit is part of what used to be a branch, it doesn't have to pass the test suite.

There's a very good reason for that, and it's this: when you introduce a new feature, if you're using TDD correctly, you would add a unit test in the first commit and then implement the feature in a future commit. And that... would make the first commit fail the test suite:

master:  -> c1 -> c2 ----------------> c3
                    \                /
      feature:        -> f1 -----> f2 
                         |         |
                       Test       Test
                      failing     passing

Graphically, in gitk, this will tell you: "Oh! So you want to revert f2. Very well then, but you should know that it was added alongside with f1, so you'd better revert that too, just in case."

Note that, if you don't rebase you branch on top of master, this gets much more dirty. For example, note that you develop branch comes from the commit 00cdae0265da197a2f8826133646b98175a153b7.

That's basically because you've been reusing the same branch, which is not bad, but you've never rebased it on master since then. In the example case, if you don't rebase your branch when you reuse it, it won't contain c3!! So, when you merge it again, it will be coming from a more remote past, which results in unnecessarily long branches.

[drimer]

Merged in 3ccb5a64a5baa22d2ff83943a09e053ab8300586