Bugzilla – Full Text Bug Listing
| Summary: | resource "dimensions" and common UI for switching | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | johnjbarton, libingw, tomasz.zarna |
| Version: | 0.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
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. |