[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

On Friday 29 February 2008 8:29:07 am Otavio Salvador wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > On Fri, Feb 29, 2008 at 09:16:59AM -0300, Otavio Salvador wrote:
> >> Ian Jackson <ian@davenant.greenend.org.uk> 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 

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 

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

Reply to: