On Tue, Feb 3, 2009 at 5:10 PM, Steve Borho <[email protected]> wrote: > On Tue, Feb 3, 2009 at 10:04 AM, Peter Arrenbrecht > <[email protected]> wrote: >> On Sat, Jan 31, 2009 at 6:16 AM, Steve Borho <[email protected]> wrote: >>> On Fri, Jan 30, 2009 at 11:50 AM, Steve Borho <[email protected]> wrote: >>>> On Fri, Jan 30, 2009 at 9:59 AM, Peter Arrenbrecht >>>> <[email protected]> wrote: >>>>> On Fri, Jan 30, 2009 at 6:40 AM, Steve Borho <[email protected]> wrote: >>>>>> I've pushed a new rename dialog to my thg-crew-steve repository on >>>>>> bitbucket. It's >>>>>> currently only reachable via 'hgtk guess'. It is a GUI interface to >>>>>> Mercurial's addremove >>>>>> command with a couple of twists: >>>>>> >>>>>> * The list of renames that hg detects is presented for your review >>>>>> (these are pairs that >>>>>> hg would have declared rename source and destination). From this list >>>>>> you can examine >>>>>> diffs from the source to the destination and if you agree with the >>>>>> matches you 'accept' them. >>>>> >>>>> In a highly modularized Java project path names can get painfully >>>>> long. And the really differentiating part of the name is at the end. >>>>> So a general mode (not just for renames) that shows the _end_ of a >>>>> path when space is insufficient would be very useful. This mode would >>>>> likely have to be configurable on a per-repo basis. >>>> >>>> I can turn on elipsized paths in general, I think. I'll give this a try. >>>> >>>> This brings up another point, we probably want to be able to provide >>>> file patterns to the copy detection routine. >>> >>> I've pushed this change and the 'AR' support to my repo. Other than >>> known performance issue (the whole dialog needs to be threaded), >>> let me know if you spot any problems with it. >> >> Do I need to enable ellipsized paths somehow? > > No, it should be enabled by default. I assume you've pulled from me > recently? Are you running on Linux or Windows?
Up to 9a9e4fe2ac0b, which I thought would suffice. But I'll try later with a more recent pull. I'm on Ubuntu 8.10: Linux sapient 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux >> And it seems that when I have recorded a rename, the commit dialog >> cannot show the diff hunks anymore (git-style diffs are active). It >> does tell me about the rename and how many hunks there are, but does >> not show the hunks themselves. > > This is somewhat by design as it doesn't show diff hunks for 'special' > patches. > It probably has to broad of a definition of what constitutes a special > patch, but > I thought rename targets were by definition new (added) files, and > thus the patch > would have the entire file contents. Hmm. It could show the diff against the file it was before the rename. This is, I believe, what `hg diff` does. Would be extremely nifty if I could then even deselect hunks, so the commit would do the rename, but not all of the changes in the renamed file. But even without deselecting hunks it would be helpful to see the diff. -parren ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
