Database Version Control with Git

If you change a file and do NOT commit that file, when you change branches, that file will still be there and if you do status it is the new file. The only way you will have 2 different files in 2 different branches and they get switched out when you change branches, are if both of those files are committed to their respective branches.

This is because git, like most scm, doesn't blow away any modified files that have changes that have not yet been committed when you switch branches in the same folder.

Since the database dumped to the same location on each branch and conmmited, once you change branches, the drush sqlc < path/sqldump.sql is supposed to connect to that file that is in version control.

I am making progress. it looks like as I move from branch to branch and up and down the timeline, the datestamp of the dump file (and interestingly the parent directory and all it's other files) are of different sizes. If I checkout my initial commit from days ago, that dump file in the working directory has a current timestamp of when I checked out the repo, and not the time it was commited a few days ago...but the reported file size is changed.

More testing...

After several hours I have come to the conclusion that Git is "working" as designed, just not to my satisfaction. Being new to Git, it seemed reasonable to assume that if I worked on a fileA in one Branch (1), committed those changes and then worked on another Branch, regardless of what I did there, when I came back to Branch (1) 5 days later, my fileA would still be there in the same condition as I left it and have a timestamp from 5 days ago.

Apparently this is just "wrong" thinking. Git compares file changes in the working directory from one branch checkout to another. If two identical tracked files in their respective working directories were not touched in either Branch, Git will leave it alone. Makes sense to me!

However, if a file is tracked between branches, and it is changed in any branch, when you switch branches, Git will present the contents of the file the way you left it, but change the timestamp to the current time. This is true for directories as well.

I discovered in my database issue that I only thought my changes were not being saved from past commits because the timestamp kept changing as I moved back and forth between checkouts. Since I was using the same SQL file for my DB in both branches, Git was changing the timestamp every time I switched branches.

Finally I looked a the actual SQL-DUMP files and saw that the changes were being preserved.

This timestamp changing behavior is by design for some Make/Build responsiveness reason that I cannot yet understand. It helps Git be as fast as it is, by not doing something it would have to if the timestamps were kept intact. It's beyond me.

Anyway, thanks for the help and if you want to see this for yourself, here is a "example case."

git init
touch filea fileb

* $ ls -l

total 0
-rw-r--r-- 1 JSCS Administ 0 Apr 27 21:00 filea
-rw-r--r-- 1 JSCS Administ 0 Apr 27 21:00 fileb

$ ls -l > filea //this is the last time Master writes to this file

* $ ls -l
* total 1
* -rw-r--r--    1 JSCS     Administ      132 Apr 27 21:00 filea  
* -rw-r--r--    1 JSCS     Administ        0 Apr 27 21:00 fileb

git add .

git commit -m "first commit"

* [master (root-commit) 159c1e6] first commit
*  1 file changed, 3 insertions(+)
*  create mode 100644 filea
*  create mode 100644 fileb

git status

* # On branch master
* nothing to commit (working directory clean)

touch fileb -t 200912301000

* $ ls -l
* total 1
* -rw-r--r--    1 JSCS     Administ      132 Apr 27 21:00 filea  **Still same time on Master
* -rw-r--r--    1 JSCS     Administ        0 Dec 30  2009 fileb

git status

* # On branch master
* nothing to commit (working directory clean)

git checkout -b dev

* Switched to a new branch 'dev'

ls -l

* total 1
* -rw-r--r--    1 JSCS     Administ      132 Apr 27 21:00 filea
* -rw-r--r--    1 JSCS     Administ        0 Dec 30  2009 fileb

ls -l > filea ** writes to filea

* total 1

-rw-r--r-- 1 JSCS Administ 132 Apr 27 21:10 filea **Dev file time advances
-rw-r--r-- 1 JSCS Administ 0 Dec 30 2009 fileb

git status

* # On branch dev

Changes not staged for commit:

(use "git add ..." to update what will be committed)

(use "git checkout -- ..." to discard changes in working directory

#

modified: filea

#
no changes added to commit (use "git add" and/or "git commit -a")

git commit -am "First Dev Commit"

* [dev a5b0c75] First Dev Commit

1 file changed, 2 insertions(+), 2 deletions(-)

git st

* # On branch dev

nothing to commit (working directory clean)

ls -l

* total 1

-rw-r--r-- 1 JSCS Administ 132 Apr 27 21:10 filea **still same DEV time on file
-rw-r--r-- 1 JSCS Administ 0 Dec 30 2009 fileb

git checkout master

* Switched to branch 'master'

ls -l

* total 1

-rw-r--r-- 1 JSCS Administ 132 Apr 27 21:16 filea ##file timestamp is now advanced even though master never touched this file since last commit.
-rw-r--r-- 1 JSCS Administ 0 Dec 30 2009 fileb

I see another mydrupaljourney blog in the making!

I am still working this workflow thingy.

Sometimes I work from my laptop and sometimes the desktop PC. The main repo is on bitbucket.

The Laptop and the PC have identical (except for user.name) .git/config, .gitconfig, and git/etc/config files.

But the results of git remote show origin differ in one area:

Laptop:
Local branches configured for 'git pull':
dev rebases onto remote dev
master rebases onto remote master

PC:
Local branches configured for 'git pull':
dev merges with remote dev
master merges with remote master

I cannot for the life of me figure out why they are different, how to fix it and which one I should fix?

That's is what I thought initially too Mike, but all my git configuration files are the same between the Laptop and PC, including the .giconfig's which include:

[push]
default = current
[branch]
autosetuprebase = always

So really, with that setting, the PC should also say "rebase" just like the Laptop does now, since it has the same setting.