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/
>
> --
> 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
>
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?
- 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.
- 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.
-- 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.
Selection of the file on the treeview causes all hunks to appear or be
enabled and have no strikethrough
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'
Manually enabling or disabling *all *hunks for a file causes the
corresponding checkbox to appear as selected or de-selected appropriately
Commit:
pressing commit transparently shelves all disabled (strikethrough)
chunks, commits the remaining, and then unshelves and enables the remaining
chunks
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)
Does anyone else agree with me here, or am I just crazy?
--
Peter
------------------------------------------------------------------------------
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
