How to manage Git remotes?

[NormandC]

Hey guys,

I still struggle a lot with managing Git remotes. Well, with managing Git.

So far, to test development branches, I was creating separate directories where I pulled the complete source code. But it takes a lot of disk space, and makes for many folders since I use out-of-source builds.

I would really like to manage all FreeCAD code in a single source directory.

I git pull FreeCAD from the original SF Git repo at git://git.code.sf.net/p/free-cad/code

I would like to import ian.rees' Github repo in it to check out his Drawing-dev branch.

I followed this old post from yorik:

Code: Select all

git remote add ianrrees git://github.com/ianrrees/FreeCAD_tinkering.git

Now, typing

Code: Select all

git remote

gives me

Code: Select all

ianrrees
origin

But if I type

Code: Select all

git branch -a

It only lists the remotes/origin/ branches.

How do I list the ianrrees branches? And how do I checkout the Drawing-dev branch? I've tried this which didn't work:

Code: Select all

git checkout remotes/ianrrees/Drawing-dev
error: pathspec 'remotes/ianrrees/Drawing-dev' did not match any file(s) known to git.

Thanks!

[NormandC]

Found it, I think! After

Code: Select all

git remote add ianrrees git://github.com/ianrrees/FreeCAD_tinkering.git

I needed to

Code: Select all

git fetch ianrrees

Then:

Code: Select all

git branch -a
* master
  releases/FreeCAD-0-15
  remotes/ianrrees/Drawing-dev
  remotes/ianrrees/aa-change-dialog-fix
  remotes/ianrrees/add-CxImage-readme
  remotes/ianrrees/cmake-doxygen-dot-fix
  remotes/ianrrees/doxygen-fix20140321
  remotes/ianrrees/doxygen-undoc-fix
  remotes/ianrrees/enumerations
  remotes/ianrrees/expand-export-format-list
  remotes/ianrrees/fix2064
  remotes/ianrrees/mac-app-bundle
  remotes/ianrrees/mac-build
  remotes/ianrrees/macports-build-1
  remotes/ianrrees/master
  remotes/ianrrees/mdi-warning-macos
  remotes/ianrrees/measurement_tool_cursor
  remotes/ianrrees/mouse-nav-aspectratio
  remotes/ianrrees/open-file-cleanup
  remotes/ianrrees/open-file-cleanup2
  remotes/ianrrees/property-work
  remotes/ianrrees/propertyview-remember-last-tab2
  remotes/ianrrees/read-unordered-zips
  remotes/ianrrees/remember-placement-relative
  remotes/ianrrees/sketcher-antialiasing
  remotes/ianrrees/sketcher-box-selection
  remotes/ianrrees/sketcher-cancel-auto-constraints
  remotes/ianrrees/sketcher-icons
  remotes/ianrrees/sketcher-icons-remove-debugging
  remotes/ianrrees/sketcher-keyboard-shortcuts
  remotes/origin/HEAD -> origin/master
  remotes/origin/Post-PySide
  remotes/origin/dvdjimmy/MachDist
  remotes/origin/jriegel/Cache
  remotes/origin/jriegel/Jt-Reader
  remotes/origin/jriegel/NewWinBuild
  remotes/origin/jriegel/Rift
  remotes/origin/jriegel/dev-assembly-old
  remotes/origin/jriegel/dev-assembly2
  remotes/origin/jriegel/pcl-dev
  remotes/origin/jriegel/review-NewLibPack
  remotes/origin/jriegel/sketcher-update
  remotes/origin/logari81/PartDesign
  remotes/origin/logari81/PartDesignPattern
  remotes/origin/logari81/sketch-diagnostics
  remotes/origin/logari81/sketcher
  remotes/origin/master
  remotes/origin/master-spreadsheet
  remotes/origin/releases/FreeCAD-0-13
  remotes/origin/releases/FreeCAD-0-14
  remotes/origin/releases/FreeCAD-0-15
  remotes/origin/review-CL-Bundler
  remotes/origin/sanguinariojoe-plot
  remotes/origin/sanguinariojoe-ship
  remotes/origin/snaptools
  remotes/origin/surfaces
  remotes/origin/tanderson-dev-expressions1
  remotes/origin/tanderson-dev-modelRefineBug
  remotes/origin/tanderson-dev-partOffsetFill1
  remotes/origin/tanderson-dev-partOffsetFill2
  remotes/origin/tanderson-mac-spaceball
  remotes/origin/tanderson-merge-assembly-pd-pattern
  remotes/origin/tanderson-merge-modelrefine
  remotes/origin/wmayer-spaceball
  remotes/origin/wmayer/double-precision
  remotes/origin/wmayer/featurepython
  remotes/origin/wmayer/pcl-testing
  remotes/origin/wmayer/remote-debugger
  remotes/origin/yorik/archstyles

