Hi,
      
      I use git pretty much exclusively, and maintain a git mirror of
      LSMB here:
      
      * Browse at: 
http://git.freelock.com/?p=ledgersmb.git;a=summary
      * Clone from: git://git.freelock.com/git/ledgersmb.git
      
      This repo automatically updates from the SVN master every 6 hours,
      so it should be quite up to date. Occasionally if I'm trying to
      address something specific I'll do a manual update more often...
      
      I'd be happy to move this repo to Github if people would prefer --
      and I probably will if a lot of people start using it. I'm sure I
      could set up our current update script to update a copy at
      Github...
      
      I've been using this setup for years now, and have had no issues
      whatsoever related to working with the project. I generally use
      git diff to generate patches and then email those to Chris or Erik
      for review/commit to SVN -- when I sent some patches via git
      format-patch, Chris had trouble applying it, so since then I've
      stuck to manually generating patch files and sending them as
      attachments.
      
      So while I'm definitely in favor of a move to github or
      equivalent, I don't think it's important enough to disrupt the
      current productivity of the core developers. And I'm not feeling
      like there's anything more necessary to facilitate git users -- as
      Jeff mentioned, git svn seems to work reasonably well if you do
      want to commit directly to svn...
      
      Cheers,
      John
      
      
      
      On 09/05/2012 06:57 AM, Ed W wrote:
    
      
      Hi
      
      So with those thoughts in mind I want to ask two
        basic questions:
        
        1)  For git users, what do we need to do today to make use of
        git with LedgerSMB more pleasant?
      
      
      Simply that a well maintained Git repo is available and clearly
      documented that there is a commitment to remain up to date (eg
      it's implemented in an automatic fashion)
      
      For mild preference I would like the git repo hosted somewhere
      that encourages forks to remain visible, eg Github.  However,
      there is a whole new can of worms by suggesting that, so I will
      leave that as a separate suggestion.
      
      
      2)  For those who currently use git what sorts of
        processes can we have today, without moving currently, that will
        help you get more out of using git with ledgersmb?  This is an
        important one because even if we move in the future, it isn't
        clear we'd entertain direct pull requests.  We might use git
        just to make it easier for people to maintain mini-forks and
        share features between such.  (My understanding is this is
        largely how PostgreSQL uses it for main development, and my
        guess is that virtually all patches still come in via email.)
      
      
      Opinion is divided on whether pull requests are that useful. 
      Linux kernel takes external contributions via email and that is
      what the "git am" command is for.  Possibly this is something  you
      currently feel requires a script for svn users to implement
      correctly, but under git there should be no need, eg you might
      develop like this:
      
      // Make feature branch
      git checkout master -b my_fork
      
      // do some work...
      // ...
      git commit
      // do some work...
      // ...
       git commit
      // rinse, repeat, etc
      
      // Now, assuming master has moved on, ensure that our patches
        apply perfectly to HEAD
      git fetch
      git rebase master
      
      // Submit patches
      // Generate complete email:
      
      
      git format-patch -1 -s
      // or send the emails as well:
      
      
      git send-email
      
      
      You the developers can apply patches using either git-am or
      git-apply (am reads the patches right out of a mail file, apply
      assumes you saved them to disk first).
      
      So, yes, email is probably the simplest way to accept new patches
      with git, however, one of the nice things about public git hosting
      (especially github/gitorious) is that you have the option to "poke
      around" and do a git-pull or git-cherry-pick if appropriate.  I
      personally rarely git-pull stuff though unless I very much trust
      the upstream - mostly I work with patches
      
      
      Oh, final useful thing is maintaining git-branches and git-tags
      that correspond with the actual releases.  This should come across
      automatically from SVN, but just highlighting it's a nice to have
      
      
      Cheers
      
      Ed W
      
      !DSPAM:50475a8c313569016576474!
      
      
      
      ------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
!DSPAM:50475a8c313569016576474!
      
      
      
      _______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
!DSPAM:50475a8c313569016576474!