> > Ideally, you would be able to select a branch either for viewing, or > > for committing on. Obviously, you can't commit to tags or "All > > branches" so we'd need some way to discriminate these. One sensible > > option would be to indicate via another icon, color, or both in the > > sidebar that a branch has staged/unstaged changes that *can be > > committed*. Tags and remotes, etc. would obviously never have this > > indication. Only one branch can have unstaged changes.[1] > > I think one thing that we have wrong currently is that we don't > represent the 'currently checked out branch' in any way. The HEAD is a > very important concept in git, as you can only commit (sanely) on the > current branch. It'll be very hard to implement committing on an > alternative branch.
The HEAD branch is shown in the title, but there is no way to change it inside of GitX. It's confusing for it to say "(branch: master)" in the title, while you peruse the history of another branch. Is there a reason GitX cannot switch HEAD, for instance by issuing git checkout branch when a new branch is selected for committing (exactly *how* to make that selection is debatable -- see below)? > Similarly, you would want an option in GitX where you always see the > current branch, so that if you switch branches and refresh, the view > would show the new branch, rather than still displaying the old branch > (as is currently the case -- start gitx, switch a branch, and it'll > still show master). > > If we can represent this current branch in some way in the tree view, > we might be able to attach the commit view to that in some way -- for > example by showing a batch with 'commit...' in it, or a small arrow > pointing right, like the arrows in iTunes that bring you to the store. That's a decent idea. I'm still not sure why we can't select other branches to commit on, though I agree making it too easy might cause confusion. > I'm not at all sure about this, but my gut feeling is that it should > be possible to represent these concepts in the tree. > > > When such a "commitable" branch is selected, an single toggle icon -- > > "Commit/View" -- is enabled (disabled for branches without changes). > > If you are already in commit view, selecting another commitable branch > > just changes the target for commits (and the staged changes on that > > branch are updated, etc.). If you have unstaged changes on the > > current branch, you will be warned that they would be lost, and > > prompted whether to continue (which would invoke checkout -f).[1] > > You would have to switch branches for that to work. I think in that > case you'll cause confusion between two different actions: committing > and switching. I'm not sure people will understand why they suddenly > changed branches just because they went to the commit view, but didn't > actually commit anything. I can see that as a concern. Some indicator in the tree to show you which branch you are committing on would help here. This could be moved for example by right-clicking and selecting "Switch to branch for commit" or some-such. I.e. they don't switch branches unless they go out of their way to do so. > > Another related and useful metaphor would be to show a notional > > history element for staged + unstaged changes directly at the top of > > the history graph (with a special color), allowing you to double click > > them to switch to commit view. Again, these would only appear on true > > "commitable" branches. > > I guess, gitk does something similar. Being able to view the current > changes without switching to the commit part is probably very useful. > I'm not sure what to do with those changes though. Doubleclicking > doesn't seem very intuitive, but perhaps a button in the detailed > part? It all sounds a bit icky to me. Especially if you only want to > commit new files, so there is no 'local changes' item in the 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. JD
