On Friday 29 February 2008 8:29:07 am Otavio Salvador wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote: > >> Ian Jackson <[EMAIL PROTECTED]> writes: > >> > What I am trying to achieve is to use git in the proper way: that is, > >> > in a way which makes merging work properly. > >> > > >> > Insisting that I use git in a manner which makes merges break but > >> > gives prettier logfiles is absurd. > >> > >> That's why you should avoid using the branch as basis to others until > >> it's clean and also avoid to make it public (without a reason) too. > > > > This makes it more difficult to ask for review while the branch is in > > progress, which is a valuable property. It is ridiculous to artificially > > avoid making branches public; a branch is a useful means of > > collaboration and we should take advantage of it as such. > > I'm not saying that it couldn't be made public for review however I > suppose noone will ask for review if it's still at start of > development process.
The moment you commit a patch on the branch is the moment it potentially is interesting. Here's an example. I'm looking at evaluating Redmine, a web-based project management tool, sorta like *forge but smaller, easier, faster, and better. Redmine's SVN tree has integration with Darcs, Mercurial, etc. -- but not git. So someone made a Git branch of it that has Git support. This support will certainly be integrated into mainline at some point. Meanwhile, even if he is still working to refine it, it's useful to me to see it because I'd want Git integration. I understand the risks of running bleeding-edge code, and in this case maybe it's worth it, and maybe I'm interested in helping to test, too. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]