Git

[yorik]

I'm getting more confident with git! I just added a branch of shoogen from github and merged it with our master branch... Incredible how this is easy! And when committing, the whole history of shoogen goes together, with his author name. I find that really cool, people can contribute to freecad and have their name appear, even if it is someone else who does the final commit.

About all the commit messages, I begin to understand that it is how git works... Every small action such as Merge is registered by a commit message, that's the way it works and we shouldn't worry about it.

One thing I don't know how to do, that might be useful, is to change the committer name. For example, shoogen worked on the Draft svg importer in his github branch. I fetched his branch, reviewed, then merged in our master branch. All the commits he did now appear in our commit log, which I found cool. But they also appear as committed by him (in git author and committer can be different). Maybe it would be nice to have the committer name as the person who pushed into the official repo, so we can track who was the "contact" but I couldnt find out if it is possible...

[jriegel]

You can rework commits, but your problem is much easier to solve. Just look at the branch history and you see your commit on master which integrate the foreign branch.
With TortoiseGIT is good to see...

[shoogen]

One short note for those who intend to use github. If you fork an existing repo you can use browse those nice network graph. I would recommend to fork the one from danielfalck. The repo from jobermayer will likely give you (or the integrator) some headache ('warning: no common commits').
EDIT
The repo from danielfalck has been cloned from sf. You can see that the first commit is from wmayer on 10.10.2011. Therefore there will be a common commit in the history. And merging is generaly possible. Fetching from sf is always a good idea to have your repo up to date. And the only way to be shure to have the right one;)
The commits in jobermayer's are generated by some svn2git conversion utility and do not corospondent to commits the sf git repo. I see it as nice way to visualize the Freecad history.
/EDIT
The work the integrator has to do depends. Mainly on, how much effort the maintainer of the branch makes, to solve conflicts beforehand.
For example I just merged the master to my branch to make it easier to pull. This thook me some time, because i didn't find a suitabel merge strategy. It's was not even recognized as a conflict but simply auto-merged. This was because some old code fragment became 'new' via merging back and forth with SVN. In that case Jürgens commit 1779de2 was the cause, which even broke the bezier functionallity in importSVG that time. (Yesterday it gave me some headache when I was testing, and even with master branch it didn't work again)
I was lucky because I could work arround it by removing importSVG.py from the (commit) index which merged the master branch to my branch.

[jriegel]

Syncing from SVN back and forth will cause some problems. We have to keep an eye on that!
I would not recommend to merge back a repo not cloned from our sf.net git repo.

[shoogen]

It works perfectly fine to create the repo at github by forking danielfalcks repo, without ever fetching/pulling from from there. Instead I only clone/fetch from sf and only push to github.
@jriegel: do you have any other suggestions, where to put one's personal repo?

[tanderson69]

The work the integrator has to do depends. Mainly on, how much effort the maintainer of the branch makes, to solve conflicts beforehand.
For example I just merged the master to my branch to make it easier to pull.

Not a git guru, but of course I have an opinion . I agree with what you are trying to do, as the integrator should not be resolving conflicts in code that he/she has no experience with. I think a rebase of the branch is a better strategy than merging master to the branch. The ideal here is that the merges are always fast forward, not always possible but a good goal to shoot for.

[jriegel]

No problem to give everyone write access to our repo, as long as he/she obeys the rules and leafs the master untouched...
Its much easier to advise and help if the dev branch is in our repo and we can just easily switch and diff...

[tanderson69]

I think a rebase of the branch is a better strategy than merging master to the branch. The ideal here is that the merges are always fast forward, not always possible but a good goal to shoot for.

Talking to myself again I wanted to make a better case as to why I think merging master into a feature branch is a bad idea. Once you do this merge, your feature branch will have a mixture of your feature commits and the master branch commits. Obviously the end game for your feature branch is to merge it back into master. At that point git has to figure out what commits on that branch are the feature commits and which ones came from the master. Git is able to do that really well in certain conditions. Now lets say that before you merge this feature branch into master you want to clean-up your commit history so things will be nice and clean for the master branch. you use git rebase -i and do a bunch of really fantastic stuff to your feature branch. Then when you merge the feature branch into the master chaos ensues. Once you did your rebase, git can no longer distinguish the master commits from your feature commits on your feature branch. So you say well we just won't use rebase. That will probably solve the problem, but take out one of the best features in git. Take a look at this guys experience. http://stackoverflow.com/questions/4579 ... -questions. He doesn't mention a rebase after the "master to feature" merge caused his problems, but I am guessing it did. Most catastrophic errors come from screwing up with rebase.


One warning: from link

"Essentially, create a feature branch, ALWAYS rebase from master to the branch, and merge from the branch back to master. Important to note is that the branch always stays local."

This sounds backwards too me. Just to clarify when you rebase, you have your feature branch checked out and you

Code: Select all

git rebase master

rebasing has a downside for feature branches tracked on other repositories. Once you rebase, the link between the repos for the feature branch gets broke and you will have to setup the tracking branch again. That can be hassle, but much easier than resolving a mountain of conflicts. Hopefully this will save some head-aches in the future. I can sympathize with that guy when he says

It took me a day to sort everything out

Been there, done that, bought the tee shirt

[shoogen]

Once you rebase, the link between the repos for the feature branch gets broke and you will have to setup the tracking branch again.

I tried to rebase. To me it meant that my commits were duplicated. When it comes to preparing a merge into master I found it much more usefull do 'squash' at the same time. The changes are aggregated into one or a few commits, and the history would be broken by 'rebase' anyway.

What procedure would you recommend to merge changes from SVN to a local Git repo. I need to have at least SVN 5404 but I want keep up with Yorik's changes to git.

[jriegel]

To stay tuned on SVN you just sync master from Git. I put the SVN changes into git from time to time (every some days so far).

On rebase before merge I have no opinion so far, I still experimenting. some time git gave me a headache! Its a very complicated tool!