We only need to resolve merge-conflicts created by our own edits. Good news is, once subtrees are set up through command-line, they are transparent to Smartgit! Merging updates from upstream into each respective subtree works like a charm. Sage deep down the tree): git subtree add -prefix=site/web/app/themes/sage sage master -m "Add Sage subtree" Submodules do not work for this use case, as explained. We only need to manage the path where each sub-repo is checked out, as they do not live in different subfolders. So it makes sense to keep the entire code in a single repository. Yet we want to receive diff updates on the code, which is not possible by cutting the link to the original repos. added more steps to deploy additional software on the server. The particular about this environment is that we pull Trellis, Bedrock & Sage not as dependencies, but as source the we modify. That's a shame, because we lose the power of git and every update equates to a fresh install. Subtree is particularly useful when working with Roots, a powerful Wordpress framework.ĭocumentation for Roots & its subprojects recommends installing by pulling the git repo. Should it be more like the Submodule Add wizard? Should it be a simple operation which can be executed on any selectedīranch to add it as subtree, like Subtree I'm wondering how the GUI could look like IMHO, for core subtree operations, there is now just "git Local-remote-branch categorization and would raise several "Features" or "Local Branches") is that it's orthogonal to SmartGit's current The problem with a dedicated "Subtrees"-category (like Subtree-related functionality in the Branches Those (few?) users which actually work with subtrees can add theĬorresponding subtree repository as additional remote and thus will get more Logic, like merging or cherry-picking from subtrees, will We could even hide them by default as longĪs there is no. The only visual difference for them will be ♣ symbols for Subtree-enabled repository which shouldn't be interested in the presence of Git's core subtree design and should be sufficient for most users of a The display of subtrees is kept really simple, by justĭenoting subtree Branches and Log Graph commits by ♣. Note that most of the functionality requires that a subtree had been initialized with "git subtree add", in order to have meta data present in the initial subtree merge commit message, like: SG-13693: Subtree: denote subtree refs in Log Graph, Journal and Branches SG-13686: Subtree: "subtree merge" command SG-13685: Subtree: "subtree split" command SG-9149: Log: distinguish between allowed and not allowed cross-subtree SG-9149: Journal: distinguish between allowed and not allowed SG-9149: Branches: distinguish between allowed and not allowed I have now uploaded 20.2 preview build 16021 which
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |