On Mon, Jan 12, 2009 at 6:33 AM, Doug Philips <[email protected]> wrote: > On or about Monday, January 12, 2009, at 01:16AM, Peer Sommerlund indited: >>Are you sure the commit tool should do it? >>How about calling the merge tool, starting with two files "no changes" and >>"all changes" and merging into the third file "selected changes" >> >>This saves a lot of developer time and gives the user a choice of gui >>(kdiff3 / winmerge / whatever). > > That is a very interesting and intriguing question. Where would the > uncommited changes "go" in this model? > > It is esp. interesting in the light of TK Soh being the maintainer for the > command-line shelve extension. :)
Even more interestingly, the shelve/unshelve support is done via the same hg-shelve extension in my experiment right now ;-) Actually, the plan to do eventually has hg-shelve included and maintained within TortoiseHg, which supports both the GUI and command line versions. > What if we had a TortoiseHG gui interface to shelve? Would that be better > than having a temporary shelve built-in to the internal commit tool? > What, if anything, should the various TortoiseHG GUIs do to show that there > are currently shelved changes? What are the other GUI's, beside commit and status? ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