Lotsa stuff to play with!

[wmayer]

Often other people's branches are behind some bigger commits in master. So, when you switch to the branch and later back to master you end up in building FreeCAD twice.

If the test branch doesn't include too many commits you first fetch the branch, make and checkout a local branch based on current master and cherry-pick the commits from the test branch.

Example (from the pull request viewtopic.php?f=27&t=10681):

Code: Select all

git fetch https://github.com/ianrrees/FreeCAD_tinkering enumerations
git branch enum # choose whatever name you  want here
git checkout enum
git cherry-pick e7c61facb17e10db4a2b8d68b1888b22a7156c8c

[PrzemoF]

After setting up remote/fetching you can use:

Code: Select all

git branch --track my_local_name_of_a_remote_branch ianrees/sketcher-icons

to create a local branch tracking the remote branch

[tanderson69]

Off topic:
Norm,
Your list of remote branches is out of date with respect to deleted branches. You need to:

Code: Select all

git remote update --prune

[NormandC]

Thanks for the tips, guys.

@tanderson69: no, this is exactly on topic I think!

Often other people's branches are behind some bigger commits in master. So, when you switch to the branch and later back to master you end up in building FreeCAD twice.

Ok, please bear with me, I'm not sure I understand everything.

Right now, I pull/fetch/checkout everyting into the single directory "freecad-code". I have a "freecad-build" folder where I compile from master, and I have a third folder "freecad-drawing-dev" to compile the remotes/ianrrees/Drawing-dev branch.

If I understand correctly, your example works in the case I would compile the "enum" branch in my freecad-build directory, and it would allow me to compile it a lot faster than in a separate folder?

What happens if I don't cherry-pick the commit?

[shoogen]

What happens if I don't cherry-pick the commit?

If you use a branch which is far behind the master, all files will be changed to that old state and the incremental build will take longer.
I issued some pull request for the sole reason reduce such differences.
But if the the differences between the master branch and the development branch. Checking out other peoples branches might be sufficient.
I prefer another work flow.
I create a testing branch, based on master. Then I merge every development branch into my testing branch.

Code: Select all

#!/bin/sh
git fetch origin
#git rebase origin/master master
git checkout -B testing origin/master
git merge --no-edit $*

According to my bash history I used this script the last time as follows:

Code: Select all

./testing.sh debian-workaround danfalck/path-module dev-skiprecompute dev-fuzzyboolean dev-profile-shift bugfix2018-master dev-bb

I changed the version information to handle such octopus merges specially. Instead of setting the branch name to "testing" it follows the names of the branches in the last octopus merge.

Code: Select all

OS: Debian GNU/Linux 7.8 (wheezy)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.4897 +367 (Git)
Branch: master,debian-workaround,danfalck/path-module,dev-skiprecompute,dev-fuzzyboolean,dev-profile-shift,bugfix2018-master,dev-bb
Hash: 34b7385d7909baa613e7e175218622f3ed6a5e61
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 4.0.0a

The merge may fail because of conflicts. Mostly this is because a single development branch could not be merged (or rebased) on the current master automatically. Sometimes there are conflicts between different development branches.
However. Those conflicts would show up later anyway, when merging the development branches into the master.
So I prefer to notify the developer early, that there is a conflict.
Sometimes I help then so resolve the conflict early. If they don't care at all, I ignore their branches.

[tanderson69]

norm,
Just so you know. What Werner and Shoogen are doing are saving time when building (make -j?). You don't have to do these things if you don't mind waiting for builds. I would suggest for now that you keep things simple and have just one source directory and one build directory. Let the build times frustrate you enough to warrant the added complexity.