I'm gonna check out the git-portable package this weekend. So far, I've found the biggest annoyance is jumping between the 5-6 computers during the day... and forgetting to set a global config setting (*cough* my name, usually, and now this).
>From what I can see, the git-portable keeps everything happily local to that directory/jumpdrive. I don't need the Explorer context menu additions, so this would be ideal (if it works). :) -dl On Thu, Jul 23, 2009 at 7:54 AM, James Gregory <[email protected]>wrote: > I think I'll put together a contributing guide, because you're not the > first person to do this (and won't be the last!). > > > On Thu, Jul 23, 2009 at 1:45 PM, David R. Longnecker < > [email protected]> wrote: > >> Well, that answered my question before I even had time to ask. I noticed >> on my fork this morning that my commit went a bit out of control. Grabbing >> my changes again and reforking. >> >> Thanks for the hint. :) >> >> -dl >> >> >> On Thu, Jul 23, 2009 at 7:19 AM, Paul Batum <[email protected]> wrote: >> >>> Hi Dave, >>> >>> Rather than continuing this discussion on the issue item, I thought it >>> might be easier to use the mailing list. Tonight I pulled your changes, but >>> I've ran into problems. >>> Unfortunately it looks like your commit has unnecessarily touched alot of >>> files. I think you have your 'autocrlf' setting set incorrectly. You can >>> check your setting using: >>> >>> git config core.autocrlf >>> >>> You can set it to false using: >>> >>> git config core.autocrlf false >>> >>> With this setting set to true, the windows style line endings in our >>> files have been replaced with unix style line endings. Doh! At this point >>> the best course of action is: >>> >>> 1. Ensure your autocrlf is set to false >>> 2. Create another branch from the upstream >>> 3. Redo your changes on the new branch. Keep an eye on what files are >>> actually being changed. Given that your autocrlf will be off, there should >>> be far fewer changed files than from the last attempt. >>> 4. Reset your master to the new branch and then push to your github >>> repo. I'll pull it and let you know how it looks. >>> >>> Let me know if you get stuck! >>> >>> Paul Batum >>> >>> P.S James, if you're reading this and you think this can be explained >>> clearer please don't hesitate to do so. >>> >>> >>> >>> On Mon, Jul 13, 2009 at 7:36 AM, DaveW <[email protected]>wrote: >>> >>>> >>>> I've taken the approach of issues 256 and 257 and extended them on to >>>> allow the types of references (of all cardinalities - I hope) to be >>>> changed after the mapping has been defined, so it could be set up by a >>>> new ProxyConvention. Just instantiate it with a function that returns >>>> the proxy interface type for a given mapped entity class, and it >>>> should do the rest. >>>> >>>> The patch (attached to issue 256) is built against rev 539 of the >>>> subversion repo. >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
