Community
Participate
Working Groups
in our work on the Orion page anatomy (http://wiki.eclipse.org/Orion/Page_Layout#Defining_Page_Elements), we've left room in the banner for 1 to n "dimension switchers." The dimension switchers are also in various banner mockups (such as "master" and "local" shown in the mockup at https://bugs.eclipse.org/bugs/attachment.cgi?id=210135). The idea was that something like branch switching could be something that the git plugin would contribute to other pages. Basically, if we can determine the branch and repo for a resource, we could offer ways to switch branches or between local/remote from that page. We have space reserved for dimensions in the banner but have not implemented for 0.4. I realized in M2 we wouldn't get to this, but I didn't realize we never had a bug for this work. We've just had the anatomy and the mockup, and some discussion in a number of other different bugs. As I close various RC1 bugs for "related links" I will put use cases for any "dimension" work in this bug. I'd like to look at this early in 0.5 What it means is that: - we could branch switch in nav, editor, etc. without going to a repo page - we could have "switch to remote/local" and "switch branches" pages in common places on the banner vs. putting branch info in the breadcrumbs and having toolbar commands that do these things.
the original comment re: branches was in bug 359277. jjb had the opposite wish: >I wish the navigator and edit pages showed me the branch name. >I wish the branch name linked to the git status page.
*** Bug 372423 has been marked as a duplicate of this bug. ***
I recently learned more about git. The changes on the working files are not -- as I was imagining -- devoted to the current branch. Rather the current changes are closer to an uncommitted patch. The current branch has two roles: it's the reference for the patch and it's the default for commits from the working set. The most significant result from this understanding is that creating a new branch is *cognitively* cheap, not (only) primarily computer resource cheap. If the user has changes in their working set they can commit those changes to the current branch or they can create new branch and commit those changes. The first path binds the change to the original branch: backing out from the decision is hard. The second path binds the changes to a name that makes backing out or many other actions relatively simple. This leads me to an another switching suggestion: on git-status where we are preparing to commit, make it really easy to create a new branch.
(In reply to comment #3) You are right, the branch just dictates where the commit will go, it's not tied until commit. Some branch manipulation actions cannot succeed with working changes, and I haven't spent the time yet to understand what branch actions I can do with uncommitted changes (some) and when I'm going to get the "dirty working tree" error. I'd like to understand that better. > This leads me to an another switching suggestion: on git-status where we are > preparing to commit, make it really easy to create a new branch. that is really good idea. We should probably have a separate bug for this, because even if we have common branch UI in the page heading, I agree it should be even more visible in git status. Perhaps similarly to the "change author or commit" you could "change branch." For now I'll make a similar note in bug 349328. I'd like to see us think about branch management conceptually and then decide particularly on common support and git status support.
(In reply to comment #3) > If the user has changes in their working set they can commit those changes > to the current branch or they can create new branch and commit those changes. > The first path binds the change to the original branch: backing out from the > decision is hard. That's not that hard, at least in the command line: $ (on master) git commit -a -m 'dirty fix' // oops, I wanted the fix to be on a branch $ (on master) git branch branch $ (on master) git reset --hard HEAD^ // tada! the same result as you would choose the second path
There are really bigger fish to fry in the short run, so I don't see common "dimension support" happening in 0.5. To that end, we should pull the div out of the header as it's not needed.
I don't see us going in this direction until we have more than the "Git branch" use case. I pulled the div out of the header during 0.5.
