Branch Management in Git Fusion

Editor's Notes

• #2: - Already have, or are considering adding, one of our Git solutions. - Recognize benefits of - narrow cloning or the ability to slice and dice your depot into any manner of Git repo - File-level protections - Perforce Helix as single source of truth - Security benefits and the ability to comply with some industry’s regulations
• #3: - Discuss core functionality of our Git solutions - reconciling Perforce Helix branches and Git branches. Two very different models. - Consider the two data models, and what branches mean in the two systems - Look at how these branches are mapped between the systems and what it means to change those mappings - LW vs FP - Lastly, purpose ghost change lists
• #4: Essential characteristics of Helix branches: - Helix branches depict hierarchy - branches of depot hierarchy - Changes to files tracked individually over time - Integration history between file revisions is tracked. Resolve decisions (accept yours, theirs, merge? conflict resolved?) Each decision recorded
• #5: • commit hierarchy: Each Git commit has one or more parents. Can’t say the changelist that came before this changelist is its parent • branch references: Git branch references point to specific commits within the commit hierarchy. • common history across branches: Git history often shares the same sequence of commits across several branches. * anonymous branches: Git branch references can be deleted, or just not included with a git push. The result is that many sub-paths through Git commit history have no branch name.
• #6: Now let’s look at the Git data model. The first aspect of Git history to consider is its immutability. Actually, you can rewrite history, but you’ll probably tick your colleagues off if you do so.
• #7: Anatomy of a Commit Core objects in Git are blobs, which are files, trees, which are snapshots of files and directories, and commits. Commits make are what make sense of it all, and are analogous to change lists. Each object gets a SHA1 calculation Commit message Author of the commit Committer - usually the same as the author Tree Parent(s) - The SHA1 of one or more parent commits. All part of SH A1 calc Did you notice what was not in the commit?
• #8: Git does not store branch info in its core data model. While immutable, much of Git history is unknowable.
• #9: Git history is just a series of of workspace snapshots, identified by its commits A branch is simply a lightweight movable pointer to a commit.
• #10: Git lacks helix concepts Depot hierarchy - Git’s hierarchy is only the workspace tree, or workspace hierarchy, and commit hierarchy Client view mapping - With no hierarchy, there is nothing to map File actions - whether the file was added, edited, deleted, or moved, is not recorded. The action can only be inferred when comparing commits Can’t refer to individual file revisions File integration history - without file actions, per-file integration history is another step removed On what branch was this commit made? not tracked
• #11: - Git history immutable - Changing anything in a commit causes a cascading effect - Commit and changelist become bound Early days Support had admonitions not to do anything that would “break history” “Rebuild” if feasible
• #12: Let’s consider the effects of making various changes to branch mappings, including… Adding a new branch to the repo Removing a branch or depot path Adding a new depot path to an existing branch mapping Adding branch mapping with pre-existing history
• #13: Describe branch mapping example
• #14: Adding a mapping for a new branch has always been expected behavior To go from Helix to Git: Create the branch in Helix with p4 integ or p4 populate Add the new branch mapping to your repo configuration Pull it into your repo
• #15: Same thing from the other side. Say you have a git branch you want mapped to a fully-populated branch in Helix Add the mapping to the repo config Push it to Git Fusion or GitSwarm
• #16: - Core functionality rebuild a repo from Helix - recovery or new instance - Stores commit and tree objects, blobs stored as file revisions - Process commit, tree refers to blob that is no longer part of the repo’s view. Breakage
• #18: 4 changelists. 2 in src directory and the other 2 in a doc folder
• #19: Map src only
• #20: Expected Git history
• #21: Wish you had included doc
• #22: Another look at Helix history Note change 14323 with “start doc”.
• #23: Only 2nd commit in doc included. Earlier history not touched, did not break history
• #24: If doc included from beginning…
• #25: By adding the doc depot path late, you don’t break anything. But it’s not perfect – what if the git user was trying find when a bug was introduced? She’d find the first commit available for this path, but the change that actually introduced it might have come before.
• #26: Next we’ll consider adding a new branch mapping.
• #27: Describe mapping for 2 branches
• #28: note “merge foo” - merge commit, 2 parents - “comment foo” and “explain foo”
• #29: - “merge foo” still there, but only one parent - time of commit was processes, only 1 parent was known - stage branch did not exist for this repo - content same - new history will capture merge commits
• #30: When making most changes to branch mappings, just know: You can’t break Git history Git Fusion protects To most accurately reflect Helix history, think about what is needed
• #31: Next we look at lightweight and fully populated branches, the differences between the two and the options you have for using them.
• #32: - 2013.1 - unmapped branches were LW - LW branches only capture what has changed - Since creating integration history is a bit heavy, this reduced work We had a way to accommodate any Git history But paths are jarring to P4 users – describe path Customers wanted predictable depot paths on the fly
• #33: Enter the fully-populated branch. Fully populated - target depot view reflects the state of the Git workspace for that branch. (To be clear) All mapped branches are fully populated. In 2014.2, we made it possible for Git users to create fully-populated Helix branches on the fly. No longer need update config file manually!
• #34: Describe slide
• #35: Describe slide Our Git solutions generally put no onus on the end user. Git services look like regular git remotes “explicit” setting is an exception.
• #36: Make Helix history reflect Git history Helix needs to branch a file into existence before you can delete it or easily compare a new revision to the previous revision Diffing a new commit on new branch in git is the same as if it was on the same branch Describe branch for delete It’s this conceptual mismatch that led to the need for ghost changelists
• #37: New FP depot path Same for JIT on LW Describe branch reuse - “task1” don’t forget deleting branch locally after first use Create task1 Do some work, push Merge into master, push1 Delete the local branch ref, and push 1 month later reuse task1 Do some work, push task1 – totally new basis, from a new parent
• #38: Describe slide – identifying features
• #39: Hopefully you better understand ramifications of making changes to repo branch mappings - You recognize how projects are structured in Helix and how Git users will use the repo, and how the repo will likely evolve, will help you define your repos from the beginning You have better idea whether to use FP branches on demand See a ghost, don’t panic, you can figure out how it came about