On Wed, Apr 9, 2008 at 1:47 PM, Ted Pavlic <[EMAIL PROTECTED]> wrote: > >> Either that or make "update to new tip" mean something different when "do > > > > Maybe "update to new tip pulled" will be slightly less confusing? > > How about "update after pull" ? And make it mutually exclusive with "do > fetch". > > Then it's absolutely clear what's going on. And, because they're > mutually exclusive, it should be clear to me that "fetch" merges if > needed and "update after pull" does it.
"update after pull" may imply an update will take place after pull is completed, regardless of whether anything new has been pulled. From hg help, --update mean "update to new tip if changesets were pulled". My suggestion of "update to new tip pulled" is meant to be a shorter version of that. > > I originally wanted to make "Fetch" a button by itself, but later > > decide on making it an option of Pull instead, since functionally it's > > a extension of pull. But after reading what you said, maybe having a > > Fetch button will be better. > > I think that "fetch" is a loaded term because the execution flow is very > different based on what happens after the pull. That's why it might be > nice to have it as an extension. That being said, I'd be OK with the > wording change mentioned above. The term "fetch" is taken literally from the Fetch extension bundled with Mercurial. It was added in response to a feature request. I was assuming most user should be aware of it. Perhaps it was the wrong assumption to make. The addition of 'do fetch' was a somewhat quick-n-dirty hack. First of all, it was easy to do. Second, that way I don't have to worry about what Fetch actually does. It's left as a homework for user to figure out how Fetch behave. Maybe we should reconsider the design on this aspect. Any suggestions? > Additionally, is there a way to change what's checked by default? It > would be nice if I could configure "do fetch" to be checked by default. > In projects where "pushes" to a central repository only come from one > user, but "pulls" go to lots of people, "fetch" will be much more often > used than "pull." (especially if those people are new to Mercurial) It's our plan to try to make some of the options 'sticky'. We just haven't come to that item on the rather lengthy TODO list. > >> The little "update to tip" button that shows up in the bottom of > >> Synchronize provides an easy way to deal with the "problem" of having to > >> update before fetch. However, especially because of the similarities in > the > >> wording, it's easy to overlook. > > > > Any suggestion of improving the design on the buttons, in terms of > > layout, wording, etc? > > Again, I think changing the "update to new tip" to something like > "update after pull" to be a good one. > > The button placement of "Update to Tip" at the *bottom* of the screen > was difficult for me to notice at first. My eyes were focussed at the > top of the window with all of the other buttons. I figured the bottom of > the window was only for status. I had the same feeling when I saw the buttons for the first time (it was added by Steve). But since I can't think of a better place for them, it's best for me to just let it be. > Because those "Update to Tip" buttons only show up in special cases, it > might be nice to have them drop out of the button bar (like how Firefox > (at least the beta) drops its "Are you sure?" type messages out of its > button bar at the top of the view window). I just need something to draw > my attention to them. I am not sure I get the picture. Perhaps you can help clarify more. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
