On Thu, Sep 10, 2009 at 12:30 AM, JDS<[email protected]> wrote: > 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.
You can right-click on a branch label in GitX, and select "checkout branch". This should obviously be applied to the sidebar now. > 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)? That could be done, but you have to make sure that the dirty changes can be applied on the new branch. You can never know that for sure in advance. >> 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. Switching branches can be annoying for a number of reasons. You can have changes, in which case it fails, but it can also be that you have an untracked file in your current branch, which would be overwritten by an already tracked file in the branch you're switching to. Stuff like that can go wrong in a number of ways, so switching branches really should be something a user wants to do himself. >> 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. Perhaps we can move the currently checked out branch from the 'branches' head to somewhere else (on top)? That way you'd have a visual distinction of which branch is checked out. 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. >> 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. 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.
