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
------------------------------------------------------------------------------
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/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
