(I do not want to checkout as "develop2" just because develop has diverged!) The idea is using an existing local branch that is already tracking it, not create a new local branch. I am not a git command line wiz, but I suspect it might not be obvious to implement this without being absolutely certain that there is no possibility of loosing something because maybe the origin diverged wildly differently while the operation is executing.Example: current branch is branch1 want to checkout 'develop' but develop diverged and requires a pull (an extra step). I also understand that there could be multiple local branches tracking the selected target, well, this is why you would have a branch selector similar to the one that is already present but only showing branches that are tracking the target. I certainly do not want to create a local branch "develop-2". I think SmartGit can easily detect if it is safe and perform a checkout without loosing anything. In the picture, I right-clicked the "origin/develop" yellow branch and did "Checkout". I believe we can detect this case and simply not allow to perform this "direct" operation. If you mean a local commit on 'develop' that has not been pushed to 'origin', then I understand you would need a re-base of some sort or it's gone. Although I don't know why we couldn't simply go into the standard Stash/Apply dance. If you mean uncommitted changes, then yes, in that case it might not be good. In this case, a git pull on 'develop' would immediately jump to 'origin/develop'. I am not sure what you mean, but in the attached picture, SmartGit says "Local branch 'develop' is diverged from checkout target 'origin/develop' - this does not seem to match what you are talking. I think we could safely add another option. From a Git standpoint, we could have saved lot of time by going directly to the other commit without going through a very old commit first.Ĭurrently this case is already detected in SmartGit and a dialog with a few options are shown to the user. In the case that the pull step would presumable restore the branch to a fairly recent state, then we could have saved us the heavy back&forth in history. Optimization large repo with long history: switching to a branch that has diverged for a long time on a large repo can be very slow (because of the large number of files to change). PR workflow : PR systems often merges a PR branch to develop/master, locally switching from a PR branch that just got merged by such system to the latest "develop" would often yield near-zero change and would be more "friendly" with system that looks for changes on disk to "reload" pages and such. This is not an operation that is well done when performing a checkout and submodules directories gets in the way when switching back & forth in history. Submodules: Over time submodules can be changed (added/removed). Example: current branch is branch1 want to checkout 'develop' but develop diverged and requires a pull (an extra step).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |