On Tue, Jan 27, 2009 at 4:33 AM, Peter Ruibal <[email protected]> wrote: > On Sat, Jan 24, 2009 at 7:21 PM, Steve Borho <[email protected]> wrote: >> >> On Sat, Jan 24, 2009 at 1:46 PM, Steve Borho <[email protected]> wrote: >> > On Fri, Jan 23, 2009 at 11:37 PM, Douglas Philips <[email protected]> wrote: >> >> It is definitely useful/desirable to be able to see both the to-be- >> >> committed and to-be-shelved chunks in situ side by side. >> >> Maybe a "hide shelved" and "hide commitable" (names are hard) check >> >> boxes? >> >> I've checked in a change that adds a 'Show Rejected Chunks' to the top >> of the diff frame. It toggles the rejected patch chunks between >> strike-through and not-visible. I think this improves the intention >> of the rejected chunks (leaving them out of the commit or shelving >> operation). >> >> I still would like to show the contents of the shelf patch as well, >> but am not certain of the best way to show them. Mixing them with >> changes in the working directory could be quite confusing (the file >> list and states could conflict, for starters). >> >> Please have a look. >> http://bitbucket.org/sborho/thg-crew-steve/ > > > A couple of things: > > - Part of my changeset adds a file, but this isn't handled very well > (permanent invisibility!) -- new / deleted files should be treated as one > big hunk, no?
There's two reasons for this: 1) Change selection cannot work on added or removed files, so there's not much to be gained by showing that patch content (other than filling vertical screen space). 2) Putting large changes in that treeview widget is _slow_. It takes a long time to fill, and it scrolls very clunkily. This is a GTK problem. > - I've been able to completely freak out the visibility / strikethrough > (getting the fileheader to disappear or get crossed out) ... had a huge > patch applied to the tip, and kept messing with the selected hunks and "Show > rejected hunks" checkbox in all kinds of ways, which might explain it. If you can figure out how to reproduce it, let me know. > - Other than that, the current usage model is a little confusing to me : > -- Right now you have to pick all of the changesets you want to commit -- > but double clicking causes them to disappear or be crossed out (as if you're > not going to commit them) -- then you click 'shelve' to swap the changes > you've hidden with the ones you haven't -- the treeview on the left now > updates -- your hidden changes magically re-appear for commit. These are two different functionalities. You don't have to shelve changes to have them left out of the commit. The verbiage is confusing. Commit and shelve both operate on the set of non-rejected changes. So when you hit the shelve button it takes the non-rejected changes and puts them in the shelf, then you're left with just the rejected changes in your working directory. The same thing would have happened if you had committed, except the non-rejected changes would be a changeset, not the shelf. I think it's the fact that both buttons are visible which is confusing. I'm tempted to hide the shelve button when in commit mode, and rename the 'status' dialog 'shelve'. That way it's explicit that you are selecting (rejecting) patches for a commit or the shelf. > -- The luser in me gets a little confused by this behavior.. Consider the > following usage model: > > User opens commit dialog. > Treeview: > De-Selection of a file on the treview causes all corresponding hunks on > the right to automatically update with a strike-through or as disabled or > hidden. As happens now. > Selection of the file on the treeview causes all hunks to appear or be > enabled and have no strikethrough As also happens now > Diff/Chunk Viewer > Selecting and unselecting a mixture of hunks within a single file causes > the checkbox on the treeview for that file to be marked as 'inconsistent' there's a TODO to add a way to visualize files which are partially rejected. I'm thinking about greying the filename text or something. Have a better idea? > Manually enabling or disabling all hunks for a file causes the > corresponding checkbox to appear as selected or de-selected appropriately Should also be happening now. > Commit: > pressing commit transparently shelves all disabled (strikethrough) > chunks, commits the remaining, and then unshelves and enables the remaining > chunks That is what it does now, except this is done via record type functionality. The working copy of each file is saved off, the file is reverted, then the un-rejected patches are re-applied to it. After the commit, the originals is returned. The shelf is untouched by the commit/record. > I think this model is a little more intuitive and easier for newbies to > pick up, and doesn't require any buttons to be added to the toolbar. > > Some work would need to be done to ensure that the temporary Shelve used by > hgtk then, does not conflict with any shelve presently in use by the user > (manually at the command line) Exactly, it doesn't today but it looks like it does because both buttons are visible at the same time. > Does anyone else agree with me here, or am I just crazy? I think we agree. -- Steve ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
