On Fri, Sep 18, 2009 at 11:10 PM, JDS <[email protected]> wrote: >> * 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.
That doesn't seem very clear. I've never seen a program use two different highlights before. It also doesn't solve the problem that you want to select something that means 'follow the curretn branch, even if it changes', which won't be possible unless you explicitly add something in the tree for that. > 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. It's already possible to switch branches by right-clicking on a branch label and selecting 'checkout branch', which I'll also add to the sidebar. > 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)? git checkout by default will only checkout another branch if the changed files in your working directory aren't changed between the current HEAD and the branch you're switching to. That's just a very small percent of the times you want to switch branches. Otherwise you have to specify the -m, after which you can't be sure if it'll produce conflicts or not. I'm not sure why we should support committing on a different branch? I've never heard anyone complain about that, and it completely contradicts how the rest of git works. That just doesn't seem like a good idea, and IMHO we should just keep to the 'commit on the current branch' way that we already have.
