On 27.04.2014, at 17:19, Sean P. DeNigris <sean@clipperadams.com> wrote:
Goubier Thierry wrote
I didn't understand that you could, instead of the branch, use a tag or a commit ID as the version identifier
Something interesting I read recently that helped me understand git better is that a "branch" is just a pointer to a commit, just like a release tag.
correct.
The history of the branch is available, not because there is a "branch object" that stores/calculates it, but because commits are linked back to their ancestors.
exactly.
If you arbitrarily change the #myBranch pointer to point to a different commit, you'd automatically get that commit's history.
yes.
So I'm seeing that there is a tree of commits, with references to various leaves, called "tag" or "branch" or "id" depending on the use context. IIRC even when you do a rebase it doesn't change that commit (call it x), but creates a new commit x' and changes the pointer to point to it.
Thatâs essentially right. The problem with rebase however, is that the branch (e.g. âdevâ) will point to a different commit *with different history* after the rebase. So as soon as you have shared any of the commits that are part of the rebase, the people that have pulled from you will (usually) be forced to reclone your repository since Git canât know that a rebase happened (one could manually reset the branch to a common parent and then apply the pull, but you donât really want to do that). Some open source repository owners advocate a strict âno mergeâ policy, which implies that contributing developers canât merge their work into the public branch. Instead they are required to perform a rebase. That works (as said above) as long as none of those commits were shared. Iâm not a big fan of rebasing⦠:)
I am a git beginner, so feel free to correct or augment the aboveâ¦
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fast-way-to-load-package-form-github-tp4756579p4756686... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.