> But then again, you really want to support two different things: > > * Showing the currently checked out branch, whatever that might be, > and update to a new branch if someone switches (through the CLI, for > instance). > * Showing a specific branch, which just happens to be the currently > checked out branch. If we then switch to another branch on the CLI, > you still want GitX to track the first branch > > Because of that split, it seems like you really need to represent the > 'current branch' as a separate node in the tree, rather than making > the currently checked out branch just (only) visually distinct from > the others. I agree it's still sensible to make more clear in GitX > what branch you're on now. One way I can think of doing this is making > the commit view a bit prettier. Perhaps a big heading above the diff > view that just says "Committing on <branch name>" or something. It > could be really pretty with a gradient or whatever.
It seems to me you could get both supported just by using two forms of highlighting of branches in the sidebar: the main one (e.g. a normal colored highlight) indicating the current branch being viewed, and some additional icon or embellishment for the current branch for commits. In commit view, just omit the normal colored highlight. And obviously you can't give the embellishment to "meta" branches like "All branches", etc. How you switch branches is TBD, e.g.: 1. Right click and select "Commit on this branch" with a warning if you have uncommitted changes. 2. Keyboard/menu equivalent of this. 3. CLI-only, with auto-refresh instantly showing the change. This would also work well should you choose to allow users to Apple- select multiple branches for a custom combined history. > > This reflects my confusion regarding uncommitted changes. There is > > only one index, not one index per branch, so there is only one set of > > staged or unstaged changes. This set can be migrated from branch to > > branch, however. Which means selecting a different branch to commit > > on is a sensible option, but showing a per-branch set of "changes" > > isn't so helpful as I had assumed. > > I think the migration is more difficult than you think. You'd have to > create a patch with the current changes, and then just hope it applies > on the other branch. Then you'll have to decide what to show in the > case that it does not apply cleanly. And you can't really know if > it'll apply cleanly until you try it, as all the merge stuff in git is > done on the actual work tree. Hmmm, I thought git checkout did this for you (inasmuch as it could without conflict)?
