1

There really is a question at the end of this wall of text. It just takes some set-up to get to. I appreciate your bearing with me.

I have a project I'm tech lead on, with two other developers. Some time earlyish but not actually at the beginning of the current phase of development, we got interested in git.

I imported the SVN working directory into git. The three of us were working on features to be deployed in order (nicknamed "promo", then "map", then "survey"). So, not really knowing any better at the time, I branched "map" from "master", and "survey" from "map". I would do it differently now, but a few months ago, that's how I did it.

The developer working on the "first" project, "promo", kept working in SVN, and I manually kept the master branch in sync with his changes, periodically merging them through the feature branches. It looked like this:

* ------- master (in sync with svn and containing work for "promo")
 \*------- dev/map
   \*------  dev/survey

So last week "promo" went live and yesterday "map" went live, and this whole thing was ripe for some cleanup.

The production push methodology was, I did git diff --stat master..dev/map to find all the changed files, and manually FTP'ed them to the production server.

Once that was tested and accepted, I went:

git checkout master
git merge dev/map
git branch -d dev/map

So now master represents what's on both the staging and development servers. Then:

git checkout -b production
git checkout -b development
git checkout -b hotfix

So now I have a branch for what's on production, one for integration, and one for the inevitable quick-fixes into production. I can think of dev/survey as a branch off "development".

I did the git remote commands to mirror and push all these changes to my central (gitolite) repo. It wouldn't let me push :master because that would be confusing on clone--and I do get that, but I'll probably configure it to let me go ahead and do that.

So then I asked my guy working on "survey" to pull down all these changes, and use git diff --stat to find his changed files to put up on the staging server. When he did that, he got a LONG list of files that seemed unrelated to his changes. He did get all these new branches, but somehow didn't actually get all the commits or something.

I had him get a clean clone of the repo, and he got all the changes I intended, and was able to get his work up on the staging server for testing.

The question is: what happened on his repo, when it was confronted with all these branch changes? I thought a branch was just a special case of a tag--a tag that moves along with HEAD. It should have just gotten all the right goods, shouldn't it?

Dan Ray
  • 21,623
  • 6
  • 63
  • 87

1 Answers1

0

Somehow the master on the gitolite repo has a different history than the master on the git repo of the developer.
So it not so much "what happen on his repo?" as it is about "what happen (during the push) on the gitolite (central) repo?".

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Well, but a fresh clone got the good goods. That's what puzzles me. – Dan Ray Jul 20 '11 at 17:41
  • @Dan: using a fresh clone, you reset the local history of the master branch to the one of the remote gitolite one. The diff proceed on a repo with a coherent history as opposed to a diff between a local branch made from a "different" master and a remote branch started from a different master. By looking at a common ancestor, Git was forced to go back all the way in that case. – VonC Jul 20 '11 at 17:51